On Mon, 9 Apr 2001, David Brownell wrote:

Hi David,

> What "proper alignment"?  None is mentioned in any
> part of the linux/Documentation/DMA-mapping.txt ...

Yes - in fact there are no requirements at all mentioned there wrt. to
the address to be mapped by pci_map_single(). Accordingly, something
like

>>>>
static char buf[123];

dma_addr = pci_map_single(dev,buf,sizeof(buf),PCI_DMA_FROMDEVICE);
<<<<

should be ok. However, at least for x86, pci_map_single() is nothing but
a wrapper for virt_to_bus(). I don't know much about details of PCI-specs,
but I'm really wondering, whether a BM device may access the system memory
using arbitrary alignment. I might be wrong, but I've seen USB transaction
which are failing when transfer buffer was located at some non-kmalloced
location. And there are more such reports here on this list. Or are there
other reasons, why this won't work?
You know, pci_alloc_consistent()/x86 uses __get_free_pages(GFP_ATOMIC)
making whatever it returns being page-aligned.

> if there are such requirements on any platform, I'd
> certainly expect them to be mentioned there!

right. On the other hand, pci_map_* family is meant to abstract the
different platforms therefore such specific requirements might be better
handled internally - if possible.
The Linux-USB docs say somewhere one should use kmalloc(GFP_KERNEL) to get
the transfer buffer - but the explanation is something like "don't
ask", IIRC. My feeling is, alignment might be important.

> Related patches for pci_map_single should handle all the
> data (or control setup) buffers handed by device drivers
> to the HCDs.

Yes. But in former times, when virt_to_bus() was used, there where further
requirements for the transfer buffer. Because pci_map_single()/x86 is
simply a wrapper for it, I would be surprised to find them disappeared
now. Or is the pci-pool meant to be used for the transfer buffer as well?

> > BTW2, since it is ok to call the DMA mapping API functions from interrupt
> > context it should be ok to call usb_submit_urb() from your urb completion
> > handler catc_irq(), regardless whether you use the pci_pool patches or
> > not, IMHO.
> 
> In fact, the only USB driver API functions that you can't call
> from interrupt context should be the blocking API calls
> (usb_control_msg, usb_bulk_msg).

Thanks for the clarification. I simply have not installed your patches yet
(due to x86 and no need for slab debugging so far) and don't wanted to
claim nothing would have changed with your pci-pool included - due to some
locking requirements for example. Looking at the code makes me believe
you've found a really clean solution!

Martin


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to