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: Sun, 17 Jul 2016 16:39:27 +0200 Message-ID: <49ce09ae-052a-bb2b-ce66-f0aa0d0024e3@megous.com> References: <20160623192104.18720-1-megous@megous.com> <20160623192104.18720-7-megous@megous.com> <20160625070208.GA4000@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="63kumigEHuHdLIJ5kqe2SluAfbEn4ojHq" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20160625070208.GA4000@lukather> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Maxime Ripard , Chen-Yu Tsai Cc: 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) --63kumigEHuHdLIJ5kqe2SluAfbEn4ojHq Content-Type: multipart/mixed; boundary="8X5f73B3gjjJ5fxHBjkgb9Vkcncgp10M6" From: =?UTF-8?Q?Ond=c5=99ej_Jirman?= To: Maxime Ripard , Chen-Yu Tsai Cc: dev , linux-arm-kernel , Rob Herring , Mark Rutland , Russell King , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list Message-ID: <49ce09ae-052a-bb2b-ce66-f0aa0d0024e3-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> 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> In-Reply-To: <20160625070208.GA4000@lukather> --8X5f73B3gjjJ5fxHBjkgb9Vkcncgp10M6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/sun8= i-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 all >>> 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. :( >=20 > This has never been the case, and we always had some deviation in the > FEX files for all the SoCs. >=20 > If we could come up with standard OPPs that work for every one, > there's no reason it can't happen here. >=20 > 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 (1368000000) core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) core: _opp_supported_by_regulators: OPP minuV: 1140000 maxuV: 1140000, not supported by regulator cpu cpu0: _opp_add: OPP not supported by regulators (1008000000) regards, o. > Maxime >=20 --=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. --8X5f73B3gjjJ5fxHBjkgb9Vkcncgp10M6-- --63kumigEHuHdLIJ5kqe2SluAfbEn4ojHq 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 iQIcBAEBCAAGBQJXi5ijAAoJEG5kJsZ3z+/xLuwP/RAYtPxBVE3tmQ9Egab4/Az2 UZiXopJPieB6LJAWV7ZdTbpQhWnE0BLng3ZnpTZwpCaw5VeuibEABhHSBulteXia FIfUjxNc/S0Hi8Q93s/JD0vt96DKz/hpS1rwITSDkZnNGG+epbDIIif/VhFJwBWO 7sftHzix/QlmmHCnSMRc0jkyK4bLsS44aXQwRGr9YQOo0j4ka85GPG6mcBraxqAE pw02Ae2L2H/HxepyHHH9cb2W607Ha9DQCqES3bje2psA2pciu/2FBhEIxYl4BVJ+ jHwMwf8q7b+fHikPBLJe4vfE6b/KyrPrux+RUFsx6ETpRCGLPq1Nvkcooqhr3KmF JwrsIca7vK1WCXJFJV08UvQ+JqEP9tCHI7O2Wc5LWDmj19TGAh+5faIQ09XpkXMl x7ynfLiXHxsGiGZnKEIiCm3WFmNpC6fxFQXtz9LzULfgA3BzSFn2fPOHi8Z0DeBo kh6oz70OHlZ1GGJ+zkXsocBODSOXWIAlPuYnsIlOjGMIfnbBI2/gS+9mMrsQJgRH 7mbwAtJHN0o2fdx+u+QkMZtA/jA2HBpKXkY1wf23eWxQ5iah+sj7ttxM706bgoSY X5H+6UF/UC2N5K1dQvrDt0kLLR6mBXEIeWFsSAu1aL92m0qBeOBmpphkPRmn90qS gZg1EiCJG463S0QLSduJ =v7LQ -----END PGP SIGNATURE----- --63kumigEHuHdLIJ5kqe2SluAfbEn4ojHq--