Loading drivers based on board identification

Loading drivers based on board identification

[Mark Brown]

Recently there's been quite a bit of discussion surrounding how to set
up machine specific hardware that can't readily be represented in the
device tree.  I was wondering if one way of solving these problems might
be to provide a mechanism for drivers to load based on board type rather
than by binding to nodes in the device tree, similar to DMI on x86
systems?

The particular case that this has been cropping up for is ASoC machine
drivers - these are drivers which specify how the components of an
embedded audio subsystem (each of which has its own driver) should be
used together to make a functional ALSA device.  Broadly, it will say
something along the lines of "The audio codec at this I2C address is
connected to one or more SSI ports on the SoC and these are clocked in
the following way", though it can get much more complex.  

This isn't a property of any of the component devices - it's all about
the relationships between these devices - and it gets sufficiently
complex in many systems that it's not realistic to try to encode it in
the device tree.  There is normally no specific hardware associated with
this that isn't controlled by one of the component drivers which makes
it difficult to fit into the device tree - in hardware terms this
roughly corresponds to the physical board the system is on.

Since this is difficult to represent in an idiomatic way in the device
tree probing based on the board type seems like reasonable solution.

RE: Loading drivers based on board identification

[Stephen Neuendorffer]

Mark,

I'm very interested in trying to factor out board data from the device
tree, but for slightly different reasons, I think.  (Although I don't
exactly understand what you're proposing...)

In FPGA-based designs, it would be nice to be able to describe a device
tree fragment for the board, which includes things like PCI interrupt
maps, ethernet phy information and i2c bus information and orthogonalize
it from the information in the FPGA (which should only be dependent on
the IP in the FPGA).  This should allow the generation of the FPGA
device tree to be independent of the board.

I don't yet have a proposal, but I'd be curious to hear your thoughts.

Steve

> -----Original Message-----
> From: linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of Mark
Brown
> Sent: Tuesday, June 17, 2008 1:27 PM
> To: linuxppc-dev@ozlabs.org
> Subject: Loading drivers based on board identification
> =

> Recently there's been quite a bit of discussion surrounding how to set
> up machine specific hardware that can't readily be represented in the
> device tree.  I was wondering if one way of solving these problems
might
> be to provide a mechanism for drivers to load based on board type
rather
> than by binding to nodes in the device tree, similar to DMI on x86
> systems?
> =

> The particular case that this has been cropping up for is ASoC machine
> drivers - these are drivers which specify how the components of an
> embedded audio subsystem (each of which has its own driver) should be
> used together to make a functional ALSA device.  Broadly, it will say
> something along the lines of "The audio codec at this I2C address is
> connected to one or more SSI ports on the SoC and these are clocked in
> the following way", though it can get much more complex.
> =

> This isn't a property of any of the component devices - it's all about
> the relationships between these devices - and it gets sufficiently
> complex in many systems that it's not realistic to try to encode it in
> the device tree.  There is normally no specific hardware associated
with
> this that isn't controlled by one of the component drivers which makes
> it difficult to fit into the device tree - in hardware terms this
> roughly corresponds to the physical board the system is on.
> =

> Since this is difficult to represent in an idiomatic way in the device
> tree probing based on the board type seems like reasonable solution.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev


This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.

Re: Loading drivers based on board identification

[Mark Brown]

On Tue, Jun 17, 2008 at 02:31:03PM -0700, Stephen Neuendorffer wrote:

> I'm very interested in trying to factor out board data from the device
> tree, but for slightly different reasons, I think.  (Although I don't
> exactly understand what you're proposing...)

Sorry, I should have gone into a *little* more detail about what DMI
information actually is.  DMI provides device management data - you can
see the things that Linux supports in include/linux/dmi.h.  Of most
relevance to what I'm talking about here is information like the board,
chassis and system manufactuer, product name and version though there is
other, more device tree style, information in there.

This information can be queried by drivers to allow them to override
default behaviour based on knowledge about the system in a similar way
to how OpenFirmware but of more relevance here is that it is also
possible for drivers to use the module autoloading infrastructure to
automatically load modules which provide dmi: module aliases (for
example, this is used by the dcdbas driver which interfaces to Dell
system management controllers to automatically load on Dell systems).

> I don't yet have a proposal, but I'd be curious to hear your thoughts.

My proposal would be to essentially clone at least the system
information bit of the DMI API to provide equivalent information.