* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-10 18:51 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-10 18:51 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Hi,
> Am 10.09.2019 um 20:30 schrieb Adam Ford <aford173@gmail.com>:
>
> On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Hi Adam,
>>
>>> Am 09.09.2019 um 21:13 schrieb Adam Ford <aford173@gmail.com>:
>>>
>>> On Mon, Sep 9, 2019 at 1:11 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>>
>>>> Ok, we have to check if the ti,abb-v2 "LDO" driver
>>>> drivers/regulator/ti-abb-regulator.c
>>>> can handle that with a DT entry similar to:
>>>>
>>>> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/omap5.dtsi#L365
>>>
>>> At least for the 3630, the ti-abb-regulator driver is the same driver,
>>> but different structures based on v1, v2, or v3 are used based on
>>> which compatible flag is used.
>>>
>>> I tried enabling the vbb-supply in the device tree, but the driver
>>> doesn't load it without .multi_regulator being true.
>>>
>>> cpus {
>>> /* OMAP3630/OMAP37xx variants OPP50 to OPP130 and OPP1G */
>>> cpu: cpu@0 {
>>> operating-points-v2 = <&cpu0_opp_table>;
>>> vbb-supply = <&abb_mpu_iva>;
>>
>> Oh, that is great that the app_mpu_iva already exists!
>>
>> So we just need plumbing pieces together.
>>
>>> clock-latency = <300000>; /* From omap-cpufreq driver */
>>> };
>>> };
>>>
>>> I enabled that in the 3630 structure, but then the opp must list
>>> voltage points for both regulators.
>>> Looking at the entry for abb_mpu_iva, it appears to have voltages that
>>> directly match the OPP table, so I made a duplicate entry:
>>>
>>> opp-microvolt = <1012500 1012500 1012500>,
>>> <1012500 1012500 1012500>;
>
> Out of curiosity, if we're only going to use one value for the opp
> voltage, do we need to have 3 listed? when I looked at the driver
> yesterday, it appears to support either 1 or 3 entries per opp.
> If we're going to support two regulators, showing them as
> opp-microvolt = <1012500>, <1012500>; would be cleaner and can fit on
> one line.
Well, IMHO it would be cleaner to specify min and max values as well
since the data sheets define them. It is also not clear if we need
them for AVS or such mechanisms.
>
>>>
>>> and similar for 600, 800 and 1000 similar to the way dra7.dtsi does
>>
>> Yes.
>>
>>> it, but then I got some nasty errors and crashes.
>>
>> I have done the same but not (yet) seen a crash or error. Maybe you had
>> a typo?
>
> Can you send me an updated patch? I'd like to try to get where you
> are that doesn't crash.
Yes, as soon as I have access.
>
>>
>>>
>>> I started undoing the stuff, and I wanted to see if the abb_mpu_iva
>>> regulator was even running, but I would get -22 errors when I went to
>>> read the voltage.
>>>
>>> # cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.5/microvolts
>>> -22
>>
>> So it reports wrong voltage settings of -22µV...
>>
>> I have tested and have the same.
>>
>> root@letux:~# cd /sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3/
>> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# ls -l
>> total 0
>> lrwxrwxrwx 1 root root 0 Jan 1 00:02 device -> ../../../483072f0.regulator-abb-mpu
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 max_microvolts
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 microvolts
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 min_microvolts
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 name
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 num_users
>> lrwxrwxrwx 1 root root 0 Jan 1 00:02 of_node -> ../../../../../../firmware/devicetree/base/ocp@68000000/regulator-abb-mpu
>> drwxr-xr-x 2 root root 0 Jan 1 00:02 power
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 requested_microamps
>> lrwxrwxrwx 1 root root 0 Jan 1 00:02 subsystem -> ../../../../../../class/regulator
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_disk_state
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_mem_state
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_standby_state
>> -r--r--r-- 1 root root 4096 Jan 1 00:02 type
>> -rw-r--r-- 1 root root 4096 Jan 1 00:02 uevent
>> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# cat *
>> cat: device: Is a directory
>> 1375000
>> -22
>> 1012500
>> abb_mpu_iva
>> 1
>> cat: of_node: Is a directory
>> cat: power: Is a directory
>> 0
>> cat: subsystem: Is a directory
>> disabled
>> disabled
>> disabled
>> voltage
>> OF_NAME=regulator-abb-mpu
>> OF_FULLNAME=/ocp@68000000/regulator-abb-mpu
>> OF_COMPATIBLE_0=ti,abb-v1
>> OF_COMPATIBLE_N=1
>
> I concur with your findings.
>
>> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# cd
>> root@letux:~# cpufreq-info
>> cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
>> Report errors and bugs to cpufreq@vger.kernel.org, please.
>> analyzing CPU 0:
>> driver: cpufreq-dt
>> CPUs which run at the same hardware frequency: 0
>> CPUs which need to have their frequency coordinated by software: 0
>> maximum transition latency: 300 us.
>> hardware limits: 300 MHz - 1000 MHz
>> available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>> current policy: frequency should be within 300 MHz and 1000 MHz.
>> The governor "ondemand" may decide which speed to use
>> within this range.
>> current CPU frequency is 300 MHz (asserted by call to hardware).
>> cpufreq stats: 300 MHz:31.36%, 600 MHz:4.23%, 800 MHz:3.76%, 1000 MHz:60.65% (1933)
>> root@letux:~#
>>
>> So it runs with different OPPs... My chip may also be more robust to wrong ABB FBB setting.
>>
>>>
>>> If someone has any suggestions on how to test the abb_mpu_iva driver,
>>> let me know.
>>
>> Well, next I want to look into the code for cat microvolts and
>> maybe add some printk to understand the result...
>>
>> A first result is that it comes from
>>
>> /* We do not know where the OPP voltage is at the moment */
>> abb->current_info_idx = -EINVAL;
>>
>> But this is not treated as an -EINVAL but value of -22 microvolts...
>> Maybe an error check is missing somewhere in the regulator core.
>
> I assumed this to be -EINVAL, but I'd be happy to be wrong.
It seems that cat microvolts stringifies the int returned from reading
the regulator voltage.
Since it is initialized to -EINVAL it returns "-22" as string instead of
converting into an errno return when reading /sys... So one step is
missing a proper error check.
But that is just a symptom that there is no call to set a good voltage.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-10 18:51 ` H. Nikolaus Schaller
@ 2019-09-10 19:26 ` H. Nikolaus Schaller
-1 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-10 19:26 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Hi Adam,
> Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi,
>
>> Am 10.09.2019 um 20:30 schrieb Adam Ford <aford173@gmail.com>:
>>
>> On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>
>>
>> I assumed this to be -EINVAL, but I'd be happy to be wrong.
>
> It seems that cat microvolts stringifies the int returned from reading
> the regulator voltage.
>
> Since it is initialized to -EINVAL it returns "-22" as string instead of
> converting into an errno return when reading /sys... So one step is
> missing a proper error check.
Ok, found it in regulator_uV_show().
ret = sprintf(buf, "%d\n", regulator_get_voltage_rdev(rdev));
simply prints the result into a string.
But regulator_get_voltage_rdev() (or _regulator_get_voltage() before v5.3-rc1)
may return errors like -EPROBE_DEFER or -EINVAL or whatever
rdev->desc->ops->get_voltage_sel(rdev) returns.
So this is clearly a bug in regulator_uV_show().
> But that is just a symptom that there is no call to set a good voltage.
That is the next issue to find...
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-10 19:26 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-10 19:26 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Hi Adam,
> Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi,
>
>> Am 10.09.2019 um 20:30 schrieb Adam Ford <aford173@gmail.com>:
>>
>> On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>>
>>
>> I assumed this to be -EINVAL, but I'd be happy to be wrong.
>
> It seems that cat microvolts stringifies the int returned from reading
> the regulator voltage.
>
> Since it is initialized to -EINVAL it returns "-22" as string instead of
> converting into an errno return when reading /sys... So one step is
> missing a proper error check.
Ok, found it in regulator_uV_show().
ret = sprintf(buf, "%d\n", regulator_get_voltage_rdev(rdev));
simply prints the result into a string.
But regulator_get_voltage_rdev() (or _regulator_get_voltage() before v5.3-rc1)
may return errors like -EPROBE_DEFER or -EINVAL or whatever
rdev->desc->ops->get_voltage_sel(rdev) returns.
So this is clearly a bug in regulator_uV_show().
> But that is just a symptom that there is no call to set a good voltage.
That is the next issue to find...
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-10 18:51 ` H. Nikolaus Schaller
(?)
(?)
@ 2019-09-10 19:36 ` Adam Ford
-1 siblings, 0 replies; 46+ messages in thread
From: Adam Ford @ 2019-09-10 19:36 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
On Tue, Sep 10, 2019 at 1:51 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi,
>
> > Am 10.09.2019 um 20:30 schrieb Adam Ford <aford173@gmail.com>:
> >
> > On Tue, Sep 10, 2019 at 11:59 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >>
> >> Hi Adam,
> >>
> >>> Am 09.09.2019 um 21:13 schrieb Adam Ford <aford173@gmail.com>:
> >>>
> >>> On Mon, Sep 9, 2019 at 1:11 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >>>>
> >>>> Ok, we have to check if the ti,abb-v2 "LDO" driver
> >>>> drivers/regulator/ti-abb-regulator.c
> >>>> can handle that with a DT entry similar to:
> >>>>
> >>>> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/omap5.dtsi#L365
> >>>
> >>> At least for the 3630, the ti-abb-regulator driver is the same driver,
> >>> but different structures based on v1, v2, or v3 are used based on
> >>> which compatible flag is used.
> >>>
> >>> I tried enabling the vbb-supply in the device tree, but the driver
> >>> doesn't load it without .multi_regulator being true.
> >>>
> >>> cpus {
> >>> /* OMAP3630/OMAP37xx variants OPP50 to OPP130 and OPP1G */
> >>> cpu: cpu@0 {
> >>> operating-points-v2 = <&cpu0_opp_table>;
> >>> vbb-supply = <&abb_mpu_iva>;
> >>
> >> Oh, that is great that the app_mpu_iva already exists!
> >>
> >> So we just need plumbing pieces together.
> >>
> >>> clock-latency = <300000>; /* From omap-cpufreq driver */
> >>> };
> >>> };
> >>>
> >>> I enabled that in the 3630 structure, but then the opp must list
> >>> voltage points for both regulators.
> >>> Looking at the entry for abb_mpu_iva, it appears to have voltages that
> >>> directly match the OPP table, so I made a duplicate entry:
> >>>
> >>> opp-microvolt = <1012500 1012500 1012500>,
> >>> <1012500 1012500 1012500>;
> >
> > Out of curiosity, if we're only going to use one value for the opp
> > voltage, do we need to have 3 listed? when I looked at the driver
> > yesterday, it appears to support either 1 or 3 entries per opp.
> > If we're going to support two regulators, showing them as
> > opp-microvolt = <1012500>, <1012500>; would be cleaner and can fit on
> > one line.
>
> Well, IMHO it would be cleaner to specify min and max values as well
> since the data sheets define them. It is also not clear if we need
> them for AVS or such mechanisms.
>
> >
> >>>
> >>> and similar for 600, 800 and 1000 similar to the way dra7.dtsi does
> >>
> >> Yes.
> >>
> >>> it, but then I got some nasty errors and crashes.
> >>
> >> I have done the same but not (yet) seen a crash or error. Maybe you had
> >> a typo?
> >
> > Can you send me an updated patch? I'd like to try to get where you
> > are that doesn't crash.
>
> Yes, as soon as I have access.
>
> >
> >>
> >>>
> >>> I started undoing the stuff, and I wanted to see if the abb_mpu_iva
> >>> regulator was even running, but I would get -22 errors when I went to
> >>> read the voltage.
> >>>
> >>> # cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.5/microvolts
> >>> -22
> >>
> >> So it reports wrong voltage settings of -22µV...
> >>
> >> I have tested and have the same.
> >>
> >> root@letux:~# cd /sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3/
> >> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# ls -l
> >> total 0
> >> lrwxrwxrwx 1 root root 0 Jan 1 00:02 device -> ../../../483072f0.regulator-abb-mpu
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 max_microvolts
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 microvolts
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 min_microvolts
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 name
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 num_users
> >> lrwxrwxrwx 1 root root 0 Jan 1 00:02 of_node -> ../../../../../../firmware/devicetree/base/ocp@68000000/regulator-abb-mpu
> >> drwxr-xr-x 2 root root 0 Jan 1 00:02 power
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 requested_microamps
> >> lrwxrwxrwx 1 root root 0 Jan 1 00:02 subsystem -> ../../../../../../class/regulator
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_disk_state
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_mem_state
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 suspend_standby_state
> >> -r--r--r-- 1 root root 4096 Jan 1 00:02 type
> >> -rw-r--r-- 1 root root 4096 Jan 1 00:02 uevent
> >> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# cat *
> >> cat: device: Is a directory
> >> 1375000
> >> -22
> >> 1012500
> >> abb_mpu_iva
> >> 1
> >> cat: of_node: Is a directory
> >> cat: power: Is a directory
> >> 0
> >> cat: subsystem: Is a directory
> >> disabled
> >> disabled
> >> disabled
> >> voltage
> >> OF_NAME=regulator-abb-mpu
> >> OF_FULLNAME=/ocp@68000000/regulator-abb-mpu
> >> OF_COMPATIBLE_0=ti,abb-v1
> >> OF_COMPATIBLE_N=1
> >
> > I concur with your findings.
> >
> >> root@letux:/sys/bus/platform/devices/483072f0.regulator-abb-mpu/regulator/regulator.3# cd
> >> root@letux:~# cpufreq-info
> >> cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
> >> Report errors and bugs to cpufreq@vger.kernel.org, please.
> >> analyzing CPU 0:
> >> driver: cpufreq-dt
> >> CPUs which run at the same hardware frequency: 0
> >> CPUs which need to have their frequency coordinated by software: 0
> >> maximum transition latency: 300 us.
> >> hardware limits: 300 MHz - 1000 MHz
> >> available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
> >> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
> >> current policy: frequency should be within 300 MHz and 1000 MHz.
> >> The governor "ondemand" may decide which speed to use
> >> within this range.
> >> current CPU frequency is 300 MHz (asserted by call to hardware).
> >> cpufreq stats: 300 MHz:31.36%, 600 MHz:4.23%, 800 MHz:3.76%, 1000 MHz:60.65% (1933)
> >> root@letux:~#
> >>
> >> So it runs with different OPPs... My chip may also be more robust to wrong ABB FBB setting.
> >>
> >>>
> >>> If someone has any suggestions on how to test the abb_mpu_iva driver,
> >>> let me know.
> >>
> >> Well, next I want to look into the code for cat microvolts and
> >> maybe add some printk to understand the result...
> >>
> >> A first result is that it comes from
> >>
> >> /* We do not know where the OPP voltage is at the moment */
> >> abb->current_info_idx = -EINVAL;
> >>
> >> But this is not treated as an -EINVAL but value of -22 microvolts...
> >> Maybe an error check is missing somewhere in the regulator core.
> >
> > I assumed this to be -EINVAL, but I'd be happy to be wrong.
>
> It seems that cat microvolts stringifies the int returned from reading
> the regulator voltage.
>
> Since it is initialized to -EINVAL it returns "-22" as string instead of
> converting into an errno return when reading /sys... So one step is
> missing a proper error check.
>
> But that is just a symptom that there is no call to set a good voltage.
I unrolled the patches to see what a stock kernel does. When I 'cat
num_users' it returns 1. Do you know if there is a way to determine
who the user is? The stock tree doesn't appear to have any users of
this regulator.
adam
>
> BR,
> Nikolaus
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-10 18:51 ` H. Nikolaus Schaller
@ 2019-09-10 19:55 ` H. Nikolaus Schaller
-1 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-10 19:55 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Ok,
> Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>>>> it, but then I got some nasty errors and crashes.
>>>
>>> I have done the same but not (yet) seen a crash or error. Maybe you had
>>> a typo?
>>
>> Can you send me an updated patch? I'd like to try to get where you
>> are that doesn't crash.
>
> Yes, as soon as I have access.
it turns out that my patch breaks cpufreq completely...
So it looks as if *I* have a typo :)
Hence I am likely running at constant speed and the
VDD1 regulator is fixed a 1.200V.
root@letux:~# dmesg|fgrep opp
[ 2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1)
[ 2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1200000
root@letux:~#
The error message looks as if we have to enable multi_regulator.
And that may need to rename cpu0-supply to vdd-supply (unless the
names can be configured).
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-10 19:55 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-10 19:55 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Ok,
> Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>>>> it, but then I got some nasty errors and crashes.
>>>
>>> I have done the same but not (yet) seen a crash or error. Maybe you had
>>> a typo?
>>
>> Can you send me an updated patch? I'd like to try to get where you
>> are that doesn't crash.
>
> Yes, as soon as I have access.
it turns out that my patch breaks cpufreq completely...
So it looks as if *I* have a typo :)
Hence I am likely running at constant speed and the
VDD1 regulator is fixed a 1.200V.
root@letux:~# dmesg|fgrep opp
[ 2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1)
[ 2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1200000
root@letux:~#
The error message looks as if we have to enable multi_regulator.
And that may need to rename cpu0-supply to vdd-supply (unless the
names can be configured).
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-10 19:55 ` H. Nikolaus Schaller
(?)
@ 2019-09-10 20:06 ` Adam Ford
2019-09-11 0:24 ` Adam Ford
-1 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-10 20:06 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Ok,
>
> > Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> >>>> it, but then I got some nasty errors and crashes.
> >>>
> >>> I have done the same but not (yet) seen a crash or error. Maybe you had
> >>> a typo?
> >>
> >> Can you send me an updated patch? I'd like to try to get where you
> >> are that doesn't crash.
> >
> > Yes, as soon as I have access.
>
> it turns out that my patch breaks cpufreq completely...
> So it looks as if *I* have a typo :)
>
> Hence I am likely running at constant speed and the
> VDD1 regulator is fixed a 1.200V.
>
> root@letux:~# dmesg|fgrep opp
> [ 2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1)
> [ 2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
> root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> 1200000
> root@letux:~#
>
> The error message looks as if we have to enable multi_regulator.
That will enable both vdd and vbb regulators from what I can tell in the driver.
> And that may need to rename cpu0-supply to vdd-supply (unless the
> names can be configured).
That is consistent with what I found. vdd-supply = <&vcc>; and
vbb-supply = <&abb_mpu_iva>;
I put them both under the cpu node. Unfortunately, when I did that,
my board crashed.
I am thinking it has something to do with the abb_mpu_iva driver
because until this point, we've always operated at 800MHz or lower
which all have the same behavior in abb_mpu_iva.
With the patch you posted for the regulator, without the update to
cpufreq, and with debugging enabled, I received the following in
dmesg:
[ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
'efuse-address' IO resource
[ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
[ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
Clk_rate=13000000, sr2_cnt=0x00000032
adam
>
> BR,
> Nikolaus
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-10 20:06 ` Adam Ford
@ 2019-09-11 0:24 ` Adam Ford
2019-09-11 0:41 ` Adam Ford
0 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-11 0:24 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
On Tue, Sep 10, 2019 at 3:06 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >
> > Ok,
> >
> > > Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > >
> > >>>> it, but then I got some nasty errors and crashes.
> > >>>
> > >>> I have done the same but not (yet) seen a crash or error. Maybe you had
> > >>> a typo?
> > >>
> > >> Can you send me an updated patch? I'd like to try to get where you
> > >> are that doesn't crash.
> > >
> > > Yes, as soon as I have access.
> >
> > it turns out that my patch breaks cpufreq completely...
> > So it looks as if *I* have a typo :)
> >
> > Hence I am likely running at constant speed and the
> > VDD1 regulator is fixed a 1.200V.
> >
> > root@letux:~# dmesg|fgrep opp
> > [ 2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1)
> > [ 2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
> > root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> > 1200000
> > root@letux:~#
> >
> > The error message looks as if we have to enable multi_regulator.
>
> That will enable both vdd and vbb regulators from what I can tell in the driver.
>
> > And that may need to rename cpu0-supply to vdd-supply (unless the
> > names can be configured).
>
> That is consistent with what I found. vdd-supply = <&vcc>; and
> vbb-supply = <&abb_mpu_iva>;
> I put them both under the cpu node. Unfortunately, when I did that,
> my board crashed.
>
> I am thinking it has something to do with the abb_mpu_iva driver
> because until this point, we've always operated at 800MHz or lower
> which all have the same behavior in abb_mpu_iva.
>
> With the patch you posted for the regulator, without the update to
> cpufreq, and with debugging enabled, I received the following in
> dmesg:
>
> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
> 'efuse-address' IO resource
> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
> Clk_rate=13000000, sr2_cnt=0x00000032
>
Using an unmodified kernel, I changed the device tree to make the abb
regulator power the cpu instead of vcc. After doing so, I was able to
read the microvolt value, and it matched the processor's desired OPP
voltage, and the debug code showed the abb regulator was attempting to
set the various index based on the needed voltage. I think the abb
driver is working correctly.
I think tomorrow, I will re-apply the patches and tweak it again to
support both vdd and vbb regulators. If it crashes again, I'll look
more closely at the logs to see if I can determine why. I think it's
pretty close. I also need to go back and find the SmartReflex stuff
as well.
adam
>
> adam
> >
> > BR,
> > Nikolaus
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 0:24 ` Adam Ford
@ 2019-09-11 0:41 ` Adam Ford
2019-09-11 5:13 ` H. Nikolaus Schaller
0 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-11 0:41 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
On Tue, Sep 10, 2019 at 7:24 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Sep 10, 2019 at 3:06 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Tue, Sep 10, 2019 at 2:55 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> > >
> > > Ok,
> > >
> > > > Am 10.09.2019 um 20:51 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > > >
> > > >>>> it, but then I got some nasty errors and crashes.
> > > >>>
> > > >>> I have done the same but not (yet) seen a crash or error. Maybe you had
> > > >>> a typo?
> > > >>
> > > >> Can you send me an updated patch? I'd like to try to get where you
> > > >> are that doesn't crash.
> > > >
> > > > Yes, as soon as I have access.
> > >
> > > it turns out that my patch breaks cpufreq completely...
> > > So it looks as if *I* have a typo :)
> > >
> > > Hence I am likely running at constant speed and the
> > > VDD1 regulator is fixed a 1.200V.
> > >
> > > root@letux:~# dmesg|fgrep opp
> > > [ 2.426208] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1)
> > > [ 2.438140] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
> > > root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> > > 1200000
> > > root@letux:~#
> > >
> > > The error message looks as if we have to enable multi_regulator.
> >
> > That will enable both vdd and vbb regulators from what I can tell in the driver.
> >
> > > And that may need to rename cpu0-supply to vdd-supply (unless the
> > > names can be configured).
> >
> > That is consistent with what I found. vdd-supply = <&vcc>; and
> > vbb-supply = <&abb_mpu_iva>;
> > I put them both under the cpu node. Unfortunately, when I did that,
> > my board crashed.
> >
> > I am thinking it has something to do with the abb_mpu_iva driver
> > because until this point, we've always operated at 800MHz or lower
> > which all have the same behavior in abb_mpu_iva.
> >
> > With the patch you posted for the regulator, without the update to
> > cpufreq, and with debugging enabled, I received the following in
> > dmesg:
> >
> > [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
> > 'efuse-address' IO resource
> > [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
> > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> > [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
> > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> > [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
> > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> > [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
> > ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> > [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
> > Clk_rate=13000000, sr2_cnt=0x00000032
> >
>
> Using an unmodified kernel, I changed the device tree to make the abb
> regulator power the cpu instead of vcc. After doing so, I was able to
> read the microvolt value, and it matched the processor's desired OPP
> voltage, and the debug code showed the abb regulator was attempting to
> set the various index based on the needed voltage. I think the abb
> driver is working correctly.
>
> I think tomorrow, I will re-apply the patches and tweak it again to
> support both vdd and vbb regulators. If it crashes again, I'll look
> more closely at the logs to see if I can determine why. I think it's
> pretty close. I also need to go back and find the SmartReflex stuff
> as well.
>
Well, I couldn't give it up for the night, so I thought I'd show my data dump
[ 9.807647] ------------[ cut here ]------------
[ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
dev_pm_opp_set_rate+0x3cc/0x480
[ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
twl4030_pwrbutton sn
d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
drm_panel_or
ientation_quirks cec
[ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
[ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[ 9.909515] Workqueue: events dbs_work_handler
[ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
(show_stack+0x10/0x14)
[ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
(dump_stack+0xb4/0xd4)
[ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
(__warn.part.3+0xa8/0xd4)
[ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
(warn_slowpath_null+0x40/0x4c)
[ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
(dev_pm_opp_set_rate+0x3cc/0x480)
[ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
(set_target+0x30/0x58 [cpufreq_dt])
[ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
[<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
[ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
[<c06de050>] (od_dbs_update+0x130/0x15c)
[ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
(dbs_work_handler+0x28/0x58)
[ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
(process_one_work+0x20c/0x500)
[ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
(worker_thread+0x2c/0x5bc)
[ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
(kthread+0x134/0x148)
[ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
(ret_from_fork+0x14/0x2c)
[ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
[ 10.026062] bfa0: 00000000
00000000 00000000 00000000
[ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
[ 10.053894] cpu cpu0: multiple regulators are not supported
[ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
> adam
> >
> > adam
> > >
> > > BR,
> > > Nikolaus
> > >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 0:41 ` Adam Ford
@ 2019-09-11 5:13 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 5:13 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Hi Adam,
> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>
>>>> The error message looks as if we have to enable multi_regulator.
>>>
>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>
>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>> names can be configured).
>>>
>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>> vbb-supply = <&abb_mpu_iva>;
>>> I put them both under the cpu node. Unfortunately, when I did that,
>>> my board crashed.
>>>
>>> I am thinking it has something to do with the abb_mpu_iva driver
>>> because until this point, we've always operated at 800MHz or lower
>>> which all have the same behavior in abb_mpu_iva.
>>>
>>> With the patch you posted for the regulator, without the update to
>>> cpufreq, and with debugging enabled, I received the following in
>>> dmesg:
>>>
>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>> 'efuse-address' IO resource
>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>
>>
>> Using an unmodified kernel, I changed the device tree to make the abb
>> regulator power the cpu instead of vcc. After doing so, I was able to
>> read the microvolt value, and it matched the processor's desired OPP
>> voltage, and the debug code showed the abb regulator was attempting to
>> set the various index based on the needed voltage. I think the abb
>> driver is working correctly.
>>
>> I think tomorrow, I will re-apply the patches and tweak it again to
>> support both vdd and vbb regulators. If it crashes again, I'll look
>> more closely at the logs to see if I can determine why. I think it's
>> pretty close. I also need to go back and find the SmartReflex stuff
>> as well.
>>
> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>
> [ 9.807647] ------------[ cut here ]------------
> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
> dev_pm_opp_set_rate+0x3cc/0x480
> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
> twl4030_pwrbutton sn
> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
> drm_panel_or
> ientation_quirks cec
> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [ 9.909515] Workqueue: events dbs_work_handler
> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
> (show_stack+0x10/0x14)
> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
> (dump_stack+0xb4/0xd4)
> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
> (__warn.part.3+0xa8/0xd4)
> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
> (warn_slowpath_null+0x40/0x4c)
> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
> (dev_pm_opp_set_rate+0x3cc/0x480)
> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
> (set_target+0x30/0x58 [cpufreq_dt])
> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
> [<c06de050>] (od_dbs_update+0x130/0x15c)
> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
> (dbs_work_handler+0x28/0x58)
> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
> (process_one_work+0x20c/0x500)
> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
> (worker_thread+0x2c/0x5bc)
> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
> (kthread+0x134/0x148)
> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
> (ret_from_fork+0x14/0x2c)
> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
> [ 10.026062] bfa0: 00000000
> 00000000 00000000 00000000
> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
> [ 10.053894] cpu cpu0: multiple regulators are not supported
> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
I have the same:
[ 4.701354] cpu cpu0: multiple regulators are not supported
[ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
Comes from within dev_pm_opp_set_rate().
It appears that we also have to define opp_table->set_opp to make use
of _set_opp_custom(). And I am not sure which custom-opp-setter we should
use. Maybe ti_opp_supply_set_opp() is ok. Or not.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 5:13 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 5:13 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
Hi Adam,
> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>
>>>> The error message looks as if we have to enable multi_regulator.
>>>
>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>
>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>> names can be configured).
>>>
>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>> vbb-supply = <&abb_mpu_iva>;
>>> I put them both under the cpu node. Unfortunately, when I did that,
>>> my board crashed.
>>>
>>> I am thinking it has something to do with the abb_mpu_iva driver
>>> because until this point, we've always operated at 800MHz or lower
>>> which all have the same behavior in abb_mpu_iva.
>>>
>>> With the patch you posted for the regulator, without the update to
>>> cpufreq, and with debugging enabled, I received the following in
>>> dmesg:
>>>
>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>> 'efuse-address' IO resource
>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>
>>
>> Using an unmodified kernel, I changed the device tree to make the abb
>> regulator power the cpu instead of vcc. After doing so, I was able to
>> read the microvolt value, and it matched the processor's desired OPP
>> voltage, and the debug code showed the abb regulator was attempting to
>> set the various index based on the needed voltage. I think the abb
>> driver is working correctly.
>>
>> I think tomorrow, I will re-apply the patches and tweak it again to
>> support both vdd and vbb regulators. If it crashes again, I'll look
>> more closely at the logs to see if I can determine why. I think it's
>> pretty close. I also need to go back and find the SmartReflex stuff
>> as well.
>>
> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>
> [ 9.807647] ------------[ cut here ]------------
> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
> dev_pm_opp_set_rate+0x3cc/0x480
> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
> twl4030_pwrbutton sn
> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
> drm_panel_or
> ientation_quirks cec
> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [ 9.909515] Workqueue: events dbs_work_handler
> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
> (show_stack+0x10/0x14)
> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
> (dump_stack+0xb4/0xd4)
> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
> (__warn.part.3+0xa8/0xd4)
> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
> (warn_slowpath_null+0x40/0x4c)
> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
> (dev_pm_opp_set_rate+0x3cc/0x480)
> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
> (set_target+0x30/0x58 [cpufreq_dt])
> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
> [<c06de050>] (od_dbs_update+0x130/0x15c)
> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
> (dbs_work_handler+0x28/0x58)
> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
> (process_one_work+0x20c/0x500)
> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
> (worker_thread+0x2c/0x5bc)
> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
> (kthread+0x134/0x148)
> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
> (ret_from_fork+0x14/0x2c)
> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
> [ 10.026062] bfa0: 00000000
> 00000000 00000000 00000000
> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000
> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
> [ 10.053894] cpu cpu0: multiple regulators are not supported
> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
I have the same:
[ 4.701354] cpu cpu0: multiple regulators are not supported
[ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
Comes from within dev_pm_opp_set_rate().
It appears that we also have to define opp_table->set_opp to make use
of _set_opp_custom(). And I am not sure which custom-opp-setter we should
use. Maybe ti_opp_supply_set_opp() is ok. Or not.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 5:13 ` H. Nikolaus Schaller
@ 2019-09-11 6:03 ` H. Nikolaus Schaller
-1 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 6:03 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Adam,
>
>> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>>
>
>>>>> The error message looks as if we have to enable multi_regulator.
>
>>>>
>>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>>
>>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>>> names can be configured).
>>>>
>>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>>> vbb-supply = <&abb_mpu_iva>;
>>>> I put them both under the cpu node. Unfortunately, when I did that,
>>>> my board crashed.
>>>>
>>>> I am thinking it has something to do with the abb_mpu_iva driver
>>>> because until this point, we've always operated at 800MHz or lower
>>>> which all have the same behavior in abb_mpu_iva.
>>>>
>>>> With the patch you posted for the regulator, without the update to
>>>> cpufreq, and with debugging enabled, I received the following in
>>>> dmesg:
>>>>
>>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>>> 'efuse-address' IO resource
>>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>>
>>>
>>> Using an unmodified kernel, I changed the device tree to make the abb
>>> regulator power the cpu instead of vcc. After doing so, I was able to
>>> read the microvolt value, and it matched the processor's desired OPP
>>> voltage, and the debug code showed the abb regulator was attempting to
>>> set the various index based on the needed voltage. I think the abb
>>> driver is working correctly.
>>>
>>> I think tomorrow, I will re-apply the patches and tweak it again to
>>> support both vdd and vbb regulators. If it crashes again, I'll look
>>> more closely at the logs to see if I can determine why. I think it's
>>> pretty close. I also need to go back and find the SmartReflex stuff
>>> as well.
>>>
>> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>>
>> [ 9.807647] ------------[ cut here ]------------
>> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
>> dev_pm_opp_set_rate+0x3cc/0x480
>> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
>> twl4030_pwrbutton sn
>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
>> drm_panel_or
>> ientation_quirks cec
>> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
>> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>> [ 9.909515] Workqueue: events dbs_work_handler
>> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
>> (show_stack+0x10/0x14)
>> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
>> (dump_stack+0xb4/0xd4)
>> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
>> (__warn.part.3+0xa8/0xd4)
>> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
>> (warn_slowpath_null+0x40/0x4c)
>> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
>> (dev_pm_opp_set_rate+0x3cc/0x480)
>> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
>> (set_target+0x30/0x58 [cpufreq_dt])
>> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
>> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
>> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
>> [<c06de050>] (od_dbs_update+0x130/0x15c)
>> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
>> (dbs_work_handler+0x28/0x58)
>> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
>> (process_one_work+0x20c/0x500)
>> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
>> (worker_thread+0x2c/0x5bc)
>> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
>> (kthread+0x134/0x148)
>> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
>> (ret_from_fork+0x14/0x2c)
>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
>> [ 10.026062] bfa0: 00000000
>> 00000000 00000000 00000000
>> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
>> [ 10.053894] cpu cpu0: multiple regulators are not supported
>> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
>
> I have the same:
>
> [ 4.701354] cpu cpu0: multiple regulators are not supported
> [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
>
> Comes from within dev_pm_opp_set_rate().
>
> It appears that we also have to define opp_table->set_opp to make use
> of _set_opp_custom(). And I am not sure which custom-opp-setter we should
> use. Maybe ti_opp_supply_set_opp() is ok. Or not.
This appears to be set by dra7.dtsi through loading the
"ti,omap5-opp-supply" compatible driver:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/boot/dts/dra7.dtsi#L699
Maybe we can use "ti,omap-opp-supply" here, which does not read
additional eFuses?
See also
https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
And, if I understand the code ti_opp_supply_set_opp() correctly, we may not have
to rename cpu0-suppy to vdd-supply because that driver takes the first
regulator as vdd and the second as vbb.
Something like
opp_supply_mpu_iva: opp_supply {
compatible = "ti,omap-opp-supply";
ti,absolute-max-voltage-uv = <1375000>;
};
But that is a quite wild guess...
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 6:03 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 6:03 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, André Roth, Linux-OMAP,
Discussions about the Letux Kernel, Linux Kernel Mailing List,
Andreas Kemnade, Nishanth Menon
> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Adam,
>
>> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>>
>
>>>>> The error message looks as if we have to enable multi_regulator.
>
>>>>
>>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>>
>>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>>> names can be configured).
>>>>
>>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>>> vbb-supply = <&abb_mpu_iva>;
>>>> I put them both under the cpu node. Unfortunately, when I did that,
>>>> my board crashed.
>>>>
>>>> I am thinking it has something to do with the abb_mpu_iva driver
>>>> because until this point, we've always operated at 800MHz or lower
>>>> which all have the same behavior in abb_mpu_iva.
>>>>
>>>> With the patch you posted for the regulator, without the update to
>>>> cpufreq, and with debugging enabled, I received the following in
>>>> dmesg:
>>>>
>>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>>> 'efuse-address' IO resource
>>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>>
>>>
>>> Using an unmodified kernel, I changed the device tree to make the abb
>>> regulator power the cpu instead of vcc. After doing so, I was able to
>>> read the microvolt value, and it matched the processor's desired OPP
>>> voltage, and the debug code showed the abb regulator was attempting to
>>> set the various index based on the needed voltage. I think the abb
>>> driver is working correctly.
>>>
>>> I think tomorrow, I will re-apply the patches and tweak it again to
>>> support both vdd and vbb regulators. If it crashes again, I'll look
>>> more closely at the logs to see if I can determine why. I think it's
>>> pretty close. I also need to go back and find the SmartReflex stuff
>>> as well.
>>>
>> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>>
>> [ 9.807647] ------------[ cut here ]------------
>> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
>> dev_pm_opp_set_rate+0x3cc/0x480
>> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
>> twl4030_pwrbutton sn
>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
>> drm_panel_or
>> ientation_quirks cec
>> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
>> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>> [ 9.909515] Workqueue: events dbs_work_handler
>> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
>> (show_stack+0x10/0x14)
>> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
>> (dump_stack+0xb4/0xd4)
>> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
>> (__warn.part.3+0xa8/0xd4)
>> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
>> (warn_slowpath_null+0x40/0x4c)
>> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
>> (dev_pm_opp_set_rate+0x3cc/0x480)
>> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
>> (set_target+0x30/0x58 [cpufreq_dt])
>> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
>> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
>> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
>> [<c06de050>] (od_dbs_update+0x130/0x15c)
>> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
>> (dbs_work_handler+0x28/0x58)
>> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
>> (process_one_work+0x20c/0x500)
>> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
>> (worker_thread+0x2c/0x5bc)
>> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
>> (kthread+0x134/0x148)
>> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
>> (ret_from_fork+0x14/0x2c)
>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
>> [ 10.026062] bfa0: 00000000
>> 00000000 00000000 00000000
>> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
>> 00000000 00000000 00000000
>> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
>> [ 10.053894] cpu cpu0: multiple regulators are not supported
>> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
>
> I have the same:
>
> [ 4.701354] cpu cpu0: multiple regulators are not supported
> [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
>
> Comes from within dev_pm_opp_set_rate().
>
> It appears that we also have to define opp_table->set_opp to make use
> of _set_opp_custom(). And I am not sure which custom-opp-setter we should
> use. Maybe ti_opp_supply_set_opp() is ok. Or not.
This appears to be set by dra7.dtsi through loading the
"ti,omap5-opp-supply" compatible driver:
https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/boot/dts/dra7.dtsi#L699
Maybe we can use "ti,omap-opp-supply" here, which does not read
additional eFuses?
See also
https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
And, if I understand the code ti_opp_supply_set_opp() correctly, we may not have
to rename cpu0-suppy to vdd-supply because that driver takes the first
regulator as vdd and the second as vbb.
Something like
opp_supply_mpu_iva: opp_supply {
compatible = "ti,omap-opp-supply";
ti,absolute-max-voltage-uv = <1375000>;
};
But that is a quite wild guess...
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 6:03 ` H. Nikolaus Schaller
@ 2019-09-11 6:49 ` H. Nikolaus Schaller
-1 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 6:49 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
> Am 11.09.2019 um 08:03 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>
>> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>
>> Hi Adam,
>>
>>> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>>>
>>
>>>>>> The error message looks as if we have to enable multi_regulator.
>>
>>>>>
>>>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>>>
>>>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>>>> names can be configured).
>>>>>
>>>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>>>> vbb-supply = <&abb_mpu_iva>;
>>>>> I put them both under the cpu node. Unfortunately, when I did that,
>>>>> my board crashed.
>>>>>
>>>>> I am thinking it has something to do with the abb_mpu_iva driver
>>>>> because until this point, we've always operated at 800MHz or lower
>>>>> which all have the same behavior in abb_mpu_iva.
>>>>>
>>>>> With the patch you posted for the regulator, without the update to
>>>>> cpufreq, and with debugging enabled, I received the following in
>>>>> dmesg:
>>>>>
>>>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>>>> 'efuse-address' IO resource
>>>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>>>
>>>>
>>>> Using an unmodified kernel, I changed the device tree to make the abb
>>>> regulator power the cpu instead of vcc. After doing so, I was able to
>>>> read the microvolt value, and it matched the processor's desired OPP
>>>> voltage, and the debug code showed the abb regulator was attempting to
>>>> set the various index based on the needed voltage. I think the abb
>>>> driver is working correctly.
>>>>
>>>> I think tomorrow, I will re-apply the patches and tweak it again to
>>>> support both vdd and vbb regulators. If it crashes again, I'll look
>>>> more closely at the logs to see if I can determine why. I think it's
>>>> pretty close. I also need to go back and find the SmartReflex stuff
>>>> as well.
>>>>
>>> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>>>
>>> [ 9.807647] ------------[ cut here ]------------
>>> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
>>> dev_pm_opp_set_rate+0x3cc/0x480
>>> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
>>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
>>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
>>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
>>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
>>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
>>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
>>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
>>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
>>> twl4030_pwrbutton sn
>>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
>>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
>>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
>>> drm_panel_or
>>> ientation_quirks cec
>>> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
>>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
>>> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>>> [ 9.909515] Workqueue: events dbs_work_handler
>>> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
>>> (show_stack+0x10/0x14)
>>> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
>>> (dump_stack+0xb4/0xd4)
>>> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
>>> (__warn.part.3+0xa8/0xd4)
>>> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
>>> (warn_slowpath_null+0x40/0x4c)
>>> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
>>> (dev_pm_opp_set_rate+0x3cc/0x480)
>>> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
>>> (set_target+0x30/0x58 [cpufreq_dt])
>>> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
>>> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
>>> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
>>> [<c06de050>] (od_dbs_update+0x130/0x15c)
>>> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
>>> (dbs_work_handler+0x28/0x58)
>>> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
>>> (process_one_work+0x20c/0x500)
>>> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
>>> (worker_thread+0x2c/0x5bc)
>>> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
>>> (kthread+0x134/0x148)
>>> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
>>> (ret_from_fork+0x14/0x2c)
>>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
>>> [ 10.026062] bfa0: 00000000
>>> 00000000 00000000 00000000
>>> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
>>> 00000000 00000000 00000000
>>> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
>>> [ 10.053894] cpu cpu0: multiple regulators are not supported
>>> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
>>
>> I have the same:
>>
>> [ 4.701354] cpu cpu0: multiple regulators are not supported
>> [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
>>
>> Comes from within dev_pm_opp_set_rate().
>>
>> It appears that we also have to define opp_table->set_opp to make use
>> of _set_opp_custom(). And I am not sure which custom-opp-setter we should
>> use. Maybe ti_opp_supply_set_opp() is ok. Or not.
>
> This appears to be set by dra7.dtsi through loading the
> "ti,omap5-opp-supply" compatible driver:
>
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/boot/dts/dra7.dtsi#L699
>
> Maybe we can use "ti,omap-opp-supply" here, which does not read
> additional eFuses?
>
> See also
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
>
> And, if I understand the code ti_opp_supply_set_opp() correctly, we may not have
> to rename cpu0-suppy to vdd-supply because that driver takes the first
> regulator as vdd and the second as vbb.
>
> Something like
>
> opp_supply_mpu_iva: opp_supply {
> compatible = "ti,omap-opp-supply";
> ti,absolute-max-voltage-uv = <1375000>;
> };
>
> But that is a quite wild guess...
Well,
seems to boot without complaints and do something reasonable!
[ 144.816009] regulator regulator.3: ti_abb_get_voltage_sel
[ 144.821685] regulator regulator.3: ti_abb_get_voltage_sel idx=2
[ 144.828521] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
[ 145.133605] regulator regulator.3: ti_abb_get_voltage_sel
[ 145.139404] regulator regulator.3: ti_abb_get_voltage_sel idx=1
[ 145.146881] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
[ 145.174163] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
[ 145.449493] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
[ 145.485534] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 2
(I have added printk to ti_abb_get_voltage_sel/ti_abb_set_voltage_sel).
I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1012500
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1325000
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1200000
root@letux:~#
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1325000
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1200000
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1200000
root@letux:~#
What I haven't checked so far is if it toggles the ABB FBB bit.
I have pushed my current work (the last 4 commits) to
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-dm3730-1ghz
so that you can inspect/compare/test/check before I tidy up and add
the patches for our OPP-v2 patch set.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 6:49 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 6:49 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
> Am 11.09.2019 um 08:03 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>
>> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>>
>> Hi Adam,
>>
>>> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
>>>>>>
>>
>>>>>> The error message looks as if we have to enable multi_regulator.
>>
>>>>>
>>>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
>>>>>
>>>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
>>>>>> names can be configured).
>>>>>
>>>>> That is consistent with what I found. vdd-supply = <&vcc>; and
>>>>> vbb-supply = <&abb_mpu_iva>;
>>>>> I put them both under the cpu node. Unfortunately, when I did that,
>>>>> my board crashed.
>>>>>
>>>>> I am thinking it has something to do with the abb_mpu_iva driver
>>>>> because until this point, we've always operated at 800MHz or lower
>>>>> which all have the same behavior in abb_mpu_iva.
>>>>>
>>>>> With the patch you posted for the regulator, without the update to
>>>>> cpufreq, and with debugging enabled, I received the following in
>>>>> dmesg:
>>>>>
>>>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
>>>>> 'efuse-address' IO resource
>>>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
>>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
>>>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
>>>>> Clk_rate=13000000, sr2_cnt=0x00000032
>>>>>
>>>>
>>>> Using an unmodified kernel, I changed the device tree to make the abb
>>>> regulator power the cpu instead of vcc. After doing so, I was able to
>>>> read the microvolt value, and it matched the processor's desired OPP
>>>> voltage, and the debug code showed the abb regulator was attempting to
>>>> set the various index based on the needed voltage. I think the abb
>>>> driver is working correctly.
>>>>
>>>> I think tomorrow, I will re-apply the patches and tweak it again to
>>>> support both vdd and vbb regulators. If it crashes again, I'll look
>>>> more closely at the logs to see if I can determine why. I think it's
>>>> pretty close. I also need to go back and find the SmartReflex stuff
>>>> as well.
>>>>
>>> Well, I couldn't give it up for the night, so I thought I'd show my data dump
>>>
>>> [ 9.807647] ------------[ cut here ]------------
>>> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
>>> dev_pm_opp_set_rate+0x3cc/0x480
>>> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
>>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
>>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
>>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
>>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
>>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
>>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
>>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
>>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
>>> twl4030_pwrbutton sn
>>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
>>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
>>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
>>> drm_panel_or
>>> ientation_quirks cec
>>> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
>>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
>>> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
>>> [ 9.909515] Workqueue: events dbs_work_handler
>>> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
>>> (show_stack+0x10/0x14)
>>> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
>>> (dump_stack+0xb4/0xd4)
>>> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
>>> (__warn.part.3+0xa8/0xd4)
>>> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
>>> (warn_slowpath_null+0x40/0x4c)
>>> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
>>> (dev_pm_opp_set_rate+0x3cc/0x480)
>>> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
>>> (set_target+0x30/0x58 [cpufreq_dt])
>>> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
>>> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
>>> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
>>> [<c06de050>] (od_dbs_update+0x130/0x15c)
>>> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
>>> (dbs_work_handler+0x28/0x58)
>>> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
>>> (process_one_work+0x20c/0x500)
>>> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
>>> (worker_thread+0x2c/0x5bc)
>>> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
>>> (kthread+0x134/0x148)
>>> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
>>> (ret_from_fork+0x14/0x2c)
>>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
>>> [ 10.026062] bfa0: 00000000
>>> 00000000 00000000 00000000
>>> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
>>> 00000000 00000000 00000000
>>> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
>>> [ 10.053894] cpu cpu0: multiple regulators are not supported
>>> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
>>
>> I have the same:
>>
>> [ 4.701354] cpu cpu0: multiple regulators are not supported
>> [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
>>
>> Comes from within dev_pm_opp_set_rate().
>>
>> It appears that we also have to define opp_table->set_opp to make use
>> of _set_opp_custom(). And I am not sure which custom-opp-setter we should
>> use. Maybe ti_opp_supply_set_opp() is ok. Or not.
>
> This appears to be set by dra7.dtsi through loading the
> "ti,omap5-opp-supply" compatible driver:
>
> https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/boot/dts/dra7.dtsi#L699
>
> Maybe we can use "ti,omap-opp-supply" here, which does not read
> additional eFuses?
>
> See also
>
> https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
>
> And, if I understand the code ti_opp_supply_set_opp() correctly, we may not have
> to rename cpu0-suppy to vdd-supply because that driver takes the first
> regulator as vdd and the second as vbb.
>
> Something like
>
> opp_supply_mpu_iva: opp_supply {
> compatible = "ti,omap-opp-supply";
> ti,absolute-max-voltage-uv = <1375000>;
> };
>
> But that is a quite wild guess...
Well,
seems to boot without complaints and do something reasonable!
[ 144.816009] regulator regulator.3: ti_abb_get_voltage_sel
[ 144.821685] regulator regulator.3: ti_abb_get_voltage_sel idx=2
[ 144.828521] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
[ 145.133605] regulator regulator.3: ti_abb_get_voltage_sel
[ 145.139404] regulator regulator.3: ti_abb_get_voltage_sel idx=1
[ 145.146881] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
[ 145.174163] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
[ 145.449493] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
[ 145.485534] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 2
(I have added printk to ti_abb_get_voltage_sel/ti_abb_set_voltage_sel).
I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1012500
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1325000
root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
1200000
root@letux:~#
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1325000
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1200000
root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
1200000
root@letux:~#
What I haven't checked so far is if it toggles the ABB FBB bit.
I have pushed my current work (the last 4 commits) to
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-dm3730-1ghz
so that you can inspect/compare/test/check before I tidy up and add
the patches for our OPP-v2 patch set.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 6:49 ` H. Nikolaus Schaller
(?)
@ 2019-09-11 12:43 ` Adam Ford
2019-09-11 15:46 ` H. Nikolaus Schaller
-1 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-11 12:43 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
On Wed, Sep 11, 2019 at 1:50 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>
> > Am 11.09.2019 um 08:03 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> >
> >> Am 11.09.2019 um 07:13 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >>
> >> Hi Adam,
> >>
> >>> Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@gmail.com>:
> >>>>>>
> >>
> >>>>>> The error message looks as if we have to enable multi_regulator.
> >>
> >>>>>
> >>>>> That will enable both vdd and vbb regulators from what I can tell in the driver.
> >>>>>
> >>>>>> And that may need to rename cpu0-supply to vdd-supply (unless the
> >>>>>> names can be configured).
> >>>>>
> >>>>> That is consistent with what I found. vdd-supply = <&vcc>; and
> >>>>> vbb-supply = <&abb_mpu_iva>;
> >>>>> I put them both under the cpu node. Unfortunately, when I did that,
> >>>>> my board crashed.
> >>>>>
> >>>>> I am thinking it has something to do with the abb_mpu_iva driver
> >>>>> because until this point, we've always operated at 800MHz or lower
> >>>>> which all have the same behavior in abb_mpu_iva.
> >>>>>
> >>>>> With the patch you posted for the regulator, without the update to
> >>>>> cpufreq, and with debugging enabled, I received the following in
> >>>>> dmesg:
> >>>>>
> >>>>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing
> >>>>> 'efuse-address' IO resource
> >>>>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0
> >>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> >>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0
> >>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> >>>>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0
> >>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> >>>>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1
> >>>>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0
> >>>>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings:
> >>>>> Clk_rate=13000000, sr2_cnt=0x00000032
> >>>>>
> >>>>
> >>>> Using an unmodified kernel, I changed the device tree to make the abb
> >>>> regulator power the cpu instead of vcc. After doing so, I was able to
> >>>> read the microvolt value, and it matched the processor's desired OPP
> >>>> voltage, and the debug code showed the abb regulator was attempting to
> >>>> set the various index based on the needed voltage. I think the abb
> >>>> driver is working correctly.
> >>>>
> >>>> I think tomorrow, I will re-apply the patches and tweak it again to
> >>>> support both vdd and vbb regulators. If it crashes again, I'll look
> >>>> more closely at the logs to see if I can determine why. I think it's
> >>>> pretty close. I also need to go back and find the SmartReflex stuff
> >>>> as well.
> >>>>
> >>> Well, I couldn't give it up for the night, so I thought I'd show my data dump
> >>>
> >>> [ 9.807647] ------------[ cut here ]------------
> >>> [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630
> >>> dev_pm_opp_set_rate+0x3cc/0x480
> >>> [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211
> >>> joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class
> >>> panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v
> >>> ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common
> >>> bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery
> >>> snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph
> >>> y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt
> >>> watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+)
> >>> snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+)
> >>> twl4030_pwrbutton sn
> >>> d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio
> >>> soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004
> >>> tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm
> >>> drm_panel_or
> >>> ientation_quirks cec
> >>> [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted
> >>> 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5
> >>> [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> >>> [ 9.909515] Workqueue: events dbs_work_handler
> >>> [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>]
> >>> (show_stack+0x10/0x14)
> >>> [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>]
> >>> (dump_stack+0xb4/0xd4)
> >>> [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>]
> >>> (__warn.part.3+0xa8/0xd4)
> >>> [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>]
> >>> (warn_slowpath_null+0x40/0x4c)
> >>> [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>]
> >>> (dev_pm_opp_set_rate+0x3cc/0x480)
> >>> [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>]
> >>> (set_target+0x30/0x58 [cpufreq_dt])
> >>> [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from
> >>> [<c06db05c>] (__cpufreq_driver_target+0x188/0x514)
> >>> [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from
> >>> [<c06de050>] (od_dbs_update+0x130/0x15c)
> >>> [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>]
> >>> (dbs_work_handler+0x28/0x58)
> >>> [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>]
> >>> (process_one_work+0x20c/0x500)
> >>> [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>]
> >>> (worker_thread+0x2c/0x5bc)
> >>> [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>]
> >>> (kthread+0x134/0x148)
> >>> [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>]
> >>> (ret_from_fork+0x14/0x2c)
> >>> [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8)
> >>> [ 10.026062] bfa0: 00000000
> >>> 00000000 00000000 00000000
> >>> [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000
> >>> 00000000 00000000 00000000
> >>> [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
> >>> [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]---
> >>> [ 10.053894] cpu cpu0: multiple regulators are not supported
> >>> [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22
> >>
> >> I have the same:
> >>
> >> [ 4.701354] cpu cpu0: multiple regulators are not supported
> >> [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22
> >>
> >> Comes from within dev_pm_opp_set_rate().
> >>
> >> It appears that we also have to define opp_table->set_opp to make use
> >> of _set_opp_custom(). And I am not sure which custom-opp-setter we should
> >> use. Maybe ti_opp_supply_set_opp() is ok. Or not.
> >
> > This appears to be set by dra7.dtsi through loading the
> > "ti,omap5-opp-supply" compatible driver:
> >
> > https://elixir.bootlin.com/linux/v5.3-rc8/source/arch/arm/boot/dts/dra7.dtsi#L699
> >
> > Maybe we can use "ti,omap-opp-supply" here, which does not read
> > additional eFuses?
> >
> > See also
> >
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/ti-omap5-opp-supply.txt
> >
> > And, if I understand the code ti_opp_supply_set_opp() correctly, we may not have
> > to rename cpu0-suppy to vdd-supply because that driver takes the first
> > regulator as vdd and the second as vbb.
> >
> > Something like
> >
> > opp_supply_mpu_iva: opp_supply {
> > compatible = "ti,omap-opp-supply";
> > ti,absolute-max-voltage-uv = <1375000>;
> > };
> >
> > But that is a quite wild guess...
>
> Well,
> seems to boot without complaints and do something reasonable!
>
> [ 144.816009] regulator regulator.3: ti_abb_get_voltage_sel
> [ 144.821685] regulator regulator.3: ti_abb_get_voltage_sel idx=2
> [ 144.828521] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
> [ 145.133605] regulator regulator.3: ti_abb_get_voltage_sel
> [ 145.139404] regulator regulator.3: ti_abb_get_voltage_sel idx=1
> [ 145.146881] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
> [ 145.174163] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 1
> [ 145.449493] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 0
> [ 145.485534] regulator regulator.3: ti_abb_set_voltage_sel: choose sel 2
>
> (I have added printk to ti_abb_get_voltage_sel/ti_abb_set_voltage_sel).
>
> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
I concur. I have good results with the added ti,omap-opp-supply entry.
>
> root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> 1012500
> root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> 1325000
> root@letux:~# cat /sys/class/regulator/regulator.8/microvolts
> 1200000
> root@letux:~#
>
> root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
> 1325000
> root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
> 1200000
> root@letux:~# cat /sys/class/regulator/regulator.3/microvolts
> 1200000
> root@letux:~#
>
> What I haven't checked so far is if it toggles the ABB FBB bit.
>
> I have pushed my current work (the last 4 commits) to
>
> http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-dm3730-1ghz
>
I noticed the FIXME note on the omap36xx.dtsi file where you added the
vdd-supply reference. For what its worth, I searched for a list of
all files that reference omap3630, then built a bunch of dtb's
make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
DTC arch/arm/boot/dts/omap3-igep0020.dtb
DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
DTC arch/arm/boot/dts/omap3-igep0030.dtb
DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
DTC arch/arm/boot/dts/omap3-n950.dtb
DTC arch/arm/boot/dts/omap3-n9.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
DTC arch/arm/boot/dts/omap3-sniper.dtb
DTC arch/arm/boot/dts/omap3-zoom3.dtb
DTC arch/arm/boot/dts/omap3-gta04a5.dtb
DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
DTC arch/arm/boot/dts/omap3-gta04a3.dtb
DTC arch/arm/boot/dts/omap3-gta04a4.dtb
I think it's probably safe to leave the vcc-supply there, but you may
want to add a note that users who do not use twl4030 should add
something to their device tree to specify the vcc-supply.
At this point, I doubt anyone will do new designs on omap3 SoC's.
> so that you can inspect/compare/test/check before I tidy up and add
> the patches for our OPP-v2 patch set.
I think it looks good. Maybe Tony and or TI people have some
comments, but it appears to set both regulators now.
Nice job!
adam
>
> BR,
> Nikolaus
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 12:43 ` Adam Ford
@ 2019-09-11 15:46 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 15:46 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
Hi,
> Am 11.09.2019 um 14:43 schrieb Adam Ford <aford173@gmail.com>:
>
>>
>> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
>
> I concur. I have good results with the added ti,omap-opp-supply entry.
Great!
There are some subtleties for testing.
* I have added turbo-mode; to OPP6 / OPP1G
* which means they are available but not used by the ondemand govenor
* to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
Testing is also easily done through cpufreq-set -f 800m or-f 1g
Then I can see the microvolts change and also registers
PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB
PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB
I have added both of this as descriptive notes to the commit messages.
What I have to check is if it behaves as expected on a dm3730 without
1GHz rating.
> I noticed the FIXME note on the omap36xx.dtsi file where you added the
> vdd-supply reference. For what its worth, I searched for a list of
> all files that reference omap3630, then built a bunch of dtb's
>
> make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
> DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
> DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
> DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
> DTC arch/arm/boot/dts/omap3-igep0020.dtb
> DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
> DTC arch/arm/boot/dts/omap3-igep0030.dtb
> DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
> DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
> DTC arch/arm/boot/dts/omap3-n950.dtb
> DTC arch/arm/boot/dts/omap3-n9.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
> DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
> DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
> DTC arch/arm/boot/dts/omap3-sniper.dtb
> DTC arch/arm/boot/dts/omap3-zoom3.dtb
> DTC arch/arm/boot/dts/omap3-gta04a5.dtb
> DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
> DTC arch/arm/boot/dts/omap3-gta04a3.dtb
> DTC arch/arm/boot/dts/omap3-gta04a4.dtb
Quite a lot...
> I think it's probably safe to leave the vcc-supply there, but you may
> want to add a note that users who do not use twl4030 should add
> something to their device tree to specify the vcc-supply.
>
> At this point, I doubt anyone will do new designs on omap3 SoC's.
Well, I am not sure if there are out-of-tree boards with omap3
where we could break everything. I know of at least one such
board.
Therefore I have looked where the cpu0-supply vs. vdd-supply
is decoded. It turns out to be also the ti-cpufreq driver
which we already tweak for omap3 support.
So I just have to modify ca. 10 LOC to add this "cpu0" to the
SoC description tables and process it once during probe time.
Then, it works with unmodified board.dtb
defining cpu0-supply = <&vcc> or whatever regulator.
The only question that comes up is if this change is am3517
compatible. I.e. can we still use the omap36xx_soc_data for
it as well which now expects two regulators... So you
might now see an error message that cpu0-supply and vbb-supply
are missing or not the right number of regulators is given.
We may have to add an am3517_soc_data table, but that would
be straightforward now.
>
>> so that you can inspect/compare/test/check before I tidy up and add
>> the patches for our OPP-v2 patch set.
>
> I think it looks good. Maybe Tony and or TI people have some
> comments, but it appears to set both regulators now.
>
> Nice job!
With your kind help!
Now it's time to wrap up and post a new PATCH set version for
review.
Best regards,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 15:46 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 15:46 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
Hi,
> Am 11.09.2019 um 14:43 schrieb Adam Ford <aford173@gmail.com>:
>
>>
>> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
>
> I concur. I have good results with the added ti,omap-opp-supply entry.
Great!
There are some subtleties for testing.
* I have added turbo-mode; to OPP6 / OPP1G
* which means they are available but not used by the ondemand govenor
* to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
Testing is also easily done through cpufreq-set -f 800m or-f 1g
Then I can see the microvolts change and also registers
PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB
PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB
I have added both of this as descriptive notes to the commit messages.
What I have to check is if it behaves as expected on a dm3730 without
1GHz rating.
> I noticed the FIXME note on the omap36xx.dtsi file where you added the
> vdd-supply reference. For what its worth, I searched for a list of
> all files that reference omap3630, then built a bunch of dtb's
>
> make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
> DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
> DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
> DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
> DTC arch/arm/boot/dts/omap3-igep0020.dtb
> DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
> DTC arch/arm/boot/dts/omap3-igep0030.dtb
> DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
> DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
> DTC arch/arm/boot/dts/omap3-n950.dtb
> DTC arch/arm/boot/dts/omap3-n9.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
> DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
> DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
> DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
> DTC arch/arm/boot/dts/omap3-sniper.dtb
> DTC arch/arm/boot/dts/omap3-zoom3.dtb
> DTC arch/arm/boot/dts/omap3-gta04a5.dtb
> DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
> DTC arch/arm/boot/dts/omap3-gta04a3.dtb
> DTC arch/arm/boot/dts/omap3-gta04a4.dtb
Quite a lot...
> I think it's probably safe to leave the vcc-supply there, but you may
> want to add a note that users who do not use twl4030 should add
> something to their device tree to specify the vcc-supply.
>
> At this point, I doubt anyone will do new designs on omap3 SoC's.
Well, I am not sure if there are out-of-tree boards with omap3
where we could break everything. I know of at least one such
board.
Therefore I have looked where the cpu0-supply vs. vdd-supply
is decoded. It turns out to be also the ti-cpufreq driver
which we already tweak for omap3 support.
So I just have to modify ca. 10 LOC to add this "cpu0" to the
SoC description tables and process it once during probe time.
Then, it works with unmodified board.dtb
defining cpu0-supply = <&vcc> or whatever regulator.
The only question that comes up is if this change is am3517
compatible. I.e. can we still use the omap36xx_soc_data for
it as well which now expects two regulators... So you
might now see an error message that cpu0-supply and vbb-supply
are missing or not the right number of regulators is given.
We may have to add an am3517_soc_data table, but that would
be straightforward now.
>
>> so that you can inspect/compare/test/check before I tidy up and add
>> the patches for our OPP-v2 patch set.
>
> I think it looks good. Maybe Tony and or TI people have some
> comments, but it appears to set both regulators now.
>
> Nice job!
With your kind help!
Now it's time to wrap up and post a new PATCH set version for
review.
Best regards,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 15:46 ` H. Nikolaus Schaller
(?)
@ 2019-09-11 15:56 ` Adam Ford
2019-09-11 16:01 ` H. Nikolaus Schaller
-1 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-11 15:56 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
On Wed, Sep 11, 2019 at 10:46 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi,
>
> > Am 11.09.2019 um 14:43 schrieb Adam Ford <aford173@gmail.com>:
> >
> >>
> >> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
> >
> > I concur. I have good results with the added ti,omap-opp-supply entry.
>
> Great!
>
> There are some subtleties for testing.
>
> * I have added turbo-mode; to OPP6 / OPP1G
> * which means they are available but not used by the ondemand govenor
> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
Will that be documented somewhere? If not, can we put a comment in the
device tree so people know how to enable it?
>
> Testing is also easily done through cpufreq-set -f 800m or-f 1g
>
> Then I can see the microvolts change and also registers
> PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB
> PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB
>
> I have added both of this as descriptive notes to the commit messages.
>
> What I have to check is if it behaves as expected on a dm3730 without
> 1GHz rating.
I already tested it. From what I can see, it's behaving normally.
>
> > I noticed the FIXME note on the omap36xx.dtsi file where you added the
> > vdd-supply reference. For what its worth, I searched for a list of
> > all files that reference omap3630, then built a bunch of dtb's
> >
> > make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
> > DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
> > DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
> > DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
> > DTC arch/arm/boot/dts/omap3-igep0020.dtb
> > DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
> > DTC arch/arm/boot/dts/omap3-igep0030.dtb
> > DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
> > DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
> > DTC arch/arm/boot/dts/omap3-n950.dtb
> > DTC arch/arm/boot/dts/omap3-n9.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
> > DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
> > DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
> > DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
> > DTC arch/arm/boot/dts/omap3-sniper.dtb
> > DTC arch/arm/boot/dts/omap3-zoom3.dtb
> > DTC arch/arm/boot/dts/omap3-gta04a5.dtb
> > DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
> > DTC arch/arm/boot/dts/omap3-gta04a3.dtb
> > DTC arch/arm/boot/dts/omap3-gta04a4.dtb
>
> Quite a lot...
>
> > I think it's probably safe to leave the vcc-supply there, but you may
> > want to add a note that users who do not use twl4030 should add
> > something to their device tree to specify the vcc-supply.
> >
> > At this point, I doubt anyone will do new designs on omap3 SoC's.
>
> Well, I am not sure if there are out-of-tree boards with omap3
> where we could break everything. I know of at least one such
> board.
>
> Therefore I have looked where the cpu0-supply vs. vdd-supply
> is decoded. It turns out to be also the ti-cpufreq driver
> which we already tweak for omap3 support.
>
> So I just have to modify ca. 10 LOC to add this "cpu0" to the
> SoC description tables and process it once during probe time.
>
> Then, it works with unmodified board.dtb
> defining cpu0-supply = <&vcc> or whatever regulator.
>
> The only question that comes up is if this change is am3517
> compatible. I.e. can we still use the omap36xx_soc_data for
> it as well which now expects two regulators... So you
> might now see an error message that cpu0-supply and vbb-supply
> are missing or not the right number of regulators is given.
>
> We may have to add an am3517_soc_data table, but that would
> be straightforward now.
I will run some tests on the 3517 using the 3430 table instead of the
3630. I didn't look into great detail as to what the tables do, but it
might be sufficient.
Otherwise, I can copy-paste the 3630 table and change the
multi-regulator off and test it that way if you'd prefer.
Let me know your preference, and I can do it.
>
> >
> >> so that you can inspect/compare/test/check before I tidy up and add
> >> the patches for our OPP-v2 patch set.
> >
> > I think it looks good. Maybe Tony and or TI people have some
> > comments, but it appears to set both regulators now.
> >
> > Nice job!
>
> With your kind help!
>
I am glad to help.
> Now it's time to wrap up and post a new PATCH set version for
> review.
>
> Best regards,
> Nikolaus
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 15:56 ` Adam Ford
@ 2019-09-11 16:01 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 16:01 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
>
> On Wed, Sep 11, 2019 at 10:46 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Hi,
>>
>>> Am 11.09.2019 um 14:43 schrieb Adam Ford <aford173@gmail.com>:
>>>
>>>>
>>>> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
>>>
>>> I concur. I have good results with the added ti,omap-opp-supply entry.
>>
>> Great!
>>
>> There are some subtleties for testing.
>>
>> * I have added turbo-mode; to OPP6 / OPP1G
>> * which means they are available but not used by the ondemand govenor
>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
>
> Will that be documented somewhere? If not, can we put a comment in the
> device tree so people know how to enable it?
It seems to be pretty standard on i86 systems if you google for "turbo mode".
I have added it to the commit message which adds the vbb regulator.
>
>>
>> Testing is also easily done through cpufreq-set -f 800m or-f 1g
>>
>> Then I can see the microvolts change and also registers
>> PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB
>> PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB
>>
>> I have added both of this as descriptive notes to the commit messages.
>>
>> What I have to check is if it behaves as expected on a dm3730 without
>> 1GHz rating.
>
> I already tested it. From what I can see, it's behaving normally.
>
>>
>>> I noticed the FIXME note on the omap36xx.dtsi file where you added the
>>> vdd-supply reference. For what its worth, I searched for a list of
>>> all files that reference omap3630, then built a bunch of dtb's
>>>
>>> make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
>>> DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
>>> DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
>>> DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0020.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0030.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
>>> DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
>>> DTC arch/arm/boot/dts/omap3-n950.dtb
>>> DTC arch/arm/boot/dts/omap3-n9.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
>>> DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
>>> DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
>>> DTC arch/arm/boot/dts/omap3-sniper.dtb
>>> DTC arch/arm/boot/dts/omap3-zoom3.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a5.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a3.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a4.dtb
>>
>> Quite a lot...
>>
>>> I think it's probably safe to leave the vcc-supply there, but you may
>>> want to add a note that users who do not use twl4030 should add
>>> something to their device tree to specify the vcc-supply.
>>>
>>> At this point, I doubt anyone will do new designs on omap3 SoC's.
>>
>> Well, I am not sure if there are out-of-tree boards with omap3
>> where we could break everything. I know of at least one such
>> board.
>>
>> Therefore I have looked where the cpu0-supply vs. vdd-supply
>> is decoded. It turns out to be also the ti-cpufreq driver
>> which we already tweak for omap3 support.
>>
>> So I just have to modify ca. 10 LOC to add this "cpu0" to the
>> SoC description tables and process it once during probe time.
>>
>> Then, it works with unmodified board.dtb
>> defining cpu0-supply = <&vcc> or whatever regulator.
>>
>> The only question that comes up is if this change is am3517
>> compatible. I.e. can we still use the omap36xx_soc_data for
>> it as well which now expects two regulators... So you
>> might now see an error message that cpu0-supply and vbb-supply
>> are missing or not the right number of regulators is given.
>>
>> We may have to add an am3517_soc_data table, but that would
>> be straightforward now.
>
> I will run some tests on the 3517 using the 3430 table instead of the
> 3630. I didn't look into great detail as to what the tables do, but it
> might be sufficient.
Yes, but it reads some undocumented register...
> Otherwise, I can copy-paste the 3630 table and change the
> multi-regulator off and test it that way if you'd prefer.
I'd prefer to copy-paste the old 3630 table (which was already
tested...).
> Let me know your preference, and I can do it.
>
>>
>>>
>>>> so that you can inspect/compare/test/check before I tidy up and add
>>>> the patches for our OPP-v2 patch set.
>>>
>>> I think it looks good. Maybe Tony and or TI people have some
>>> comments, but it appears to set both regulators now.
>>>
>>> Nice job!
>>
>> With your kind help!
>>
> I am glad to help.
>
>> Now it's time to wrap up and post a new PATCH set version for
>> review.
>>
>> Best regards,
>> Nikolaus
>>
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 16:01 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 16:01 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel, Andreas Kemnade
> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
>
> On Wed, Sep 11, 2019 at 10:46 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>> Hi,
>>
>>> Am 11.09.2019 um 14:43 schrieb Adam Ford <aford173@gmail.com>:
>>>
>>>>
>>>> I can also see that there are transitions on the voltages (reg.8 is vdd and reg.3 is abb).
>>>
>>> I concur. I have good results with the added ti,omap-opp-supply entry.
>>
>> Great!
>>
>> There are some subtleties for testing.
>>
>> * I have added turbo-mode; to OPP6 / OPP1G
>> * which means they are available but not used by the ondemand govenor
>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
>
> Will that be documented somewhere? If not, can we put a comment in the
> device tree so people know how to enable it?
It seems to be pretty standard on i86 systems if you google for "turbo mode".
I have added it to the commit message which adds the vbb regulator.
>
>>
>> Testing is also easily done through cpufreq-set -f 800m or-f 1g
>>
>> Then I can see the microvolts change and also registers
>> PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB
>> PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB
>>
>> I have added both of this as descriptive notes to the commit messages.
>>
>> What I have to check is if it behaves as expected on a dm3730 without
>> 1GHz rating.
>
> I already tested it. From what I can see, it's behaving normally.
>
>>
>>> I noticed the FIXME note on the omap36xx.dtsi file where you added the
>>> vdd-supply reference. For what its worth, I searched for a list of
>>> all files that reference omap3630, then built a bunch of dtb's
>>>
>>> make `cat dtb-list` ARCH=arm CROSS_COMPILE="ccache arm-linux-" -j8
>>> DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
>>> DTC arch/arm/boot/dts/omap3-cm-t3730.dtb
>>> DTC arch/arm/boot/dts/omap3-evm-37xx.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0020.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0020-rev-f.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0030.dtb
>>> DTC arch/arm/boot/dts/omap3-igep0030-rev-g.dtb
>>> DTC arch/arm/boot/dts/omap3-lilly-dbb056.dtb
>>> DTC arch/arm/boot/dts/omap3-n950.dtb
>>> DTC arch/arm/boot/dts/omap3-n9.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-alto35.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-chestnut43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-gallop43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-palo35.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-palo43.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-summit.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-tobi.dtb
>>> DTC arch/arm/boot/dts/omap3-overo-storm-tobiduo.dtb
>>> DTC arch/arm/boot/dts/omap3-pandora-1ghz.dtb
>>> DTC arch/arm/boot/dts/omap3-sbc-t3730.dtb
>>> DTC arch/arm/boot/dts/omap3-sniper.dtb
>>> DTC arch/arm/boot/dts/omap3-zoom3.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a5.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a5one.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a3.dtb
>>> DTC arch/arm/boot/dts/omap3-gta04a4.dtb
>>
>> Quite a lot...
>>
>>> I think it's probably safe to leave the vcc-supply there, but you may
>>> want to add a note that users who do not use twl4030 should add
>>> something to their device tree to specify the vcc-supply.
>>>
>>> At this point, I doubt anyone will do new designs on omap3 SoC's.
>>
>> Well, I am not sure if there are out-of-tree boards with omap3
>> where we could break everything. I know of at least one such
>> board.
>>
>> Therefore I have looked where the cpu0-supply vs. vdd-supply
>> is decoded. It turns out to be also the ti-cpufreq driver
>> which we already tweak for omap3 support.
>>
>> So I just have to modify ca. 10 LOC to add this "cpu0" to the
>> SoC description tables and process it once during probe time.
>>
>> Then, it works with unmodified board.dtb
>> defining cpu0-supply = <&vcc> or whatever regulator.
>>
>> The only question that comes up is if this change is am3517
>> compatible. I.e. can we still use the omap36xx_soc_data for
>> it as well which now expects two regulators... So you
>> might now see an error message that cpu0-supply and vbb-supply
>> are missing or not the right number of regulators is given.
>>
>> We may have to add an am3517_soc_data table, but that would
>> be straightforward now.
>
> I will run some tests on the 3517 using the 3430 table instead of the
> 3630. I didn't look into great detail as to what the tables do, but it
> might be sufficient.
Yes, but it reads some undocumented register...
> Otherwise, I can copy-paste the 3630 table and change the
> multi-regulator off and test it that way if you'd prefer.
I'd prefer to copy-paste the old 3630 table (which was already
tested...).
> Let me know your preference, and I can do it.
>
>>
>>>
>>>> so that you can inspect/compare/test/check before I tidy up and add
>>>> the patches for our OPP-v2 patch set.
>>>
>>> I think it looks good. Maybe Tony and or TI people have some
>>> comments, but it appears to set both regulators now.
>>>
>>> Nice job!
>>
>> With your kind help!
>>
> I am glad to help.
>
>> Now it's time to wrap up and post a new PATCH set version for
>> review.
>>
>> Best regards,
>> Nikolaus
>>
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 16:01 ` H. Nikolaus Schaller
@ 2019-09-11 17:43 ` H. Nikolaus Schaller
-1 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 17:43 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel
Hi Adam,
> Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>>
>> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
>>
>>> There are some subtleties for testing.
>>>
>>> * I have added turbo-mode; to OPP6 / OPP1G
>>> * which means they are available but not used by the ondemand govenor
>>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
>>
>> Will that be documented somewhere? If not, can we put a comment in the
>> device tree so people know how to enable it?
>
> It seems to be pretty standard on i86 systems if you google for "turbo mode".
> I have added it to the commit message which adds the vbb regulator.
And, I am not sure if DT maintainers will accept comments about the
Linux /sys implementation in device tree files or bindings. Those
should be independent of Linux.
Basically the turbo-mode property is a hint to the OPP system (which
may or may not use of it).
So I think it is indeed better to have it in the commit message and
not the code.
One more thought: as long as we do not have junction temperature monitoring
we should keep it off by default... We may even remove the turbo-mode
designator if we have the 90°C limit and smart reflex working.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
@ 2019-09-11 17:43 ` H. Nikolaus Schaller
0 siblings, 0 replies; 46+ messages in thread
From: H. Nikolaus Schaller @ 2019-09-11 17:43 UTC (permalink / raw)
To: Adam Ford
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel
Hi Adam,
> Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
>>
>> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
>>
>>> There are some subtleties for testing.
>>>
>>> * I have added turbo-mode; to OPP6 / OPP1G
>>> * which means they are available but not used by the ondemand govenor
>>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
>>
>> Will that be documented somewhere? If not, can we put a comment in the
>> device tree so people know how to enable it?
>
> It seems to be pretty standard on i86 systems if you google for "turbo mode".
> I have added it to the commit message which adds the vbb regulator.
And, I am not sure if DT maintainers will accept comments about the
Linux /sys implementation in device tree files or bindings. Those
should be independent of Linux.
Basically the turbo-mode property is a hint to the OPP system (which
may or may not use of it).
So I think it is indeed better to have it in the commit message and
not the code.
One more thought: as long as we do not have junction temperature monitoring
we should keep it off by default... We may even remove the turbo-mode
designator if we have the 90°C limit and smart reflex working.
BR,
Nikolaus
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 17:43 ` H. Nikolaus Schaller
(?)
@ 2019-09-11 17:49 ` Adam Ford
2019-09-12 13:58 ` Adam Ford
-1 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-11 17:49 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel
On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
> Hi Adam,
>
> > Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> >>
> >> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
> >>
> >>> There are some subtleties for testing.
> >>>
> >>> * I have added turbo-mode; to OPP6 / OPP1G
> >>> * which means they are available but not used by the ondemand govenor
> >>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
> >>
> >> Will that be documented somewhere? If not, can we put a comment in the
> >> device tree so people know how to enable it?
> >
> > It seems to be pretty standard on i86 systems if you google for "turbo mode".
> > I have added it to the commit message which adds the vbb regulator.
>
> And, I am not sure if DT maintainers will accept comments about the
> Linux /sys implementation in device tree files or bindings. Those
> should be independent of Linux.
OK.
>
> Basically the turbo-mode property is a hint to the OPP system (which
> may or may not use of it).
>
> So I think it is indeed better to have it in the commit message and
> not the code.
That makes sense.
>
> One more thought: as long as we do not have junction temperature monitoring
> we should keep it off by default... We may even remove the turbo-mode
> designator if we have the 90°C limit and smart reflex working.
We're almost there!
adam
>
> BR,
> Nikolaus
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-11 17:49 ` Adam Ford
@ 2019-09-12 13:58 ` Adam Ford
2019-09-12 18:52 ` Adam Ford
0 siblings, 1 reply; 46+ messages in thread
From: Adam Ford @ 2019-09-12 13:58 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel
On Wed, Sep 11, 2019 at 12:49 PM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> >
> > Hi Adam,
> >
> > > Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > >
> > >>
> > >> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
> > >>
> > >>> There are some subtleties for testing.
> > >>>
> > >>> * I have added turbo-mode; to OPP6 / OPP1G
> > >>> * which means they are available but not used by the ondemand govenor
> > >>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
> > >>
> > >> Will that be documented somewhere? If not, can we put a comment in the
> > >> device tree so people know how to enable it?
> > >
> > > It seems to be pretty standard on i86 systems if you google for "turbo mode".
> > > I have added it to the commit message which adds the vbb regulator.
> >
> > And, I am not sure if DT maintainers will accept comments about the
> > Linux /sys implementation in device tree files or bindings. Those
> > should be independent of Linux.
>
> OK.
> >
> > Basically the turbo-mode property is a hint to the OPP system (which
> > may or may not use of it).
> >
> > So I think it is indeed better to have it in the commit message and
> > not the code.
>
> That makes sense.
>
> >
> > One more thought: as long as we do not have junction temperature monitoring
> > we should keep it off by default... We may even remove the turbo-mode
> > designator if we have the 90°C limit and smart reflex working.
I found some info on the thermal framework [1]. It seems to show that
we can put placeholders in the device tree to help facilitate this.
An excerpt from [1] shows:
Cooling devices provide control on power dissipation.
There are essentially two ways to provide control on power dissipation.
First is by means of regulating device performance, which is
known as passive cooling (DVFS).
... [snip stuff about cooling fans]
It also shows there are ways to link the cpu node to the cooling info.
Since it shows DVFS can be used to regulate temperature, it seems like
the hooks might already be in place
[1] - https://blog.linuxplumbersconf.org/2015/ocw//system/presentations/2613/original/thermal-framework-status-no-transitioning.pdf
The downside is that the OMAP thermal sensor is unreliable.
>
> We're almost there!
>
> adam
> >
> > BR,
> > Nikolaus
> >
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
2019-09-12 13:58 ` Adam Ford
@ 2019-09-12 18:52 ` Adam Ford
0 siblings, 0 replies; 46+ messages in thread
From: Adam Ford @ 2019-09-12 18:52 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Nishanth Menon, Linux-OMAP, Tony Lindgren,
Linux Kernel Mailing List, André Roth,
Discussions about the Letux Kernel
On Thu, Sep 12, 2019 at 8:58 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Wed, Sep 11, 2019 at 12:49 PM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Wed, Sep 11, 2019 at 12:43 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
> > >
> > > Hi Adam,
> > >
> > > > Am 11.09.2019 um 18:01 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> > > >
> > > >>
> > > >> Am 11.09.2019 um 17:56 schrieb Adam Ford <aford173@gmail.com>:
> > > >>
> > > >>> There are some subtleties for testing.
> > > >>>
> > > >>> * I have added turbo-mode; to OPP6 / OPP1G
> > > >>> * which means they are available but not used by the ondemand govenor
> > > >>> * to enable them one has to echo 1 >/sys/devices/system/cpu/cpufreq/boost
> > > >>
> > > >> Will that be documented somewhere? If not, can we put a comment in the
> > > >> device tree so people know how to enable it?
> > > >
> > > > It seems to be pretty standard on i86 systems if you google for "turbo mode".
> > > > I have added it to the commit message which adds the vbb regulator.
> > >
> > > And, I am not sure if DT maintainers will accept comments about the
> > > Linux /sys implementation in device tree files or bindings. Those
> > > should be independent of Linux.
> >
> > OK.
> > >
> > > Basically the turbo-mode property is a hint to the OPP system (which
> > > may or may not use of it).
> > >
> > > So I think it is indeed better to have it in the commit message and
> > > not the code.
> >
> > That makes sense.
> >
> > >
> > > One more thought: as long as we do not have junction temperature monitoring
> > > we should keep it off by default... We may even remove the turbo-mode
> > > designator if we have the 90°C limit and smart reflex working.
>
> I found some info on the thermal framework [1]. It seems to show that
> we can put placeholders in the device tree to help facilitate this.
>
> An excerpt from [1] shows:
> Cooling devices provide control on power dissipation.
> There are essentially two ways to provide control on power dissipation.
> First is by means of regulating device performance, which is
> known as passive cooling (DVFS).
> ... [snip stuff about cooling fans]
>
> It also shows there are ways to link the cpu node to the cooling info.
> Since it shows DVFS can be used to regulate temperature, it seems like
> the hooks might already be in place
>
> [1] - https://blog.linuxplumbersconf.org/2015/ocw//system/presentations/2613/original/thermal-framework-status-no-transitioning.pdf
>
> The downside is that the OMAP thermal sensor is unreliable.
I submitted an RFC for thermal throttling. I am not sure if I did it
right, and I don't have a good way to test it.
adam
> >
> > We're almost there!
> >
> > adam
> > >
> > > BR,
> > > Nikolaus
> > >
^ permalink raw reply [flat|nested] 46+ messages in thread