CPM2 USB driver & MPC8248

CPM2 USB driver & MPC8248

[Laurent Pinchart]

Hi Mike,

I'm having trouble using your CPM2 USB host controller driver on an Embedded 
Planet EP8248 board with Linux 2.6.15.

The driver didn't compiler with 2.6.15 but the required changes were minor 
(the root hub doesn't have to be registered by the host controller driver 
anymore, and a few functions have been renamed). I modified the board setup 
function according to my hardware (different BCSR registers) and the driver 
loads properly.

When I connect a USB 2.0 Mass Storage device, initialization fails when trying 
to fetch the string descriptors. Here's what USBMon produces (I decoded the 
USB transactions with the device).

/* Initialization */
c054a860 62948014 C Ii:001:01 0 1 D
c054a860 62948089 S Ii:001:01 -115 2 D
c04500e0 62948126 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948134 C Ci:001:00 0 4 = 01010100
c04500e0 62948146 S Co:001:00 s 23 01 0010 0001 0000 0
c04500e0 62948151 C Co:001:00 0 0
c04500e0 62948158 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948163 C Ci:001:00 0 4 = 01010000
c04500e0 62980027 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62980045 C Ci:001:00 0 4 = 01010000
c04500e0 63012025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63012042 C Ci:001:00 0 4 = 01010000
c04500e0 63044025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63044042 C Ci:001:00 0 4 = 01010000
c04500e0 63076025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63076043 C Ci:001:00 0 4 = 01010000
c04500e0 63076088 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63172013 C Co:001:00 0 0
c04500e0 63228024 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63228042 C Ci:001:00 0 4 = 03010000
c04500e0 63284035 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63284052 C Co:001:00 0 0
c04500e0 63456779 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c04500e0 63457301 C Ci:000:00 0 18 = 12010002 00000040 81075051 20000102 0301
c04500e0 63457338 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63552013 C Co:001:00 0 0
c04500e0 63608025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63608043 C Ci:001:00 0 4 = 03010000
c04500e0 63664025 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63664042 C Co:001:00 0 0
c04500e0 63664055 S Co:000:00 s 00 05 0002 0000 0000 0
c04500e0 63664590 C Co:000:00 0 0

/* GET_DESCRIPTOR DEVICE 0x12 bytes */
c04500e0 63680039 S Ci:002:00 s 80 06 0100 0000 0012 18 <
c04500e0 63680781 C Ci:002:00 0 18 = 12010002 00000040 81075051 20000102 0301

/* GET_DESCRIPTOR CONFIGURATION 0x09 bytes */
c04500e0 63680825 S Ci:002:00 s 80 06 0200 0000 0009 9 <
c04500e0 63681795 C Ci:002:00 0 9 = 09022000 01010080 32

/* GET_DESCRIPTOR CONFIGURATION 0x20 bytes */
c04500e0 63681832 S Ci:002:00 s 80 06 0200 0000 0020 32 <
c04500e0 63682820 C Ci:002:00 0 32 = 09022000 01010080 32090400 00020806 
50000705 81024000 00070501 02400000

/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 63682877 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 68680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 68680075 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 73680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 73725213 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 78724036 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 78724141 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 83724019 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 83769592 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 88768017 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 88768053 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 93768016 C Ci:002:00 -104 0

/* SET_CONFIGURATION 1 */
c0450140 93814145 S Co:002:00 s 00 09 0001 0000 0000 0
c0450140 98812017 C Co:002:00 -104 0

As you can see, the devices sends its device and configuration descriptors, 
but something goes wrong with the string descriptors. I modified the core USB 
code to request 0x40 bytes (which is the value of bMaxPacketSize0) or even 
0x20 bytes, but the same problem occurs (same USBMon traces with 0xff 
replaced by 0x40).

Could you help me ? Kernel coding is not a problem, so I can make experiments 
if you point me to some direction. I'm also quite familiar with the USB specs 
down to the various types of transfers (control, interrupt, bulk and 
isochronous) but not with the lower-level protocol (frames, tokens, ...). I 
can learn if needed.

Laurent Pinchart

Re: CPM2 USB driver & MPC8248

[Laurent Pinchart]

Hi,

after more testing, I found out that only the first 3 control URBs complete 
successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request, 
and the second one which worked before now fails. If I unplug/replug the 
device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from 
hub_port_init fails:

