From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1168452AbdDXK0A (ORCPT ); Mon, 24 Apr 2017 06:26:00 -0400 Received: from hermes.aosc.io ([199.195.250.187]:50020 "EHLO hermes.aosc.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933783AbdDXKZx (ORCPT ); Mon, 24 Apr 2017 06:25:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 24 Apr 2017 18:25:51 +0800 From: icenowy@aosc.io To: Maxime Ripard Cc: devicetree@vger.kernel.org, Mark Brown , linux-sunxi@googlegroups.com, Liam Girdwood , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Rob Herring , Lee Jones , linux-arm-kernel@lists.infradead.org Subject: Re: [linux-sunxi] Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64 In-Reply-To: <20170424071746.u2lrk43kmvvd7m25@lukather> References: <20170417115747.7300-1-icenowy@aosc.io> <20170417115747.7300-3-icenowy@aosc.io> <20170418070016.qsng3qtk76bqxyc5@lukather> <20170420055802.btibui5pspan4qal@lukather> <18ae853e9ce59a83bdeb6b64f96caee0@aosc.io> <20170424071746.u2lrk43kmvvd7m25@lukather> Message-ID: <2970665c4666a321f14a8d2ff13bc57c@aosc.io> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2017-04-24 15:17，Maxime Ripard 写道： > On Thu, Apr 20, 2017 at 03:03:38PM +0800, icenowy@aosc.io wrote: >> 在 2017-04-20 13:58，Maxime Ripard 写道： >> > On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote: >> > > >> > > >> > > 于 2017年4月18日 GMT+08:00 下午3:00:16, Maxime Ripard >> > > 写到: >> > > >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote: >> > > >> Allwinner A64 SoC features a NMI controller, which is usually >> > > >connected >> > > >> to the AXP PMIC. >> > > >> >> > > >> Add support for it. >> > > >> >> > > >> Signed-off-by: Icenowy Zheng >> > > >> Acked-by: Chen-Yu Tsai >> > > >> --- >> > > >> Changes in v2: >> > > >> - Added Chen-Yu's ACK. >> > > >> >> > > >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++ >> > > >> 1 file changed, 8 insertions(+) >> > > >> >> > > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> index 05ec9fc5e81f..53c18ca372ea 100644 >> > > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> @@ -403,6 +403,14 @@ >> > > >> ; >> > > >> }; >> > > >> >> > > >> + nmi_intc: interrupt-controller@01f00c0c { >> > > >> + compatible = "allwinner,sun6i-a31-sc-nmi"; >> > > >> + interrupt-controller; >> > > >> + #interrupt-cells = <2>; >> > > >> + reg = <0x01f00c0c 0x38>; >> > > > >> > > >The base address is not correct, and there's uncertainty on whether >> > > >this is this particular controller or not. Did you even test this? >> > > >> > > Tested by axp20x-pek. >> > >> > Still, the base address is wrong, which is yet another hint that this >> > is not the same interrupt controller, and just works by accident. >> >> No, it's the same as other post-sun6i device trees. >> See other post-sun6i device trees: (or maybe they're all wrong, but >> as we have no document for it, we should temporarily keep them) >> >> sun6i-a31.dtsi >> ``` >> nmi_intc: interrupt-controller@01f00c0c { >> compatible = "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells = <2>; >> reg = <0x01f00c0c 0x38>; >> interrupts = ; >> }; >> ``` >> >> sun8i-a23-a33.dtsi >> ``` >> nmi_intc: interrupt-controller@01f00c0c { >> compatible = "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells = <2>; >> reg = <0x01f00c0c 0x38>; >> interrupts = ; >> }; >> ``` >> >> But according to the BSP device tree, the base address should be >> 0x01f00c00. Should I send some patch to fix all of them? (but it will >> break device tree compatibility) > > I'm really not a big fan of "if we see something that is broken, just > let it rot" to be honest. > > We have no idea how this controller works exactly, just like we have > no idea if it is exactly the same controller or not. > > The only thing we have today is the memory map, and it tells us that > it has more registers than what you express here. > > Because of the DT backward compatibility, you have to think of it the > other way around: what will happen if it turns out we need to setup > any register outside of that region you described in the DT, in > something like a year or so? > > We can't, really. While if you have the full memory region from the > beginning, then you just have to add a single writel in your driver. So things are now already broken, and we may need to fix also A31 and A23/33. How should we do this? > > Maxime > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: icenowy-h8G6r0blFSE@public.gmane.org Subject: Re: Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64 Date: Mon, 24 Apr 2017 18:25:51 +0800 Message-ID: <2970665c4666a321f14a8d2ff13bc57c@aosc.io> References: <20170417115747.7300-1-icenowy@aosc.io> <20170417115747.7300-3-icenowy@aosc.io> <20170418070016.qsng3qtk76bqxyc5@lukather> <20170420055802.btibui5pspan4qal@lukather> <18ae853e9ce59a83bdeb6b64f96caee0@aosc.io> <20170424071746.u2lrk43kmvvd7m25@lukather> Reply-To: icenowy-h8G6r0blFSE@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20170424071746.u2lrk43kmvvd7m25@lukather> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Maxime Ripard Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mark Brown , linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Liam Girdwood , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai , Rob Herring , Lee Jones , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org =E5=9C=A8 2017-04-24 15:17=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93=EF=BC= =9A > On Thu, Apr 20, 2017 at 03:03:38PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote: >> =E5=9C=A8 2017-04-20 13:58=EF=BC=8CMaxime Ripard =E5=86=99=E9=81=93=EF= =BC=9A >> > On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote: >> > > >> > > >> > > =E4=BA=8E 2017=E5=B9=B44=E6=9C=8818=E6=97=A5 GMT+08:00 =E4=B8=8B=E5= =8D=883:00:16, Maxime Ripard >> > > =E5=86=99=E5=88=B0: >> > > >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote: >> > > >> Allwinner A64 SoC features a NMI controller, which is usually >> > > >connected >> > > >> to the AXP PMIC. >> > > >> >> > > >> Add support for it. >> > > >> >> > > >> Signed-off-by: Icenowy Zheng >> > > >> Acked-by: Chen-Yu Tsai >> > > >> --- >> > > >> Changes in v2: >> > > >> - Added Chen-Yu's ACK. >> > > >> >> > > >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++ >> > > >> 1 file changed, 8 insertions(+) >> > > >> >> > > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> index 05ec9fc5e81f..53c18ca372ea 100644 >> > > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> @@ -403,6 +403,14 @@ >> > > >> ; >> > > >> }; >> > > >> >> > > >> + nmi_intc: interrupt-controller@01f00c0c { >> > > >> + compatible =3D "allwinner,sun6i-a31-sc-nmi"; >> > > >> + interrupt-controller; >> > > >> + #interrupt-cells =3D <2>; >> > > >> + reg =3D <0x01f00c0c 0x38>; >> > > > >> > > >The base address is not correct, and there's uncertainty on whether >> > > >this is this particular controller or not. Did you even test this? >> > > >> > > Tested by axp20x-pek. >> > >> > Still, the base address is wrong, which is yet another hint that this >> > is not the same interrupt controller, and just works by accident. >>=20 >> No, it's the same as other post-sun6i device trees. >> See other post-sun6i device trees: (or maybe they're all wrong, but >> as we have no document for it, we should temporarily keep them) >>=20 >> sun6i-a31.dtsi >> ``` >> nmi_intc: interrupt-controller@01f00c0c { >> compatible =3D "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells =3D <2>; >> reg =3D <0x01f00c0c 0x38>; >> interrupts =3D ; >> }; >> ``` >>=20 >> sun8i-a23-a33.dtsi >> ``` >> nmi_intc: interrupt-controller@01f00c0c { >> compatible =3D "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells =3D <2>; >> reg =3D <0x01f00c0c 0x38>; >> interrupts =3D ; >> }; >> ``` >>=20 >> But according to the BSP device tree, the base address should be >> 0x01f00c00. Should I send some patch to fix all of them? (but it will >> break device tree compatibility) >=20 > I'm really not a big fan of "if we see something that is broken, just > let it rot" to be honest. >=20 > We have no idea how this controller works exactly, just like we have > no idea if it is exactly the same controller or not. >=20 > The only thing we have today is the memory map, and it tells us that > it has more registers than what you express here. >=20 > Because of the DT backward compatibility, you have to think of it the > other way around: what will happen if it turns out we need to setup > any register outside of that region you described in the DT, in > something like a year or so? >=20 > We can't, really. While if you have the full memory region from the > beginning, then you just have to add a single writel in your driver. So things are now already broken, and we may need to fix also A31 and A23/33. How should we do this? >=20 > Maxime >=20 > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --=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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: icenowy@aosc.io (icenowy at aosc.io) Date: Mon, 24 Apr 2017 18:25:51 +0800 Subject: [linux-sunxi] Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64 In-Reply-To: <20170424071746.u2lrk43kmvvd7m25@lukather> References: <20170417115747.7300-1-icenowy@aosc.io> <20170417115747.7300-3-icenowy@aosc.io> <20170418070016.qsng3qtk76bqxyc5@lukather> <20170420055802.btibui5pspan4qal@lukather> <18ae853e9ce59a83bdeb6b64f96caee0@aosc.io> <20170424071746.u2lrk43kmvvd7m25@lukather> Message-ID: <2970665c4666a321f14a8d2ff13bc57c@aosc.io> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ? 2017-04-24 15:17?Maxime Ripard ??? > On Thu, Apr 20, 2017 at 03:03:38PM +0800, icenowy at aosc.io wrote: >> ? 2017-04-20 13:58?Maxime Ripard ??? >> > On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote: >> > > >> > > >> > > ? 2017?4?18? GMT+08:00 ??3:00:16, Maxime Ripard >> > > ??: >> > > >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote: >> > > >> Allwinner A64 SoC features a NMI controller, which is usually >> > > >connected >> > > >> to the AXP PMIC. >> > > >> >> > > >> Add support for it. >> > > >> >> > > >> Signed-off-by: Icenowy Zheng >> > > >> Acked-by: Chen-Yu Tsai >> > > >> --- >> > > >> Changes in v2: >> > > >> - Added Chen-Yu's ACK. >> > > >> >> > > >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++ >> > > >> 1 file changed, 8 insertions(+) >> > > >> >> > > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> index 05ec9fc5e81f..53c18ca372ea 100644 >> > > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> > > >> @@ -403,6 +403,14 @@ >> > > >> ; >> > > >> }; >> > > >> >> > > >> + nmi_intc: interrupt-controller at 01f00c0c { >> > > >> + compatible = "allwinner,sun6i-a31-sc-nmi"; >> > > >> + interrupt-controller; >> > > >> + #interrupt-cells = <2>; >> > > >> + reg = <0x01f00c0c 0x38>; >> > > > >> > > >The base address is not correct, and there's uncertainty on whether >> > > >this is this particular controller or not. Did you even test this? >> > > >> > > Tested by axp20x-pek. >> > >> > Still, the base address is wrong, which is yet another hint that this >> > is not the same interrupt controller, and just works by accident. >> >> No, it's the same as other post-sun6i device trees. >> See other post-sun6i device trees: (or maybe they're all wrong, but >> as we have no document for it, we should temporarily keep them) >> >> sun6i-a31.dtsi >> ``` >> nmi_intc: interrupt-controller at 01f00c0c { >> compatible = "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells = <2>; >> reg = <0x01f00c0c 0x38>; >> interrupts = ; >> }; >> ``` >> >> sun8i-a23-a33.dtsi >> ``` >> nmi_intc: interrupt-controller at 01f00c0c { >> compatible = "allwinner,sun6i-a31-sc-nmi"; >> interrupt-controller; >> #interrupt-cells = <2>; >> reg = <0x01f00c0c 0x38>; >> interrupts = ; >> }; >> ``` >> >> But according to the BSP device tree, the base address should be >> 0x01f00c00. Should I send some patch to fix all of them? (but it will >> break device tree compatibility) > > I'm really not a big fan of "if we see something that is broken, just > let it rot" to be honest. > > We have no idea how this controller works exactly, just like we have > no idea if it is exactly the same controller or not. > > The only thing we have today is the memory map, and it tells us that > it has more registers than what you express here. > > Because of the DT backward compatibility, you have to think of it the > other way around: what will happen if it turns out we need to setup > any register outside of that region you described in the DT, in > something like a year or so? > > We can't, really. While if you have the full memory region from the > beginning, then you just have to add a single writel in your driver. So things are now already broken, and we may need to fix also A31 and A23/33. How should we do this? > > Maxime > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel