Date: Fri, 28 Dec 2007 16:32:57 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.163257.756911359.imp@bsdimp.com> In-Reply-To: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> References: <B62C4CEF-F7CE-4388-B57F-288812BD9696@juniper.net> <20071228.150443.-924279995.imp@bsdimp.com> <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net>
Marcel Moolenaar <marcelm@juniper.net> writes:
: On Dec 28, 2007, at 2:04 PM, M. Warner Losh wrote:
:
: > 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.
:
: Euh... the whole point of our discussion is exactly about creating
: an abstraction layer that hides the details of the enumeration
: mechanism from the driver so that you can in fact have a single bus
: attachment.
:
: ocpbus(4) is inherently useless if we still need to create different
: bus attachments for different, bus similar, busses. While I don't
: intend ocpbus(4) to be the one and only bus attachment, it should at
: least unify busses and/or configurations that aren't self-enumerating.
I think that's a noble goal. However, I think that it might be an
unreachable goal. Maybe we should talk about how we're going to deal
with the following situations that come up in the ARM port. That
might help see how close we can come to this ideal. Maybe I'm just
too jaded by my experience so far and you've discovered a cool way
around this problem.
The usb driver on atmel needs to manipulate the clock generator when
it is attached to generate the 48MHz needed for the USB devices.
However, when the driver isn't present in the kernel, the right thing
to do is to keep this clock off because it uses power. How could this
be done generically?
On the xscale port, there's support for the compact flash that lives
on many of them. There's a number of chip-specific and board-specific
hacks that must happen in order for the generic driver to work.
On the mips platform there are at least two flavors of 16550-like
uarts present. One requires 32-bit access that's shifted 3 and the
other 64-bit access that's shifted 4.
The SPI, and MMC drivers need to interact with the chip selects the
chip offers. The manner of these interactions varies based on the
underlying SoC.
Right now, all of these situations are dealt with by having a bit of
code in a specific attachment cope.
: > 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.
:
: No, this is more or less the gist of it. The type and id
: can be chosen in any way we like, including using the type
: as the id. The abstract bus driver does not need to know
: anything other than maybe translate a table into a newbus
: hierarchy and using the type/id combination to flag a
: child.
How does this abstract driver know about the children to add? Or
rather, how were you envisioning it getting the table it needed?
: Any newbus node that implements the ocpbus handshake is
: then automatically an ocpbus driver even though there's
: no mention of how it obtains the device information. As
: I said before: it's about avoiding the flurry of bus
: attachments, not about dictating how devices are
: enumerated.
I agree that's a noble goal, and maybe we can avoid it in many cases,
but not in all cases. I just don't think having a large enumeration
table to make this work is worth the effort of maintaining it. When
you go to add a new ocpbus driver, you need to touch additional places
than the direct method.
Now, apart from enumeration, I think that having a good, well known
protocol would be good. I'm still a little unclear how one would
communicate some of the stuff to the drivers, but I'm doing a p4 sync
right now to get the e500 branch so I can take a look at what's there.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.163257.756911359.imp>