c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 134700018 C Ci:000:00 -104 0
c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 135700016 C Ci:000:00 -104 0
c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 136700018 C Ci:000:00 -104 0

Hope this helps to diagnose the problem,

Laurent Pinchart

Re: CPM2 USB driver & MPC8248

[Alexandre BASTOS]

I don't know if it could be of interest for you.
I experienced same problem, but only with a subset of the USB storage
devices I have tested. There are same which worked fine.

Best regards,

Alex

> Hi,
>
> after more testing, I found out that only the first 3 control URBs complete
> successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request,
> and the second one which worked before now fails. If I unplug/replug the
> device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from
> hub_port_init fails:
>
> c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 134700018 C Ci:000:00 -104 0
> c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 135700016 C Ci:000:00 -104 0
> c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 136700018 C Ci:000:00 -104 0
>
> Hope this helps to diagnose the problem,
>
> Laurent Pinchart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>

Re: CPM2 USB driver & MPC8248

[Laurent Pinchart]

> I don't know if it could be of interest for you.
> I experienced same problem, but only with a subset of the USB storage
> devices I have tested. There are same which worked fine.

I tried with two USB Mass Storage devices. Both fail but at different stages. 
Do you know if the devices you were able to access were USB 1.1 or USB 2.0 
devices ?

Laurent Pinchart

Re: CPM2 USB driver & MPC8248

[Alex BASTOS]

All of them were labelled as USB 2.0, and where also recognized as
USB 2.0 devices in other systems, as x86 workstation with Fedora Core


Best regards

Alex


> > I don't know if it could be of interest for you.
> > I experienced same problem, but only with a subset of the USB storage
> > devices I have tested. There are same which worked fine.
>
> I tried with two USB Mass Storage devices. Both fail but at different stages.
> Do you know if the devices you were able to access were USB 1.1 or USB 2.0
> devices ?
>
> Laurent Pinchart
>

Re: CPM2 USB driver & MPC8248

[Mike Rapoport]

Laurent,

[snip]

>When I connect a USB 2.0 Mass Storage device, initialization fails when trying 
>to fetch the string descriptors. Here's what USBMon produces (I decoded the 
>USB transactions with the device).
>  
>
[snip]

I had similar problems with mass storage devices (disk-on-key). I've 
tried to find out what was causing them but I hadn't much success with it.
I think that problem might be in driver performance because it is very 
far from optimal.
Another thing that may cause problems is how storage devices treat SOF 
packets, but I'm not USB expert enough to be sure about that.

>As you can see, the devices sends its device and configuration descriptors, 
>but something goes wrong with the string descriptors. I modified the core USB 
>code to request 0x40 bytes (which is the value of bMaxPacketSize0) or even 
>0x20 bytes, but the same problem occurs (same USBMon traces with 0xff 
>replaced by 0x40).
>
>Could you help me ? Kernel coding is not a problem, so I can make experiments 
>if you point me to some direction. I'm also quite familiar with the USB specs 
>down to the various types of transfers (control, interrupt, bulk and 
>isochronous) but not with the lower-level protocol (frames, tokens, ...). I 
>can learn if needed.
>
>Laurent Pinchart
>
>
>
>  
>

-- 
Sincerely yours,
Mike Rapoport

Re: CPM2 USB driver & MPC8248

[Laurent Pinchart]

> >When I connect a USB 2.0 Mass Storage device, initialization fails when
> > trying to fetch the string descriptors. Here's what USBMon produces (I
> > decoded the USB transactions with the device).
>
> [snip]
>
> I had similar problems with mass storage devices (disk-on-key). I've
> tried to find out what was causing them but I hadn't much success with it.
> I think that problem might be in driver performance because it is very
> far from optimal.

How is the driver development going ? You're not using the sourceforge CVS/SVN 
repository, is there another one somewhere (maybe a git tree) ? Are you 
actively working on performance issues, or is the development currently 
stalled ? What are the major performance issues ? I noticed that the driver 
uses the MPC82xx packet level interface. Why don't you use the transaction 
level interface ?

> Another thing that may cause problems is how storage devices treat SOF
> packets, but I'm not USB expert enough to be sure about that.

