diff mbox series

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

Message ID 20201105174434.1817539-9-l.stach@pengutronix.de
State New
Headers show
Series i.MX8MM power domain support | expand

Commit Message

Lucas Stach Nov. 5, 2020, 5:44 p.m. UTC
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@pengutronix.de>
---
 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Lucas Stach Nov. 17, 2020, 2:11 p.m. UTC | #1
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@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.

Regards,
Lucas
Lucas Stach Nov. 30, 2020, 9:57 a.m. UTC | #2
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@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?

Regards,
Lucas
Lucas Stach Feb. 10, 2021, 2:35 p.m. UTC | #3
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@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.

Regards,
Lucas
Marek Vasut Feb. 10, 2021, 2:42 p.m. UTC | #4
On 2/10/21 3:35 PM, 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@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.


Not just MX8MM anymore, but also MX8MN and MX8MP , so it would be real 
helpful to unblock this.
Adam Ford March 22, 2021, 6:19 p.m. UTC | #5
On Tue, Nov 17, 2020 at 8:11 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>

> 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@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.

>


Rob,

Do you have any guidance on how we might be able to give you want you
want so we can move forward?  This power-domain driver will be used
for a variety of Freescale/NXP IMX SoC's, and looking at other power
domain controllers [1], they don't explicitly define what each reset
is.  Since the resets for this family vary from SoC to SoC, the number
of resets will change from one SoC to another.  If you could give us a
suggestion or an example of a board that has the power-domain resets
do what you ask, it would help move this forward.  Without this
driver, several boards are unable to use a significant number of
peripherals.

adam
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml?h=v5.12-rc4

> Regards,

> Lucas

>
Frieder Schrempf April 26, 2021, 9:24 a.m. UTC | #6
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@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
Frieder Schrempf April 29, 2021, 2:38 p.m. UTC | #7
On 26.04.21 11:24, Frieder Schrempf wrote:
> 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@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.


It looks like Rob is fine with the bindings if there is an explanation 
in the bindings for why the resets are not defined.

Quote from Rob on IRC: "Just explain why the resets are unknown and 
variable in the binding".
diff mbox series

Patch

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
+
         required:
           - '#power-domain-cells'
           - reg