2021-10-27 21:31:52

by Krzysztof Kozlowski

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

On Wed, 27 Oct 2021 at 16:44, Rob Herring <[email protected]> wrote:
>
> On Tue, Oct 26, 2021 at 10:38 PM Hector Martin <[email protected]> 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.

Best regards,
Krzysztof


2021-10-29 07:10:42

by Hector Martin

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

On 27/10/2021 23.51, Krzysztof Kozlowski wrote:
> On Wed, 27 Oct 2021 at 16:44, Rob Herring <[email protected]> wrote:
>>
>> On Tue, Oct 26, 2021 at 10:38 PM Hector Martin <[email protected]> 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 ([email protected])
Public Key: https://mrcn.st/pub