On 30/04/17 13:49, Mark Brown wrote: > On Thu, Apr 27, 2017 at 10:42:49AM +0100, Sudeep Holla wrote: >> On 26/04/17 14:55, Mark Brown wrote: > >>> As I'm getting fed up of saying: if the values you are setting are not >>> voltages and do not behave like voltages then the hardware should not be >>> represented as a voltage regulator since if they are represented as >>> voltage regulators things will expect to be able to control them as >>> voltage regulators. This hardware is quite clearly providing OPPs >>> directly, I would expect this to be handled in the OPP code somehow. > >> I agree with you that we need to be absolutely sure on what it actually >> represents. > >> But as more and more platform are pushing such power controls to >> dedicated M3 or similar processors, we need abstraction. Though we are >> controlling hardware, we do so indirectly. Since there were discussions >> around device tree representing hardware vs platform, I tend to think, >> we are moving towards platform(something similar to ACPI). > > I don't think there's a meaningful hardware/platform distinction here - > in terms of what DT is describing the platform bit is just what the > hardware (the microcontrollers) happen to do, > Yes agreed. It's similar to PSCI or any other platform firmware IMO. The question is how do we deal with such controls that needs to be done via the firmware ? We generally plug-in to the existing framework in Linux using the existing bindings. Most of the time, much simpler bindings than the one that present complete hardware description. > DT doesn't much care about that though. No sure about that, may be doesn't care about the internals, but we need to care about interface, no ? -- Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
