On 14:43-20130802, Sudeep KarkadaNagesha wrote: > On 01/08/13 17:49, Stephen Warren wrote: > > On 08/01/2013 07:54 AM, Mark Rutland wrote: > > ... > >> We seem to be going over two cases, which both feel wrong to me: > >> > >> * One SoC used in multiple boards, where on some boards an OPP cannot be > >> used because some requirement is not met. In this case, the board's > >> dts (by including the SoC's dtsi) describes something that's not > >> necessarily usable, and we seem to have no way to describe in the OPP > >> table that the OPP is not usable for that board. > > > > There are probably a lot of examples of this already. For example, for > > pinctrl, people often want the SoC .dtsi file to include "pin > > configuration nodes" (see > > Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt) for many > > common pinmux configurations in the SoC .dtsi file, so that board files > > can simply refer to the already-existing nodes rather than having to > > write everything from scratch. Obviously, not all common configurations > > are used by every board. > > > > ... > Agreed, but I am not convinced with the comparison(pinmux and OPPs). > The main concern I have is that if some developer wants to experiment > with various configurations provided by SoC(e.g. I have seen some SoC > where the pinmux have multiple functions and you can chose one of them) > But that's not true with OPPs, if someone experiments with wrong OPP > profile, then it might damage the board permanently. Even today, nothing prevents folks from "adding custom OPPs" at their own personal risk here - We have seen folks do this as part of board files - Now, for that matter, there is nothing that prevents folks linking the wrong LDO or setting wrong LDO voltage and damaging the board either. I mean, at the level where we "describe" the hardware and it's operation, you cannot be idiot or experimenter-proof - If these were to be considered paramount and prevent us from choosing the right concept that is needed for as many SoCs as possible, it'd be a shame. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
