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. 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. 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. 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? 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. 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). 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? Thanks, Mike. --- Alan Stern <[EMAIL PROTECTED]> wrote: > On Sat, 10 Mar 2007, Michael Cook wrote: > > > Hi, > > > > I'm trying to understand how the USB Mass Storage > Device > > works in 2.6. Specifically 2.6.14. I see a fair > amount of > > churn in this subsystem. > > You didn't really ask any specific questions in your > email -- you just > said you were curious about some things -- and that makes > it kind of hard > to answer. > > And exactly what do you mean by "churn"? To me, that > word means the > subsystem changes a lot from one kernel release to > another, which is not > true any more (although it was truer at the time 2.6.14 > was released). > > Anyway, 2.6.14 is fairly old. You should try to use a > more recent kernel > version, if possible. > > > My principle concern/question is how does data from a > file > > on the filesystem get transported to a memory stick? I > > have dumped info at many stages and see varying URB > buffers > > sent out. > > That's how the file data gets transported. :-) > > > My device is using PIO not DMA. > > Irrelevant; who cares how the mass-storage device works? > Maybe you mean > the host controller uses PIO instead of DMA. > > > ----------------------------- > > > > As I try to trace through the use of this, I see that > the > > following flags are changing depending on various SCSI > > activity to the memory stick: > > > > ----------------------------- > > > > # pehci urb_enqueue: URB:0xef708338 TxFlags:0xc > > TxBuff:0xee110000 of 31 bytes [0x55 0x53 0x42 > > 0x43...] > > pehci urb_enqueue: URB:0xef7084e8 TxFlags:0x5 > > TxBuff:0xc240a098 of 36 bytes [0x00 0x00 0x00 > > 0x00...] > > > ..... > > > > ----------------------------- > > > > When I actually transfer file contents, I see the > buffer > > sizes increase dramaitcally: > > That's what you should expect, since the buffers now have > to contain the > file contents. > > > ----------------------------- > > > > pehci urb_enqueue: URB:0xef7080b0 TxFlags:0x5 > > TxBuff:0xc2a40000 of 20480 bytes [0x33 0xcd 0xa9 > > 0x71...] > > pehci urb_enqueue: URB:0xef708338 TxFlags:0xc > > TxBuff:0xee110000 of 13 bytes [0x55 0x53 0x42 > > 0x43...] > > > I'm curious how the TxFlags keep changing... these are > > combinations of: > > > > ----------------------------- > > > > #define URB_SHORT_NOT_OK 0x0001 /* report short reads > as > > errors */ > > #define URB_ISO_ASAP 0x0002 /* iso-only, > urb->start_frame > > ignored */ > > #define URB_NO_TRANSFER_DMA_MAP 0x0004 /* > urb->transfer_dma > > valid on submit */ > > #define URB_NO_SETUP_DMA_MAP 0x0008 /* urb->setup_dma > valid > > on submit */ > > #define URB_NO_FSBR 0x0020 /* UHCI-specific */ > > #define URB_ZERO_PACKET 0x0040 /* Finish bulk OUTs > with > > short packet */ > > #define URB_NO_INTERRUPT 0x0080 /* HINT: no non-error > > interrupt needed */ > > Those aren't TxFlags; they are urb->transfer_flags > values. > > Did you really mean "why the driver sets TxFlags to these > changing > values"? To understand that, you have to understand what > the flags mean > and how the driver works. > > > ----------------------------- > > > > I only see the flags non-zero once the SCSI system > start > > discoverying the memorystick. Previous URB enqueues > are > > all zero for the most part. > > > > My present situation is that after transfering files I > see > > file contents that are corrupt, along with system > > instability. > > > > I'm trying to isolate if I'm indeed copying correclty > to > > and from memory. > > "if I'm indeed copying correclty to and from memory" > Surely _your're_ not > doing any copying at all; the drivers are doing it. Do > you want to know > if the drivers are copying correctly? About the only way > to find out is > to read the data back from your mass-storage device and > see if it is the > same as what you wrote. > > > I see DMA-based HCDs use pools of data. For non DMA > based > > HCDs I see accomodations have been made in teh hcd.c > > allocation system. But wonder if the SCSI USB Mass > Storage > > device works with this in mind? > > The device doesn't care where the memory comes from -- or > even if there's > any memory at all. All it cares about is the data it > receives over the > USB bus. > > > I would also like to figure out if/why the flags for > DMA > > transfers are fluctuating so much... and specifically > the > > logic behind this snippet: > > > > ----------------------------- > > /* we assume that if transfer_buffer isn't us->iobuf > then > > it > > * hasn't been mapped for DMA. Yes, this is clunky, > but > > it's > > * easier than always having the caller tell us > whether > > the > > * transfer buffer has already been mapped. */ > > us->current_urb->transfer_flags = > URB_NO_SETUP_DMA_MAP; > > if (us->current_urb->transfer_buffer == us->iobuf) > > us->current_urb->transfer_flags |= > > URB_NO_TRANSFER_DMA_MAP; > > us->current_urb->transfer_dma = us->iobuf_dma; > > us->current_urb->setup_dma = us->cr_dma; > > Do you know what the comment means? Do you know what the > flag means? If > you do, then what part of the logic is unclear? > > Earlier you implied that your host controller doesn't use > DMA. In that > case, why do you care about the DMA flag settings? They > shouldn't have > any effect on your system's operation. > > > ----------------------------- > > > > I'm missing something here... I'm just trying to figure > out > > where I SHOULD be reading & writing from in memory as > I'm > > presently not and its blowing up whenever the SCSI > system > > notices my memory stick. > > I still don't know why you think _you_ should be reading > & writing > anything in memory. As the computer user, all you do is > run programs. > > As for where the host controller driver should read & > write memory, the > answer is simple. Since it doesn't use DMA, it should > access the memory > pointed to by urb->transfer_buffer (and urb->setup_packet > for control > transfers). > > Alan Stern > > ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 ------------------------------------------------------------------------- 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
