On Sun, 11 Mar 2007, Michael Cook wrote: > Hi Alan, > > Thanks for your response. A bit more context... I dont > have a choice in kernel release. > > I have the ISP1761 example driver which apparently works in > 2.6.9 and I can't verify this as there isn't a > configuration for 2.6.9 for my platform. > > I have modified very little to get it to 2.6.14 on a PPC > system with Local Bus connectivity. The driver (ISP1761) > for the Host Controller is using PIO not DMA and not using > PCI interface.
Did you take care about checking byte-endian issues? > It references the 'transfer_buffer' when a URB is > submitted. > > So my questions were general because I'm unsure where the > memory for transfer_buffer comes from. They appear to be > coming from the USB Mass Storage driver. The memory could come from anywhere. Sometimes it comes from usbcore, sometimes it comes from usb-storage, sometimes it comes from the SCSI disk driver. > Right now, I'm trying to figure this out because the system > is becoming very unstable (corrupt) shortly after USB Mass > Storage driver finds the Memory Stick. Ultimately, copying > file back and forth are corrupted along with the system. > > The type of corruption appears that chunks of the RTOS > memory are copied into the file on outbound messages to the > stick. > > Can I be sure this is because of a poorly working ISP1761 > driver or an incompatibility between it and USB Mass > Storage driver? The ISP1761 driver appears to work fine on > startup, but not when larger amounts of data are passed to > it. One thing I noticed were transfer flags were always > zero until the USB Mass Storage driver kicked in. > > My original question was more concerned with trying to > understand what the transfer-flags mean. The comments > weren't clear to me. It sounded like the driver (HCD?) > should provide the memory space in the case of using DMA. No. The HCD does not provide the memory; the caller provides the memory. The transfer_flags you're wondering about indicate when the memory is mapped for DMA. Since you don't use DMA, the memory never needs to be mapped and so those flags don't have any effect. > On inspection of the buffer alloc request in PIO it seemed > only a small amount of data space was reserved for > ctrl-messages (64 bytes). This buffer us->iobuf apparently > equals transfer_buffer for some of the time. This > correlates to packets which are inexcess of 64bytes. As > far as I can see the us->iobuf is only assigned 64bytes > once via HCD buffer_alloc. This seemed to be a problem - > maybe I've missed something? Yes, you have missed something. If you look more carefully, you'll see that transfer_buffer is not equal to us->iobuf when transfer_length is > 64. > Again, the ISP1761 driver doesn't take much notice of the > flags and only references the transfer_buffer. So it would > gladly copy transfer_buffer into the device. I would > expect this to fluctuate as it reads different chunks of a > file from the file system. Indeed, it does fluctuate. Check your logs and you'll see. > What responsibility does the EHCI driver have in preparing > transfer memory in PIO? I was assuming only the PIO memory > space to which the ISP1761 driver copies the contents of > transfer_buffer in - eventually after converting to QTDs > (PTDs). The EHCI driver has no responsibility for preparing the memory. That all should be done by the caller. > As for churn, I use this term to mean change. There is a > fair amount of design change in the USB Mass Storage > directory for example between 2.6.9, 2.6.14. AFter 2.6.14 > there is very little change. I have yet to find a decent > source that may describe why these changes were made and > hence wonder if different versions may cause > incompatibility with this example driver? The changes are explained when they are submitted into the kernel. Look through the email archives for the USB Mass Storage driver (look it up in the MAINTAINERS file in the kernel source). Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
