From: Andre Przywara <andre.przywara@arm.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Chen-Yu Tsai <wens@csie.org>,
Samuel Holland <samuel@sholland.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org, linux-pm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev
Subject: [RFC PATCH 0/1] sunxi: H616: add GPU power domain driver
Date: Sun, 25 Feb 2024 16:06:15 +0000 [thread overview]
Message-ID: <20240225160616.15001-1-andre.przywara@arm.com> (raw)
The Allwinner provided BSP code and experiments show that the Mali GPU
on the Allwinner H616 SoC needs to have a bit in one PRCM register
cleared to work. In the WIP graphics support patches, this was typically
covered by a U-Boot one-liner hack.
This patch here adds a proper power-domain driver for this one bit.
Since "power-domains" is a generic DT property, it already works on the
Panfrost driver side, without extra code. Said register is in the PRCM
MMIO range, which we already use in the R-CCU driver, so add the power
domain registration code there.
I mark this as RFC to get answers to some questions. Once people are
happy with the approach, I will send out a proper series with the
respective Kconfig and DT patches.
- Is modelling this as a power domain the right approach in the first
place? Is that maybe just another reset bit? The logic seems backwards
for that (bit set = disabled), but who knows?
- Is embedding this in the R-CCU driver the right way? I also have a
version for a standalone driver in a separate file, but we have to
artificially split the MMIO region to not conflict with the R-CCU
driver, which looks arbitrary. If anyone has any information about
the PRCM (register map), it would help to make an informed decision.
- Experiments in U-Boot identify bit 0 in 0x7010260 as behaving similar
as our bit 0 in 0x7010254 here, so chances are there is another power
domain for some other peripheral nearby. Also bits 0x7010250[9:0] are
writable and stick, with setting bit 2 hanging the chip. So to allow
further extensions without breaking compatibility, I made this a
one-cell power domain ("power-domains = <&r_ccu 0>;"). Please let me
know if this sounds overkill and a simple ("no cell") approach would be
better.
- This patch makes the R-CCU driver dependent on CONFIG_PM. Shall we model
this is a simple "select" or "depends on" in Kconfig, or shall the code
be made conditional in the R-CCU driver, to allow compilation without
PM support enabled?
- Shall any failure in registering the PPU driver also abort the R-CCU
probe? Or do we treat this as optional?
I'd be grateful for any feedback.
Cheers,
Andre
Andre Przywara (1):
clk: sunxi-ng: h6-r: add GPU power domain
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 84 ++++++++++++++++++++++++++
1 file changed, 84 insertions(+)
--
2.35.8
next reply other threads:[~2024-02-25 16:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-25 16:06 Andre Przywara [this message]
2024-02-25 16:06 ` [RFC PATCH 1/1] clk: sunxi-ng: h6-r: add GPU power domain Andre Przywara
2024-04-08 3:33 ` Stephen Boyd
2024-04-08 12:55 ` Ulf Hansson
2024-04-15 23:00 ` Andre Przywara
2024-04-16 11:09 ` Ulf Hansson
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=20240225160616.15001-1-andre.przywara@arm.com \
--to=andre.przywara@arm.com \
--cc=jernej.skrabec@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mturquette@baylibre.com \
--cc=samuel@sholland.org \
--cc=sboyd@kernel.org \
--cc=ulf.hansson@linaro.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).