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.