USB driver for MPC850/823

USB driver for MPC850/823

[Bjvrn Lundberg]

The driver is developed under Malek's 2.2.5 for embedded PPC.
Since the documentation has been a bit poor for the USB host mode, much
had to be done with trial and error. Some of which is left in the
source.
Most changes are in new source files but some changes has been done in
commproc.c and .h to support RISC timers and more DPRAM (microcode
alert).
For some reason I couldn't use USB buffers in SDRAM, only DPRAM!?
As stated earlier on the list it's developed on an 850, but I haven't
found anything that says it won't work on an 823.

The USB-driver is a replacement for the UHCI or OHCI in the standard usb
stack.
It still needs to be URBified, so it's not up to date with the latest
developments
in the standard stack. It has been tested with the ACM driver (which is
included in the tar) and is running chat, ppp and mgetty. Also included
are the versions of usb.c usb-debug.c and usb.h used.

I did a tar (all changes are in arch/ppc/8xx_io) since I don't know how
useful a diff against 2.2.5 is when most are working on later versions.

Enjoy
  Bjorn

PS.
If You use chat, You'll find a bug in terminate(). Don't call fatal(),
it'll call terminate()....

PPS.
The mail was to big to be accepted to this list but you can find it
and the tar at

http://lists.suse.com/archives/linux-usb/2000-Mar/0234.html

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: USB driver for MPC850/823

[Steve Calfee]

At 10:35 AM 3/8/00 +0100, Björn Lundberg wrote:

>The driver is developed under Malek's 2.2.5 for embedded PPC.
>Since the documentation has been a bit poor for the USB host mode, much
>had to be done with trial and error. Some of which is left in the
>source.
>Most changes are in new source files but some changes has been done in
>commproc.c and .h to support RISC timers and more DPRAM (microcode
>alert).
>For some reason I couldn't use USB buffers in SDRAM, only DPRAM!?
>As stated earlier on the list it's developed on an 850, but I haven't
>found anything that says it won't work on an 823.

I have started looking at your code to try understand some of the
roadblocks that I have hit. I have ISOC in/out working on the 823 USB. My
IN and OUT packets are from main system Dram. You dont say what the problem
was, but if the problem is; the data sent was garbage, not what you
prepared, the problem may be memory mapping. The CPM wants to access
physical memory addresses. You use a macro __pa for this, but I dont think
that works for all cases of user and kernel memory. I grepped and found:

#define PAGE_OFFSET     0xc0000000
#define __pa(x)                 ((unsigned long)(x)-PAGE_OFFSET)

Look at virt_to_phys(x); but that only does kmalloc'ed memory. There seems
to be many mapping macros/routines but I don't know if one works for ANY
virtual address to its physical address.

Does anyone have a pointer to a document that thoroughly describes memory
mapping, both for the x86 and the ppc?



Steve Calfee	--	embedded systems consultant
calfee@home.com
cell phone: (510) 468-5837
Kerbango phone: (408) 517-3355
home office ph: (510) 657-6039


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: USB driver for MPC850/823

[Dan Malek]

Steve Calfee wrote:

> .... The CPM wants to access
> physical memory addresses. You use a macro __pa for this, but I dont think
> that works for all cases of user and kernel memory.

It will certainly never work for user memory, you should only copyin/out
user addresses for a variety of reasons.

> Look at virt_to_phys(x); but that only does kmalloc'ed memory.

The virt_to_phys() and __pa() do the same thing.  Both work on kmalloc'ed
memory.  Neither will work with vmalloc'ed memory.

When using the CPM on the 8xx, you have to be careful about the cache
attributes on the pages as the 8xx doesn't have bus snooping to ensure
coherency.  I use a couple of different methods to get memory allocated
in the kernel for the CPM, sometimes they are cached and require software
management, other times not cached.  Depends upon how it is used.

You can use kmalloc() or __get_free_pages() to allocate memory for the
CPM.  Just make sure kmalloc() gives you something that is properly
aligned, as some CPM functions have rather large alignment boundaries.
When allocated in this way, you have to chase down the pte's and modify
the cache attributes yourself if desired.

> Does anyone have a pointer to a document that thoroughly describes memory
> mapping, both for the x86 and the ppc?

It would probably be correct only until the next source update.  While
trying to keep up with the 2.3.xx source tree, I have changed the CPM
memory interfaces at least three times.  I think we are back where we
started, at least this week.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: USB driver for MPC850/823

[Björn Lundberg]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

The simple reason (makes me blush) why buffers in SDRAM didn't work was
beacuse I omitted to flush the cache. (Thanks Brad and Malek)

I did a quick change and an even quicker test.
Patch attached.

Cheers
 Bjorn

Dan Malek wrote:
>
snip
>
> When using the CPM on the 8xx, you have to be careful about the cache
> attributes on the pages as the 8xx doesn't have bus snooping to ensure
> coherency.  I use a couple of different methods to get memory allocated
> in the kernel for the CPM, sometimes they are cached and require software
> management, other times not cached.  Depends upon how it is used.
>

[-- Attachment #2: patch-8xxhci.c-SDRAM.diff --]
[-- Type: text/plain, Size: 3249 bytes --]

--- ../usb.8xx_io/8xxhci.c	Tue Mar  7 13:31:50 2000
+++ 8xxhci.c	Thu Mar  9 13:06:43 2000
@@ -55,8 +55,10 @@

 #ifdef BUF_IN_DPRAM
 #define BD_BUFADDR(bdp)	((unsigned char*)((bdp)->cbd_bufaddr))
+#define BD_RELEASE(bdpbuf)
 #else	/* buffs in sdram */
 #define BD_BUFADDR(bdp)	((unsigned char*)__va((bdp)->cbd_bufaddr))
+#define BD_RELEASE(bdpbuf) flush_dcache_range((int)bdpbuf, (int)bdpbuf + PKT_BUF_SIZE)
 #endif

 #define	MY_USMOD	(USMOD_HOST | USMOD_EN)	/* | USMOD_TEST) */
@@ -314,6 +316,7 @@
 	return 0;
 }

+#if NOT_USED
 /*
  * Lets define a set of functions that can help us terminate messages
  * that are put here for periodic (rescheduled) transfer
@@ -346,6 +349,7 @@

 	remove_wait_queue(&terminate_wakeup, &wait);
 }
+#endif

 /*
  * Called from outside to stop an interrupt message
@@ -353,9 +357,8 @@
 int cpm_hci_release_irq(struct usb_device *usb_dev, void *_irp)
 {
 	struct cpm_hci_irp	*irp = (struct cpm_hci_irp*)_irp;
-	struct cpm_hci *cpm_hci = irp->dev->cpm_hci;
 	struct cpm_hci_device	*dev = usb_to_cpm_hci(usb_dev);
-	unsigned long flags;
+	// unsigned long flags;

 	if (!irp)
 		return USB_ST_INTERNALERROR;
@@ -602,8 +605,7 @@
 {
 	struct cpm_hci_irp	*irp = (struct cpm_hci_irp*)_irp;
 	struct cpm_hci_device	*dev = usb_to_cpm_hci(usb_dev);
-	struct cpm_hci *cpm_hci = irp->dev->cpm_hci;
-	unsigned long flags;
+	// unsigned long flags;

 	if (!irp) {
 		printk("USB: cpm_hci_terminate_bulk irp == NULL\n");
@@ -846,6 +848,7 @@
 	bdpbuf[0] = tok;
 	bdpbuf[1] = (__u8)(tok_data & 0x00ff);
 	bdpbuf[2] = (__u8)(tok_data >> 8);
+	BD_RELEASE(bdpbuf);
 	bdp->cbd_datlen = 3;
 	bdp->cbd_sc &= BD_USB_TX_WRAP;		/* clear all but wrap-bit */
 	bdp->cbd_sc |= (BD_USB_TX_LAST);	/* this is the last buffer in msg */
