From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 20:04:25 2007 Return-Path: Delivered-To: embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7280916A41B for ; Fri, 28 Dec 2007 20:04:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 12C1A13C467 for ; Fri, 28 Dec 2007 20:04:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lBSJwgZx076365; Fri, 28 Dec 2007 12:58:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 13:03:29 -0700 (MST) Message-Id: <20071228.130329.43010549.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20071228.114559.-311937481.imp@bsdimp.com> <20071228.121213.-494094613.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: embedded@freebsd.org Subject: Re: ocpbus(4) X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 20:04:25 -0000 In message: Marcel Moolenaar writes: : On Dec 28, 2007, at 11:12 AM, M. Warner Losh wrote: : : > If the ocpbus has a table of bus types, what's wrong with having it : > directly assign the driver when it ads its children? : : It violates newbus in that drivers compete for a device. : If the bus assigns the driver, then there's no competition : possible. The fact that the bus is abstract should not : mean that we should change its paradigm. No it doesn't. There's two kinds of busses in newbus. Those that self enumerate based on the hardware present (ie pccard, pci, usb, firewire) and then those that are told what's there (oldcard-style pccard, pure ISA, I2C, etc). The busses on the SoC more strongly resemble the latter than the former. The former busses already are enumerated with hints, but the actual mechanism is just a few calls that could be replaced with something better. : > I guess I agree with you that we need an abstraction layer, but : > quibble over the details. I especially object to creating an : > enumeration where an actual device driver name would do. : : Agreed. We should not use device driver names. We could use : strings instead of numbers, but other than that it's an : abstract name or number that. : : > Plus the : > problem is complicated because none of these devices is standard. : > Sorry if my first reply came on a little strong on the enumeration : > point. If there is a compelling argument for it, I'll listen, but it : > isn't as if we have competing drivers for devices in this domain like : > we did with sio vs uart. : : We should not abandon competition, because that would : be a step away from generalization. Even though we're : discussing this in the context of embedded systems, : I don't see any reason why it couldn't equally apply to : the LPC devices in PCs that are enumerated by ACPI... That's a different case. Do not confuse these cases. ACPI has a table of devices that associated resources with an ID. There's no such tables in the SoC world, typically. At most, you have a CPU ID you can read and from that know, based on a hardwired set of tables, the devices that are present. It isn't extensible in any way when a new CPU ID comes along. With ACPI you'd get new devices and you wouldn't worry. With the new CPU ID in the SoC world, you'd get nothing until you created a new table. Any construction of an artificial device ID would likely just make it harder to write drivers for these platforms. Rather than just adding a driver and something to the table (hints, say) and having it work, one would have to also allocate a new device ID (one that might conflict with others doing similar work, causing integration problems later) as well as write code to test for that ID. I guess I don't see that many SoCs that have that many devices that are shared with others. 16550-like UARTs are about the only thing that has any big amount of commonality. The rest of the devices are specific to a chip or a small family of chips. Even the 16550 uarts are wired up differently and have different access requirements. : True, competition is not likely to be a often-used : feature in an embedded system but modules may be and : it's so much easier to deal with modules if you keep : the existing paradigm and not have the bus driver : assign device drivers. For in that case the bus driver : need to be made aware that a new device driver was : loaded and see if it's one it can assign to a device. They aren't incompatible at all. The device creates a node in the new bus tree that's assigned to "at91_twi" for instance. If there's no at91_twi driver loaded, then nothing happens. If one is later loaded, at91_twi will automatically probe that device. The name is what is important. When a module that implements a device of the right name is loaded, the right things happen. OLDCARD did this for years, and I've done it more recently with I2C stuff. If you load/unload drivers like this, it just works. You don't need competition for this to work. That doesn't answer the question of 'Is competition always needed?' but that's a point we differ on. Warner