From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Ond=c5=99ej_Jirman?= Subject: Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi Date: Wed, 29 Jun 2016 23:11:11 +0200 Message-ID: References: <20160623192104.18720-1-megous@megous.com> <20160623192104.18720-7-megous@megous.com> <20160625070208.GA4000@lukather> <380ebf34-fd4a-ea2d-f9cf-68b8ede44757@megous.com> <20160629204553.GJ6095@lukather> Reply-To: megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Rl4Eor9tLbWgDqfHv4JgKTwKmEVrg2beG" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20160629204553.GJ6095@lukather> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Maxime Ripard Cc: Chen-Yu Tsai , dev , linux-arm-kernel , Rob Herring , Mark Rutland , Russell King , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list List-Id: devicetree@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Rl4Eor9tLbWgDqfHv4JgKTwKmEVrg2beG Content-Type: multipart/mixed; boundary="dUHqQFPPKjpxShM7itmHxW8PbdGlvFjSA" From: =?UTF-8?Q?Ond=c5=99ej_Jirman?= To: Maxime Ripard Cc: Chen-Yu Tsai , dev , linux-arm-kernel , Rob Herring , Mark Rutland , Russell King , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Message-ID: Subject: Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi References: <20160623192104.18720-1-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> <20160623192104.18720-7-megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> <20160625070208.GA4000@lukather> <380ebf34-fd4a-ea2d-f9cf-68b8ede44757-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> <20160629204553.GJ6095@lukather> In-Reply-To: <20160629204553.GJ6095@lukather> --dUHqQFPPKjpxShM7itmHxW8PbdGlvFjSA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29.6.2016 22:45, Maxime Ripard wrote: > Hi, >=20 > On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ond=C5=99ej 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=C5=99ej 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/su= n8i-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 =3D <1>; >>>>>>> #size-cells =3D <0>; >>>>>>> >>>>>>> - cpu@0 { >>>>>>> + cpu0: cpu@0 { >>>>>>> compatible =3D "arm,cortex-a7"; >>>>>>> device_type =3D "cpu"; >>>>>>> reg =3D <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 a= ll >>>>> H3 boards out there. >>>> >>>> I meant clocks =3D <...> and clock-latency =3D <...>. >>>> >>>> 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=C2=B0C (first trip point) to over 110=C2=B0C in l= ess 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. >=20 > 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. >=20 > But that's just my understanding, I might be speaking non-sense :) >=20 > Maxime >=20 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 --=20 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 e= mail to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout. --dUHqQFPPKjpxShM7itmHxW8PbdGlvFjSA-- --Rl4Eor9tLbWgDqfHv4JgKTwKmEVrg2beG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXdDlzAAoJEG5kJsZ3z+/xr68QAIjuh5vvGqj3U9UWtdnKBLru n7qZxCR0HHv//JemMt7nw6w9ClAjfKsRyDTMx4+XhIf4ptd0dUaoKpy8s2Q7A5H1 5gFQ5H5NptSlo4874DS/HE/oh0fx8Fc9PJ56XccrZZGIcrX+aZms+MZWIIXXK4x6 mGzbxCm9Wo5Cv6EBPEKzqh1wZnRtrn3yELmbJ8r7xD3z9U52WgFvUO0MulVJCOX2 7wRk0eDBz6VaQhZrbeuAAfeOstxDVZDGeTg+q8hnU1aqT2HjHXe6fvbe34DQUm4K 8lsmWPJDrHjzgAGdy8MsHmVBY6Z57g2oWFo1i0lsKIAil8nlvHz/rFwb3Lpg3pbK NKUcxqrqwJfxVX14uRTHN0tm0o0rb8X5QILhdxkZbzzR3PRg5PYVEwK1jeixJ5u0 bkVJof4k69oIPrZrEPTlPfLcDCocnR/uzqltZDcQCQNwCu/kw5hbcV6i6/cvZs3z TU+RMxxVTiTs6iMACPOekdO13xM6WZ8t324mVYbf57HdViQe5UQrBAx4w6HBABz1 9womTJvXhPOqp+xp32k+k9nYx3cNfy8TeApvI8EoKlApiBYbhyBJrV+ga1nguGlQ 7eEBIfDoy6NNG/Org36t6KvAqA0HqEIx3dbSuq22y+fB0/p9M5/V3L9lBsidPX3j 2CTWrrCBYvMTQ4mHtnd5 =V17f -----END PGP SIGNATURE----- --Rl4Eor9tLbWgDqfHv4JgKTwKmEVrg2beG--