Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Thu, Jun 13, 2013 at 10:07 AM, Mark Brown wrote: > On Thu, Jun 13, 2013 at 09:58:03AM -0500, Nishanth Menon wrote: > >> I am proposing moving the following into OF match data. >> ti,i2c-slave-address >> ti,i2c-voltage-register >> ti,i2c-command-register >> ti,slew-rate-microvolt >> ti,step-size-micro-volts >> ti,voltage-selector-set-bits >> ti,voltage-selector-mask >> ti,voltage-selector-offset >> ti,non-zero-voltage-selector > >> The only thing I propose to retain is board specific variations - e.g. >> gpios, boot voltage and standard regulator min,max overrides if any. > >> I can also do voltage selector based operations while at it. > > OK, this sounds like a step in the right direction. Thanks for the review and guidance. I will post a new RFC series with the above changes in a day or so. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Thu, Jun 13, 2013 at 09:58:03AM -0500, Nishanth Menon wrote: > I am proposing moving the following into OF match data. > ti,i2c-slave-address > ti,i2c-voltage-register > ti,i2c-command-register > ti,slew-rate-microvolt > ti,step-size-micro-volts > ti,voltage-selector-set-bits > ti,voltage-selector-mask > ti,voltage-selector-offset > ti,non-zero-voltage-selector > The only thing I propose to retain is board specific variations - e.g. > gpios, boot voltage and standard regulator min,max overrides if any. > I can also do voltage selector based operations while at it. OK, this sounds like a step in the right direction. signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 15:47-20130613, Mark Brown wrote: > On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote: > > > I am having a bit of a difficulty trying to understand your concern > > here. > > Your device tree for this stuff appears to mostly consist of repeating > the description of the PMIC that we already have - this really doesn't > seem like a great result. > > > Problem statement: > > > OMAP has this weird custom h/w where one programs the voltage and that > > voltage is send over i2c - this is not same as Tegra's lookup table > > array which automatically sends out entries, in OMAP, software has to > > trigger > > the voltage transition > > The basic idea that's important here is that you need to figure out how > to tell the hardware what to write - how those writes get triggered is a > separate problem. > > > If your concern was describing PMIC parameters in dts, I can easily move > > them inside the omap_pmic driver and provide required compatible flags. > > If, on the other hand, the entire approach followed is flawed, I'd like to > > understand the rationale for the same. > > That's the biggest problem I saw so far but to be honest I've not > drilled down too much into the specifics. From my point of view the > main thing is how this fits into the frameworks and so on, having the > register information in the DT was an alarm flag that suggested the > overall approach was a concern. OK. would you be ok with an generic omap_pmic driver if the PMIC specific data set is moved into OF compatible data? I am proposing moving the following into OF match data. ti,i2c-slave-address ti,i2c-voltage-register ti,i2c-command-register ti,slew-rate-microvolt ti,step-size-micro-volts ti,voltage-selector-set-bits ti,voltage-selector-mask ti,voltage-selector-offset ti,non-zero-voltage-selector The only thing I propose to retain is board specific variations - e.g. gpios, boot voltage and standard regulator min,max overrides if any. I can also do voltage selector based operations while at it. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote: > I am having a bit of a difficulty trying to understand your concern > here. Your device tree for this stuff appears to mostly consist of repeating the description of the PMIC that we already have - this really doesn't seem like a great result. > Problem statement: > OMAP has this weird custom h/w where one programs the voltage and that > voltage is send over i2c - this is not same as Tegra's lookup table > array which automatically sends out entries, in OMAP, software has to trigger > the voltage transition The basic idea that's important here is that you need to figure out how to tell the hardware what to write - how those writes get triggered is a separate problem. > If your concern was describing PMIC parameters in dts, I can easily move > them inside the omap_pmic driver and provide required compatible flags. > If, on the other hand, the entire approach followed is flawed, I'd like to > understand the rationale for the same. That's the biggest problem I saw so far but to be honest I've not drilled down too much into the specifics. From my point of view the main thing is how this fits into the frameworks and so on, having the register information in the DT was an alarm flag that suggested the overall approach was a concern. signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On 19:01-20130610, Mark Brown wrote: > On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote: > > > a) Tegra seems to use Lookup Table for sending predefinied voltage > > values to PMIC. OMAP has no concept of lookup table. > > They seem to be doing basically the same thing here, you've got a linear > map of selector to voltage too AFAICT. > > > b) Tegra and OMAP h/w blocks seem to use I2C - that is good. > > c) How about the i2c slave and register addresses, slew rates, start, > > end voltages, max voltages that SoC can support etc, I am yet to > > understand those. > > d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), > > Voltage Controller(VC) - I am not yet sure about the Tegra hardware > > blocks involved. > > This all seems like it's at the implementation detail level - the bit > that seems like we should be able to share it is the big picture bit for > how we describe how the AP side stuff and PMIC are hooked up without > having to have a bunch of completely non-framework stuff for things > like describing the PMIC. I am having a bit of a difficulty trying to understand your concern here. Problem statement: OMAP has this weird custom h/w where one programs the voltage and that voltage is send over i2c - this is not same as Tegra's lookup table array which automatically sends out entries, in OMAP, software has to trigger the voltage transition This path is split into 3 different modules - AVS, VC, VP -> This is implementation detail as you already mentioned. Anyhow, to recap, the overview of the hardware interface is as follows: PMIC that OMAP interfaces to are of two categories: a) ones that talk only on the custom OMAP VC path b) ones that talk both custom OMAP VC and regular i2c (e.g. twl4030,6030,palmas) The voltage control for a voltage rail (e.g. vdd_mpu) is again PMIC specific a) 6030 will not allow voltage to be set over regular i2c b) 4030 allows either custom i2c path OR regular i2c path (only 1 at a time). c) palmas allows both custom i2c path AND regular i2c path to set voltage! >From a Linux angle, when using regular i2c, it is a piece of cake. Standard regulator uses regular i2c, vc-vp angle avoided Example: Palmas: we'd use the regular palmas driver to do this. When using custom i2c path(vc/vp/avs), it gets a bit complex We'd like (if possible) drivers like cpufreq to be ignorant of regulator and transfer path used ofcourse as this depends on the board component selection. E.g. 4030/palmas/6030 vdd_mpu can be represented as a regulator, which in turn uses custom OMAP data transfer path to set voltage I was trying to understand your statement as to what Paul was doing (which was basically pull out the vsel values and put them in his hardware lookup table for h/w to auto send the voltage) Vs what I was attempting to do (describe OMAP's view of the PMIC and provide data path). In my view, we were trying to do "voltage scale" in two completely different ways depending on the SoC we were working on. If your concern was describing PMIC parameters in dts, I can easily move them inside the omap_pmic driver and provide required compatible flags. If, on the other hand, the entire approach followed is flawed, I'd like to understand the rationale for the same. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote: > a) Tegra seems to use Lookup Table for sending predefinied voltage > values to PMIC. OMAP has no concept of lookup table. They seem to be doing basically the same thing here, you've got a linear map of selector to voltage too AFAICT. > b) Tegra and OMAP h/w blocks seem to use I2C - that is good. > c) How about the i2c slave and register addresses, slew rates, start, > end voltages, max voltages that SoC can support etc, I am yet to > understand those. > d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), > Voltage Controller(VC) - I am not yet sure about the Tegra hardware > blocks involved. This all seems like it's at the implementation detail level - the bit that seems like we should be able to share it is the big picture bit for how we describe how the AP side stuff and PMIC are hooked up without having to have a bunch of completely non-framework stuff for things like describing the PMIC. signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown wrote: > On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: >> On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: >> > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > >> > So, the biggest problem here has been patch 4 (having to have a hack to >> > deploy this stuff is a bit worrying) plus the general not having a real >> > driver thing. > >> Patch #4 in this series was a hack as it was not properly split up and >> organized as a proper DTS series -it was meant as a proof of concept - >> not entirely meant to indicate the remaining 1-3 patches were hacks >> :). > > The way it reads is that you're building up to a hack - if what you've > done isn't enabling a sensible solution there might be a problem with > the earlier steps. Understood, I should have taken extra steps to split up the patch into it's logical series, but wanted to get a quick feel from community about the approach before spending time on it. I apologize for the confusion caused. > >> I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I >> will dig into it. if it is possible for Tegra and OMAP to use the same >> framework and strategy to deal with these kind of h/w blocks, all the >> more better. > > Not just better, if each system doing this sort of thing needs to > reinvent the wheel something is going wrong. Fair enough, I did spend a short while digging through the discussion in the series, I need to find Tegra TRM to see if there is commonolity between OMAP and what Tegra does at hardware level. a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. maybe Paul could comment as well, I suppose if we could take a common approach between Tegra and OMAP. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: > On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: > > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > > So, the biggest problem here has been patch 4 (having to have a hack to > > deploy this stuff is a bit worrying) plus the general not having a real > > driver thing. > Patch #4 in this series was a hack as it was not properly split up and > organized as a proper DTS series -it was meant as a proof of concept - > not entirely meant to indicate the remaining 1-3 patches were hacks > :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. > I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I > will dig into it. if it is possible for Tegra and OMAP to use the same > framework and strategy to deal with these kind of h/w blocks, all the > more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. signature.asc Description: Digital signature
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
+Paul. On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown wrote: > On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: > > So, the biggest problem here has been patch 4 (having to have a hack to > deploy this stuff is a bit worrying) plus the general not having a real > driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). > >> +- ti,i2c-slave-address - I2C slave address of the PMIC >> +- ti,i2c-voltage-register - I2C register address where voltage commands are >> + to be set. >> +- ti,i2c-command-register - I2C register address where commands are to be >> set >> + when OMAP enters low power state. This may be the same as >> + ti,i2c-voltage-register depending on the PMIC. >> +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage >> + transition in microvolts per microseconds (uV/uS) >> +- step-size-micro-volts - Step size in micovolts as to what one step in >> voltage >> + selector increment translates to. See example. >> +- regulator-min-microvolt - Minimum voltage in microvolts which is >> supported by >> + the PMIC in ti,step-size-microvolt increments. See example. >> +- regulator-max-microvolt - Maximum voltage in microvolts which is supported >> + by the PMIC in ti,step-size-microvolt increments. See example. > > The other thing is this whole business of encoding the properties of the > PMIC in the DT like this. Paul Walmsley has started doing some work for > some similiar hardware where instead of doing this the regulator is in > the DT as normal and then the driver for the offloaded voltage scaling > gets the information about the register layout from the regulator > driver. This is a bit neater overall and would cope with determining > which method to use at runtime. I think you mean http://marc.info/?t=13705924913&r=1&w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. > +- ti,i2c-slave-address - I2C slave address of the PMIC > +- ti,i2c-voltage-register - I2C register address where voltage commands are > + to be set. > +- ti,i2c-command-register - I2C register address where commands are to be set > + when OMAP enters low power state. This may be the same as > + ti,i2c-voltage-register depending on the PMIC. > +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage > + transition in microvolts per microseconds (uV/uS) > +- step-size-micro-volts - Step size in micovolts as to what one step in > voltage > + selector increment translates to. See example. > +- regulator-min-microvolt - Minimum voltage in microvolts which is supported > by > + the PMIC in ti,step-size-microvolt increments. See example. > +- regulator-max-microvolt - Maximum voltage in microvolts which is supported > + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. signature.asc Description: Digital signature
[RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI custom hardware block to better facilitate and standardize integration of Power Management ICs which communicate over I2C. In fact, many custom PMICs were designed to be usable over this interface. On the other hand, generic PMICs which are compatible to the I2C protocol supported by Voltage controller may also be used. In general, the following categories of PMICs exist: a) PMICs which are completely controlled by voltage controller/voltage processor pair - this implies even configuration needs to be done over the same interface. Example: TPS62361 used on PandaBoard-ES and many OMAP4460 based platforms. Few Maxim and Fairchild PMICs used on certain products would fall in this category. - Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver" b) PMICs which provide two views over two I2C interfaces - however, voltage can only be set only on one of them. Example: TWL4030/5030: allows us to use Voltage controller once we set up a bit over regular I2C - This is used in OMAP3. TWO6030/TWL6032 - configuration *has* to be performed over regular i2c (example smps_offset) and voltage control *has* to be performed by using voltage controller/processor. - Note: in this case, there may exist "traditional Linux regulator driver" however, it may not support in any form SMPS modelling for that part of the device which is exposed to voltage controller/processor. c) PMICs which allow voltage and configurations over either i2c interfaces - TWL6035/TWL6037/Palmas family of TI processor - Note: in this case, there may exist "traditional Linux regulator driver" and, it may support in some form SMPS modelling for that part of the device which is exposed to voltage controller/processor. d) custom PMICs which are setup so that no configuration is needed to be performed and they operate with preset register offsets and minimal conferability using voltage controller/processor. - Note: in this case, there may not even exist/needed to support an "traditional Linux regulator driver" However, no matter the type of PMIC used, the OMAP view of a PMIC is generic when used over voltage controller/processor. We attempt to model this generic view of the regulator represented by OMAP SoC. Alternative to this approach would be to "hack" into the get voltage/set voltage interfaces of regulator drivers which represent the rest of the PMIC controlled over regular I2C interface and re-route the requests to voltage controller/processor. But, by doing that, we needlessly create additional code which may be abstracted out into device tree node information. Since the regulator node representing PMIC, voltage controller, processors are probed at varied points in time, probe deferral is used to sequence in the right order. It is expected by the driver to register omap_pmic_register_controller_ops providing mandatory operations at the earliest possible opportunity. Despite the current SoCs implementing the solution based on voltage controller and voltage processor (which are part of the OMAP SoC modules which enable Adaptive Voltage Scaling class support), the interfaces are generic enough to handle future equivalent modules. [grygorii.stras...@ti.com: co-developer] Signed-off-by: Grygorii Strashko Signed-off-by: Nishanth Menon --- .../bindings/regulator/omap-pmic-regulator.txt | 121 + drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/omap-pmic-regulator.c| 554 include/linux/regulator/omap-pmic-regulator.h | 147 ++ 5 files changed, 835 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt create mode 100644 drivers/regulator/omap-pmic-regulator.c create mode 100644 include/linux/regulator/omap-pmic-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt new file mode 100644 index 000..b87dd3c --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/omap-pmic-regulator.txt @@ -0,0 +1,121 @@ +Generic Power Management IC(PMIC) Regulator for Texas Instruments OMAP SoCs + +Required Properties: +- compatible: Should be: + - "ti,omap-pmic" + +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector incr