That might explain why some devices don't even respond to the first request. I 
noticed that, on my EP8248 board, the controller only sends 990 SOF packets 
per second (or rather 990 SOF interrupts are generated). I might have a time 
base problem somewhere, as I computed the number of interrupts per second 
with a simple

cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 && 
cat /proc/driver/m8xxhci_privateh > sof.2

Do you have the same problem ? I'll see if I can get my hands on a USB 
protocol analyzer.

Laurent Pinchart

Re: CPM2 USB driver & MPC8248

[Mike Rapoport]

Laurent Pinchart wrote:

>How is the driver development going ? You're not using the sourceforge CVS/SVN 
>repository, is there another one somewhere (maybe a git tree) ? Are you 
>actively working on performance issues, or is the development currently 
>stalled ? 
>  
>
The driver development is stalled and I don't know when I'll be able to 
continue working on it.

>What are the major performance issues ? 
>  
>
One of the issues in this driver is redunduncy between qe end ep 
structures and as a consequence a lot of uneeded code that make cross 
updates.
I didn't run profiling, so I can't tell better.

>I noticed that the driver uses the MPC82xx packet level interface. 
>Why don't you use the transaction level interface ?
>  
>
The original driver I've started with used packet level. I thought on 
switching to transaction level, but I hadn't time for it because of 
other projects pressure.

>  
>
>>Another thing that may cause problems is how storage devices treat SOF
>>packets, but I'm not USB expert enough to be sure about that.
>>    
>>
>
>That might explain why some devices don't even respond to the first request. I 
>noticed that, on my EP8248 board, the controller only sends 990 SOF packets 
>per second (or rather 990 SOF interrupts are generated). I might have a time 
>base problem somewhere, as I computed the number of interrupts per second 
>with a simple
>
>cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 && 
>cat /proc/driver/m8xxhci_privateh > sof.2
>
>  
>
I'm not sure such measurements are correct, since you sleep not exatly 
300 seconds. I haven't measured how many SOF interrupts I get, but I 
think you maybe right.
It may happen that during transmit or recieve the interrupts are off and 
SOF packets are not sent.

>Do you have the same problem ? I'll see if I can get my hands on a USB 
>protocol analyzer.
>  
>
Good luck, I'll try to help but unfotunately I'm very much busy with 
other projects now.

>Laurent Pinchart
>
>
>
>  
>


-- 
Sincerely yours,
Mike Rapoport

Re: CPM2 USB driver & MPC8248

[Laurent Pinchart]

> The driver development is stalled and I don't know when I'll be able to
> continue working on it.

Bad news, but I do understand. Please inform me when you will resume working 
on the driver, so that I can inform you of the progress I will have made (if 
any).

> >What are the major performance issues ?
>
> One of the issues in this driver is redunduncy between qe end ep
> structures and as a consequence a lot of uneeded code that make cross
> updates.
> I didn't run profiling, so I can't tell better.

Ok.

> >I noticed that the driver uses the MPC82xx packet level interface.
> >Why don't you use the transaction level interface ?
>
> The original driver I've started with used packet level. I thought on
> switching to transaction level, but I hadn't time for it because of
> other projects pressure.

Do you think it would be worth it, or are there any issue which you are aware 
of that would make it difficult/impractical/impossible/useless ?

> >That might explain why some devices don't even respond to the first
> > request. I noticed that, on my EP8248 board, the controller only sends
> > 990 SOF packets per second (or rather 990 SOF interrupts are generated).
> > I might have a time base problem somewhere, as I computed the number of
> > interrupts per second with a simple
> >
> >cat /proc/driver/m8xxhci_privateh > sof.1 && sleep 300 &&
> >cat /proc/driver/m8xxhci_privateh > sof.2
>
> I'm not sure such measurements are correct, since you sleep not exatly
> 300 seconds. I haven't measured how many SOF interrupts I get, but I
> think you maybe right.
> It may happen that during transmit or recieve the interrupts are off and
> SOF packets are not sent.

My bad, this was caused by the boot loader passing 66000000Hz instead of 
66666666Hz to Linux as the bus frequency. This is fixed now, and I get 1000 
SOF interrupts per second.

> >Do you have the same problem ? I'll see if I can get my hands on a USB
> >protocol analyzer.
>
> Good luck, I'll try to help but unfotunately I'm very much busy with
> other projects now.

Thanks for your help already.

Laurent Pinchart