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

[Marcel Moolenaar]

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.

-- 
Marcel Moolenaar
xcllnt at mac.com