Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Quoting Nishanth Menon (2013-04-02 19:00:02) On 20:35-20130402, Andrii Tseglytskyi wrote: On 04/02/2013 08:16 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 20:35:45) On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. ACK. Making the ABB code into a regulator driver is the right thing to do regardless of whether or not we use a Super Regulator(tm) or just chain together Not So Super Regulators(tm). I'm not an expert at the regulator framework, but I encourage Andrii to look into regulator_set_mode(), which might be a more semantically accurate alternative than regulator_set_voltage() for the ABB ldo. Agree. It is a good idea in general. regulator_set_mode() API seems to be good enough for handling ABB mode (FBB/RBB/Bypass). Knowledge about ABB mode on each OPP can be moved from ABB regulator to Super regulator. Thanks a lot for all your comments. Digging a little more on this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/regulator/consumer.h#n41 If we were to mean usage of mode to mean - usage of PWM/PFM etc mode(like in tps/twl chips), this makes sense. However, if we mean forward, reverse and bypass as modes we might be misusing the original intent of the API. Yeah, I agree that using those modes would probably qualify as abuse. However I still find it tempting to use FAST for FBB and maybe NORMAL or STANDBY for bypass. Instead of using a mode then a voltage could be used. Any Vnom value passed into regulator_set_voltage would result in ABB ldo being bypassed, whereas if 900mV was passed in that would put the ABB ldo into FBB. And that 900mV value isn't really set in stone, it is just more often than not the value observed on OMAP3630 and OMAP4. However that is really a kludge and completely non-intuitive for someone looking at the code for the first time. I haven't gone digging through the regulator stuff concerning this but I hope a good solution can be found. Regards, Mike -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 04/02/2013 06:35 AM, Nishanth Menon wrote:
On 17:05-20130401, Mike Turquette wrote:
OK, so we're in agreement on what The Future looks like. What does that
mean for Andrii's patchset?
Unless anyone has an fundamental issue with the approach of an Super
regulator controlling sub regulators, I think, in-line with your
view, we should probably make ABB as an regulator instead of inventing
our own API and hooking it around clock notifiers.
Hi Nishanth, All
One question here, regarding Super regulator - How are you going to
differentiate
OPP changing and AVS Voltage adjustment requests to the Super regulator??
As you know, to select OPP changing direction, ABB type (or VC/VP
parameters)
properly you need Nominal (and only Nominal) voltage as input.
And in real world, AVS can adjust voltage, as example, for OPP100 even
low than for OPP50.
OMAP4 example:
MPU OPPVsrVnom ABB
OPP50 0.862249970436096 1.025 NOM
OPP100 1.03509700298309 1.2NOM
OPPTurbo 1.09257805347443 1.325 NOM
OPPNitro 1.18703103065491 1.388 FAST
OPPNitroSB 1.29427194595337 1.398 FAST
So, while adjusting voltage, AVS can hit other OPP voltage and, as
result, ABB mode may be changed.
I think, your vision would be more clear if you could be able to provide
Sequence diagram in addition.
And would it be allowed to use DT for such regulator chain definitions
(or board-generic.c should be used instead), just for clarification,
because I have not to much DT experience:
omap443x.dtsi:
vdd_mpu: regulator-omap-ti1 { -- Super regulator
compatible = ti,omapX-regulator;
regulator-min-microvolt = 75;
regulator-max-microvolt = 1388000;
smps-supply = smps_mpu; [or smps-supply = vcc;]
abb-supply = abb_mpu;
};
smps_mpu: regulator-omap-smps1 { --VC/VP regulator
compatible = ti,omapX-smps-regulator;
ti,vc = vc
ti,vp = vp_mpu
};
twl4030.dtsi
vcc: regulator-vdd1 {
compatible = ti,twl4030-vdd1;
regulator-min-microvolt = 60;
regulator-max-microvolt = 145;
};
Regards,
Grygorii Strashko
--
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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 13:15-20130402, Grygorii Strashko wrote:
On 04/02/2013 06:35 AM, Nishanth Menon wrote:
On 17:05-20130401, Mike Turquette wrote:
OK, so we're in agreement on what The Future looks like. What does that
mean for Andrii's patchset?
Unless anyone has an fundamental issue with the approach of an Super
regulator controlling sub regulators, I think, in-line with your
view, we should probably make ABB as an regulator instead of inventing
our own API and hooking it around clock notifiers.
Hi Nishanth, All
One question here, regarding Super regulator - How are you going
to differentiate
OPP changing and AVS Voltage adjustment requests to the Super regulator??
As you know, to select OPP changing direction, ABB type (or VC/VP
parameters)
properly you need Nominal (and only Nominal) voltage as input.
And in real world, AVS can adjust voltage, as example, for OPP100
even low than for OPP50.
OMAP4 example:
MPU OPPVsrVnom ABB
OPP50 0.862249970436096 1.025 NOM
OPP100 1.03509700298309 1.2NOM
OPPTurbo 1.09257805347443 1.325 NOM
OPPNitro 1.18703103065491 1.388 FAST
OPPNitroSB 1.29427194595337 1.398 FAST
So, while adjusting voltage, AVS can hit other OPP voltage and, as
result, ABB mode may be changed.
The expectation is that we will use Vnom in the super regulator. Vnom
does not change per OPP across devices. Expectation will be to use Vnom
as indexing key inside regulator framework.
I think, your vision would be more clear if you could be able to
provide Sequence diagram in addition.
I should be able to do better, I should be able to post a RFC revision
of the super regulator verifiable on Beagle XM using I2C1 (instead of
i2c_sr) as start, I will give it hooks to handle Efuse Vnom support
which our upcoming SoC needs as well.
And would it be allowed to use DT for such regulator chain definitions
(or board-generic.c should be used instead), just for clarification,
because I have not to much DT experience:
omap443x.dtsi:
vdd_mpu: regulator-omap-ti1 { -- Super regulator
I would not link only *OMAP* to this - as originally stated, this is
needed by OMAP, AM, DM and potentially, Keystone family of TI
processors.
How about we debate this with the super regulator patch?
[...]
--
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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 04/02/2013 08:16 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 20:35:45) On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. ACK. Making the ABB code into a regulator driver is the right thing to do regardless of whether or not we use a Super Regulator(tm) or just chain together Not So Super Regulators(tm). I'm not an expert at the regulator framework, but I encourage Andrii to look into regulator_set_mode(), which might be a more semantically accurate alternative than regulator_set_voltage() for the ABB ldo. Regards, Mike -- Regards, Nishanth Menon Hi, Agree. It is a good idea in general. regulator_set_mode() API seems to be good enough for handling ABB mode (FBB/RBB/Bypass). Knowledge about ABB mode on each OPP can be moved from ABB regulator to Super regulator. Thanks a lot for all your comments. Regards, Andrii -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 20:35-20130402, Andrii Tseglytskyi wrote: On 04/02/2013 08:16 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 20:35:45) On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. ACK. Making the ABB code into a regulator driver is the right thing to do regardless of whether or not we use a Super Regulator(tm) or just chain together Not So Super Regulators(tm). I'm not an expert at the regulator framework, but I encourage Andrii to look into regulator_set_mode(), which might be a more semantically accurate alternative than regulator_set_voltage() for the ABB ldo. Agree. It is a good idea in general. regulator_set_mode() API seems to be good enough for handling ABB mode (FBB/RBB/Bypass). Knowledge about ABB mode on each OPP can be moved from ABB regulator to Super regulator. Thanks a lot for all your comments. Digging a little more on this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/regulator/consumer.h#n41 If we were to mean usage of mode to mean - usage of PWM/PFM etc mode(like in tps/twl chips), this makes sense. However, if we mean forward, reverse and bypass as modes we might be misusing the original intent of the API. -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) In case if VC/VP use clock notifier to scale voltage, there is no guarantee of order. The only option which I see is to create ABB API and call it from OMAP regulator during OPP change. I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); Mike, do you agree to proceed in this way? Also I need you opinion about files placement. Now it is placed in The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. Regards, Mike drivers/power/avs/abb.c And header will be added to include/linux/power/abb.h Regards, Andrii -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On Mon, Apr 1, 2013 at 1:10 PM, Mike Turquette mturque...@linaro.org wrote: Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) In case if VC/VP use clock notifier to scale voltage, there is no guarantee of order. The only option which I see is to create ABB API and call it from OMAP regulator during OPP change. I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); Mike, do you agree to proceed in this way? Also I need you opinion about files placement. Now it is placed in The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. http://picpaste.com/KmqDYTn0.jpg is an quick depiction of the thought I have in my mind. We do have, in the upcoming SoCs, where Nominal Voltages per device, will now be encoded into the efuse itself(so called class 0 voltage). Future SoCs will need to be able to use ABB along with standard regulators (without use of VC-VP) - in fact, even today, SoCs like AM and DM series of processors have the same requirement. We also will have to support class 2 variants of AVS (which will use standard regulators to set voltage). As of date, CCF does not control regulators - which means the interim solution would be for the device control to manipulate both clock and regulator voltage (similar to what cpufreq-cpu0 driver does today). these drivers should not know the existance of SoC specific intricacies - so ABB linked to voltage values make more sense if ABB sequencing is handled in TI regulator Intent of VC/VP regulator is to be replaceable, on required platforms, with appropriate regulator which do not use VC/VP paths (e.g. on SoCs that do not have it). There is also need to support multiple voltage rails supplied by a single SMPS - in which case controlling via regulator framework is more desirable. --- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 14:34-20130401, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 12:28:20) On Mon, Apr 1, 2013 at 1:10 PM, Mike Turquette mturque...@linaro.org wrote: Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. http://picpaste.com/KmqDYTn0.jpg is an quick depiction of the thought I have in my mind. OK, looks like the Super Regulator Approach(tm). :D I hope it can be modelled after TI SoCs and then expanded to other SoCs as needed. We do have, in the upcoming SoCs, where Nominal Voltages per device, will now be encoded into the efuse itself(so called class 0 voltage). Future SoCs will need to be able to use ABB along with standard regulators (without use of VC-VP) - in fact, even today, SoCs like AM and DM series of processors have the same requirement. This de-linking of ABB from VC/VP probably supports modeling ABB ldo's as Linux regulators. That would provide a common interface where either the VC/VP code or another regulator could call something like regulator_set_mode. If we're going to export something which can get called by different actors it's best to use an already exported interface which the regulator framework supplies, instead of exporting something new and omap-specific. Yep - that was my original thought - though modeling it as a regulator in itself is, IMHO, I think is a good idea. We also will have to support class 2 variants of AVS (which will use standard regulators to set voltage). As of date, CCF does not control regulators - which means the interim solution would be for the device control to manipulate both clock and regulator voltage (similar to what cpufreq-cpu0 driver does today). these drivers should not know the existance of SoC specific intricacies - so ABB linked to voltage values make more sense if ABB sequencing is handled in TI regulator Intent of VC/VP regulator is to be replaceable, on required platforms, with appropriate regulator which do not use VC/VP paths (e.g. on SoCs that do not have it). Well if everything is nicely modeled then I suppose per-board and per-soc DT will give you the ability to link things up nicely. E.g. replacing VC/VP with an external physical LDO, etc. True - that is precisely what are attempting to do in (hopefully) edible stages :). -- 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 5/6] ARM: OMAP3+: ABB: introduce ABB driver
On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. -- 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
