Add USB to MPC8349 PB platform support

This adds USB platform support to MPC8349 PB. It works with the fsl_usb2_udc driver.

Signed-off-by Li Yang <[email protected]>

---

arch/powerpc/platforms/83xx/Kconfig       |   4  ++
arch/powerpc/platforms/83xx/mpc834x_sys.c |   72 +++++++++++++++++++ 
++++++++++
arch/powerpc/platforms/83xx/mpc834x_sys.h |   24 ++++++++++
3 files changed, 113 insertions(+), 0 deletions(-)

arch/powerpc/platforms/83xx/Kconfig +4 -0

index 7675e67..8404cdf 100644
@@ -24,4 +31,14 @@ config MPC834x
 	select PPC_INDIRECT_PCI
 	default y if MPC834x_SYS
 
+config 834x_USB_SUPPORT
+	bool
+	default y if MPC834x_SYS && (USB || USB_GADGET)
+	

endmenu

arch/powerpc/platforms/83xx/mpc834x_sys.c +70 -0

index 7e789d2..f10d4ae 100644
@@ -36,6 +36,7 @@ #include <asm/irq.h>
 #include <asm/prom.h>
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>
+#include <linux/fsl_devices.h>
 #include "mpc83xx.h"

@@ -71,6 +72,72 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
 }
 #endif				/* CONFIG_PCI */
+#ifdef CONFIG_834x_USB_SUPPORT
+void mpc834x_usb_board_cfg(void)
+{
+	unsigned char __iomem *bcsr;
+	volatile unsigned char *bcsr5_p;
+
+	/*
+	 * if SYS board is plug into PIB board,
+	 * force to use the PHY on SYS board
+	 * */
+	bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+	bcsr5_p = bcsr + BCSR5_OFF;
+	if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
+		*bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
+	iounmap(bcsr);
+}
+
+/* Note: This is only for PB, not for PB+PIB
+ * On PB only port0 is connected using ULPI */
+static int mpc834x_usb_cfg(void)
+{
+	unsigned long sccr, sicrl;
+	volatile unsigned long *p;
+	unsigned long __iomem *immap;
+	struct device_node *np = NULL;
+	int port0_is_dr = 0;
+
+	if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-dr")) !=  
 NULL)
+		port0_is_dr = 1;
+	if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-mph")) !=  
 NULL){
+		if (port0_is_dr) {
+			printk(KERN_WARNING
+				"There is only one USB port on PB board! \n");
+			return -1;
+		} else if (!port0_is_dr)
+			/* No usb port enabled */
+			return -1;
+	}
+	
+	immap = ioremap(get_immrbase(), 0x100000);
+	
+	/* Configure clock */
+	p = (volatile unsigned long *)((u32)immap + MPC83XX_SCCR_OFFS);
+	sccr = *p;
+	if (port0_is_dr)
+		sccr |= MPC83XX_SCCR_USB_DRCM_11;  /* 1:3 */
+	else
+		sccr |= MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
+	*p = sccr;
+
+	/* Configure Pin */
+	p = (volatile unsigned long *)((u32)immap + MPC83XX_SICRL_OFFS);  
+	sicrl = *p;
+	/* set port0 only */
+	if (port0_is_dr) +		sicrl |= MPC83XX_SICRL_USB0;
+	else +		sicrl &= ~(MPC83XX_SICRL_USB0);
+	*p = sicrl;
+	
+	iounmap(immap);
+	return 0;
+}
+
+#endif /* CONFIG_834x_USB_SUPPORT */
+
 /* ************************************************************************
 *
 * Setup the architecture

@@ -102,6 +169,11 @@ #ifdef CONFIG_PCI
 	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
+#ifdef CONFIG_834x_USB_SUPPORT
+	mpc834x_usb_cfg();
+	mpc834x_usb_board_cfg();
+#endif
+
 #ifdef  CONFIG_ROOT_NFS
 	ROOT_DEV = Root_NFS;
 #else

arch/powerpc/platforms/83xx/mpc834x_sys.h +23 -0

index fedecb7..30e45e8 100644
@@ -20,4 +20,28 @@ #define PIRQB	MPC83xx_IRQ_EXT5
 #define PIRQC	MPC83xx_IRQ_EXT6
 #define PIRQD	MPC83xx_IRQ_EXT7
+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
+#define BCSR_SIZE		((uint)(32 * 1024))
+ +#define BCSR5_OFF		0x05
+#define BCSR5_INT_USB		0x02
+
+#define MPC83XX_SCCR_OFFS          0xA08
+#define MPC83XX_SCCR_USB_MPHCM_11  0x00c00000
+#define MPC83XX_SCCR_USB_MPHCM_01  0x00400000
+#define MPC83XX_SCCR_USB_MPHCM_10  0x00800000
+#define MPC83XX_SCCR_USB_DRCM_11   0x00300000
+#define MPC83XX_SCCR_USB_DRCM_01   0x00100000
+#define MPC83XX_SCCR_USB_DRCM_10   0x00200000
+
+/* system i/o configuration register low */
+#define MPC83XX_SICRL_OFFS         0x114
+#define MPC83XX_SICRL_USB0         0x40000000
+#define MPC83XX_SICRL_USB1         0x20000000
+
+/* system i/o configuration register high */
+#define MPC83XX_SICRH_OFFS         0x118
+#define MPC83XX_SICRH_USB_UTMI     0x00020000
+
+
 #endif				/* __MACH_MPC83XX_SYS_H__ */
 

Nack, my expectation is this is all setup by the boot loader.

- k

Quoted 5 lines · Li Yang

This adds USB platform support to MPC8349 PB. It works with the fsl_usb2_udc driver.

Signed-off-by Li Yang <[email protected]>

---

Quoted 1 line · Kumar Gala

Nack, my expectation is this is all setup by the boot loader.

That's a good wish. ;) However, USB is not required by bootloader. So it is not likely to be initialized there. And if we put it in bootloader, it will be hard to change the mode(MPH/DR), which requires a re-burn of bootloader. It's better that we make sure it's correctly configured here.

Quoted 8 lines · Li Yang

Quoted 1 line · Kumar Gala

Nack, my expectation is this is all setup by the boot loader.

That's a good wish. ;) However, USB is not required by bootloader. So it is not likely to be initialized there. And if we put it in bootloader, it will be hard to change the mode(MPH/DR), which requires a re-burn of bootloader. It's better that we make sure it's correctly configured here.

I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well.

Seems to me that it's far better to have init code in the kernel than firmware.

For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code than firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future.

-Hollis

-----Original Message-----
From: David Brownell [mailto:[email protected]]
Sent: Tuesday, July 18, 2006 6:58 AM
To: [email protected]
Cc: Hollis Blanchard; Kumar Gala; [email protected]; Li

Subject: Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform

Quoted 2 lines

Seems to me that it's far better to have init code in the kernel

Quoted 1 line

firmware.

If there's a general Linux policy on the issue, I think that'd be it.

Plus, remember that boot firmware _can't_ always be changed/bugfixed; sometimes it can, but not as a general rule.

- Dave

Quoted 2 lines

For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code

Quoted 5 lines

firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future.

-Hollis

Seems to me that it's far better to have init code in the kernel than firmware. For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code than firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future.

Quoted 5 lines · Hollis Blanchard

Seems to me that it's far better to have init code in the kernel than firmware. For one example, look at the x86 video card init problem PowerPC Linux has. It's also far easier to fix/deploy Linux code than firmware code, as Li observed, and on top of that it's less work for non-UBoot firmwares in the future.

I also agree 100%. The boot loader should only be required to initialize whatever hardware it uses. The kernel should be required to initialize whatever hardware it supports. The kernel should not assume that USB or PCI or whatever has already been initialized by the boot loader. This doesn't happen on x86, so we should it happen on PPC?

I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well.

Quoted 4 lines · Kumar Gala

I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well.

Well, I'm going to have to disagree with your disagreement :-) The kernel should not assume things are properly initialized and rely on the boot rom to do such things. I have several reasons for this. One is that we are always pressed to make embedded systems boot more quickly, and taking time to initialize things in the boot rom just makes that a totally inflexible system design. We don't need to initialize things we don't use, or can postpone until later. Two, it makes us dependent upon a particular boot rom, or boot rom behavior, that not all boards may choose to support. Three, board designs may have external logic that requires a certain start up sequence or control register access that complicates the boot rom in it's ability to share code or implementation.

There are more, but I think you see the trend. In my years of doing this kind of development, you can't assume a boot rom is going to do much more than initialize memory and load the kernel. I prefer the flexibility to be in the kernel, and not in the boot rom, because it is so much easier to develop and control.

Well, I think there is a coupling that exists between whatever your boot rom is and the kernel.

If you are trying to optimize boot time I'd say one thing you would want is to avoid multiple writing the same configuration registers.

I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the various ways one can configure the Freescale board.

-----Original Message-----
From: Kumar Gala [mailto:[email protected]]
Sent: Tuesday, July 18, 2006 5:39 AM
To: Dan Malek
Cc: Li Yang-r58472; [email protected];

Subject: Re: [PATCH] Add USB to MPC8349 PB platform support =20
=20
On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
=20

Quoted 8 lines · Kumar Gala

Quoted 5 lines

I disagree. You are coming from this from a board that does everything under the sun. I'd like to avoid having this type of initialization in the kernel. There is a whole additional kitchen sink that could move into the kernel as well.

Quoted 14 lines

Well, I'm going to have to disagree with your disagreement :-) The kernel should not assume things are properly initialized and rely on the boot rom to do such things. I have several reasons for this. One is that we are always pressed to make embedded systems boot more quickly, and taking time to initialize things in the boot rom just makes that a totally inflexible system design. We don't need to initialize things we don't use, or can postpone until later. Two, it makes us dependent upon a particular boot rom, or boot rom behavior, that not all boards may choose to support. Three, board designs may have external logic that requires a certain start up sequence or control register access that complicates the boot rom in it's ability to share code or implementation.

=20
Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. If you are trying to optimize boot time I'd say one thing you would want is to avoid multiple writing the same configuration registers.
=20
I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the various ways one can configure the Freescale board.

=20

Quoted 6 lines

There are more, but I think you see the trend. In my years of doing this kind of development, you can't assume a boot rom is going to do much more than initialize memory and load the kernel. I prefer the flexibility to be in the kernel, and not in the boot rom, because it is so much easier to develop and control.

=20
- kumar

Quoted 5 lines

Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. If you are trying to optimize boot time I'd say one thing you would want is to avoid multiple writing the same configuration registers.

Quoted 4 lines

I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the various ways one can configure the Freescale board.

We won't have the thousand and one config options, making use of the device
tree. So this is not a problem.

..... I'm concerned about where to draw the line because of all the ways a user can configure the MDS board.

I'm talking about opening the door to a ton of options, not that we have them now. For example, your patch doesnt handle the USB PHYs if

-----Original Message-----
From: Kumar Gala [mailto:[email protected]]
Sent: Tuesday, July 18, 2006 9:53 PM
To: Li Yang-r58472
Cc: Dan Malek; [email protected];

Subject: Re: [PATCH] Add USB to MPC8349 PB platform support =20
[snip]
=20

Quoted 2 lines

Quoted 2 lines

Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. If you are trying to optimize boot

Quoted 6 lines

Quoted 6 lines

I'd say one thing you would want is to avoid multiple writing the same configuration registers.

I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the

Quoted 5 lines

Quoted 1 line

ways one can configure the Freescale board.

We won't have the thousand and one config options, making use of the device
tree. So this is not a problem.

=20
I'm talking about opening the door to a ton of options, not that we have them now. For example, your patch doesnt handle the USB PHYs if they are on the MDS instead of the SYS board. It doesn't handle setting SCCR properly for different frequency choices. I'm concerned about where to draw the line because of all the ways a user can configure the MDS board.

=20
- kumar

Quoted 5 lines

-----Original Message-----
From: Kumar Gala [mailto:[email protected]]
Sent: Tuesday, July 18, 2006 9:53 PM
To: Li Yang-r58472
Cc: Dan Malek; [email protected];

[email protected]

Quoted 6 lines

Subject: Re: [PATCH] Add USB to MPC8349 PB platform support

[snip]

Quoted 2 lines

Quoted 2 lines

Well, I think there is a coupling that exists between whatever your boot rom is and the kernel. If you are trying to optimize boot

time

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

I'd say one thing you would want is to avoid multiple writing the same configuration registers.

I dont have an issue if a fixed function board decides to do these things in their kernel init instead of their boot rom. I however, don't want thousand and one config options to support all the

various

Quoted 6 lines

Quoted 5 lines

Quoted 1 line

ways one can configure the Freescale board.

We won't have the thousand and one config options, making use of the device
tree. So this is not a problem.

Quoted 6 lines

I'm talking about opening the door to a ton of options, not that we have them now. For example, your patch doesnt handle the USB PHYs if they are on the MDS instead of the SYS board. It doesn't handle setting SCCR properly for different frequency choices. I'm concerned about where to draw the line because of all the ways a user can configure the MDS board.

My understanding is that in embedded world only this kind of versatile development boards needs to have Linux port in mainstream kernel. A fixed function customer board used in embedded product will never get into kernel source.

The reasons for Freescale to provide this kind of boards are: first, verify functions on chip; second, demonstrate chip functions to customer; third, validate customer application on reference board; forth, help customer to build their own product by cutting down the board and software.

Doing that, we do need some configure options to demonstrate main functions. But there won't be too many options to confuse the user. Only key working modes are needed. In your example, I think making USB PHYs configurable for MDS is reasonable, but for SCCR it isn't as it is well commented in code and is not likely to be modified. Keep in mind that our only purpose is making customers easier and faster in developing their own products.

This is an incorrect assumption. Its more often that people dont post their ports to the Linux kernel for acceptance. We will accept any port that is willing to work with the community. for example

Quoted 4 lines · Kumar Gala

This is an incorrect assumption. Its more often that people dont post their ports to the Linux kernel for acceptance. We will
accept any port that is willing to work with the community. for
example

I agree. The customers of board ports I've done over the years are always eager to get these into the public sources. It just seems we run out of time during the pressure of trying to get the products done, and they just issue them on CDs or for download afterward.

But why? Most embedded products facing end-user wouldn't like users to modify the system by themselves.

Sometimes they even put effort in preventing user to do so.

The only kind of products I can think of, which want the users to modify the code is reference boards, IMHO.

-----Original Message-----
From: Pete Zaitcev [mailto:[email protected]]
Sent: Thursday, July 20, 2006 3:19 AM
To: Li Yang-r58472
Cc: [email protected]; [email protected];

[email protected]; [email protected]
Subject: Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform

=20
On Thu, 20 Jul 2006 02:59:44 +0800, "Li Yang" <[email protected]>

=20

Quoted 2 lines

But why? Most embedded products facing end-user wouldn't like users to modify the system by themselves.

=20
Certainly vendors won't like to give consumers extra freedoms. However, consumers like those freedoms, even if they would not use them in any specific instance.
=20

Quoted 1 line

Sometimes they even put effort in preventing user to do so.

=20
Jerks and criminals, that's what they are. Why would Linux developers care about needs of these people?
=20
Free software is about protecting the rights of users against vendors who "wouldn't like" users doing what they want with the product they bought.
=20

Quoted 2 lines

The only kind of products I can think of, which want the users to modify the code is reference boards, IMHO.

=20
Ever heard of WRT54? But in fact, every product out there may provide its owner an additional value when customized. I'd love to fix some bugs in my microwave, for instance. The silly thing will not start the timer if the door is open. It probably uses the same function which prevents cooking from starting (it also has a hardware interlock that cuts the magnetron, but this is different).

Quoted 8 lines · Dan Malek

Quoted 4 lines · Kumar Gala

This is an incorrect assumption. Its more often that people dont post their ports to the Linux kernel for acceptance. We will
accept any port that is willing to work with the community. for
example

Quoted 5 lines

I agree. The customers of board ports I've done over the years are always eager to get these into the public sources. It just seems we run out of time during the pressure of trying to get the products done, and they just issue them on CDs or for download afterward.

But why?

Most embedded products facing end-user wouldn't like users to modify the system by themselves. Sometimes they even put effort in preventing user to do so. If no one else is going to modify the code, what is the value of putting them in public sources? Just to show the compliance with GPL? The only kind of products I can think of, which want the users to modify the code is reference boards, IMHO. Please correct me if I'm wrong.

I agree. The customers of board ports I've done over the years are always eager to get these into the public sources. It just seems we run out of time during the pressure of trying to get the products done, and they just issue them on CDs or for download afterward.

Having my changes for our boards that are very specific since they are connected to FPGAs would IMHO serve little purpose in the Linux kernel:
there is very limited access to the hardware and it would only serve to clutter the kernel with an exponentionally growing number of ports that most ppl will never use. I think (even though using ARCH and CROSS_COMPILE during compilation limits the audience); the target audience between U-Boot and the Linux kernel is slightly different.

Though I do agree that there is a gap: it would be nice to have some place to submit the kernel patches; possibly not included in the main tree; just to see how other ppl are tackling the same problem and avoiding re-doing the same work for the nth time (e.g. writing some communciation protocol where there are a number of references of ppl haveing done them, but no real code).

Quoted 2 lines

Though I do agree that there is a gap: it would be nice to have some place to submit the kernel patches;

This should be the kernel. The general rule of thumb I've used is if its useful to more than one other person its worth trying to get into the kernel. However, I can see if you are doing a one off kernel for

your embedded product that getting your changes into the kernel wouldn't be worth while. You have to have a desire to interact with the community if you want to get your code in.

Personally, I see it useful if for no other reason that someone will fixup my board port if/when they change something which will make my moving to a newer kernel release that much easier.

Quoted 6 lines

Quoted 2 lines

Though I do agree that there is a gap: it would be nice to have some place to submit the kernel patches;

This should be the kernel. The general rule of thumb I've used is if its useful to more than one other person its worth trying to get into the kernel. However, I can see if you are doing a one off kernel for

That is about the same rule that I use; luckily (a credit to the Linux kernel and other developers); I don't have to change much stuff like that.

Quoted 3 lines

your embedded product that getting your changes into the kernel wouldn't be worth while. You have to have a desire to interact with the community if you want to get your code in.

There is a grey zone, but let's talk about a specific case:

In my current queue, I have to write a Host Port Interface (HPI) protocol (serial) to a TI DSP. I would imagine that this is a useful contribution. However, using HPI is almost by nature limited to specific embedded designs (most of which differ slightly from one another). Furthermore; I will need to use a number of GPIO pins on a 834x processor. Using this needs to be backed by configuration settings in U-Boot. If someone else makes a similar design; it would most likely be with another processor family; and even then; they'll have other pins connected/used.

Though the protocol would be a real nice addition; the physical connection/configuration make including it in the main kernel tree difficult.

Quoted 3 lines

Personally, I see it useful if for no other reason that someone will fixup my board port if/when they change something which will make my moving to a newer kernel release that much easier.

Even though I would welcome this; our boards are included in larger expensive systems that would just be shipped back in case of problems; but we've never had functional (linux) problems (yet).

Come to think of it, I have a number of minor patches for 8349SYS based configurations; where can I find the last devel code (next to 2.6.17) for patch creation (and to whom to send them back)?

This adds USB platform support to MPC8349 PB. It works with the fsl_usb2_udc driver.

Signed-off-by Li Yang <[email protected]>

---

arch/powerpc/platforms/83xx/Kconfig       |   4  ++
arch/powerpc/platforms/83xx/mpc834x_sys.c |   72 +++++++++++++++++++ 
++++++++++
arch/powerpc/platforms/83xx/mpc834x_sys.h |   24 ++++++++++
3 files changed, 113 insertions(+), 0 deletions(-)

arch/powerpc/platforms/83xx/Kconfig +4 -0

