Re: bus dma: a flag/quirk for page zero

On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote:
> on 10/01/2012 22:53 Ian Lepore said the following:
> > On Tue, 2012-01-10 at 22:18 +0200, Andriy Gapon wrote:
> >>
> >> Some hardware interfaces may reserve a special meaning for a (physical) memory
> >> address value of zero.  One example is the OHCI specification where a zero value
> >> in CurrentBufferPointer doesn't mean a physical address, but has a reserved
> >> meaning.  To be honest I don't have another example :) but don't preclude its
> >> existence.
> >>
> >> To deal with this peculiarity we could use a special flag/quirk that would
> >> instruct the bus dma code to never use the page zero for communication with the
> >> hardware.
> >> Here's a proof of concept patch that implements the idea:
> >> http://people.freebsd.org/~avg/usb-dma-pagezero.diff
> >>
> >> Some concerns:
> >> - not sure if BUS_DMA_NO_PAGEZERO is the best name for the flag
> >> - the patch implements the flag only for x86 at the moment
> >> - usb code uses the flag regardless of the actual controller type
> >>
> >> What do you think?
> > 
> > I think another way to handle this, one that doesn't require modifying
> > the busdma_machdep implementation for every architecture, would be for
> > usb_dma_tag_create() to set lowaddr to zero and provide a filter func
> > that filters based on both the value zero and the expression currently
> > being passed as lowaddr.  At least, I think that's how the filterfunc
> > stuff is supposed to work, I've never actually coded a busdma filter.
> 
> This has still some problems:
> - filter func is called for the range (lowaddr, hiaddr], that is lowadr is not
> inclusive, as such there is no way to filter page zero
> - a bounce page could still be at the physical address zero
> - and overriding the above, even worse, bounce pages are allocated in the range
> below lowaddr, so with lowaddr of zero it's impossible to have any bounce pages

Wow, I didn't realize.  That almost reads like a list of bugs in the
current busdma design.  It seems especially wrong to assume that no
hardware in the world now or ever would have its range of DMA-able
addresses in the middle of its physical address space.

I'll throw one more idea out, (because it just popped into my head, not
because I think it's the best possible idea)...  Could the problems you
list be circumvented (for this situation and maybe others) with a new
flag BUS_DMA_ALWAYS_FILTER that makes the filter function run regardless
of the low/high addr values?  That would add the flexibility to handle
any arbitary kinds of ranges no matter what hardware or strange
requirements come along.

-- Ian