From owner-freebsd-embedded@FreeBSD.ORG Fri Dec 28 22:07:09 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 CC3FE16A417 for ; Fri, 28 Dec 2007 22:07:09 +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 8888B13C458 for ; Fri, 28 Dec 2007 22:07:09 +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 lBSLxstW077728; Fri, 28 Dec 2007 14:59:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 28 Dec 2007 15:04:43 -0700 (MST) Message-Id: <20071228.150443.-924279995.imp@bsdimp.com> To: marcelm@juniper.net From: "M. Warner Losh" In-Reply-To: References: <20071228.130329.43010549.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 22:07:10 -0000 In message: Marcel Moolenaar writes: : This has nothing to do with the origin of the device tree : (firmware, kernel or other) or whether the bus is self- : enumerating or not. Any bus that's not self-enumerating : is enumerable in some other shape or form, including those : that need hardcoded tables in the kernel. I don't care and : that's why I want it abstracted from drivers. They should : not have to care either. I think you and I are arguing just to argue at this point. You can achieve your goals. : > : > 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. : : Yes there is. If the table is not in firmware, it : typically is in the kernel. The ID may not be needed : if the table references the driver directly, but : other than that it's exactly the same. There's no : confusion. There's simply no distinction. Somewhere : it's recorded that something exists. The ocpbus(4) : idea is to abstract the details of where that : information comes from by making it available in a : generic way. I guess my point is that you are creating extra work here. I've tried to be nice in saying that. All we're doing is creating an extra layer of abstraction that buys us nothing. You've not articulated how this extra layer saves code, or provides a better interface to the kernel other than to say, basically, it is more like pci. Have I missed this somewhere? : > 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. : : My point exactly ;-) : : > 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. : : It's irrelevant to the abstraction whether a new : device is dynamically found or whether it needs : to be added to some static table by virtue of a : firmware or kernel upgrade. The ability to allow : a dynamic scheme does not impact static schemes. What is it you are trying to say here? We're never going to get around the fact that we have to have a different bus attachment for each of the enumeration mechanisms in the kernel. ACPI is always going to be special in some way. PCI is always going to be special in some way. Even if these two differ only by the tables they have to attach a device. The opcbus is also going to be special in some way. You and I disagree about how to make it special. You are advocating, if I read your proposal correctly, creating an artificial device identifier that is one or more integers of some flavor and then using that to match in a probe routine. There's a lookup in a table and a translation to a device number, effectively. I'm advocating a translation to a string. A string that happens to be the device and, possibly, the unit number of the device. My method doesn't require the addition of enumerations to tables and the string can be passed directly to newbus. The bus layer itself doesn't need to know about anything else, and doesn't need to change, apart from a new table, when new busses are added. This has the side effect of making the probe routine always return 'matched' in some fashion. If I understand your proposed method, then we would create a new integer of some flavor assigned for each and every type of device there is. You'd have us have something like: #define DEVICE_TYPE_UART 1 #define DEVCIE_TYPE_NETIF 2 #define DEVICE_TYPE_MMCSD 3 #define DEVICE_TYPE_SYNC 4 #define DEVICE_TYPE_SPI 5 #define DEVICE_TYPE_WIRELESS 6 #define DEVICE_TYPE_OHCI 7 #define DEVICE_TYPE_PCIB 8 #define DEVICE_TYPE_UHCI 9 ... #define DEVICE_ID_16550 1 #define DEVICE_ID_ATMEL_SERIAL 2 #define DEVICE_ID_ARM_LTD_SERIAL 3 #define DEVICE_ID_CIRRUS_SERIAL 4 #define DEVICE_ID_ATMEL_SSC 5 #define DEVICE_ID_ATMEL_MCI 6 #define DEVICE_ID_ATMEL_MCI2 7 #define DEVICE_ID_ATMEL_ETHER 8 /* AT91RM9200 ethernet device */ #define DEVICE_ID_ATMEL_ETHER2 9 /* AT91SAMxxx ethernet device */ #define DEVICE_ID_ATMEL_SPI 10 #define DEVICE_ID_ATMEL_TWI 11 #define DEVICE_ID_ATMEL_RTC 12 #define DEVICE_ID_ATMEL_PMC 13 #define DEVICE_ID_ATMEL_ST 14 #define DEVICE_ID_ATMEL_SERIAL_DBGU 15 /* Special, limited func serial port */ #define DEVICE_ID_ATMEL_UDP 16 #define DEVICE_ID_ATMEL_PIO 16 #define DEVICE_ID_CIRRUS_ETHER 18 #define DEVICE_ID_CIRRUS_GPIO 19 #define DEVICE_ID_XSCALE_MMC1 20 #define DEVICE_ID_XSCALE_MMC2 21 #define DEVICE_ID_XSCALE_MMC3 22 #define DEVICE_ID_XSCALE_GPIO 23 ... Am I understanding your proposal correctly? I can't see how else it would work if this isn't the case, but if you have some clever scheme, I'd be interested. Warner