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
