On Tue, 10 Apr 2001, David Brownell wrote:

> >    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. 
> 
> That was my issue:  if there's such an alignment concern, then it
> should be documented so any Linux developer can know it.  What
> you wrote seemed to me to suggest you knew of some specific
> omission in the documentation.

Unfortunately not. I'm really not sure whether there is such a omission or
not. Alignment issues are simply my personal guess (see below) since I've
definitely seen cases were a statically allocated transfer buffer failed
whereas a kmalloc'ed one worked fine. I don't have any further idea, how
to explain this difference.

> Statements do circulate about only using kmalloc'd memory, but since
> I can't recall explanations for them they sound mostly like voodoo.
> There could be reasons, unknown to me and also not documented
> for general knowledge in DMA-mapping.txt ...

My concern on alignment is based on:

PCI is 32 bit wide (at least) and BM-DMA is probably done using
burst-cycles, i.e. 32 bit transfered for every PCI clock and _no_ address
line incrementing by the BM-device (the BM-target has to manage this by
itself during burst cycles). So I don't see a way to execute a burst
transfer with len != n*4 (byte). Well, I can not exclude there is
some spec saying len!=n*4 size transfers have to fallback to non-burst
mode or split or something - but if you ask me, I would define such a
transfer to be always len==n*4 and required to start at align=4. Looking
at the BAR address mask for memory mapped device resources might even
suggest align=16 - at least to keep things unified.
Ok, I better stop my guessing here - apparently this deserves some
clarification by someone who knows the PCI spec better than me.

Martin


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

Reply via email to