[PATCH v1 0/6] drm/msm: Improved a6xx GMU reset

[PATCH v1 0/6] drm/msm: Improved a6xx GMU reset

[Jordan Crouse]

This is a stack of changes for 5.1 (if I'm not already too late). The bulk of
the changes implement a better GMU reset sequence using the new gpucc power
domain added in 5.0. If a GMU fault occurs during runtime we try to do a
standard GPU recovery and if the fault happens during GMU start then try to
fail somewhat gracefully than BUG_ON.

There will be a DT change to go along with this, but we can send that along
after the core code is merged. The downside for not having the domain
properly listed is that the runtime reset sequence probably won't work which
is no worse than it is today.

Jordan Crouse (6):
  drm/msm/a6xx: Remove unwanted regulator code
  dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings
  drm/msm/gpu: Attach to the GPU GX power domain
  drm/msm/a6xx: Make GMU reset useful
  msm/drm/a6xx: Turn off the GMU if resume fails
  drm/msm/a6xx: Remove an unused struct member

 .../devicetree/bindings/display/msm/gmu.txt        |  10 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c              | 200 +++++++++++++--------
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h              |   9 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c              |  20 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h              |   3 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c         |   1 +
 6 files changed, 144 insertions(+), 99 deletions(-)

-- 
2.7.4

[PATCH v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Jordan Crouse]

The GMU should have two power domains defined: "cx" and "gx". "cx" is the
actual power domain for the device and "gx" will be attached at runtime
to manage reference counting on the GPU device in case of a GMU crash.

Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---

 Documentation/devicetree/bindings/display/msm/gmu.txt | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt b/Documentation/devicetree/bindings/display/msm/gmu.txt
index 3439b38..90af5b0 100644
--- a/Documentation/devicetree/bindings/display/msm/gmu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -24,7 +24,10 @@ Required properties:
    * "cxo"
    * "axi"
    * "mnoc"
-- power-domains: should be <&clock_gpucc GPU_CX_GDSC>
+- power-domains: should be:
+	<&clock_gpucc GPU_CX_GDSC>
+	<&clock_gpucc GPU_GX_GDSC>
+- power-domain-names: Matching names for the power domains
 - iommus: phandle to the adreno iommu
 - operating-points-v2: phandle to the OPP operating points
 
@@ -51,7 +54,10 @@ Example:
 			<&gcc GCC_GPU_MEMNOC_GFX_CLK>;
 		clock-names = "gmu", "cxo", "axi", "memnoc";
 
-		power-domains = <&gpucc GPU_CX_GDSC>;
+		power-domains = <&gpucc GPU_CX_GDSC>,
+				<&gpucc GPU_GX_GDSC>;
+		power-domain-names = "cx", "gx";
+
 		iommus = <&adreno_smmu 5>;
 
 		operating-points-v2 = <&gmu_opp_table>;
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Rob Herring]

On Mon, Feb 4, 2019 at 10:15 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> The GMU should have two power domains defined: "cx" and "gx". "cx" is the
> actual power domain for the device and "gx" will be attached at runtime
> to manage reference counting on the GPU device in case of a GMU crash.

power-domains are supposed to be actual regions on a chip die which
can be power gated. However, they are often abused by being defined in
terms of kernel PM domains which are not always the same thing. This
description sounds like the latter case.

Rob

Re: [PATCH v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Rob Clark]

On Sun, Feb 17, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Feb 4, 2019 at 10:15 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> >
> > The GMU should have two power domains defined: "cx" and "gx". "cx" is the
> > actual power domain for the device and "gx" will be attached at runtime
> > to manage reference counting on the GPU device in case of a GMU crash.
>
> power-domains are supposed to be actual regions on a chip die which
> can be power gated. However, they are often abused by being defined in
> terms of kernel PM domains which are not always the same thing. This
> description sounds like the latter case.
>

iirc (and Jordan can correct me), this arrangement was needed because
normally the GMU does the GPU power control (except for if we manage
to crash it and need to reset the GMU)..

so maybe not 100% about the actual regions on chip die which can be
gated.. but it is a reality of how hw + fw + sw fit together..

BR,
-R

Re: [PATCH v1 2/6] dt-bindings: drm/msm/a6xx: Add GX power-domain for GMU bindings

[Jordan Crouse]

On Sun, Feb 17, 2019 at 05:43:16PM -0500, Rob Clark wrote:
> On Sun, Feb 17, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Mon, Feb 4, 2019 at 10:15 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> > >
> > > The GMU should have two power domains defined: "cx" and "gx". "cx" is the
> > > actual power domain for the device and "gx" will be attached at runtime
> > > to manage reference counting on the GPU device in case of a GMU crash.
> >
> > power-domains are supposed to be actual regions on a chip die which
> > can be power gated. However, they are often abused by being defined in
> > terms of kernel PM domains which are not always the same thing. This
> > description sounds like the latter case.
> >
> 
> iirc (and Jordan can correct me), this arrangement was needed because
> normally the GMU does the GPU power control (except for if we manage
> to crash it and need to reset the GMU)..
> 
> so maybe not 100% about the actual regions on chip die which can be
> gated.. but it is a reality of how hw + fw + sw fit together..

Ack - forgot to add Stephen who knows about this.

Rob is correct. The GX domain is real but it is normally controlled by an
off-CPU microcontroller. The CPU needs to get involved only when the
microcontroller crashes and we need to get things back to normal.  So the
description of it being an actual region on a chip die is accurate.

It sounds like I need to describe the hardware better in the bindings document.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno