From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs Date: Fri, 22 Apr 2016 08:44:07 +0100 Message-ID: <5719D647.6000407@arm.com> References: <1461122150-9042-1-git-send-email-jay.xu@rock-chips.com> <5718AFB8.5070004@rock-chips.com> <20160421123018.096d4a75@arm.com> <2131452.5tyGOfVRfi@diego> <20160421221228.359fab3c@arm.com> <57198351.2060608@rock-chips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <57198351.2060608-TNX95d0MmH7DzftRWevZcw@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "jay.xu" , =?UTF-8?Q?Heiko_St=c3=bcbner?= Cc: "Huang, Tao" , Mark Rutland , will.deacon-5wv7dgnIgG8@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, pawel.moll-5wv7dgnIgG8@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, catalin.marinas-5wv7dgnIgG8@public.gmane.org, davidriley-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, jwerner-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, smbarber-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On 22/04/16 02:50, jay.xu wrote: > Hi Marc: >=20 > On 2016=E5=B9=B404=E6=9C=8822=E6=97=A5 05:12, Marc Zyngier wrote: >> On Thu, 21 Apr 2016 22:24:09 +0200 >> Heiko St=C3=BCbner wrote: >> >>> Am Donnerstag, 21. April 2016, 12:30:18 schrieb Marc Zyngier: >>>> On Thu, 21 Apr 2016 18:47:20 +0800 >>>> >>>> "Huang, Tao" wrote: >>>>> Hi, Mark: >>>>> >>>>> On 2016=E5=B9=B404=E6=9C=8821=E6=97=A5 18:19, Mark Rutland wrote: >>>>>> On Thu, Apr 21, 2016 at 11:58:12AM +0800, Jianqun Xu wrote: >>>>>>> + cpu_l0: cpu@0 { >>>>>>> + device_type =3D "cpu"; >>>>>>> + compatible =3D "arm,cortex-a53", "arm,armv8"; >>>>>>> + reg =3D <0x0 0x0>; >>>>>>> + enable-method =3D "psci"; >>>>>>> + #cooling-cells =3D <2>; /* min followed by max */ >>>>>>> + clocks =3D <&cru ARMCLKL>; >>>>>>> + }; >>>>>>> + cpu_b0: cpu@100 { >>>>>>> + device_type =3D "cpu"; >>>>>>> + compatible =3D "arm,cortex-a72", "arm,armv8"; >>>>>>> + reg =3D <0x0 0x100>; >>>>>>> + enable-method =3D "psci"; >>>>>>> + #cooling-cells =3D <2>; /* min followed by max */ >>>>>>> + clocks =3D <&cru ARMCLKB>; >>>>>>> + }; >>>>>>> + >>>>>>> + arm-pmu { >>>>>>> + compatible =3D "arm,armv8-pmuv3"; >>>>>>> + interrupts =3D ; >>>>>>> + }; >>>>>> This is wrong, and must go. There should be a separate node for = the PMU >>>>>> of each microarchitecture, with the appropriate compatible strin= g to >>>>>> represent that (see the juno dts). >>>>> You are right. The first version we wrote is: >>>>> pmu_a53 { >>>>> =20 >>>>> compatible =3D "arm,cortex-a53-pmu"; >>>>> interrupts =3D ; >>>>> interrupt-affinity =3D <&cpu_l0>, >>>>> =20 >>>>> <&cpu_l1>, >>>>> <&cpu_l2>, >>>>> <&cpu_l3>; >>>>> =20 >>>>> }; >>>>> =20 >>>>> pmu_a72 { >>>>> =20 >>>>> compatible =3D "arm,cortex-a72-pmu"; >>>>> interrupts =3D ; >>>>> interrupt-affinity =3D <&cpu_b0>, >>>>> =20 >>>>> <&cpu_b1>; >>>>> =20 >>>>> }; >>>>> >>>>> but unfortunately, the arm pmu driver do not support PPI in two c= luster >>>>> well, >>>>> so we have to replace with this implementation. >>>>> >>>>>> In this case things are messier as the same PPI number is being = used >>>>>> across clusters. Marc (Cc'd) has been working on PPI partitions,= which >>>>>> should allow us to support that. >>>>> Great! So what we can do right now? Wait this feature, and delete >>>>> arm-pmu node? >>>> I'd rather you have a look at the patches, test them with your HW, >>>> and comment on what doesn't work! >>> I would think we could do it in two tracks, testing and fixing but = also letting >>> the rk3399 devicetrees move forward without the pmu at first :-) . >> Where would the fun be then? ;-) > thanks for your advices, and I will try to test the percpu-partition=20 > patches. >=20 > by the way, do you think it's better to let the dtsi be reviewed firs= t, > then the percpu-partition patches could be tested by more people ? Up to you. As long as what is in the DT is correct and Acked by the DT maintainers, I'm fine with it. Thanks, M. --=20 Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html