index 7675e67..8404cdf 100644
@@ -24,4 +31,14 @@ config MPC834x
 	select PPC_INDIRECT_PCI
 	default y if MPC834x_SYS
 
+config 834x_USB_SUPPORT
+	bool
+	default y if MPC834x_SYS && (USB || USB_GADGET)
+	

endmenu

arch/powerpc/platforms/83xx/mpc834x_sys.c +1 -0

index 7e789d2..f10d4ae 100644
@@ -36,6 +36,7 @@ #include <asm/irq.h>
 #include <asm/prom.h>
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>
+#include <linux/fsl_devices.h>
 #include "mpc83xx.h"

arch/powerpc/platforms/83xx/mpc834x_sys.c +38 -0

+void mpc834x_usb_board_cfg(void)
+{
+	unsigned char __iomem *bcsr;
+	volatile unsigned char *bcsr5_p;
+
+	/*
+	 * if SYS board is plug into PIB board,
+	 * force to use the PHY on SYS board
+	 * */
+	bcsr = ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+	bcsr5_p = bcsr + BCSR5_OFF;
+	if ( (*bcsr5_p & BCSR5_INT_USB) == 0 )
+		*bcsr5_p = (*bcsr5_p | BCSR5_INT_USB);
+	iounmap(bcsr);
+}
+
+/* Note: This is only for PB, not for PB+PIB
+ * On PB only port0 is connected using ULPI */
+static int mpc834x_usb_cfg(void)
+{
+	unsigned long sccr, sicrl;
+	volatile unsigned long *p;
+	unsigned long __iomem *immap;
+	struct device_node *np = NULL;
+	int port0_is_dr = 0;
+
+	if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-dr")) !=  
 NULL)
+		port0_is_dr = 1;
+	if ((np = of_find_compatible_node(np, "usb", "fsl-usb2-mph")) !=  
 NULL){
+		if (port0_is_dr) {
+			printk(KERN_WARNING
+				"There is only one USB port on PB board! \n");
+			return -1;
+		} else if (!port0_is_dr)
+			/* No usb port enabled */
+			return -1;
+	}
+	

arch/powerpc/platforms/83xx/mpc834x_sys.c +11 -0

+	iounmap(immap);
+	return 0;
+}
+
+#endif /* CONFIG_834x_USB_SUPPORT */
+
 /* ************************************************************************
 *
 * Setup the architecture

@@ -102,6 +169,11 @@ #ifdef CONFIG_PCI
 	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
+#ifdef CONFIG_834x_USB_SUPPORT
+	mpc834x_usb_cfg();
+	mpc834x_usb_board_cfg();
+#endif
+
 #ifdef  CONFIG_ROOT_NFS
 	ROOT_DEV = Root_NFS;
 #else

arch/powerpc/platforms/83xx/mpc834x_sys.h +11 -0

index fedecb7..30e45e8 100644
@@ -20,4 +20,28 @@ #define PIRQB	MPC83xx_IRQ_EXT5
 #define PIRQC	MPC83xx_IRQ_EXT6
 #define PIRQD	MPC83xx_IRQ_EXT7
+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
+#define BCSR_SIZE		((uint)(32 * 1024))
+ +#define BCSR5_OFF		0x05
+#define BCSR5_INT_USB		0x02
+
+#define MPC83XX_SCCR_OFFS          0xA08
+#define MPC83XX_SCCR_USB_MPHCM_11  0x00c00000
+#define MPC83XX_SCCR_USB_MPHCM_01  0x00400000
+#define MPC83XX_SCCR_USB_MPHCM_10  0x00800000
+#define MPC83XX_SCCR_USB_DRCM_11   0x00300000
+#define MPC83XX_SCCR_USB_DRCM_01   0x00100000

-----Original Message-----
From: [email protected] [mailto:[email protected]] On =

Gala
Sent: Thursday, July 20, 2006 4:09 AM
To: Li Yang-r58472
Cc: [email protected]; [email protected]
Subject: Re: [PATCH] Add USB to MPC8349 PB platform support =20
=20
On Jul 14, 2006, at 6:52 AM, Li Yang wrote:
=20

Quoted 25 lines

This adds USB platform support to MPC8349 PB. It works with the fsl_usb2_udc driver.

Signed-off-by Li Yang <[email protected]>

---

arch/powerpc/platforms/83xx/Kconfig       |   4  ++
arch/powerpc/platforms/83xx/mpc834x_sys.c |   72 +++++++++++++++++++
++++++++++
arch/powerpc/platforms/83xx/mpc834x_sys.h |   24 ++++++++++
3 files changed, 113 insertions(+), 0 deletions(-)

arch/powerpc/ renamed from arch/powerpc/platforms/83xx/Kconfig +0 -0

platforms/83xx/Kconfig
index 7675e67..8404cdf 100644

arch/powerpc/platforms/83xx/Kconfig +4 -0

@@ -24,4 +31,14 @@ config MPC834x
 	select PPC_INDIRECT_PCI
 	default y if MPC834x_SYS
 
+config 834x_USB_SUPPORT
+	bool
+	default y if MPC834x_SYS && (USB || USB_GADGET)
+

Quoted 1 line

endmenu

=20
I dont think we need this, we should be able to use the USB, and 834x CONFIG options in the code.
=20

Quoted 9 lines

arch/ renamed from arch/powerpc/platforms/83xx/mpc834x_sys.c +0 -0

powerpc/platforms/83xx/mpc834x_sys.c
index 7e789d2..f10d4ae 100644

arch/powerpc/platforms/83xx/mpc834x_sys.c +0 -0

@@ -36,6 +36,7 @@ #include <asm/irq.h>
 #include <asm/prom.h>
 #include <asm/udbg.h>
 #include <sysdev/fsl_soc.h>

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 74

Quoted 6 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +2 -0

+#include <linux/fsl_devices.h>
 #include "mpc83xx.h"

@@ -71,6 +72,72 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
 }
 #endif				/* CONFIG_PCI */
+#ifdef CONFIG_834x_USB_SUPPORT

=20
Just make it dependent on CONFIG_USB_EHCI_HCD or something like that.

=20

Quoted 19 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +19 -0

+void mpc834x_usb_board_cfg(void)
+{
+	unsigned char __iomem *bcsr;
+	volatile unsigned char *bcsr5_p;
+
+	/*
+	 * if SYS board is plug into PIB board,
+	 * force to use the PHY on SYS board
+	 * */
+	bcsr =3D ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+	bcsr5_p =3D bcsr + BCSR5_OFF;
+	if ( (*bcsr5_p & BCSR5_INT_USB) =3D=3D 0 )
+		*bcsr5_p =3D (*bcsr5_p | BCSR5_INT_USB);
+	iounmap(bcsr);
+}
+
+/* Note: This is only for PB, not for PB+PIB
+ * On PB only port0 is connected using ULPI */
+static int mpc834x_usb_cfg(void)

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 101

Quoted 8 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +8 -0

+{
+	unsigned long sccr, sicrl;
+	volatile unsigned long *p;
+	unsigned long __iomem *immap;
+	struct device_node *np =3D NULL;
+	int port0_is_dr =3D 0;
+
+	if ((np =3D of_find_compatible_node(np, "usb", "fsl-usb2-dr")) =

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 104

Quoted 3 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +2 -0

 NULL)
+		port0_is_dr =3D 1;
+	if ((np =3D of_find_compatible_node(np, "usb", "fsl-usb2-mph")) =

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 108

Quoted 4 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +3 -0

 NULL){
+		if (port0_is_dr) {
+			printk(KERN_WARNING
+				"There is only one USB port on PB board!

Quoted 11 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +11 -0

+			return -1;
+		} else if (!port0_is_dr)
+			/* No usb port enabled */
+			return -1;
+	}
+
+	immap =3D ioremap(get_immrbase(), 0x100000);
+
+	/* Configure clock */
+	p =3D (volatile unsigned long *)((u32)immap + MPC83XX_SCCR_OFFS);
+	sccr =3D *p;

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 124

Quoted 5 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +5 -0

+	if (port0_is_dr)
+		sccr |=3D MPC83XX_SCCR_USB_DRCM_11;  /* 1:3 */
+	else
+		sccr |=3D MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
+	*p =3D sccr;

=20
This really needs to take into account the platform frequency. I guess technically, at 1:3 we will always be below the max 133Mhz.

=20

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 133

Quoted 9 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +9 -0

+
+	/* Configure Pin */
+	p =3D (volatile unsigned long *)((u32)immap + MPC83XX_SICRL_OFFS);
+	sicrl =3D *p;
+	/* set port0 only */
+	if (port0_is_dr) +		sicrl |=3D MPC83XX_SICRL_USB0;
+	else +		sicrl &=3D ~(MPC83XX_SICRL_USB0);
+	*p =3D sicrl;
+

=20
Why dont we just do all this in fsl_usb_of_init

=20

arch/powerpc/platforms/83xx/mpc834x_sys.c mpc83xx_map_irq(struct pci_dev *dev, uns · line 141

Quoted 8 lines

arch/powerpc/platforms/83xx/mpc834x_sys.c +6 -0

+	iounmap(immap);
+	return 0;
+}
+
+#endif /* CONFIG_834x_USB_SUPPORT */
+
 /*
 

Quoted 38 lines

**
*
* Setup the architecture

arch/powerpc/platforms/83xx/mpc834x_sys.c +5 -0

@@ -102,6 +169,11 @@ #ifdef CONFIG_PCI
 	ppc_md.pci_exclude_device =3D mpc83xx_exclude_device;
 #endif
+#ifdef CONFIG_834x_USB_SUPPORT
+	mpc834x_usb_cfg();
+	mpc834x_usb_board_cfg();
+#endif
+
 #ifdef  CONFIG_ROOT_NFS
 	ROOT_DEV =3D Root_NFS;
 #else

arch/ renamed from arch/powerpc/platforms/83xx/mpc834x_sys.h +0 -0

powerpc/platforms/83xx/mpc834x_sys.h
index fedecb7..30e45e8 100644

arch/powerpc/platforms/83xx/mpc834x_sys.h +16 -0

@@ -20,4 +20,28 @@ #define PIRQB	MPC83xx_IRQ_EXT5
 #define PIRQC	MPC83xx_IRQ_EXT6
 #define PIRQD	MPC83xx_IRQ_EXT7
+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
+#define BCSR_SIZE		((uint)(32 * 1024))
+ +#define BCSR5_OFF		0x05
+#define BCSR5_INT_USB		0x02
+
+#define MPC83XX_SCCR_OFFS          0xA08
+#define MPC83XX_SCCR_USB_MPHCM_11  0x00c00000
+#define MPC83XX_SCCR_USB_MPHCM_01  0x00400000
+#define MPC83XX_SCCR_USB_MPHCM_10  0x00800000
+#define MPC83XX_SCCR_USB_DRCM_11   0x00300000
+#define MPC83XX_SCCR_USB_DRCM_01   0x00100000
+#define MPC83XX_SCCR_USB_DRCM_10   0x00200000
+
+/* system i/o configuration register low */
+#define MPC83XX_SICRL_OFFS         0x114
+#define MPC83XX_SICRL_USB0         0x40000000

arch/powerpc/platforms/83xx/mpc834x_sys.h #define PIRQB MPC83xx_IRQ_EXT5 · line 42

Quoted 5 lines

arch/powerpc/platforms/83xx/mpc834x_sys.h +5 -0

+#define MPC83XX_SICRL_USB1         0x20000000
+
+/* system i/o configuration register high */
+#define MPC83XX_SICRH_OFFS         0x118
+#define MPC83XX_SICRH_USB_UTMI     0x00020000

=20
Are these really generic to all MPC83XX? We should move these to include something like asm-ppc/mpc83xx.h

=20

arch/powerpc/platforms/83xx/mpc834x_sys.h #define PIRQB MPC83xx_IRQ_EXT5 · line 45

Quoted 3 lines

arch/powerpc/platforms/83xx/mpc834x_sys.h +2 -0

+
+
 #endif				/* __MACH_MPC83XX_SYS_H__ */

=20
- kumar
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev