On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote: [...] > In general, the kernel still needs a complete driver to every last > device on every strange board, and needs to support every strange way > some random board hooks all the devices together. [...] This may only be slightly related and it doesn't address all the points you brought up here, but for lack of a better place, here goes. I've had an interesting discussion with a friend over the weekend which eventually turned to a similar topic. With all the recent discussions about how to push board-specific details out into firmware, perhaps a more drastic measure would be to push for standardization of hardware interfaces. For instance, one of the reason we have so much code in the kernel is because every driver needs to talk to hardware through a slightly different set of registers. Perhaps it would be possible to get some discussion going about standardizing register interfaces for various components. This has already been done for 16550 UART and the same should be possible for a wide variety of other controllers such as I2C or SPI. There have been some attempts at creating reusable IP blocks, I think ARM does have quite a few which can be licensed. At the same time, many vendors may already have their own IP so it makes little sense for them to license third party IP just to provide a standard interface for drivers. However it might be easy in many cases to support the standard interface using custom IP blocks. I suspect something similar could be done for much of the clock, power and reset requirements of IP blocks. Now I know little about how exactly an SoC is designed these days, but I can imagine that it would be easy to move out some of the complexity into hardware by defining something like a standard register to enable a block. If each block has that standard register it becomes trivial to write driver and SoC support. It essentially becomes a matter of calling a platform_device_enable() function, analogous to pci_enable_device(). There would no longer be a need for the kind of intra-SoC glue that's taking up a significant amount of code these days. Obviously an effort such as the above is on a completely different scale and would require many vendors to sit together and work something out. But this isn't new either. After all there are committees and consortia that already do this in some areas (Khronos). Many of these working groups seem to focus mostly on software specifications, but what would prevent them from doing something similar on a hardware interface level? There are of course some dangers to this as well. Since much of the complexity is moved into hardware, bugs can no longer be fixed or easily worked around in software. However to some degree the same is true for scenarios where a lot of the complexity is moved into firmware instead, since that's typically not easily replaceable or fixable either. Thierry
Attachment:
pgpF2m3WCwNuy.pgp
Description: PGP signature
