From: Samuel Holland <samuel@sholland.org>
To: Chen-Yu Tsai <wens@csie.org>, Maxime Ripard <maxime@cerno.tech>
Cc: "André Przywara" <andre.przywara@arm.com>,
"Jernej Skrabec" <jernej.skrabec@siol.net>,
"Rob Herring" <robh+dt@kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Stephen Boyd" <sboyd@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-clk <linux-clk@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-sunxi <linux-sunxi@googlegroups.com>
Subject: Re: [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection
Date: Thu, 7 Jan 2021 04:27:14 -0600 [thread overview]
Message-ID: <bc95a8d2-ebec-489c-10af-fd5a80ea1276@sholland.org> (raw)
In-Reply-To: <CAGb2v64mcLogZax8vVJJxG9feBzmGc8VyazTvp7XkBAoLXw9JA@mail.gmail.com>
On 1/6/21 5:38 AM, Chen-Yu Tsai wrote:
> On Wed, Jan 6, 2021 at 7:06 PM Maxime Ripard <maxime@cerno.tech> 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.
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).
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
>
next prev parent reply other threads:[~2021-01-07 10:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-03 10:00 [PATCH v2 0/4] Allwinner H6 RSB support Samuel Holland
2021-01-03 10:00 ` [PATCH v2 1/4] clk: sunxi-ng: h6-r: Add R_APB2_RSB clock and reset Samuel Holland
2021-01-03 10:00 ` [PATCH v2 2/4] pinctrl: sunxi: h6-r: Add s_rsb pin functions Samuel Holland
2021-01-03 14:19 ` [linux-sunxi] " Chen-Yu Tsai
2021-01-05 22:35 ` Linus Walleij
2021-01-06 2:39 ` Chen-Yu Tsai
2021-01-06 20:10 ` Linus Walleij
2021-01-03 10:00 ` [PATCH v2 3/4] arm64: dts: allwinner: h6: Add RSB controller node Samuel Holland
2021-01-03 10:00 ` [PATCH v2 4/4] arm64: dts: allwinner: h6: Use RSB for AXP805 PMIC connection Samuel Holland
2021-01-04 10:54 ` André Przywara
2021-01-05 3:31 ` Samuel Holland
2021-01-06 11:06 ` Maxime Ripard
2021-01-06 11:38 ` Chen-Yu Tsai
2021-01-07 10:27 ` Samuel Holland [this message]
2021-01-13 9:16 ` [linux-sunxi] " Chen-Yu Tsai
2021-01-18 9:51 ` Chen-Yu Tsai
2021-03-08 15:45 ` Maxime Ripard
2021-01-04 8:31 ` [linux-sunxi] [PATCH v2 0/4] Allwinner H6 RSB support Chen-Yu Tsai
2021-01-06 11:04 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc95a8d2-ebec-489c-10af-fd5a80ea1276@sholland.org \
--to=samuel@sholland.org \
--cc=andre.przywara@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=jernej.skrabec@siol.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=maxime@cerno.tech \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox