Date: Fri, 28 Dec 2007 15:04:43 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.150443.-924279995.imp@bsdimp.com> In-Reply-To: <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net> References: <C95AFF48-2C06-40FA-BDB4-C46011EECCF3@juniper.net> <20071228.130329.43010549.imp@bsdimp.com> <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net>
Marcel Moolenaar <marcelm@juniper.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.150443.-924279995.imp>