| Message ID | 20170905105739.8330-3-heiko@sntech.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Sep 05, 2017 at 12:57:34PM +0200, Heiko Stuebner wrote: > Mali GPUs have a separate supplying regulator in a lot of socs, > so describe a mali-supply property. The already described > operating points will likely also need access to this regulator. > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > index 3b7f6f72f032..bcaa640c883f 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > @@ -39,6 +39,9 @@ Optional properties: > Memory region to allocate from, as defined in > Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt > > + - mali-supply : Phandle to regulator for the Mali device. Refer to > + Documentation/devicetree/bindings/regulator/regulator.txt for details. Wouldn't a power domain be more appropriate? > + > - operating-points-v2: > Operating Points for the GPU, as defined in > Documentation/devicetree/bindings/opp/opp.txt > -- > 2.14.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, Am Dienstag, 12. September 2017, 17:09:20 CEST schrieb Rob Herring: > On Tue, Sep 05, 2017 at 12:57:34PM +0200, Heiko Stuebner wrote: > > Mali GPUs have a separate supplying regulator in a lot of socs, > > so describe a mali-supply property. The already described > > operating points will likely also need access to this regulator. > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > > --- > > > > Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index > > 3b7f6f72f032..bcaa640c883f 100644 > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > > > @@ -39,6 +39,9 @@ Optional properties: > > Memory region to allocate from, as defined in > > Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt > > > > + - mali-supply : Phandle to regulator for the Mali device. Refer to > > + Documentation/devicetree/bindings/regulator/regulator.txt for > > details. > > Wouldn't a power domain be more appropriate? At least on Rockchip socs there is a power-domain, but also the separate additional regulator. See the similar mali-midgard binding. Heiko
On Wed, Sep 13, 2017 at 12:12:24AM +0200, Heiko Stübner wrote: > Hi Rob, > > Am Dienstag, 12. September 2017, 17:09:20 CEST schrieb Rob Herring: > > On Tue, Sep 05, 2017 at 12:57:34PM +0200, Heiko Stuebner wrote: > > > Mali GPUs have a separate supplying regulator in a lot of socs, > > > so describe a mali-supply property. The already described > > > operating points will likely also need access to this regulator. > > > > > > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > > > --- > > > > > > Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > > b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index > > > 3b7f6f72f032..bcaa640c883f 100644 > > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt > > > > > > @@ -39,6 +39,9 @@ Optional properties: > > > Memory region to allocate from, as defined in > > > Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt > > > > > > + - mali-supply : Phandle to regulator for the Mali device. Refer to > > > + Documentation/devicetree/bindings/regulator/regulator.txt for > > > details. > > > > Wouldn't a power domain be more appropriate? > > At least on Rockchip socs there is a power-domain, but also the separate > additional regulator. See the similar mali-midgard binding. And that regulator's state is independent of the power domain's state? But I guess OPPs need a regulator. Really we should allow OPPs to be tied to the power domain. Maybe we do, I can't keep up with the ever evolving PM stuff. So, given we already have it for midgard, Acked-by: Rob Herring <robh@kernel.org> Rob
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt index 3b7f6f72f032..bcaa640c883f 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt @@ -39,6 +39,9 @@ Optional properties: Memory region to allocate from, as defined in Documentation/devicetree/bindi/reserved-memory/reserved-memory.txt + - mali-supply : Phandle to regulator for the Mali device. Refer to + Documentation/devicetree/bindings/regulator/regulator.txt for details. + - operating-points-v2: Operating Points for the GPU, as defined in Documentation/devicetree/bindings/opp/opp.txt
Mali GPUs have a separate supplying regulator in a lot of socs, so describe a mali-supply property. The already described operating points will likely also need access to this regulator. Signed-off-by: Heiko Stuebner <heiko@sntech.de> --- Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 3 +++ 1 file changed, 3 insertions(+)