> Am 03.09.2019 um 08:28 schrieb Viresh Kumar <viresh.kumar@xxxxxxxxxx>: > > On 03-09-19, 08:23, H. Nikolaus Schaller wrote: >> >>> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@xxxxxxxxxx>: >>> >>> On 03-09-19, 08:01, H. Nikolaus Schaller wrote: >>>> >>>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@xxxxxxxxxx>: >>>>> >>>>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote: >>>>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the >>>>>> 1GHz capability is automatically detected. >>>>>> >>>>>> Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> >>>>>> --- >>>>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 ------- >>>>>> 1 file changed, 7 deletions(-) >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi >>>>>> index 5441e9ffdbb4..e98b0c615f19 100644 >>>>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi >>>>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi >>>>>> @@ -11,13 +11,6 @@ >>>>>> cpus { >>>>>> cpu@0 { >>>>>> cpu0-supply = <&vcc>; >>>>>> - operating-points = < >>>>>> - /* kHz uV */ >>>>>> - 300000 1012500 >>>>>> - 600000 1200000 >>>>>> - 800000 1325000 >>>>>> - 1000000 1375000 >>>>>> - >; >>>>>> }; >>>>>> }; >>>>> >>>>> This should be merged with 2/5 ? >>>> >>>> Well, it bloats 2/5. >>> >>> It is logically the right place to do this as that's where we are >>> adding opp-v2. >> >> Well, sometimes the philosophy of patches is to add something new >> first and remove the old in a second separate patch if the system >> can live with both. This makes it easier to digest single patches >> (because they are smaller) and might also better pinpoint an issue >> by bisect. > > Right, but you already removed some of the opp-v1 stuff in patch 2/5. > Why leave this one out ? > >>> >>>> What I hope (I can't test) is that this opp-v1 table >>>> is ignored if an opp-v2 table exists. So that it can be >>>> removed by a separate follow-up patch. >>> >>> It should work as that's what we are doing in OPP core, but I still >>> feel this better get merged with 2/5. >> >> Ok, I see. Noted for RFCv2. >> >> There will also be a big batch of changes for the compatible record >> (omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition >> DTS files. Should this then also become part of the new 2/5? > > Compatible thing should be separate patch anyway, I was just talking > about replacing opp-v1 with v2. Ok, understood. BR and thanks, Nikolaus