On Tue, Apr 05, 2016 at 03:51:18PM +0300, Octavian Purdila wrote: > On Tue, Apr 5, 2016 at 12:40 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > So this is mainly targeted at modules being added to base boards? > That is the main use case, yes. Velocity of platform > debugging/enabling is another one. The speed thing sounds like someone needs to work on the tooling for working on firmware TBH. > > This means that any binding of a board to an ACPI > > using system that just uses this is going to be entirely specific to the > > particular combination of base and expansion board even if the > > electrical connections are standard. > This can be solved by tools that work with high level abstractions and > generate this specific information. Simply stating that there are in future going to be some higher level things which make use of this firmware interface isn't altogether reassuring when we're still in the process of solving the issues for the DT version of this... > > This is something that people are currently looking at for DT, there the > > discussion has been about defining the connectors as entities and hiding > > the details of the muxing on the SoC behind that along with higher level > > concepts like instantiation of buses like I2C and SPI. It seems like if > > we do want to try to share between DT and ACPI we should be doing it at > > that level rather than dealing with pinmuxing at the extremely low level > > that pinctrl does. > At some point we still need to poke registers. We already have a > drivers that do this (pinctrl) and a standard configuration interface > (the pinctrl device tree bindings). It seems natural to build on top > of this for those higher level concepts / tools. Both DT and ACPI have a system model behind them and they're not the stame system model. Importing one into the other directly without carefully thinking through how they play nicely with each other seems likely to lead to problems further down the line, you might know exactly how you intend this to work but how do we make sure that a firmware author in some system integrator knows about this and is able to safely write firmware in a few years?
Attachment:
signature.asc
Description: PGP signature
