[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 at kernel.org> wrote:
>>
>> On Tue, Oct 26, 2021 at 10:38 PM Hector Martin <marcan at marcan.st> 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 at marcan.st)
Public Key: https://mrcn.st/pub