Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux