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

on 10/01/2012 23:27 Ian Lepore said the following:
> On Tue, 2012-01-10 at 23:15 +0200, Andriy Gapon wrote:
>> 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 am tempted to agree with you here, but since this is my first encounter with
the bus dma api I prefer to be cautious.  I think that there should be good
reasons, even if historical, why the current api is the way it is.  E.g. I can
not think of a good efficient way to allocate proper bounce page if the whole
memory range is subject to filtering.  Incremental try and error doesn't sound
efficient...

> 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.

This should/could work, but it has the original problem that it has to be
implemented for all archs separately.  And also the algorithm for allocating
bounce pages in this case needs to be devised.

-- 
Andriy Gapon