mbox series

[RFC,0/1] sunxi: H616: add GPU power domain driver

Message ID 20240225160616.15001-1-andre.przywara@arm.com
Headers show
Series sunxi: H616: add GPU power domain driver | expand

Message

Andre Przywara Feb. 25, 2024, 4:06 p.m. UTC 
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(+)