From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
Johan Jonker <jbx6244@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property
Date: Fri, 30 Dec 2022 19:08:58 +0200 [thread overview]
Message-ID: <87k028g6ol.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_Jsq+viP_aY3n378WC7WpxZFnsTc-vKjW9Ojvcy0Ef-z09Ng@mail.gmail.com>
Hi,
Rob Herring <robh@kernel.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
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.
> power-domains in the parent because obviously the DWC3 has 0
> power-domains.
How did you come to this conclusion?
>> It's a similar situation when you have multiple clock domains with the
>> same parent clock.
>
> Yes, that's a common problem in clock bindings too. Not really
> anything we can do about that other than require a detailed reference
> manual with every binding and someone (me) reviewing the manual
> against the binding. Neither of those are going to happen. Even on Arm
> Primecell blocks which clearly (and publicly) document the clocks,
> we've gotten these wrong (or .dts authors just didn't follow the
> binding).
Heh
--
balbi
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
Johan Jonker <jbx6244@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property
Date: Fri, 30 Dec 2022 19:08:58 +0200 [thread overview]
Message-ID: <87k028g6ol.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_Jsq+viP_aY3n378WC7WpxZFnsTc-vKjW9Ojvcy0Ef-z09Ng@mail.gmail.com>
Hi,
Rob Herring <robh@kernel.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
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.
> power-domains in the parent because obviously the DWC3 has 0
> power-domains.
How did you come to this conclusion?
>> It's a similar situation when you have multiple clock domains with the
>> same parent clock.
>
> Yes, that's a common problem in clock bindings too. Not really
> anything we can do about that other than require a detailed reference
> manual with every binding and someone (me) reviewing the manual
> against the binding. Neither of those are going to happen. Even on Arm
> Primecell blocks which clearly (and publicly) document the clocks,
> we've gotten these wrong (or .dts authors just didn't follow the
> binding).
Heh
--
balbi
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Rob Herring <robh@kernel.org>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Heiko Stuebner <heiko@sntech.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
Johan Jonker <jbx6244@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property
Date: Fri, 30 Dec 2022 19:08:58 +0200 [thread overview]
Message-ID: <87k028g6ol.fsf@balbi.sh> (raw)
In-Reply-To: <CAL_Jsq+viP_aY3n378WC7WpxZFnsTc-vKjW9Ojvcy0Ef-z09Ng@mail.gmail.com>
Hi,
Rob Herring <robh@kernel.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
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.
> power-domains in the parent because obviously the DWC3 has 0
> power-domains.
How did you come to this conclusion?
>> It's a similar situation when you have multiple clock domains with the
>> same parent clock.
>
> Yes, that's a common problem in clock bindings too. Not really
> anything we can do about that other than require a detailed reference
> manual with every binding and someone (me) reviewing the manual
> against the binding. Neither of those are going to happen. Even on Arm
> Primecell blocks which clearly (and publicly) document the clocks,
> we've gotten these wrong (or .dts authors just didn't follow the
> binding).
Heh
--
balbi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-12-30 17:16 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 19:10 [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` [PATCH 2/2] dt-bindings: usb: rockchip,dwc3: Move RK3399 to its own schema Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-19 19:10 ` Rob Herring
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 7:37 ` Felipe Balbi
2022-12-20 13:54 ` Rob Herring
2022-12-20 13:54 ` Rob Herring
2022-12-20 13:54 ` Rob Herring
2022-12-23 10:34 ` Felipe Balbi
2022-12-23 10:34 ` Felipe Balbi
2022-12-23 10:34 ` Felipe Balbi
2022-12-20 7:34 ` [PATCH 1/2] dt-bindings: usb: snps,dwc3: Allow power-domains property Felipe Balbi
2022-12-20 7:34 ` Felipe Balbi
2022-12-20 7:34 ` Felipe Balbi
2022-12-20 14:04 ` Rob Herring
2022-12-20 14:04 ` Rob Herring
2022-12-20 14:04 ` Rob Herring
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 10:31 ` Felipe Balbi
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 11:06 ` Krzysztof Kozlowski
2022-12-23 23:57 ` Thinh Nguyen
2022-12-23 23:57 ` Thinh Nguyen
2022-12-23 23:57 ` Thinh Nguyen
2022-12-24 17:37 ` Rob Herring
2022-12-24 17:37 ` Rob Herring
2022-12-24 17:37 ` Rob Herring
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 8:43 ` Felipe Balbi
2022-12-30 16:54 ` Rob Herring
2022-12-30 16:54 ` Rob Herring
2022-12-30 16:54 ` Rob Herring
2022-12-30 17:08 ` Felipe Balbi [this message]
2022-12-30 17:08 ` Felipe Balbi
2022-12-30 17:08 ` Felipe Balbi
2023-01-03 18:58 ` Rob Herring
2023-01-03 18:58 ` Rob Herring
2023-01-03 18:58 ` Rob Herring
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 19:40 ` Thinh Nguyen
2023-01-09 20:42 ` Rob Herring
2023-01-09 20:42 ` Rob Herring
2023-01-09 20:42 ` Rob Herring
2023-01-09 21:37 ` Thinh Nguyen
2023-01-09 21:37 ` Thinh Nguyen
2023-01-09 21:37 ` Thinh Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k028g6ol.fsf@balbi.sh \
--to=balbi@kernel.org \
--cc=Thinh.Nguyen@synopsys.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.