On 27/10/2021 23.51, Krzysztof Kozlowski wrote:
On Wed, 27 Oct 2021 at 16:44, Rob Herring <robh@xxxxxxxxxx> wrote:
On Tue, Oct 26, 2021 at 10:38 PM Hector Martin <marcan@xxxxxxxxx> wrote:
On 27/10/2021 03.25, Rob Herring wrote:
On Mon, Oct 25, 2021 at 11:47:12PM +0900, Hector Martin wrote:
+ compatible:
+ items:
+ - enum:
+ - apple,t8103-pmgr
+ - apple,t8103-minipmgr
+ - const: apple,pmgr
+ - const: syscon
+ - const: simple-mfd
'simple-mfd' means 'there's nothing in this node that any of the child
nodes depend on'. You should be somewhat certain as dropping it later
creates compatibility issues.
Hmm, I see simple-mfd turns this into a bus which I guess allows child
nodes to be probed without the parent node doing anything special (then
we use syscon_node_to_regmap to get the syscon instantiated). Do you
have a example use case for doing this without simple-mfd?
Drivers calling of_platform_populate or devm_of_platform_populate.
That of course does mean you need a driver. We could probably make the
syscon driver call these if needed.
Hi Hector,
I thought I mentioned this with your v1, maybe the comment got lost.
We have it for Exynos PMU:
drivers/soc/samsung/exynos-pmu.c
arch/arm/boot/dts/exynos-syscon-restart.dtsi (extending node from
arch/arm/boot/dts/exynos5420.dtsi)
Maybe you can base on that.
Ah, I remember the discrete power domains but I missed this syscon.
I see this is mostly used for poweroff/reboot, which makes sense in this
context. For pmgr though, the binding only describes the uniform power
state registers, so I think I'm comfortable leaving it as a simple-mfd.
Other pmgr sub-blocks will probably end up as separate nodes with
different bindings anyway (e.g. whatever I do for the clock muxes, need
to see how that ties in with audio which I think is the only consumer so
far).
If things get more complicated in future SoCs then we can change how we
do it on those, of course :)
--
Hector Martin (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub
