linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 0/1] sunxi: H616: add GPU power domain driver
@ 2024-02-25 16:06 Andre Przywara
  2024-02-25 16:06 ` [RFC PATCH 1/1] clk: sunxi-ng: h6-r: add GPU power domain Andre Przywara
  0 siblings, 1 reply; 6+ messages in thread
From: Andre Przywara @ 2024-02-25 16:06 UTC (permalink / raw)
  To: Ulf Hansson, Jernej Skrabec, Chen-Yu Tsai, Samuel Holland,
	Michael Turquette, Stephen Boyd
  Cc: linux-clk, linux-pm, linux-arm-kernel, linux-sunxi

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-04-16 11:10 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-25 16:06 [RFC PATCH 0/1] sunxi: H616: add GPU power domain driver Andre Przywara
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

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 NNTP newsgroup(s).