[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Maxime Ripard]

On Tue, Jul 19, 2016 at 07:10:54AM -0700, Thomas Kaiser wrote:
> Hi,
> 
> Ondřej Jirman wrote:
> >
> > We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned 
> > voltage regulation and every such board will need it's own set of 
> > operating points. 
> >
> 
> Yes, and Allwinner's current BSP kernel code might encourage board makers 
> to implement a forth variant: switching between 4 different voltages 
> through GPIOs.
> 
> Currently we have 4 boards that rely on the simple '2 voltage regulation' 
> all using 1.1V/1.3V: Orange Pi One and Lite and NanoPi M1 and NEO. Then 
> there are 2 devices with (legacy) Linux support existing that use no 
> voltage regulation at all: Banana Pi M2+ (according to schematic using 1.2V 
> but in reality it's 1.3V VDD_CPUX) and Beelink X2. And according to Tsvetan 
> if/when Olimex will release their 2 H3 boards we have two more with fixed 
> but yet unknown VDD_CPUX voltage (since olimex fears overheating maybe they 
> use 1.1V or 1.2V limiting max cpufreq to 816 or 1008 MHz). And all the 
> bigger H3 based Orange Pi use the SY8106A voltage regulator being able to 
> adjust VDD_CPUX in steps of 20mV allowing VDD_CPUX to exceed 1200 MHz (a 
> reasonable value seems to be 1296 MHz since above throttling will be an 
> issue without active cooling)

Ok, good to know. I'm not sure overclocking is ever a reasonable
solution, but that's a separate topic.

> Things get even worse since Xunlong uses copper layers inside the PCB to 
> spread the heat away from H3 so Orange Pi One/Lite do not overheat that 
> much like eg. NanoPi M1 (and maybe NEO -- can tell next week when I get dev 
> samples to play with). So while eg. Orange Pi One and NanoPi M1 switch 
> between the same voltages in the same way we (Armbian) found that we have 
> to allow M1 to downclock to even 240 MHz since when testing with legacy 
> kernel really heavy workloads led to throttling that low (even CPU cores 
> were killed at this low clockspeed -- same applies to BPi M2+ and Beelink 
> X2)

And that's what I really want to avoid. Even though that board
absolutely requires the 240MHz OPP to run properly, nothing prevents
from using that OPP on other boards as well, that will also benefit
from it. Thermal throttling is something that needs to be handled, but
power management is also something we should consider, and I see no
reason why not to have a consistent set of operating frequencies, even
though the voltage might differ depending on the regulator
capabilities.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Maxime Ripard]

