[PATCH v2 08/13] dt-bindings: imx: gpcv2: add support for optional resets

Frieder Schrempf frieder.schrempf at kontron.de
Mon Apr 26 10:24:17 BST 2021


Hi Rob,

On 10.02.21 15:35, Lucas Stach wrote:
> Am Montag, dem 30.11.2020 um 10:57 +0100 schrieb Lucas Stach:
>> Hi Rob,
>>
>> Am Dienstag, den 17.11.2020, 15:11 +0100 schrieb Lucas Stach:
>> Am Montag, den 09.11.2020, 14:15 -0600 schrieb Rob Herring:
>>> On Thu, Nov 05, 2020 at 06:44:29PM +0100, Lucas Stach wrote:
>>>> For some domains the resets of the devices in the domain are not
>>>> automatically triggered. Add an optional resets property to allow
>>>> the GPC driver to trigger those resets explicitly.
>>>>
>>>> Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
>>>> ---
>>>>   Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 7
>>>> +++++++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-
>>>> gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-
>>>> gpcv2.yaml
>>>> index a96e6dbf1858..4330c73a2c30 100644
>>>> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
>>>> @@ -66,6 +66,13 @@ properties:
>>>>   
>>>>             power-supply: true
>>>>   
>>>> +          resets:
>>>> +            description: |
>>>> +              A number of phandles to resets that need to be
>>>> asserted during
>>>> +              power-up sequencing of the domain.
>>>> +            minItems: 1
>>>> +            maxItems: 4
>>>
>>> You need to define what each reset is.
>>
>> I can't. The resets belong to devices located inside the power domain,
>> which need to be held in reset across the power-up sequence. So I
>> have no means to specify what each reset is in a generic power-domain
>> binding. Same situation as with the clocks in this binding actually.
>>
>> Do you have any guidance on what do here? Is this binding okay with
>> this explanation, or do we need to do something different here?
> 
> Any pointers on how we can make some progress with this? It's blocking
> quite a bit of functionality of the i.MX8MM SoC being enabled upstream.

One more ping from my side. Can you give us some feedback about whether 
we can proceed with the bindings proposed by Lucas or not?

This has been on hold now for over 5 months and it looks like one of the 
reasons is that we don't know if the bindings will be accepted.

Thanks
Frieder



More information about the linux-arm-kernel mailing list