From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 04:09:52 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 303381065670 for ; Sat, 13 Sep 2008 04:09:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 153C38FC14 for ; Sat, 13 Sep 2008 04:09:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id ADB3A2355; Fri, 12 Sep 2008 21:09:46 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 099192D6013; Fri, 12 Sep 2008 21:09:45 -0700 (PDT) Message-ID: <48CB3D09.4050908@elischer.org> Date: Fri, 12 Sep 2008 21:09:45 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Scott Long References: <200809112044.43749.hselasky@c2i.net> <48C9977C.2030104@samsco.org> <48CAB37F.50002@samsco.org> <20080912.145724.-1750800872.imp@bsdimp.com> <20080912150630.C39726@pooker.samsco.org> In-Reply-To: <20080912150630.C39726@pooker.samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rink@freebsd.org, current@freebsd.org, fbsd-current@mawer.org, freebsd-usb@freebsd.org, volker@vwsoft.com, hselasky@c2i.net, "M. Warner Losh" Subject: Re: "legacy" usb stack fixes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2008 04:09:52 -0000 Scott Long wrote: > On Fri, 12 Sep 2008, M. Warner Losh wrote: > >> In message: <48CAB37F.50002@samsco.org> >> Scott Long writes: >> : Scott Long wrote: >> : > This is close to How Things Should Be. Each umass target having >> its own >> : > SIM and bus is indeed wrong, but I'm not sure if it's correct for all >> : > USB controllers and buses to be under a single SIM. What would be >> the >> : > most correct is for each physical USB controller/bus instance to have >> : > its own SIM instance. I don't know if it's better to do the >> attachment >> : > in ehci/ohci/uhci controller drivers or in usb bus driver; up in the >> : > controller drivers is probably more correct. I don't like this >> hack of >> : > attaching stuff in a SYSINIT. >> : > >> : > Scott >> : > >> : > >> : >> : Now that I've thought some on it, I'll go one step further and say that >> : registering a single SIM for multiple controller+bus instances in a >> : SYSINIT will be highly undesirable thing to do. Since you have to >> : register a lock with the CAM when you register the SIM, you'll wind up >> : serializing all of the USB controllers under a single lock. Or you'll >> : probably try something dangerous and tricky with dropping the new >> global >> : lock and picking up an individual lock, then swizzling locks in the >> : completion and event paths, with the result being rather unsatisfying >> : and unpleasant. So I know that you'll do what you believe is correct, >> : but please take my advice on the matter anyways. >> >> Yes. A SIM will serialize all operations, and the most logical place >> for that is the computer <-> usb interface, which is the host >> controller. So having one SIM per host controller would be the >> optimal placement. Having one SIM per usb device doesn't result in >> any more real parallelism because the host controller necessarily >> serializes things because of how USB is defined... >> > > Correct. Another argument for having a SIM per controller/bus and not > per target is that the SIM is responsible for managing all resources on a > controller. USB is still a bus topology, and thus certain resources are > finite and shared, be they bandwidth, arbitration, or concurrency. > Granted, USB is simple enough that it doesn't give you much control over > these resources, but having the SIM be at the target level gives the > system even less control and visibility. If a future enhancement to USB > grows the ability to do useful things like more concurrency, it'll be > essential for the SIM to have a controller-wide view of this. cam/umass used to have a SIM per USB bus but it got changed sometime around 1999-2001 from memory. It was haled at the time as a great step forward when each device got its own SIM but I could never work out why. it did solve some problems though I forget what they where. > > Scott > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"