Date: Fri, 12 Sep 2008 21:09:45 -0700 From: Julian Elischer <julian@elischer.org> To: Scott Long <scottl@samsco.org> Cc: current@freebsd.org, fbsd-current@mawer.org, freebsd-usb@freebsd.org, volker@vwsoft.com Subject: Re: "legacy" usb stack fixes Message-ID: <48CB3D09.4050908@elischer.org> In-Reply-To: <20080912150630.C39726@pooker.samsco.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > On Fri, 12 Sep 2008, M. Warner Losh wrote: > >> In message: <48CAB37F.50002@samsco.org> >> Scott Long <scottl@samsco.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48CB3D09.4050908>