Re: [linux-sunxi] Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 7, 2021 at 6:27 PM Samuel Holland <samuel@xxxxxxxxxxxx> wrote:
>
> On 1/6/21 5:38 AM, Chen-Yu Tsai wrote:
> > On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote:
> >>
> >> On Mon, Jan 04, 2021 at 10:54:19AM +0000, André Przywara wrote:
> >>> On 03/01/2021 10:00, Samuel Holland wrote:
> >>>> On boards where the only peripheral connected to PL0/PL1 is an X-Powers
> >>>> PMIC, configure the connection to use the RSB bus rather than the I2C
> >>>> bus. Compared to the I2C controller that shares the pins, the RSB
> >>>> controller allows a higher bus frequency, and it is more CPU-efficient.
> >>>
> >>> But is it really necessary to change the DTs for those boards in this
> >>> way? It means those newer DTs now become incompatible with older
> >>> kernels, and I don't know if those reasons above really justify this.
> >>>
> >>> I understand that we officially don't care about "newer DTs on older
> >>> kernels", but do we really need to break this deliberately, for no
> >>> pressing reasons?
> >>>
> >>> P.S. I am fine with supporting RSB on H6, and even using it on new DTs,
> >>> just want to avoid breaking existing ones.
> >>
> >> Doing so would also introduce some inconsistencies, one more thing to
> >> consider during reviews, and would require more testing effort.
> >>
> >> I'm not sure that stretching our - already fairly sparse - resources
> >> thin would be very wise here, especially for something that we don't
> >> have to do and for a setup that isn't really used that much.
> >
> > As soon as some software component starts running RSB, (which I assume
> > is what Samuel is planning to do in Crust?), there's a chance that it
> > doesn't switch the chip back to I2C. And then Linux won't be able to
> > access it.
>
> Crust can handle either way via a config option, which currently
> defaults to I2C for H6. It must use the same selection as Linux, not
> only because of the PMIC mode, but also because of the pinctrl.

Could Crust be made to also handle pinctrl?

> TF-A is already converted to use RSB[1], and it does switch the PMIC
> back to I2C before handing off to U-Boot[2]. So new TF-A + old Linux is
> fine. However, Linux currently does not switch the PMIC back. So the
> most likely problem from this patch is that, with new Linux + old TF-A,
> TF-A will be unable to power down the board or access regulators after
> an SoC reset.
>
> I expect there will be a TF-A release between now and when 5.12 hits
> stable, but people tend not upgrade their U-Boot/TF-A very often.
>
> We could solve this by having the Linux RSB driver switch all child
> devices back to I2C in .shutdown, or by dropping this patch and only
> using RSB for new boards (which would also address Andre's concern).

This will work for most cases, except in a kernel panic or IIRC direct
reboot using sysrq. So it's not robust as we'd like it to be.

ChenYu

> Cheers,
> Samuel
>
> [1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7576
> [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7575
>
> > So I'm for keeping things consistent and converting all users to RSB.
> >
> >
> > ChenYu
> >
>
> --
> 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 email to linux-sunxi+unsubscribe@xxxxxxxxxxxxxxxx.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/bc95a8d2-ebec-489c-10af-fd5a80ea1276%40sholland.org.



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux