On Jan 13, 2007, at 6:03 AM, Manuel Bouyer wrote:

> On Fri, Jan 12, 2007 at 02:03:37PM +0100, Jachym Holecek wrote:
>> # Manuel Bouyer 2007-01-12:
>>> On Fri, Jan 12, 2007 at 12:42:15PM +0200, Yorick Hardy wrote:
>>>>> Yes. Maybe it should be better to add this as a parameter to
>>>>> bus_dmamap_create(), and compute the proper _dm_bounce_thresh  
>>>>> at this
>>>>> time. But this is a big change in the bus_dma API, and require
>>>>> changing a lot of files, unless we keep bus_dmamap_create() as  
>>>>> is and
>>>>> intruduce a new function with this extra parameter.
>>>>>
>>>>>
>>>> Is there an advantage to passing by parameter rather than by  
>>>> flag (as in
>>>> my patch) ?
>>>
>>> This is a gross hack, a flag is meant as a boolean, not an arbitrary
>>> value. And this doesn't handle bus_dmamem
>>>
>>>> Obviously my patch limits the address to a power of 2, will this  
>>>> be a
>>>> problem?
>>>
>>> And it can't sepcify a minimum address.
>>
>> Do we add "bus_addr_t minaddr, bus_addr_t limit" arguments to the  
>> affected
>> functions, or perhaps "bus_addr_t addrbits" (where only lowest and  
>> highest
>> bit set are considered)?
>
> I think it really has to be minaddr, maxaddr (i.e. 2 different  
> arguments).
> We could create a bus_dmamem_alloc_range() and  
> bus_dmamap_create_range()
> if we don't want to change all  bus_dmamem_alloc/bus_dmamap_create  
> calls.
> Another interface could be bus_dmamem_alloc_range() and  
> bus_dmamap_set_range()
> (to be called after bus_dmamap_create()).

I was thinking of
int bus_dmatag_subregion(bus_dma_tag_t dmat,
         bus_addr_t min_addr,
         bus_addr_t max_addr,
         bus_dma_tag_t *new_dmat);
int bus_dmatag_destroy(bus_dma_tag_t);

and then use the new dmatag with existing API.  Minimal change and no  
massive
changes to existing drivers.