From owner-svn-src-projects@FreeBSD.ORG Sun Jun 6 03:50:10 2010 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C33B106566C; Sun, 6 Jun 2010 03:50:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE098FC1B; Sun, 6 Jun 2010 03:50:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp025.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L3K00EF4QNBRC10@asmtp025.mac.com>; Sat, 05 Jun 2010 20:50:01 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1006050215 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-06-05_02:2010-02-06, 2010-06-05, 2010-06-05 signatures=0 From: Marcel Moolenaar In-reply-to: <516EEDC6-069A-4780-84DF-BBFF43ABCDE5@samsco.org> Date: Sat, 05 Jun 2010 20:49:59 -0700 Message-id: References: <201006052041.o55KfMF6032155@svn.freebsd.org> <184A275D-B98A-4DBF-9F4D-22F27B9319DD@mac.com> <20100605.203348.651115405925906974.imp@bsdimp.com> <516EEDC6-069A-4780-84DF-BBFF43ABCDE5@samsco.org> To: Scott Long X-Mailer: Apple Mail (2.1078) Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, nwhitehorn@FreeBSD.org, "M. Warner Losh" Subject: Re: svn commit: r208850 - projects/ppc64/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 03:50:10 -0000 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@mac.com> >> Marcel Moolenaar 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@mac.com