@@ -872,6 +875,7 @@
 	bdpbuf[0] = PID_SOF;
 	bdpbuf[1] = (__u8)(tok_data & 0x00ff);
 	bdpbuf[2] = (__u8)(tok_data >> 8);
+	BD_RELEASE(bdpbuf);
 	bdp->cbd_datlen = 3;
 	bdp->cbd_sc &= BD_USB_TX_WRAP;		/* clear all but wrap-bit */
 	bdp->cbd_sc |= (BD_USB_TX_LAST);	/* this is the last buffer in msg */
@@ -894,6 +898,7 @@

 	bdp->cbd_datlen = n;
 	memcpy(BD_BUFADDR(bdp), irp->data + irp->datadone, n);
+	BD_RELEASE(BD_BUFADDR(bdp));
 	bdp->cbd_sc &= BD_USB_TX_WRAP;		/* clear all but wrap-bit */
 	bdp->cbd_sc |= (BD_USB_TX_LAST);	/* this is the last buffer in msg */
 	bdp->cbd_sc |= (BD_USB_TX_INTR);	/* generate interrupt */
@@ -1063,6 +1068,7 @@
 			pr_debug("cpm_hci_do_resend: memcpy( %p, %p, %d)\n",
 			       BD_BUFADDR(bdp), BD_BUFADDR(bdp_failed), bdp_failed->cbd_datlen);
 			memcpy(BD_BUFADDR(bdp), BD_BUFADDR(bdp_failed), bdp_failed->cbd_datlen);
+			BD_RELEASE(BD_BUFADDR(bdp));
 			bdp->cbd_datlen = bdp_failed->cbd_datlen;

 			/* get all but wrap- and status-bits
@@ -1160,6 +1166,7 @@
 			// pr_debug("cpm_hci_do_resend: memcpy( %p, %p, %d)\n",
 			//        BD_BUFADDR(bdp), irp->bdp[i].buf, irp->bdp[i].datlen);
 			memcpy(BD_BUFADDR(bdp), irp->bdp[i].buf, irp->bdp[i].datlen);
+			BD_RELEASE(BD_BUFADDR(bdp));

 			bdp->cbd_datlen = irp->bdp[i].datlen;

@@ -1204,6 +1211,7 @@
 			bdp = next_tx_bd(bdp, cpm_hci);
 			bdp->cbd_datlen = irp->cmdlen;
 			memcpy(BD_BUFADDR(bdp), &irp->cmd, irp->cmdlen);
+			BD_RELEASE(BD_BUFADDR(bdp));
 			/*
 			 * We'll use the tx irq the wakeupcall
 			 */

Re: USB driver for MPC850/823

[Richard Hendricks]

Dan Malek wrote:
>
> Just make sure kmalloc() gives you something that is properly
> aligned, as some CPM functions have rather large alignment boundaries.
> When allocated in this way, you have to chase down the pte's and modify
> the cache attributes yourself if desired.

The most famous case of this is the IDMA buffer descriptors.  Unlike
everything elses buffer descriptors, the IDMA buffer descriptors must be
16 byte aligned, not 8.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: USB driver for MPC850/823

[Dan Malek]

Richard Hendricks wrote:

> The most famous case of this is the IDMA buffer descriptors.

I don't know about those, but DSP and ATM have 32 and 64 byte alignment
for various structures.



	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: USB driver for MPC850/823

[Richard Hendricks]

Yep.  I don't do ATM, but the majority of IDMA related questions
can be traced to misalignment issues.  Come to think of it, I
can count the number of DSP function related questions one hand.

Dan Malek wrote:
>
> Richard Hendricks wrote:
>
> > The most famous case of this is the IDMA buffer descriptors.
>
> I don't know about those, but DSP and ATM have 32 and 64 byte alignment
> for various structures.
>
>         -- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/