On Sun, Jul 17, 2016 at 04:39:27PM +0200, Ondřej Jirman wrote:
> 
> 
> On 25.6.2016 09:02, Maxime Ripard wrote:
> > On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> >> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> >>> Hello,
> >>>
> >>> comments below.
> >>>
> >>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>  On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> > From: Ondrej Jirman 
> >
> > Add label to the first cpu so that it can be referenced
> > from derived dts files.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 9938972..82faefc 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -52,7 +52,7 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > -   cpu@0 {
> > +   cpu0: cpu@0 {
> > compatible = "arm,cortex-a7";
> > device_type = "cpu";
> > reg = <0>;
> 
>  Can you also set the cpu clock here? It is part of the SoC
>  and does not belong in the board DTS files.
> >>>
> >>> Do you mean operating-points, or something else? Different SBCs will
> >>> probably require different combinations of operating points just for
> >>> safety's sake, because they have different regulators and [some have
> >>> botched] thermal designs, so it might make sense to customize it for
> >>> differnt boards, and I don't feel adventurous enough setting it for all
> >>> H3 boards out there.
> >>
> >> I meant clocks = <...> and clock-latency = <...>.
> >>
> >> These 2 are part of the SoC.
> >>
> >> The OPP can stay in the board files. It's a pity there's no standard
> >> OPP table for H3 though. :(
> > 
> > This has never been the case, and we always had some deviation in the
> > FEX files for all the SoCs.
> > 
> > If we could come up with standard OPPs that work for every one,
> > there's no reason it can't happen here.
> > 
> > I don't really see why the thermal design should change anything. If a
> > boards heats faster, it will throttle down to a lower OPP faster, but
> > those OPPs are not going to change.
> 
> So I tried, and found out that it will not be so easy. Different boards
> have different regulators, and linux doesn't deal well with voltages
> that are not supported by the regulator.
> 
> So even if the board can run at certain frequency if you round the
> voltage to the next higher voltage supported by the regulator, opp
> implementation doesn't do the rounding and just drops the operating
> points that have no support in the voltage regulator.
> 
> We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned
> voltage regulation and every such board will need it's own set of
> operating points.
> 
> I'd leave the OPP definitions in the board files for now.

Works for me.

Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Thomas Kaiser]

Hi,

Ondřej Jirman wrote:
>
> We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned 
> voltage regulation and every such board will need it's own set of 
> operating points. 
>

Yes, and Allwinner's current BSP kernel code might encourage board makers 
to implement a forth variant: switching between 4 different voltages 
through GPIOs.

Currently we have 4 boards that rely on the simple '2 voltage regulation' 
all using 1.1V/1.3V: Orange Pi One and Lite and NanoPi M1 and NEO. Then 
there are 2 devices with (legacy) Linux support existing that use no 
voltage regulation at all: Banana Pi M2+ (according to schematic using 1.2V 
but in reality it's 1.3V VDD_CPUX) and Beelink X2. And according to Tsvetan 
if/when Olimex will release their 2 H3 boards we have two more with fixed 
but yet unknown VDD_CPUX voltage (since olimex fears overheating maybe they 
use 1.1V or 1.2V limiting max cpufreq to 816 or 1008 MHz). And all the 
bigger H3 based Orange Pi use the SY8106A voltage regulator being able to 
adjust VDD_CPUX in steps of 20mV allowing VDD_CPUX to exceed 1200 MHz (a 
reasonable value seems to be 1296 MHz since above throttling will be an 
issue without active cooling)

Things get even worse since Xunlong uses copper layers inside the PCB to 
spread the heat away from H3 so Orange Pi One/Lite do not overheat that 
much like eg. NanoPi M1 (and maybe NEO -- can tell next week when I get dev 
samples to play with). So while eg. Orange Pi One and NanoPi M1 switch 
between the same voltages in the same way we (Armbian) found that we have 
to allow M1 to downclock to even 240 MHz since when testing with legacy 
kernel really heavy workloads led to throttling that low (even CPU cores 
were killed at this low clockspeed -- same applies to BPi M2+ and Beelink 
X2)

So i would second Ondřej's suggestions since when we're talking about H3 
devices we're not talking about tablet SoCs with accompanied PMU but 3 
classes of devices behaving totally different in regard to cpufreq limits 
and dvfs OPPs (and maybe someone is already developing a new H3 device 
adding a forth variant switching between 4 different VDD_CPUX voltages)

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
 On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> Add label to the first cpu so that it can be referenced
> from derived dts files.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9938972..82faefc 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -52,7 +52,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> -   cpu@0 {
> +   cpu0: cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;

 Can you also set the cpu clock here? It is part of the SoC
 and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

So I tried, and found out that it will not be so easy. Different boards
have different regulators, and linux doesn't deal well with voltages
that are not supported by the regulator.

So even if the board can run at certain frequency if you round the
voltage to the next higher voltage supported by the regulator, opp
implementation doesn't do the rounding and just drops the operating
points that have no support in the voltage regulator.

We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned
voltage regulation and every such board will need it's own set of
operating points.

I'd leave the OPP definitions in the board files for now.

cpu cpu0: _opp_add: OPP not supported by regulators (136800)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (134400)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (129600)
core: _opp_supported_by_regulators: OPP minuV: 120 maxuV: 120,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (110400)
core: _opp_supported_by_regulators: OPP minuV: 114 maxuV: 114,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (100800)

regards,
  o.

> Maxime
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Maxime Ripard]

On Thu, Jun 30, 2016 at 01:04:40PM +0200, Michal Suchanek wrote:
> > You're probably right. Operating points should be part of h3.dtsi, and
> > if some board is particularly bad, and can't handle being above certain
> > frequency safely, due to thermal design issues, we can override
> > operating points in its dts file.
> >
> 
> Can you override them?
> 
> AFAIK you cannot replace a property set in SoC file in a board file.

You totally can, we have litterally dozens of examples of that already.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Michal Suchanek]

Hello,

On 29 June 2016 at 23:11, Ondřej Jirman  wrote:
> On 29.6.2016 22:45, Maxime Ripard wrote:
>> Hi,
>>
>> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>>> On 25.6.2016 09:02, Maxime Ripard wrote:
 On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>> Hello,
>>
>> comments below.
>>
>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
 From: Ondrej Jirman 

 Add label to the first cpu so that it can be referenced
 from derived dts files.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
 b/arch/arm/boot/dts/sun8i-h3.dtsi
 index 9938972..82faefc 100644
 --- a/arch/arm/boot/dts/sun8i-h3.dtsi
 +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
 @@ -52,7 +52,7 @@
 #address-cells = <1>;
 #size-cells = <0>;

 -   cpu@0 {
 +   cpu0: cpu@0 {
 compatible = "arm,cortex-a7";
 device_type = "cpu";
 reg = <0>;
>>>
>>> Can you also set the cpu clock here? It is part of the SoC
>>> and does not belong in the board DTS files.
>>
>> Do you mean operating-points, or something else? Different SBCs will
>> probably require different combinations of operating points just for
>> safety's sake, because they have different regulators and [some have
>> botched] thermal designs, so it might make sense to customize it for
>> differnt boards, and I don't feel adventurous enough setting it for all
>> H3 boards out there.
>
> I meant clocks = <...> and clock-latency = <...>.
>
> These 2 are part of the SoC.
>
> The OPP can stay in the board files. It's a pity there's no standard
> OPP table for H3 though. :(

 This has never been the case, and we always had some deviation in the
 FEX files for all the SoCs.

 If we could come up with standard OPPs that work for every one,
 there's no reason it can't happen here.

 I don't really see why the thermal design should change anything. If a
 boards heats faster, it will throttle down to a lower OPP faster, but
 those OPPs are not going to change.
>>>
>>> I've no way to test, but I've been told some Sinovoip boards are really
>>> bad in this regard (SoC is not even well thermally connected to the
>>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>>> readings happen at fixed intervals, so the question is if you can heat
>>> up the soc from say 80°C (first trip point) to over 110°C in less than
>>> that period (330ms currently).
>>>
>>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>>> at max load. It will burn or trigger a second trip point before the
>>> first one has a chance to trigger and the kernel will shut down. I
>>> remember tkaiser saying that he has to run that board at 240MHz max. But
>>> perhaps I'm misremembering.
>>>
>>> I'm just speculating.
>>
>> Yes, but that's just poor thermal design. What I was saying is that
>> even if we really need to throttle the SoC to 240 MHz on that board
>> because it heats too much, the couple of the frequency and the voltage
>> will likely be the same across all boards. It's just the amount of
>> time we'll spend using it that will differ.
>>
>> But that's just my understanding, I might be speaking non-sense :)
>>
>> Maxime
>>
>
> You're probably right. Operating points should be part of h3.dtsi, and
> if some board is particularly bad, and can't handle being above certain
> frequency safely, due to thermal design issues, we can override
> operating points in its dts file.
>

Can you override them?

AFAIK you cannot replace a property set in SoC file in a board file.
If you can keep the operating point list and just add option which
selects acceptable subset for the board that should work. On some
boards this subset would be determined by regulator voltage
constraints but not sure how you would select the subset for the
boards with thermal problems.

Thanks

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 29.6.2016 22:45, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>> On 25.6.2016 09:02, Maxime Ripard wrote:
>>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
 On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> Hello,
>
> comments below.
>
> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Add label to the first cpu so that it can be referenced
>>> from derived dts files.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 9938972..82faefc 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -52,7 +52,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> -   cpu@0 {
>>> +   cpu0: cpu@0 {
>>> compatible = "arm,cortex-a7";
>>> device_type = "cpu";
>>> reg = <0>;
>>
>> Can you also set the cpu clock here? It is part of the SoC
>> and does not belong in the board DTS files.
>
> Do you mean operating-points, or something else? Different SBCs will
> probably require different combinations of operating points just for
> safety's sake, because they have different regulators and [some have
> botched] thermal designs, so it might make sense to customize it for
> differnt boards, and I don't feel adventurous enough setting it for all
> H3 boards out there.

 I meant clocks = <...> and clock-latency = <...>.

 These 2 are part of the SoC.

 The OPP can stay in the board files. It's a pity there's no standard
 OPP table for H3 though. :(
>>>
>>> This has never been the case, and we always had some deviation in the
>>> FEX files for all the SoCs.
>>>
>>> If we could come up with standard OPPs that work for every one,
>>> there's no reason it can't happen here.
>>>
>>> I don't really see why the thermal design should change anything. If a
>>> boards heats faster, it will throttle down to a lower OPP faster, but
>>> those OPPs are not going to change.
>>
>> I've no way to test, but I've been told some Sinovoip boards are really
>> bad in this regard (SoC is not even well thermally connected to the
>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>> readings happen at fixed intervals, so the question is if you can heat
>> up the soc from say 80°C (first trip point) to over 110°C in less than
>> that period (330ms currently).
>>
>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>> at max load. It will burn or trigger a second trip point before the
>> first one has a chance to trigger and the kernel will shut down. I
>> remember tkaiser saying that he has to run that board at 240MHz max. But
>> perhaps I'm misremembering.
>>
>> I'm just speculating.
> 
> Yes, but that's just poor thermal design. What I was saying is that
> even if we really need to throttle the SoC to 240 MHz on that board
> because it heats too much, the couple of the frequency and the voltage
> will likely be the same across all boards. It's just the amount of
> time we'll spend using it that will differ.
> 
> But that's just my understanding, I might be speaking non-sense :)
> 
> Maxime
> 

You're probably right. Operating points should be part of h3.dtsi, and
if some board is particularly bad, and can't handle being above certain
frequency safely, due to thermal design issues, we can override
operating points in its dts file.

regards,
  Ondrej

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Maxime Ripard]

Hi,

On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
> On 25.6.2016 09:02, Maxime Ripard wrote:
> > On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> >> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> >>> Hello,
> >>>
> >>> comments below.
> >>>
> >>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>  On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> > From: Ondrej Jirman 
> >
> > Add label to the first cpu so that it can be referenced
> > from derived dts files.
> >
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> > b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 9938972..82faefc 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -52,7 +52,7 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > -   cpu@0 {
> > +   cpu0: cpu@0 {
> > compatible = "arm,cortex-a7";
> > device_type = "cpu";
> > reg = <0>;
> 
>  Can you also set the cpu clock here? It is part of the SoC
>  and does not belong in the board DTS files.
> >>>
> >>> Do you mean operating-points, or something else? Different SBCs will
> >>> probably require different combinations of operating points just for
> >>> safety's sake, because they have different regulators and [some have
> >>> botched] thermal designs, so it might make sense to customize it for
> >>> differnt boards, and I don't feel adventurous enough setting it for all
> >>> H3 boards out there.
> >>
> >> I meant clocks = <...> and clock-latency = <...>.
> >>
> >> These 2 are part of the SoC.
> >>
> >> The OPP can stay in the board files. It's a pity there's no standard
> >> OPP table for H3 though. :(
> > 
> > This has never been the case, and we always had some deviation in the
> > FEX files for all the SoCs.
> > 
> > If we could come up with standard OPPs that work for every one,
> > there's no reason it can't happen here.
> > 
> > I don't really see why the thermal design should change anything. If a
> > boards heats faster, it will throttle down to a lower OPP faster, but
> > those OPPs are not going to change.
> 
> I've no way to test, but I've been told some Sinovoip boards are really
> bad in this regard (SoC is not even well thermally connected to the
> PCB/PCB not having copper layer to spread the heat). Thermal sensor
> readings happen at fixed intervals, so the question is if you can heat
> up the soc from say 80°C (first trip point) to over 110°C in less than
> that period (330ms currently).
> 
> I say it shouldn't be a problem, if that small thing is drawing say 2W
> at max load. It will burn or trigger a second trip point before the
> first one has a chance to trigger and the kernel will shut down. I
> remember tkaiser saying that he has to run that board at 240MHz max. But
> perhaps I'm misremembering.
> 
> I'm just speculating.

Yes, but that's just poor thermal design. What I was saying is that
even if we really need to throttle the SoC to 240 MHz on that board
because it heats too much, the couple of the frequency and the voltage
will likely be the same across all boards. It's just the amount of
time we'll spend using it that will differ.

But that's just my understanding, I might be speaking non-sense :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
 On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> Add label to the first cpu so that it can be referenced
> from derived dts files.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9938972..82faefc 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -52,7 +52,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> -   cpu@0 {
> +   cpu0: cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;

 Can you also set the cpu clock here? It is part of the SoC
 and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

I've no way to test, but I've been told some Sinovoip boards are really
bad in this regard (SoC is not even well thermally connected to the
PCB/PCB not having copper layer to spread the heat). Thermal sensor
readings happen at fixed intervals, so the question is if you can heat
up the soc from say 80°C (first trip point) to over 110°C in less than
that period (330ms currently).

I say it shouldn't be a problem, if that small thing is drawing say 2W
at max load. It will burn or trigger a second trip point before the
first one has a chance to trigger and the kernel will shut down. I
remember tkaiser saying that he has to run that board at 240MHz max. But
perhaps I'm misremembering.

I'm just speculating.

regards,
  Ondrej



> Maxime
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Maxime Ripard]

On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> > Hello,
> >
> > comments below.
> >
> > On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> >> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> >>> From: Ondrej Jirman 
> >>>
> >>> Add label to the first cpu so that it can be referenced
> >>> from derived dts files.
> >>>
> >>> Signed-off-by: Ondrej Jirman 
> >>> ---
> >>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
> >>> b/arch/arm/boot/dts/sun8i-h3.dtsi
> >>> index 9938972..82faefc 100644
> >>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> >>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> >>> @@ -52,7 +52,7 @@
> >>> #address-cells = <1>;
> >>> #size-cells = <0>;
> >>>
> >>> -   cpu@0 {
> >>> +   cpu0: cpu@0 {
> >>> compatible = "arm,cortex-a7";
> >>> device_type = "cpu";
> >>> reg = <0>;
> >>
> >> Can you also set the cpu clock here? It is part of the SoC
> >> and does not belong in the board DTS files.
> >
> > Do you mean operating-points, or something else? Different SBCs will
> > probably require different combinations of operating points just for
> > safety's sake, because they have different regulators and [some have
> > botched] thermal designs, so it might make sense to customize it for
> > differnt boards, and I don't feel adventurous enough setting it for all
> > H3 boards out there.
> 
> I meant clocks = <...> and clock-latency = <...>.
> 
> These 2 are part of the SoC.
> 
> The OPP can stay in the board files. It's a pity there's no standard
> OPP table for H3 though. :(

This has never been the case, and we always had some deviation in the
FEX files for all the SoCs.

If we could come up with standard OPPs that work for every one,
there's no reason it can't happen here.

I don't really see why the thermal design should change anything. If a
boards heats faster, it will throttle down to a lower OPP faster, but
those OPPs are not going to change.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Chen-Yu Tsai]

On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
> Hello,
>
> comments below.
>
> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>>> From: Ondrej Jirman 
>>>
>>> Add label to the first cpu so that it can be referenced
>>> from derived dts files.
>>>
>>> Signed-off-by: Ondrej Jirman 
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 9938972..82faefc 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -52,7 +52,7 @@
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> -   cpu@0 {
>>> +   cpu0: cpu@0 {
>>> compatible = "arm,cortex-a7";
>>> device_type = "cpu";
>>> reg = <0>;
>>
>> Can you also set the cpu clock here? It is part of the SoC
>> and does not belong in the board DTS files.
>
> Do you mean operating-points, or something else? Different SBCs will
> probably require different combinations of operating points just for
> safety's sake, because they have different regulators and [some have
> botched] thermal designs, so it might make sense to customize it for
> differnt boards, and I don't feel adventurous enough setting it for all
> H3 boards out there.

I meant clocks = <...> and clock-latency = <...>.

These 2 are part of the SoC.

The OPP can stay in the board files. It's a pity there's no standard
OPP table for H3 though. :(

ChenYu

>
> Or is this comment related to the missing cpu clock rate message I see
> on every boot?
>
> [0.058912] /cpus/cpu@0 missing clock-frequency property
>
> regards,
>   Ondrej
>
>> Otherwise this one looks good.
>>
>> ChenYu
>>
>>> --
>>> 2.9.0
>>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

Hello,

comments below.

On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Add label to the first cpu so that it can be referenced
>> from derived dts files.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 9938972..82faefc 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -52,7 +52,7 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> -   cpu@0 {
>> +   cpu0: cpu@0 {
>> compatible = "arm,cortex-a7";
>> device_type = "cpu";
>> reg = <0>;
> 
> Can you also set the cpu clock here? It is part of the SoC
> and does not belong in the board DTS files.

Do you mean operating-points, or something else? Different SBCs will
probably require different combinations of operating points just for
safety's sake, because they have different regulators and [some have
botched] thermal designs, so it might make sense to customize it for
differnt boards, and I don't feel adventurous enough setting it for all
H3 boards out there.

Or is this comment related to the missing cpu clock rate message I see
on every boot?

[0.058912] /cpus/cpu@0 missing clock-frequency property

regards,
  Ondrej

> Otherwise this one looks good.
> 
> ChenYu
> 
>> --
>> 2.9.0
>>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Chen-Yu Tsai]

On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
> From: Ondrej Jirman 
>
> Add label to the first cpu so that it can be referenced
> from derived dts files.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 9938972..82faefc 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -52,7 +52,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> -   cpu@0 {
> +   cpu0: cpu@0 {
> compatible = "arm,cortex-a7";
> device_type = "cpu";
> reg = <0>;

Can you also set the cpu clock here? It is part of the SoC
and does not belong in the board DTS files.

Otherwise this one looks good.

ChenYu

> --
> 2.9.0
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.