> > 2. This isn't really the storage drivers problem. It should be solved
> > at a higher layer
> > So, if you need to do something in storage about it, choose the simple
> > solution and use a large bounce buffer.
>
> That's a good rationale. (Although the fix would go into the
> scatter-gather library which belongs to usbcore, not in usb-storage.
> After all, there may be other drivers at some future time that also want
> to do low-overhead s-g transfers.)
Exactly. These drivers may have other requirements for minum sizes
or alignments. How do you build that knowledge into the helper functions?
Ideally storage would specify its requirements to scsi core.
Failing that I don't think we should build workarounds into usbcore.
> > Secondly, I fear the analysis is incomplete.
> > On DMA incoherent machines, the size requirement is the transfer size
> > or a cacheline, whichever is larger and alignment needs to be on cacheline
> > boundaries.
>
> Although this becomes moot if we go for the single big bounce buffer, I
No. It is relevant for deciding whether a bounce buffer must be used or not.
> disagree. If you're referring to the overall transfer size, in general
> that's much bigger than a cacheline. If you're referring to the small
> "splice" buffers of my previous message, they can all get merged into a
> single large buffer. Since the transfer is all in one direction (read or
> write) and the host doesn't touch the data while the transfer is in
> progress, the usual DMA-mapping interface should work out okay. It's true
> that the region to be mapped must be on a cacheline boundary, but the
> actual data buffer can be a subset of the mapped region.
You can have an sglist that is perfectly valid from a transfer size point
of view, yet cannot be savely dmaed on an incoherent machine.
The issue is read/writing to memory sharing a cacheline with a transfer
buffer. For this very reason drivers had to switch to seperately
allocated transfer buffers on several occasions.
Regards
Oliver
-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
