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

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Tue, 10 Jan 2012 23:15:00 +0200
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

> This has the advantage I call "locality of strangeness."  If only the
> OHCI hardware needs this strange processing, and it seems like in the
> future this strangeness will still be more the exception than the rule,
> then the strangeness is best kept close to the place where it's needed,
> rather than being spread out all over the place (lots of machdep
> places).


-- 
Andriy Gapon
Received on Tue Jan 10 2012 - 20:15:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC