On 10/08/2014 04:34 PM, Mark Brown wrote: > On Wed, Oct 08, 2014 at 03:44:05PM +0200, Javier Martinez Canillas wrote: > >> +- regulator-initial-mode: initial regulator operating mode. One of following: >> + <1>: REGULATOR_MODE_FAST - Regulator can handle fast changes. >> + <2>: REGULATOR_MODE_NORMAL - Normal regulator power supply mode. >> + <4>: REGULATOR_MODE_IDLE - Regulator runs in a more efficient mode. >> + <8>: REGULATOR_MODE_STANDBY - Regulator runs in the most efficient mode. >> + modes are defined in the dt-bindings/regulator/regulator.h header and can be >> + used in device tree sources files. If no mode is defined, then the OS will not >> + manage the operating mode and the HW default values will be used instead. > > ...and as previously and repeatedly discussed this still gives the user > no way of telling if or how these modes might correspond to what the > chip is capable of doing. This really needs addressing rather than > ignoring, for example by not trying to define the modes in generic > bindings. > Drivers could add custom per-device DT properties. That is how it was solved in the ChromeOS kernel. There is a regulator-op-mode DT property whose value is just a magic number with the value that has to be written in the OPMODE field of the control register of each regulator and that is made on the driver probe. Another option is to not document the standard modes in the generic regulator binding but instead on each device DT binding doc. That way each device binding can define what are the semantics of the standard modes and how correspond to the real modes in the chip. That way the regulator-initial-mode could still be generic and parsed by the core instead of each driver implementing their own custom parsing. Best regards, Javier -- 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
