From: Hector Martin <marcan@marcan.st>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
Philipp Zabel <p.zabel@pengutronix.de>,
"Rafael J. Wysocki" <rafael@kernel.org>,
devicetree@vger.kernel.org,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>
Subject: Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding
Date: Mon, 11 Oct 2021 14:17:19 +0900 [thread overview]
Message-ID: <2a1aaec7-25e6-f779-fd18-23378537bbd2@marcan.st> (raw)
In-Reply-To: <CAJKOXPfp7oMJ+moizqgXyS7LbPajY-_vbXFX6+5PFrcpUFy2nA@mail.gmail.com>
On 08/10/2021 16.50, Krzysztof Kozlowski wrote:
> On Wed, 6 Oct 2021 at 17:56, Hector Martin <marcan@marcan.st> 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@marcan.st)
Public Key: https://mrcn.st/pub
WARNING: multiple messages have this Message-ID (diff)
From: Hector Martin <marcan@marcan.st>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
Philipp Zabel <p.zabel@pengutronix.de>,
"Rafael J. Wysocki" <rafael@kernel.org>,
devicetree@vger.kernel.org,
"open list:THERMAL" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>
Subject: Re: [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding
Date: Mon, 11 Oct 2021 14:17:19 +0900 [thread overview]
Message-ID: <2a1aaec7-25e6-f779-fd18-23378537bbd2@marcan.st> (raw)
In-Reply-To: <CAJKOXPfp7oMJ+moizqgXyS7LbPajY-_vbXFX6+5PFrcpUFy2nA@mail.gmail.com>
On 08/10/2021 16.50, Krzysztof Kozlowski wrote:
> On Wed, 6 Oct 2021 at 17:56, Hector Martin <marcan@marcan.st> 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@marcan.st)
Public Key: https://mrcn.st/pub
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-10-11 5:17 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 15:59 [PATCH 0/7] Apple SoC PMGR device power states driver Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 15:59 ` [PATCH 1/7] dt-bindings: arm: apple: Add apple,pmgr binding Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 20:09 ` Mark Kettenis
2021-10-05 20:09 ` Mark Kettenis
2021-10-05 22:45 ` Rob Herring
2021-10-05 22:45 ` Rob Herring
2021-10-06 15:17 ` Hector Martin
2021-10-06 15:17 ` Hector Martin
2021-10-06 6:56 ` Krzysztof Kozlowski
2021-10-06 6:56 ` Krzysztof Kozlowski
2021-10-06 7:30 ` Krzysztof Kozlowski
2021-10-06 7:30 ` Krzysztof Kozlowski
2021-10-06 15:21 ` Hector Martin
2021-10-06 15:21 ` Hector Martin
2021-10-06 15:26 ` Hector Martin
2021-10-06 15:26 ` Hector Martin
2021-10-07 13:10 ` Krzysztof Kozlowski
2021-10-07 13:10 ` Krzysztof Kozlowski
2021-10-05 15:59 ` [PATCH 2/7] dt-bindings: power: Add apple,pmgr-pwrstate binding Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 20:16 ` Mark Kettenis
2021-10-05 20:16 ` Mark Kettenis
2021-10-06 15:27 ` Hector Martin
2021-10-06 15:27 ` Hector Martin
2021-10-06 0:58 ` Rob Herring
2021-10-06 0:58 ` Rob Herring
2021-10-06 15:52 ` Hector Martin
2021-10-06 15:52 ` Hector Martin
2021-10-06 15:55 ` Hector Martin
2021-10-06 15:55 ` Hector Martin
2021-10-08 7:50 ` Krzysztof Kozlowski
2021-10-08 7:50 ` Krzysztof Kozlowski
2021-10-11 5:17 ` Hector Martin [this message]
2021-10-11 5:17 ` Hector Martin
2021-10-06 7:05 ` Krzysztof Kozlowski
2021-10-06 7:05 ` Krzysztof Kozlowski
2021-10-06 15:59 ` Hector Martin
2021-10-06 15:59 ` Hector Martin
2021-10-07 13:12 ` Krzysztof Kozlowski
2021-10-07 13:12 ` Krzysztof Kozlowski
2021-10-11 4:42 ` Hector Martin
2021-10-11 4:42 ` Hector Martin
2021-10-05 15:59 ` [PATCH 3/7] soc: apple: Add driver for Apple PMGR power state controls Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 16:08 ` Linus Walleij
2021-10-05 16:08 ` Linus Walleij
2021-10-05 16:15 ` Hector Martin
2021-10-05 16:15 ` Hector Martin
2021-10-05 19:49 ` Linus Walleij
2021-10-05 19:49 ` Linus Walleij
2021-10-05 20:21 ` Mark Kettenis
2021-10-05 20:21 ` Mark Kettenis
2021-10-06 16:00 ` Hector Martin
2021-10-06 16:00 ` Hector Martin
2021-10-06 7:28 ` Krzysztof Kozlowski
2021-10-06 7:28 ` Krzysztof Kozlowski
2021-10-06 16:08 ` Hector Martin
2021-10-06 16:08 ` Hector Martin
2021-10-06 9:24 ` Philipp Zabel
2021-10-06 9:24 ` Philipp Zabel
2021-10-06 16:11 ` Hector Martin
2021-10-06 16:11 ` Hector Martin
2021-10-05 15:59 ` [PATCH 4/7] arm64: dts: apple: t8103: Rename clk24 to clkref Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 20:22 ` Mark Kettenis
2021-10-05 20:22 ` Mark Kettenis
2021-10-05 15:59 ` [PATCH 5/7] arm64: dts: apple: t8103: Add the UART PMGR tree Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 20:25 ` Mark Kettenis
2021-10-05 20:25 ` Mark Kettenis
2021-10-05 15:59 ` [PATCH 6/7] tty: serial: samsung_tty: Support runtime PM Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-06 7:43 ` Krzysztof Kozlowski
2021-10-06 7:43 ` Krzysztof Kozlowski
2021-10-06 13:25 ` Rafael J. Wysocki
2021-10-06 13:25 ` Rafael J. Wysocki
2021-10-06 13:29 ` Krzysztof Kozlowski
2021-10-06 13:29 ` Krzysztof Kozlowski
2021-10-11 5:32 ` Hector Martin
2021-10-11 5:32 ` Hector Martin
2021-10-11 6:48 ` Krzysztof Kozlowski
2021-10-11 6:48 ` Krzysztof Kozlowski
2021-10-11 8:27 ` Johan Hovold
2021-10-11 8:27 ` Johan Hovold
2021-10-05 15:59 ` [PATCH 7/7] arm64: dts: apple: t8103: Add UART2 Hector Martin
2021-10-05 15:59 ` Hector Martin
2021-10-05 20:26 ` Mark Kettenis
2021-10-05 20:26 ` Mark Kettenis
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=2a1aaec7-25e6-f779-fd18-23378537bbd2@marcan.st \
--to=marcan@marcan.st \
--cc=alyssa@rosenzweig.io \
--cc=arnd@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mark.kettenis@xs4all.nl \
--cc=maz@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.