On Sat, Jan 13, 2007 at 07:07:06AM -0800, Matt Thomas wrote:
> 
> 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. 

Yes, I've been thinking about something like this too. It's clean; the
only issue I see is the need to allocate new memory which could be avoided ...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--