svn commit: r208850 - projects/ppc64/sys/powerpc/include
scottl at samsco.org
Sun Jun 6 04:05:14 UTC 2010
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-
> 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.
More information about the svn-src-projects