| Message ID | 20180501161227.2110-16-wens@csie.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hi, On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: > From: Icenowy Zheng <icenowy@aosc.io> > > Allwinner A64 has a SRAM controller, and in the device tree currently > we have a syscon node to enable EMAC driver to access the EMAC clock > register. As SRAM controller driver can now export regmap for this > register, replace the syscon node to the SRAM controller device node, > and let EMAC driver to acquire its EMAC clock regmap. > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > Signed-off-by: Chen-Yu Tsai <wens@csie.org> > --- > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++---- > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > index 1b2ef28c42bd..1c37659d9d41 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > @@ -168,10 +168,25 @@ > #size-cells = <1>; > ranges; > > - syscon: syscon@1c00000 { > - compatible = "allwinner,sun50i-a64-system-controller", > - "syscon"; > + sram_controller: sram-controller@1c00000 { > + compatible = "allwinner,sun50i-a64-sram-controller"; I don't think there's anything preventing us from keeping the -system-controller compatible. It's what was in the DT before, and it's how it's called in the datasheet. Otherwise, the whole serie looks good to me: Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Maxime
On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > Hi, > > On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: >> From: Icenowy Zheng <icenowy@aosc.io> >> >> Allwinner A64 has a SRAM controller, and in the device tree currently >> we have a syscon node to enable EMAC driver to access the EMAC clock >> register. As SRAM controller driver can now export regmap for this >> register, replace the syscon node to the SRAM controller device node, >> and let EMAC driver to acquire its EMAC clock regmap. >> >> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> --- >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 +++++++++++++++---- >> 1 file changed, 19 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> index 1b2ef28c42bd..1c37659d9d41 100644 >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> @@ -168,10 +168,25 @@ >> #size-cells = <1>; >> ranges; >> >> - syscon: syscon@1c00000 { >> - compatible = "allwinner,sun50i-a64-system-controller", >> - "syscon"; >> + sram_controller: sram-controller@1c00000 { >> + compatible = "allwinner,sun50i-a64-sram-controller"; > > I don't think there's anything preventing us from keeping the > -system-controller compatible. It's what was in the DT before, and > it's how it's called in the datasheet. I actually meant to ask you about this. The -system-controller compatible matches the datasheet better. Maybe we should just switch to that one? ChenYu > Otherwise, the whole serie looks good to me: > Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> > > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com
于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard ><maxime.ripard@bootlin.com> wrote: >> Hi, >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: >>> From: Icenowy Zheng <icenowy@aosc.io> >>> >>> Allwinner A64 has a SRAM controller, and in the device tree >currently >>> we have a syscon node to enable EMAC driver to access the EMAC clock >>> register. As SRAM controller driver can now export regmap for this >>> register, replace the syscon node to the SRAM controller device >node, >>> and let EMAC driver to acquire its EMAC clock regmap. >>> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >>> --- >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 >+++++++++++++++---- >>> 1 file changed, 19 insertions(+), 4 deletions(-) >>> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >>> index 1b2ef28c42bd..1c37659d9d41 100644 >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >>> @@ -168,10 +168,25 @@ >>> #size-cells = <1>; >>> ranges; >>> >>> - syscon: syscon@1c00000 { >>> - compatible = >"allwinner,sun50i-a64-system-controller", >>> - "syscon"; >>> + sram_controller: sram-controller@1c00000 { >>> + compatible = >"allwinner,sun50i-a64-sram-controller"; >> >> I don't think there's anything preventing us from keeping the >> -system-controller compatible. It's what was in the DT before, and >> it's how it's called in the datasheet. > >I actually meant to ask you about this. The -system-controller >compatible >matches the datasheet better. Maybe we should just switch to that one? No, if we do the switch the system-controller compatible, the device will be probed on the same memory region with a syscon on old DTs. > >ChenYu > >> Otherwise, the whole serie looks good to me: >> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> >> >> Maxime >> >> -- >> Maxime Ripard, Bootlin (formerly Free Electrons) >> Embedded Linux and Kernel engineering >> https://bootlin.com > >_______________________________________________ >linux-arm-kernel mailing list >linux-arm-kernel@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote: > > > 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: > >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard > ><maxime.ripard@bootlin.com> wrote: > >> Hi, > >> > >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: > >>> From: Icenowy Zheng <icenowy@aosc.io> > >>> > >>> Allwinner A64 has a SRAM controller, and in the device tree > >currently > >>> we have a syscon node to enable EMAC driver to access the EMAC clock > >>> register. As SRAM controller driver can now export regmap for this > >>> register, replace the syscon node to the SRAM controller device > >node, > >>> and let EMAC driver to acquire its EMAC clock regmap. > >>> > >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> > >>> --- > >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 > >+++++++++++++++---- > >>> 1 file changed, 19 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >>> index 1b2ef28c42bd..1c37659d9d41 100644 > >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >>> @@ -168,10 +168,25 @@ > >>> #size-cells = <1>; > >>> ranges; > >>> > >>> - syscon: syscon@1c00000 { > >>> - compatible = > >"allwinner,sun50i-a64-system-controller", > >>> - "syscon"; > >>> + sram_controller: sram-controller@1c00000 { > >>> + compatible = > >"allwinner,sun50i-a64-sram-controller"; > >> > >> I don't think there's anything preventing us from keeping the > >> -system-controller compatible. It's what was in the DT before, and > >> it's how it's called in the datasheet. > > > >I actually meant to ask you about this. The -system-controller > >compatible matches the datasheet better. Maybe we should just > >switch to that one? > > No, if we do the switch the system-controller compatible, > the device will be probed on the same memory region with > a syscon on old DTs. The device hasn't magically changed either. Maybe we just need to add a check to make sure we don't have the syscon compatible in the SRAM driver probe so that the double driver issue doesn't happen? Maxime
On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote: >> >> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard >> ><maxime.ripard@bootlin.com> wrote: >> >> Hi, >> >> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: >> >>> From: Icenowy Zheng <icenowy@aosc.io> >> >>> >> >>> Allwinner A64 has a SRAM controller, and in the device tree >> >currently >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock >> >>> register. As SRAM controller driver can now export regmap for this >> >>> register, replace the syscon node to the SRAM controller device >> >node, >> >>> and let EMAC driver to acquire its EMAC clock regmap. >> >>> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> >>> --- >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 >> >+++++++++++++++---- >> >>> 1 file changed, 19 insertions(+), 4 deletions(-) >> >>> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >>> index 1b2ef28c42bd..1c37659d9d41 100644 >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >>> @@ -168,10 +168,25 @@ >> >>> #size-cells = <1>; >> >>> ranges; >> >>> >> >>> - syscon: syscon@1c00000 { >> >>> - compatible = >> >"allwinner,sun50i-a64-system-controller", >> >>> - "syscon"; >> >>> + sram_controller: sram-controller@1c00000 { >> >>> + compatible = >> >"allwinner,sun50i-a64-sram-controller"; >> >> >> >> I don't think there's anything preventing us from keeping the >> >> -system-controller compatible. It's what was in the DT before, and >> >> it's how it's called in the datasheet. >> > >> >I actually meant to ask you about this. The -system-controller >> >compatible matches the datasheet better. Maybe we should just >> >switch to that one? >> >> No, if we do the switch the system-controller compatible, >> the device will be probed on the same memory region with >> a syscon on old DTs. > > The device hasn't magically changed either. Maybe we just need to add > a check to make sure we don't have the syscon compatible in the SRAM > driver probe so that the double driver issue doesn't happen? The syscon interface (which is not even a full blown device driver) only looks at the "syscon" compatible. Either way we're removing that part from the device tree so things should be ok for new device trees. As Maxime mentioned we can do a check for the syscon compatible and either give a warning to the user asking them to update their device tree, or not register our custom regmap, or not probe the SRAM driver. Personally I prefer the first option. The system controller block is probed before any syscon users, so we should be fine, given the dwmac driver goes the custom regmap path first. BTW, I still might end up changing the compatible. The manual uses "system control", not "system controller", which I think makes sense, since it is just a bunch of register files, kind of like the GRF (General Register Files) block found in Rockchip SoCs [1], and not an actual "controller". ChenYu [1] https://www.kernel.org/doc/Documentation/devicetree/bindings/soc/rockchip/grf.txt
1;5201;0c On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote: > On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote: > >> > >> > >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: > >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard > >> ><maxime.ripard@bootlin.com> wrote: > >> >> Hi, > >> >> > >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: > >> >>> From: Icenowy Zheng <icenowy@aosc.io> > >> >>> > >> >>> Allwinner A64 has a SRAM controller, and in the device tree > >> >currently > >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock > >> >>> register. As SRAM controller driver can now export regmap for this > >> >>> register, replace the syscon node to the SRAM controller device > >> >node, > >> >>> and let EMAC driver to acquire its EMAC clock regmap. > >> >>> > >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> > >> >>> --- > >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 > >> >+++++++++++++++---- > >> >>> 1 file changed, 19 insertions(+), 4 deletions(-) > >> >>> > >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >>> index 1b2ef28c42bd..1c37659d9d41 100644 > >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >>> @@ -168,10 +168,25 @@ > >> >>> #size-cells = <1>; > >> >>> ranges; > >> >>> > >> >>> - syscon: syscon@1c00000 { > >> >>> - compatible = > >> >"allwinner,sun50i-a64-system-controller", > >> >>> - "syscon"; > >> >>> + sram_controller: sram-controller@1c00000 { > >> >>> + compatible = > >> >"allwinner,sun50i-a64-sram-controller"; > >> >> > >> >> I don't think there's anything preventing us from keeping the > >> >> -system-controller compatible. It's what was in the DT before, and > >> >> it's how it's called in the datasheet. > >> > > >> >I actually meant to ask you about this. The -system-controller > >> >compatible matches the datasheet better. Maybe we should just > >> >switch to that one? > >> > >> No, if we do the switch the system-controller compatible, > >> the device will be probed on the same memory region with > >> a syscon on old DTs. > > > > The device hasn't magically changed either. Maybe we just need to add > > a check to make sure we don't have the syscon compatible in the SRAM > > driver probe so that the double driver issue doesn't happen? > > The syscon interface (which is not even a full blown device driver) > only looks at the "syscon" compatible. Either way we're removing that > part from the device tree so things should be ok for new device trees. > As Maxime mentioned we can do a check for the syscon compatible and > either give a warning to the user asking them to update their device > tree, or not register our custom regmap, or not probe the SRAM driver. > Personally I prefer the first option. The system controller block is > probed before any syscon users, so we should be fine, given the dwmac > driver goes the custom regmap path first. > > BTW, I still might end up changing the compatible. The manual uses > "system control", not "system controller", which I think makes sense, > since it is just a bunch of register files, kind of like the GRF > (General Register Files) block found in Rockchip SoCs [1], and not an > actual "controller". I'm not really fond of that, but we should at least make it consistent on the other patches Paul sent then. Maxime
On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > 1;5201;0c > On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote: >> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: >> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote: >> >> >> >> >> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: >> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard >> >> ><maxime.ripard@bootlin.com> wrote: >> >> >> Hi, >> >> >> >> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: >> >> >>> From: Icenowy Zheng <icenowy@aosc.io> >> >> >>> >> >> >>> Allwinner A64 has a SRAM controller, and in the device tree >> >> >currently >> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock >> >> >>> register. As SRAM controller driver can now export regmap for this >> >> >>> register, replace the syscon node to the SRAM controller device >> >> >node, >> >> >>> and let EMAC driver to acquire its EMAC clock regmap. >> >> >>> >> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> >> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> >> >> >>> --- >> >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 >> >> >+++++++++++++++---- >> >> >>> 1 file changed, 19 insertions(+), 4 deletions(-) >> >> >>> >> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644 >> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi >> >> >>> @@ -168,10 +168,25 @@ >> >> >>> #size-cells = <1>; >> >> >>> ranges; >> >> >>> >> >> >>> - syscon: syscon@1c00000 { >> >> >>> - compatible = >> >> >"allwinner,sun50i-a64-system-controller", >> >> >>> - "syscon"; >> >> >>> + sram_controller: sram-controller@1c00000 { >> >> >>> + compatible = >> >> >"allwinner,sun50i-a64-sram-controller"; >> >> >> >> >> >> I don't think there's anything preventing us from keeping the >> >> >> -system-controller compatible. It's what was in the DT before, and >> >> >> it's how it's called in the datasheet. >> >> > >> >> >I actually meant to ask you about this. The -system-controller >> >> >compatible matches the datasheet better. Maybe we should just >> >> >switch to that one? >> >> >> >> No, if we do the switch the system-controller compatible, >> >> the device will be probed on the same memory region with >> >> a syscon on old DTs. >> > >> > The device hasn't magically changed either. Maybe we just need to add >> > a check to make sure we don't have the syscon compatible in the SRAM >> > driver probe so that the double driver issue doesn't happen? >> >> The syscon interface (which is not even a full blown device driver) >> only looks at the "syscon" compatible. Either way we're removing that >> part from the device tree so things should be ok for new device trees. >> As Maxime mentioned we can do a check for the syscon compatible and >> either give a warning to the user asking them to update their device >> tree, or not register our custom regmap, or not probe the SRAM driver. >> Personally I prefer the first option. The system controller block is >> probed before any syscon users, so we should be fine, given the dwmac >> driver goes the custom regmap path first. >> >> BTW, I still might end up changing the compatible. The manual uses >> "system control", not "system controller", which I think makes sense, >> since it is just a bunch of register files, kind of like the GRF >> (General Register Files) block found in Rockchip SoCs [1], and not an >> actual "controller". > > I'm not really fond of that, but we should at least make it consistent > on the other patches Paul sent then. For the A10s / A13 right? I think my naming is slightly better, but it's just a minor detail. While we're still debating this, can I merge the R40 stuff first? The driver bits are already in. Thanks ChenYu
Hi, On Tue, May 15, 2018 at 11:47:16PM -0700, Chen-Yu Tsai wrote: > On Mon, May 14, 2018 at 1:03 AM, Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > 1;5201;0c > > On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote: > >> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > >> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote: > >> >> > >> >> > >> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到: > >> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard > >> >> ><maxime.ripard@bootlin.com> wrote: > >> >> >> Hi, > >> >> >> > >> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote: > >> >> >>> From: Icenowy Zheng <icenowy@aosc.io> > >> >> >>> > >> >> >>> Allwinner A64 has a SRAM controller, and in the device tree > >> >> >currently > >> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock > >> >> >>> register. As SRAM controller driver can now export regmap for this > >> >> >>> register, replace the syscon node to the SRAM controller device > >> >> >node, > >> >> >>> and let EMAC driver to acquire its EMAC clock regmap. > >> >> >>> > >> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io> > >> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org> > >> >> >>> --- > >> >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23 > >> >> >+++++++++++++++---- > >> >> >>> 1 file changed, 19 insertions(+), 4 deletions(-) > >> >> >>> > >> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644 > >> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi > >> >> >>> @@ -168,10 +168,25 @@ > >> >> >>> #size-cells = <1>; > >> >> >>> ranges; > >> >> >>> > >> >> >>> - syscon: syscon@1c00000 { > >> >> >>> - compatible = > >> >> >"allwinner,sun50i-a64-system-controller", > >> >> >>> - "syscon"; > >> >> >>> + sram_controller: sram-controller@1c00000 { > >> >> >>> + compatible = > >> >> >"allwinner,sun50i-a64-sram-controller"; > >> >> >> > >> >> >> I don't think there's anything preventing us from keeping the > >> >> >> -system-controller compatible. It's what was in the DT before, and > >> >> >> it's how it's called in the datasheet. > >> >> > > >> >> >I actually meant to ask you about this. The -system-controller > >> >> >compatible matches the datasheet better. Maybe we should just > >> >> >switch to that one? > >> >> > >> >> No, if we do the switch the system-controller compatible, > >> >> the device will be probed on the same memory region with > >> >> a syscon on old DTs. > >> > > >> > The device hasn't magically changed either. Maybe we just need to add > >> > a check to make sure we don't have the syscon compatible in the SRAM > >> > driver probe so that the double driver issue doesn't happen? > >> > >> The syscon interface (which is not even a full blown device driver) > >> only looks at the "syscon" compatible. Either way we're removing that > >> part from the device tree so things should be ok for new device trees. > >> As Maxime mentioned we can do a check for the syscon compatible and > >> either give a warning to the user asking them to update their device > >> tree, or not register our custom regmap, or not probe the SRAM driver. > >> Personally I prefer the first option. The system controller block is > >> probed before any syscon users, so we should be fine, given the dwmac > >> driver goes the custom regmap path first. > >> > >> BTW, I still might end up changing the compatible. The manual uses > >> "system control", not "system controller", which I think makes sense, > >> since it is just a bunch of register files, kind of like the GRF > >> (General Register Files) block found in Rockchip SoCs [1], and not an > >> actual "controller". > > > > I'm not really fond of that, but we should at least make it consistent > > on the other patches Paul sent then. > > For the A10s / A13 right? And A33, yep. > I think my naming is slightly better, but it's just a minor detail. Let's do this then. > While we're still debating this, can I merge the R40 stuff first? > The driver bits are already in. Yep, go ahead. Maxime
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi index 1b2ef28c42bd..1c37659d9d41 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi @@ -168,10 +168,25 @@ #size-cells = <1>; ranges; - syscon: syscon@1c00000 { - compatible = "allwinner,sun50i-a64-system-controller", - "syscon"; + sram_controller: sram-controller@1c00000 { + compatible = "allwinner,sun50i-a64-sram-controller"; reg = <0x01c00000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + sram_c: sram@18000 { + compatible = "mmio-sram"; + reg = <0x00018000 0x28000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x00018000 0x28000>; + + de2_sram: sram-section@0 { + compatible = "allwinner,sun50i-a64-sram-c"; + reg = <0x0000 0x28000>; + }; + }; }; dma: dma-controller@1c02000 { @@ -599,7 +614,7 @@ emac: ethernet@1c30000 { compatible = "allwinner,sun50i-a64-emac"; - syscon = <&syscon>; + syscon = <&sram_controller>; reg = <0x01c30000 0x10000>; interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq";