Re: [PATCH v2 2/8] dt-bindings: arm: apple: Add apple,pmgr binding

[Hector Martin]

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