Hi Andre,

On Tue, Jan 21, 2020 at 4:03 PM Andre Przywara <andre.przyw...@arm.com> wrote:
>
> On Tue, 21 Jan 2020 14:05:12 +0530
> Jagan Teki <ja...@amarulasolutions.com> wrote:
>
> Hi Jagan,
>
> thanks for taking care of this.
>
> > Sync R40 dts(i) files from linux-next v5.4 tag.
>
> Why this tag? Shouldn't it be just the v5.4 release tag?
> But honestly we should take the latest from Maxime's sunxi/for-next branch. 
> This isn't merged into mainline yet, but has been reviewed by the community 
> and committed by Maxime, which is usually as good as it gets. This would 
> avoid doing this exercise in a month again, especially since there are some 
> fixes to the R40 .dtsi in there.

And all Maxime's sunxi changes would first merged into linux-next,
isn't it? Since I usually sync linux-next as it has latest changed
merged.

>
> > This sync would update r40 dts(i) and v40-bananapi-m2-berry
> > dts files.
>
> So thanks for bringing this up, but see below:
>
> >
> > Signed-off-by: Jagan Teki <ja...@amarulasolutions.com>
> > Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
> > ---
> >  arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts |   7 +-
> >  arch/arm/dts/sun8i-r40.dtsi                  |  24 ++--
> >  arch/arm/dts/sun8i-v40-bananapi-m2-berry.dts | 135 ++++++++++++++++---
> >  3 files changed, 136 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts 
> > b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
> > index c488aaacbd..42d62d1ba1 100644
> > --- a/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
> > +++ b/arch/arm/dts/sun8i-r40-bananapi-m2-ultra.dts
> > @@ -201,10 +201,15 @@
> >  &pio {
> >       pinctrl-names = "default";
> >       pinctrl-0 = <&clk_out_a_pin>;
> > +     vcc-pa-supply = <&reg_aldo2>;
> > +     vcc-pc-supply = <&reg_dcdc1>;
> > +     vcc-pd-supply = <&reg_dcdc1>;
> > +     vcc-pe-supply = <&reg_eldo1>;
> > +     vcc-pf-supply = <&reg_dcdc1>;
> > +     vcc-pg-supply = <&reg_dldo1>;
> >  };
> >
> >  &reg_aldo2 {
> > -     regulator-always-on;
> >       regulator-min-microvolt = <2500000>;
> >       regulator-max-microvolt = <2500000>;
> >       regulator-name = "vcc-pa";
> > diff --git a/arch/arm/dts/sun8i-r40.dtsi b/arch/arm/dts/sun8i-r40.dtsi
> > index 06b685869f..c9c2688db6 100644
> > --- a/arch/arm/dts/sun8i-r40.dtsi
> > +++ b/arch/arm/dts/sun8i-r40.dtsi
> > @@ -119,10 +119,10 @@
> >                       compatible = "allwinner,sun8i-r40-de2-clk",
> >                                    "allwinner,sun8i-h3-de2-clk";
> >                       reg = <0x01000000 0x100000>;
> > -                     clocks = <&ccu CLK_DE>,
> > -                              <&ccu CLK_BUS_DE>;
> > -                     clock-names = "mod",
> > -                                   "bus";
> > +                     clocks = <&ccu CLK_BUS_DE>,
> > +                              <&ccu CLK_DE>;
> > +                     clock-names = "bus",
> > +                                   "mod";
> >                       resets = <&ccu RST_BUS_DE>;
> >                       #clock-cells = <1>;
> >                       #reset-cells = <1>;
> > @@ -322,8 +322,7 @@
> >               };
> >
> >               rtc: rtc@1c20400 {
> > -                     compatible = "allwinner,sun8i-r40-rtc",
> > -                                  "allwinner,sun8i-h3-rtc";
> > +                     compatible = "allwinner,sun8i-r40-rtc";
>
> This is an example where the kernel DT changed in a slightly incompatible way.
> It removes the H3 RTC string, so any kernels before v5.3 won't recognise the 
> RTC anymore. This is an issue for EFI booting, especially distro installers.
>
> From the pure RTC perspective it seems feasible to just keep the H3 fallback, 
> but this brings issues with the new clock that's derived from the compatible 
> as well.
> So we need to test a few older kernels with the new and probably amended DT 
> (where we sync the kernel DT, but skip this one change).
> I did a similar exercise in the past with some A64 and H5 boards, and found 
> some issues, which is the reason I didn't send an update yet.

If the installers are trying to use the latest u-boot, can't they use
latest linux versions or so? Otherwise dts sync approach is
incompatibility for those use cases.

>
> But maybe doing this for the R40 is a good exercise, because it has a more 
> limited scope (only two boards in U-Boot), and the changes are minimal.
> Do you have access to the M2 Ultra? I have the M2 Berry, so I would test some 
> older kernels, to identify problematic versions (for instance v5.2/v5.3). 
> Maybe you could verify any solutions on the M2 Ultra then.

Yes, I have. Let me know if you have any specific image to verify.

Reply via email to