svn commit: r208850 - projects/ppc64/sys/powerpc/include

[Scott Long]

On Jun 5, 2010, at 9:49 PM, Marcel Moolenaar wrote:
> 
> On Jun 5, 2010, at 8:38 PM, Scott Long wrote:
> 
>> On Jun 5, 2010, at 8:33 PM, M. Warner Losh wrote:
>>> In message: <184A275D-B98A-4DBF-9F4D-22F27B9319DD at mac.com>
>>>          Marcel Moolenaar <xcllnt at mac.com> writes:
>>> : 
>>> : On Jun 5, 2010, at 1:41 PM, Nathan Whitehorn wrote:
>>> : 
>>> : > Author: nwhitehorn
>>> : > Date: Sat Jun  5 20:41:22 2010
>>> : > New Revision: 208850
>>> : > URL: http://svn.freebsd.org/changeset/base/208850
>>> : > 
>>> : > Log:
>>> : >  BUS_SPACE_UNRESTRICTED is a flag, not an address, so it should be an int,
>>> : >  not a long.
>>> : 
>>> : This probably isn't right. How would you distinguish between a 32-bit
>>> : maximum of and unlimited if both can have the value 0xFFFFFFFF.
>>> : Making BUS_SPACE_UNRESTRICTED a long prevents zero-extension to 64-bit
>>> : and thus prevents this ambiguity.
>>> 
>>> But this define is used for busdma's number of segments.  It isn't
>>> used for an address at all...
>>> 
>>> from the busdma man page for bus_dma_tag_create:
>>>           nsegments    Number of discontinuities (scatter/gather segments)
>>>                        allowed in a DMA mapped region.  If there is no
>>>                        restriction, BUS_SPACE_UNRESTRICTED may be speci-
>>>                        fied.
>>> 
>>> so an argument consistent with the definition of nsegments is what is
>>> needed.  The man page doesn't specify a type for nsegments, but
>>> sys/bus_dma.h defines it as:
>>> 
>>> int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignment,
>>> 		       bus_size_t boundary, bus_addr_t lowaddr,
>>> 		       bus_addr_t highaddr, bus_dma_filter_t *filtfunc,
>>> 		       void *filtfuncarg, bus_size_t maxsize, int nsegments,
>>> 		       bus_size_t maxsegsz, int flags, bus_dma_lock_t *lockfunc,
>>> 		       void *lockfuncarg, bus_dma_tag_t *dmat);
>>> 
>>> so it is more proper to have it be an int than a long.
>>> 
>>> I got tripped up on this stupid name too when I was adding it for
>>> MIPS.  Any why it is in a MD file instead of an MI file is beyond me.
>>> I think it should be defined in sys/bus_dma.h, but maybe I'm just nuts...
>>> 
>> 
>> No, you're not nuts.  I've had a grand unification of MI/MD parts of busdma on my mind for years, and probably at least 2 or 3 aborted attempts lying around in old defunct trees.  Any unification is going to risk API/ABI changes, so I ultimately don't want to do it simply for cleanliness sake.  
> 
> Scott,
> 
> I've started an unification on the Altix branch myself because I
> need to add I/O MMU support for ia64 in order to get FreeBSD booting
> on the SGI Altix (there's no physical memory under 4GB so bounce
> buffering is impossible). If I need to work on busdma, I'd rather
> unify the whole lot so that other platforms can use I/O MMU when
> it's present.
> 
> Can you send me whatever you have or have done before so that I
> can leverage.
> 
> BTW: my current approach is to take the amd64 implementation as a
> base, and move platform specific code back into MD code.
> 
> Also: if there's interest among more people, we should probably
> create a special branch for it and work together.
> 

I struggle with answering the question of whether to just reorg the interface definitions but leave the interface alone, or whether to rewrite the interface definitions in the context of having a new DMA api.

There are a lot of things that I like about busdma, and a lot of things that I dislike.  Some things are simply too hard, clunky, and inflexible, like allocating static memory for DMA.  I like the two-stage load paradigm for i/o bufs, but it's really not appropriate for anything besides I/O, and I wonder if it'll start to be a performance liability as i/o transaction speed reaches network transaction levels.  I really don't like the inconsistency and confusion in the naming of certain functions and constants, something clearly brought out in this thread.  I don't like that simply allocating a tag is a daunting task for sorting out and supplying 14 argument.  There's probably a few other things that I'd really like to change, too.   So the question is where to start and how far to go.  Does it make sense to preserve the existing interface and layer a new meta-interface on top of it?  Or does it make sense to just change everything in-place and make a clean break from the past?  Or like I said before, is a "new" interface really not that important, with the important thing being to clean up the glaring problems in the existing interface.
 
On the specific topic of BUS_SPACE_UNRESTRICTED, that's a definition that seems to have been "borrowed" from the bus_space API.  Maybe at one time there was a desire to marry bus_space (bus.h) and bus_dma together in some fashion, but I don't see that having any practical value now.  bus_dma.h and bus.h are separate interfaces and shouldn't be sharing definitions, as far as I'm concerned.  If there are any disagreements on this, I'm happy to hear them.

Scott