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

Lucas Stach l.stach at pengutronix.de
Wed Feb 10 09:35:12 EST 2021


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.

Regards,
Lucas




More information about the linux-arm-kernel mailing list