Message-ID: <20230109213653.ubft6jfc472ey5cf@synopsys.com>
Date:   Mon, 9 Jan 2023 21:37:02 +0000
From:   Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To:     Rob Herring <robh@...nel.org>
CC:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Felipe Balbi <balbi@...nel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        "linux-rockchip@...ts.infradead.org" 
        <linux-rockchip@...ts.infradead.org>,
        Johan Jonker <jbx6244@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains
 property

On Mon, Jan 09, 2023, Rob Herring wrote:
> On Mon, Jan 9, 2023 at 1:40 PM Thinh Nguyen <Thinh.Nguyen@...opsys.com> wrote:
> >
> > On Tue, Jan 03, 2023, Rob Herring wrote:
> > > On Fri, Dec 30, 2022 at 11:09 AM Felipe Balbi <balbi@...nel.org> wrote:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Rob Herring <robh@...nel.org> writes:
> > > > >> >> > >> >  Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 3 +++
> > > > >> >> > >> >  1 file changed, 3 insertions(+)
> > > > >> >> > >> >
> > > > >> >> > >> > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > >> >> > >> > index 6d78048c4613..bcefd1c2410a 100644
> > > > >> >> > >> > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > >> >> > >> > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
> > > > >> >> > >> > @@ -91,6 +91,9 @@ properties:
> > > > >> >> > >> >          - usb2-phy
> > > > >> >> > >> >          - usb3-phy
> > > > >> >> > >> >
> > > > >> >> > >> > +  power-domains:
> > > > >> >> > >> > +    maxItems: 1
> > > > >> >> > >>
> > > > >> >> > >> AFAICT this can be incorrect. Also, you could have Cc the dwc3
> > > > >> >> > >> maintainer to get comments.
> > > > >> >>
> > > > >> >> Felipe is correct. We have 2 power-domains: Core domain and PMU.
> > > > >> >
> > > > >> > Power management unit? Performance management unit?
> > > > >> >
> > > > >> > That doesn't change that the rk3399 is 1 and we're stuck with it. So I
> > > > >> > can say 1 or 2 domains, or we add the 2nd domain when someone needs
> > > > >> > it.
> > > > >>
> > > > >> Isn't the snps,dwc3.yaml document supposed to document dwc3's view of
> > > > >> the world? In that case, dwc3 expects 2 power domains. It just so
> > > > >> happens that in rk3399 they are fed from the same power supply, but
> > > > >> dwc3' still thinks there are two of them. No?
> > > > >
> > > > > Yes. That is how bindings *should* be. However, RK3399 defined one PD
> > > > > long ago and it's an ABI. So we are stuck with it. Everyone else put
> > > >
> > > > Are you confusing things, perhaps? DWC3, the block Synopsys licenses,
> > > > has, as Thinh confirmed, 2 internal power domains. How OEMs (TI, Intel,
> > > > Rockchip, Allwinner, etc) decide to integrate the IP into their systems
> > > > is something different. That is part of the (so-called)
> > > > wrapper. Different integrators will wrap Synopsys IP however they see
> > > > fit, as long as they can provide a suitable translation layer between
> > > > Synopsys own view of the world (its own interconnect implementation, of
> > > > which there are 3 to choose from, IIRC) and the rest of the SoC.
> > > >
> > > > Perhaps what RK3399 did was provide a single power domain at the wrapper
> > > > level that feeds both of DWC3's own power domains, but DWC3 itself still
> >
> > Just for some additional context/use case, the power to the PMU (power
> > management unit) must always be on. If the device supports hibernation,
> > in hibernation, the power supply to the core can be turned off.
> 
> Things in an always-on PD may or may not be described in

I'm just providing additional info, and not everything is necessarily
needed for the DT description.

> 'power-domains', so from a DT perspective I would say 1 domain is
> perfectly valid here.
> 
> I suppose the PMU could be in a PD which can be gated off, but any
> hibernation features would be lost.
> 

Some devices have both the core and the PMU in the same power domain,
which may be the case for RK3399. However, the PMUs may be implemented
in a separate power rail than the core.

> > > > has 2 power domains, that's not something rockchip can change without
> > > > risking the loss of support from Synopsys, as it would not be Synopsys
> > > > IP anymore.
> > >
> > > Again, none of this matters. I'm documenting what is already in use
> > > and an ABI, not what is correct. The time for correctness was when
> > > this binding was added.
> >
> > That's unfortunate. That makes this very difficult to maintain if we
> > can't rectify a mistake.
> 
> Shrug. What's unfortunate is only a limited number of people can
> review bindings to be correct in this aspect. And I'm not one of them.
> 
> We deal with this all the time already. It's just amplified when it is
> shared IP. Would I like less variation? Yes, but it's not a
> showstopper.
> 
> > > To move forward, how about something like this:
> > >
> > > power-domains:
> > >   description: Really there are 2 PDs, but some implementations
> > > defined a single PD.
> > >   minItems: 1
> > >   items:
> > >     - description: core
> > >     - description: PMU
> > >
> > > We unfortunately can't constrain this to Rockchip in the schema
> > > because that specific information is in the parent node.
> > >
> > > (kind of crappy descriptions too, but that's the amount of information I have.)
> >
> > Can we omit mentioning min or maxItems? While it may not be desired,
> > it's not a hard requirement right? This can help avoid some confusion
> > with devicetree documentation and dwc3 databook.
> 
> Why? Don't you want to catch someone defining 3 domains?
> 

My concern was more about "maxItems: 1" may cause some confusion. If we
can't say "maxItems: 2", omitting it or using "minItems: 1" seems to be
a better option.

As you mentioned, we can't do much about it now that it's part of the
DT. I've provided the info you need to make the appropriate change.
Looks like there's no perfect solution. Please make the change you see
best fit.

Thanks,
Thinh

Powered by blists - more mailing lists