On 08/10/2021 16.50, Krzysztof Kozlowski wrote:
On Wed, 6 Oct 2021 at 17:56, Hector Martin <marcan@xxxxxxxxx> wrote:
Addendum: just found some prior art for this. See power/pd-samsung.yaml,
which is another single-PD binding (though in that case they put them in
the SoC node directly, not under a syscon).
Maybe the design is actually similar. In the Exynos there is a entire
subblock managing power - called Power Management Unit (PMU). It
controls most of power-related parts, except clock gating. For example
it covers registers related to entering deep-sleep modes or power
domains. However we split this into two:
1. Actual PMU driver which controls system-level power (and provides
syscon for other drivers needing to poke its registers... eh, life).
2. Power domain driver which binds multiple devices to a small address
spaces (three registers) inside PMU address space.
The address spaces above overlap, so the (1) PMU driver takes for
example 1004_0000 - 1004_5000 and power domain devices bind to e.g.
1004_4000, 1004_4020, 1004_4040.
It's similar, except Apple tends to group registers into uniform arrays,
sometimes with gaps. They definitely do some ugly overlap stuff in their
devicetree/OS which we'll try to avoid (e.g. the audio driver directly
poking clock select registers...).
Here's an incomplete memory map of the PMGR-related stuff in this SoC:
2_3b00_0000: Clocking
0_0000: PLLs
4_0000: Clock selects / dividers
000: 86 selects x 32bit (device clocks)
200: 8 selects x 32bit (aux clocks)
280: 2 selects x 32bit
4_4000: NCOs (used for audio) (5 x one 16KiB page each)
2_3b70_0000: PMGR
0_0000: Pwr-state registers
0000: 10 controls x 64bit (CPUs)
0100: 143 controls x 64bit (general devices)
0c00: 2 controls x 64bit (SEP)
4000: 13 controls x 64bit (ISP)
8000: 5 controls x 64bit (VENC)
c000: 7 controls x 64bit (ANE)
1_0000: 10 controls x 64bit (DISP0)
1_c000: Power gates
10: 74 power gates (24 bytes each?)
3_4100: Performance counters? (16 bytes each, big array)
5_4000: Secondary CPU spin-up controls
I believe the weird groupings into page-sized areas have to do with
security, so they can map only those ranges to certain coprocessors and
the like via the IOMMUs.
There is also a MiniPMGR that uses the same register formats, but
different counts/offsets, at 2_3d28_0000 (this one stays up in sleep
mode, AIUI)
So I think we won't need any overlaps, since e.g. the whole 00000-14000
subrange is all power state controls, so a driver doing system-level
stuff wouldn't have to care about those. Those would just be bound by
the syscon in this patchset. I chose to use a syscon to avoid having raw
ioremaps for each domain instance, since each one of those eats up a
whole page of mapping AIUI (and shows up in /proc/iomem individually).
One question is whether if we need to poke at power gates directly
(which isn't clear right now), we should have a separate top-level
pmgr-pwrgate syscon as a parent, or just instantiate power gate subnodes
under the same pmgr syscon at 1c000.
--
Hector Martin (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub
