Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 03/14/2013 03:58 PM, Nishanth Menon wrote: > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in > migrating the cpufreq support only through device tree (part of the effort > to migrate away from non-DT configurations for OMAP). Unfortunately, as > already > known, we have a bunch of legacy code and mutually dependent device tree > conversion that is pending. > Key features pending: > A) clock framework transition to DT - this should happen soon, so this series > hacks > the clock node for the time being as suggested in review of original series > B) on processors that use voltage controller, voltage processor (VC/VP > hardware > loop using I2C_SR path) - we have started work on transitioning them to > regulator > framework driven by DT. > C) Adaptive Body Bias and SmartReflex AVS conversion to DT. > > As a result of these pending features: > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no > regulators > associated at the moment - fortunately, we boot at highest voltage, so things > still > work. > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have > not added > those OPPs in DT yet - this also needs alignment with iMX, AM series like > pending work, > where certain OPPs need enabling based on efuse programmed bit sequences - > since it > is an add-on work, it is not addressed here. > > Note: Somewhere in the future, when we have regulators driven off CCF and OMAP > converted to CCF, we could remove the DT regulator requirements there as well. OMAP has been converted to the common clock framework (CCF). Are you referring to clock framework transition to DT or something else? Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in > migrating the cpufreq support only through device tree (part of the effort > to migrate away from non-DT configurations for OMAP). Unfortunately, as > already > known, we have a bunch of legacy code and mutually dependent device tree > conversion that is pending. > Key features pending: > A) clock framework transition to DT - this should happen soon, so this series > hacks > the clock node for the time being as suggested in review of original series > B) on processors that use voltage controller, voltage processor (VC/VP > hardware > loop using I2C_SR path) - we have started work on transitioning them to > regulator > framework driven by DT. > C) Adaptive Body Bias and SmartReflex AVS conversion to DT. > > As a result of these pending features: > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no > regulators > associated at the moment - fortunately, we boot at highest voltage, so things > still > work. > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have > not added > those OPPs in DT yet - this also needs alignment with iMX, AM series like > pending work, > where certain OPPs need enabling based on efuse programmed bit sequences - > since it > is an add-on work, it is not addressed here. > Thanks for looking into it. > Note: Somewhere in the future, when we have regulators driven off CCF and OMAP > converted to CCF, we could remove the DT regulator requirements there as well. > > Key benefit of the series is to allow all relevant TI platforms now to use a > single > cpufreq driver and equivalent frameworks in addition be part of the > transition to > DT. As a result of this series, CPUFreq feature will not be available for > non-DT > boot systems. > As commented by Jon on internal thread, I am also against the idea of dropping non-DT support now. Till we migrate to 100 % DT, it is best to keep support alive. Especial OMAP3 based devices. Why don't you take phased approach and have both supported for time being. Then once we move to DT only, we just drop the non-DT support as we plan to do for many more stuff. BTW, we are using only CPUFreq driver before this series as well. I guess you mean the common CPUFReq drivers used by other ARM SOCs. Regards, Santosh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 16:42-20130314, Jon Hunter wrote: > > On 03/14/2013 03:58 PM, Nishanth Menon wrote: > > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) > > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in > > migrating the cpufreq support only through device tree (part of the effort > > to migrate away from non-DT configurations for OMAP). Unfortunately, as > > already > > known, we have a bunch of legacy code and mutually dependent device tree > > conversion that is pending. > > Key features pending: > > A) clock framework transition to DT - this should happen soon, so this > > series hacks > > the clock node for the time being as suggested in review of original series > > B) on processors that use voltage controller, voltage processor (VC/VP > > hardware > > loop using I2C_SR path) - we have started work on transitioning them to > > regulator > > framework driven by DT. > > C) Adaptive Body Bias and SmartReflex AVS conversion to DT. > > > > As a result of these pending features: > > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no > > regulators > > associated at the moment - fortunately, we boot at highest voltage, so > > things still > > work. > > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I > > have not added > > those OPPs in DT yet - this also needs alignment with iMX, AM series like > > pending work, > > where certain OPPs need enabling based on efuse programmed bit sequences - > > since it > > is an add-on work, it is not addressed here. > > > > Note: Somewhere in the future, when we have regulators driven off CCF and > > OMAP > > converted to CCF, we could remove the DT regulator requirements there as > > well. > > OMAP has been converted to the common clock framework (CCF). Are you > referring to clock framework transition to DT or something else? I should have been explicit here - we do not have DT entries for clock nodes for OMAP. For example, compare: git grep clocks arch/arm/boot/dts/omap*.dts* Vs git grep clocks arch/arm/boot/dts/imx*.dts* The specific comment above was intended to see the following series equivalent in upstream: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 10:48-20130315, Santosh Shilimkar wrote: > On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: > > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) > > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in > > migrating the cpufreq support only through device tree (part of the effort > > to migrate away from non-DT configurations for OMAP). Unfortunately, as > > already > > known, we have a bunch of legacy code and mutually dependent device tree > > conversion that is pending. > > Key features pending: > > A) clock framework transition to DT - this should happen soon, so this > > series hacks > > the clock node for the time being as suggested in review of original series > > B) on processors that use voltage controller, voltage processor (VC/VP > > hardware > > loop using I2C_SR path) - we have started work on transitioning them to > > regulator > > framework driven by DT. > > C) Adaptive Body Bias and SmartReflex AVS conversion to DT. > > > > As a result of these pending features: > > - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no > > regulators > > associated at the moment - fortunately, we boot at highest voltage, so > > things still > > work. > > - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I > > have not added > > those OPPs in DT yet - this also needs alignment with iMX, AM series like > > pending work, > > where certain OPPs need enabling based on efuse programmed bit sequences - > > since it > > is an add-on work, it is not addressed here. > > > Thanks for looking into it. Yes, this should be the next stage to solve. > > > Note: Somewhere in the future, when we have regulators driven off CCF and > > OMAP > > converted to CCF, we could remove the DT regulator requirements there as > > well. > > > > Key benefit of the series is to allow all relevant TI platforms now to use > > a single > > cpufreq driver and equivalent frameworks in addition be part of the > > transition to > > DT. As a result of this series, CPUFreq feature will not be available for > > non-DT > > boot systems. > > > As commented by Jon on internal thread, I am also against the idea of dropping > non-DT support now. Till we migrate to 100 % DT, it is best to keep support > alive. Especial OMAP3 based devices. > > Why don't you take phased approach and have both supported for time being. > Then once we move to DT only, we just drop the non-DT support as we plan > to do for many more stuff. > > BTW, we are using only CPUFreq driver before this series as well. I guess you > mean the common CPUFReq drivers used by other ARM SOCs. I had removed the entries for OPPs and clock nodes used by omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement "CPUFreq wont work in non-DT" configuration was accurate. My intent was as follows: - This series is driven mainly from maintenance angle - having to maintain two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c), ensuring the data is proper in both OPP tables in kernel and DT entries is sure to cause mayhem sometime. This is not just an pain for OMAP community, but for cpufreq community as well (since there is absolutely no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT world). - as long as non-DT supported boot provides all features, there is no real feature incentive to move to DT. But, that said, there is one path I see possible: - keep omap-cpufreq alive (BUT I will add a patch that will not let it init when in DT entries are present) - add DT entries for all relevant OMAPs - in DT mode, we will *only* support cpufreq-cpu0 - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the alignment I believe. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 03/15/2013 09:21 AM, Nishanth Menon wrote: > On 10:48-20130315, Santosh Shilimkar wrote: >> On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote: >>> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) >>> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in >>> migrating the cpufreq support only through device tree (part of the effort >>> to migrate away from non-DT configurations for OMAP). Unfortunately, as >>> already >>> known, we have a bunch of legacy code and mutually dependent device tree >>> conversion that is pending. >>> Key features pending: >>> A) clock framework transition to DT - this should happen soon, so this >>> series hacks >>> the clock node for the time being as suggested in review of original series >>> B) on processors that use voltage controller, voltage processor (VC/VP >>> hardware >>> loop using I2C_SR path) - we have started work on transitioning them to >>> regulator >>> framework driven by DT. >>> C) Adaptive Body Bias and SmartReflex AVS conversion to DT. >>> >>> As a result of these pending features: >>> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no >>> regulators >>> associated at the moment - fortunately, we boot at highest voltage, so >>> things still >>> work. >>> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I >>> have not added >>> those OPPs in DT yet - this also needs alignment with iMX, AM series like >>> pending work, >>> where certain OPPs need enabling based on efuse programmed bit sequences - >>> since it >>> is an add-on work, it is not addressed here. >>> >> Thanks for looking into it. > Yes, this should be the next stage to solve. >> >>> Note: Somewhere in the future, when we have regulators driven off CCF and >>> OMAP >>> converted to CCF, we could remove the DT regulator requirements there as >>> well. >>> >>> Key benefit of the series is to allow all relevant TI platforms now to use >>> a single >>> cpufreq driver and equivalent frameworks in addition be part of the >>> transition to >>> DT. As a result of this series, CPUFreq feature will not be available for >>> non-DT >>> boot systems. >>> >> As commented by Jon on internal thread, I am also against the idea of >> dropping >> non-DT support now. Till we migrate to 100 % DT, it is best to keep support >> alive. Especial OMAP3 based devices. >> >> Why don't you take phased approach and have both supported for time being. >> Then once we move to DT only, we just drop the non-DT support as we plan >> to do for many more stuff. >> >> BTW, we are using only CPUFreq driver before this series as well. I guess you >> mean the common CPUFReq drivers used by other ARM SOCs. > I had removed the entries for OPPs and clock nodes used by > omap-cpufreq.c and deleted the omap-cpufreq.c as well - so the statement > "CPUFreq wont work in non-DT" configuration was accurate. > > My intent was as follows: > - This series is driven mainly from maintenance angle - having to maintain > two different drivers (legacy omap-cpufreq.c and cpufreq-cpu0.c), > ensuring the data is proper in both OPP tables in kernel and DT entries > is sure to cause mayhem sometime. This is not just an pain for OMAP > community, but for cpufreq community as well (since there is absolutely > no reason other than OMAP legacy burden for making cpu0-cpufreq work in non-DT > world). > - as long as non-DT supported boot provides all features, there is no > real feature incentive to move to DT. You are missing the point. Before you can migrate people over to DT, you need to be ready. IMO OMAP is still not quite ready unfortunately. > But, that said, there is one path I see possible: > - keep omap-cpufreq alive (BUT I will add a patch that will not let it init > when in DT entries are present) > - add DT entries for all relevant OMAPs - in DT mode, we will *only* > support cpufreq-cpu0 > - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the > alignment I believe. Yes that is what we are doing for other drivers and should be done here. Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/8] ARM: OMAP3+: Switch to use DT based cpu0-cpufreq driver
On 09:56-20130315, Jon Hunter wrote: [..] > > But, that said, there is one path I see possible: > > - keep omap-cpufreq alive (BUT I will add a patch that will not let it init > > when in DT entries are present) > > - add DT entries for all relevant OMAPs - in DT mode, we will *only* > > support cpufreq-cpu0 > > - All future SoCs will continue to use cpufreq-cpu0 using DT, as was the > > alignment I believe. > > Yes that is what we are doing for other drivers and should be done here. OK. I guess we have not much of a choice with the legacy baggage we carry around :(. Will redo the series for the same. -- Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss