linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Suchanek <hramrach@gmail.com>
To: megous@megous.com
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
	Chen-Yu Tsai <wens@csie.org>, dev <dev@linux-sunxi.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi
Date: Thu, 30 Jun 2016 13:04:40 +0200	[thread overview]
Message-ID: <CAOMqctTocMFztGh7N0y=06XYGKGzx_qknM8v1VdJSuV8L7OdBQ@mail.gmail.com> (raw)
In-Reply-To: <a3cf3531-93a5-de35-b7f4-03d28cfebb3d@megous.com>

Hello,

On 29 June 2016 at 23:11, Ondřej Jirman <megous@megous.com> 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 <megous@megous.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> comments below.
>>>>>>
>>>>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>>>>> On Fri, Jun 24, 2016 at 3:20 AM,  <megous@megous.com> wrote:
>>>>>>>> From: Ondrej Jirman <megous@megous.com>
>>>>>>>>
>>>>>>>> Add label to the first cpu so that it can be referenced
>>>>>>>> from derived dts files.
>>>>>>>>
>>>>>>>> Signed-off-by: Ondrej Jirman <megous@megous.com>
>>>>>>>> ---
>>>>>>>>  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

  reply	other threads:[~2016-06-30 11:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160623192104.18720-1-megous@megous.com>
2016-06-23 19:20 ` [PATCH 01/14] ARM: dts: sun8i: Add SID node megous
2016-06-24  2:41   ` Chen-Yu Tsai
2016-06-24 19:58     ` Ondřej Jirman
2016-06-25  1:09       ` [linux-sunxi] " Chen-Yu Tsai
2016-06-23 19:20 ` [PATCH 02/14] ARM: clk: sunxi: Add driver for the H3 THS clock megous
2016-06-23 19:20 ` [PATCH 03/14] thermal: Add support for sun8i THS on Allwinner H3 megous
2016-06-24  3:09   ` Chen-Yu Tsai
2016-06-24 21:50     ` Ondřej Jirman
2016-06-25  0:35     ` Ondřej Jirman
2016-06-25  0:54       ` Chen-Yu Tsai
2016-06-25  0:56         ` Ondřej Jirman
2016-06-23 19:20 ` [PATCH 04/14] dt-bindings: document sun8i_ths megous
2016-06-24  2:46   ` Chen-Yu Tsai
2016-06-23 19:20 ` [PATCH 05/14] ARM: dts: sun8i: Add THS node to the sun8i-h3.dtsi megous
2016-06-23 19:20 ` [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi megous
2016-06-24  3:48   ` Chen-Yu Tsai
2016-06-24 22:51     ` Ondřej Jirman
2016-06-25  1:02       ` Chen-Yu Tsai
2016-06-25  7:02         ` Maxime Ripard
2016-06-25 14:50           ` Ondřej Jirman
2016-06-29 20:45             ` Maxime Ripard
2016-06-29 21:11               ` Ondřej Jirman
2016-06-30 11:04                 ` Michal Suchanek [this message]
2016-06-30 20:41                   ` [linux-sunxi] " Maxime Ripard
2016-07-17 14:39           ` Ondřej Jirman
2016-07-25  8:26             ` Maxime Ripard
     [not found]             ` <e57eb018-ef31-408e-84b2-b329510352d0@googlegroups.com>
2016-07-25  8:51               ` Maxime Ripard
2016-06-23 19:20 ` [PATCH 07/14] regulator: SY8106A regulator driver megous
2016-06-24  3:41   ` Chen-Yu Tsai
2016-06-25  0:11     ` Ondřej Jirman
2016-06-25  1:00       ` Chen-Yu Tsai
2016-06-23 19:20 ` [PATCH 08/14] ARM: dts: sun8i: Add r_twi I2C controller megous
2016-06-23 19:20 ` [PATCH 09/14] ARM: dts: sun8i: Enable r_twi on Orange Pi PC megous
2016-06-23 19:21 ` [PATCH 10/14] ARM: dts: sun8i: Add sy8106a regulator to " megous
2016-06-24  9:14   ` Chen-Yu Tsai
2016-06-23 19:21 ` [PATCH 11/14] ARM: sun8i: clk: Add clk-factor rate application method megous
2016-06-24  2:53   ` [linux-sunxi] " Julian Calaby
2016-06-23 19:21 ` [PATCH 12/14] ARM: dts: sun8i: Setup CPU operating points for Onrage PI PC megous
2016-06-23 19:21 ` [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One megous
2016-06-24  2:51   ` [linux-sunxi] " Julian Calaby
2016-06-24 22:39     ` Ondřej Jirman
2016-06-24  2:55   ` Julian Calaby
2016-06-23 19:21 ` [PATCH 14/14] ARM: dts: sun8i: Enable DVFS " megous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOMqctTocMFztGh7N0y=06XYGKGzx_qknM8v1VdJSuV8L7OdBQ@mail.gmail.com' \
    --to=hramrach@gmail.com \
    --cc=dev@linux-sunxi.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=megous@megous.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).