From: Bjorn Andersson <andersson@kernel.org> To: Akhil P Oommen <quic_akhilpo@quicinc.com>, Ulf Hansson <ulf.hansson@linaro.org> Cc: freedreno <freedreno@lists.freedesktop.org>, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Rob Clark <robdclark@gmail.com>, Stephen Boyd <swboyd@chromium.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Philipp Zabel <p.zabel@pengutronix.de>, Douglas Anderson <dianders@chromium.org>, krzysztof.kozlowski@linaro.org, Abhinav Kumar <quic_abhinavk@quicinc.com>, Andy Gross <agross@kernel.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>, Konrad Dybcio <konrad.dybcio@somainline.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Rob Herring <robh+dt@kernel.org>, Sean Paul <sean@poorly.run>, Stephen Boyd <sboyd@kernel.org>, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface Date: Thu, 1 Dec 2022 16:57:05 -0600 [thread overview] Message-ID: <20221201225705.46r2m35ketvzipox@builder.lan> (raw) In-Reply-To: <1664960824-20951-1-git-send-email-quic_akhilpo@quicinc.com> On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > @Ulf, Akhil has a power-domain for a piece of hardware which may be voted active by multiple different subsystems (co-processors/execution contexts) in the system. As such, during the powering down sequence we don't wait for the power-domain to turn off. But in the event of an error, the recovery mechanism relies on waiting for the hardware to settle in a powered off state. The proposal here is to use the reset framework to wait for this state to be reached, before continuing with the recovery mechanism in the client driver. Given our other discussions on quirky behavior, do you have any input/suggestions on this? > Some clients like adreno gpu driver would like to ensure that its gdsc > is collapsed at hardware during a gpu reset sequence. This is because it > has a votable gdsc which could be ON due to a vote from another subsystem > like tz, hyp etc or due to an internal hardware signal. To allow > this, gpucc driver can expose an interface to the client driver using > reset framework. Using this the client driver can trigger a polling within > the gdsc driver. @Akhil, this description is fairly generic. As we've reached the state where the hardware has settled and we return to the client, what prevents it from being powered up again? Or is it simply a question of it hitting the powered-off state, not necessarily staying there? Regards, Bjorn > > This series is rebased on top of qcom/linux:for-next branch. > > Related discussion: https://patchwork.freedesktop.org/patch/493144/ > > Changes in v7: > - Update commit message (Bjorn) > - Rebased on top of qcom/linux:for-next branch. > > Changes in v6: > - No code changes in this version. Just captured the Acked-by tags > > Changes in v5: > - Nit: Remove a duplicate blank line (Krzysztof) > > Changes in v4: > - Update gpu dt-binding schema > - Typo fix in commit text > > Changes in v3: > - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof) > > Changes in v2: > - Return error when a particular custom reset op is not implemented. (Dmitry) > > Akhil P Oommen (6): > dt-bindings: clk: qcom: Support gpu cx gdsc reset > clk: qcom: Allow custom reset ops > clk: qcom: gdsc: Add a reset op to poll gdsc collapse > clk: qcom: gpucc-sc7280: Add cx collapse reset support > dt-bindings: drm/msm/gpu: Add optional resets > arm64: dts: qcom: sc7280: Add Reset support for gpu > > .../devicetree/bindings/display/msm/gpu.yaml | 6 +++++ > arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++ > drivers/clk/qcom/gdsc.c | 23 ++++++++++++++---- > drivers/clk/qcom/gdsc.h | 7 ++++++ > drivers/clk/qcom/gpucc-sc7280.c | 10 ++++++++ > drivers/clk/qcom/reset.c | 27 +++++++++++++++++++++- > drivers/clk/qcom/reset.h | 8 +++++++ > include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ > 8 files changed, 82 insertions(+), 5 deletions(-) > > -- > 2.7.4 >
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <andersson@kernel.org> To: Akhil P Oommen <quic_akhilpo@quicinc.com>, Ulf Hansson <ulf.hansson@linaro.org> Cc: David Airlie <airlied@linux.ie>, Michael Turquette <mturquette@baylibre.com>, Konrad Dybcio <konrad.dybcio@somainline.org>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, linux-clk@vger.kernel.org, Andy Gross <agross@kernel.org>, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, Abhinav Kumar <quic_abhinavk@quicinc.com>, Stephen Boyd <swboyd@chromium.org>, Rob Herring <robh+dt@kernel.org>, Sean Paul <sean@poorly.run>, Stephen Boyd <sboyd@kernel.org>, Douglas Anderson <dianders@chromium.org>, krzysztof.kozlowski@linaro.org, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, freedreno <freedreno@lists.freedesktop.org> Subject: Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface Date: Thu, 1 Dec 2022 16:57:05 -0600 [thread overview] Message-ID: <20221201225705.46r2m35ketvzipox@builder.lan> (raw) In-Reply-To: <1664960824-20951-1-git-send-email-quic_akhilpo@quicinc.com> On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > @Ulf, Akhil has a power-domain for a piece of hardware which may be voted active by multiple different subsystems (co-processors/execution contexts) in the system. As such, during the powering down sequence we don't wait for the power-domain to turn off. But in the event of an error, the recovery mechanism relies on waiting for the hardware to settle in a powered off state. The proposal here is to use the reset framework to wait for this state to be reached, before continuing with the recovery mechanism in the client driver. Given our other discussions on quirky behavior, do you have any input/suggestions on this? > Some clients like adreno gpu driver would like to ensure that its gdsc > is collapsed at hardware during a gpu reset sequence. This is because it > has a votable gdsc which could be ON due to a vote from another subsystem > like tz, hyp etc or due to an internal hardware signal. To allow > this, gpucc driver can expose an interface to the client driver using > reset framework. Using this the client driver can trigger a polling within > the gdsc driver. @Akhil, this description is fairly generic. As we've reached the state where the hardware has settled and we return to the client, what prevents it from being powered up again? Or is it simply a question of it hitting the powered-off state, not necessarily staying there? Regards, Bjorn > > This series is rebased on top of qcom/linux:for-next branch. > > Related discussion: https://patchwork.freedesktop.org/patch/493144/ > > Changes in v7: > - Update commit message (Bjorn) > - Rebased on top of qcom/linux:for-next branch. > > Changes in v6: > - No code changes in this version. Just captured the Acked-by tags > > Changes in v5: > - Nit: Remove a duplicate blank line (Krzysztof) > > Changes in v4: > - Update gpu dt-binding schema > - Typo fix in commit text > > Changes in v3: > - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof) > > Changes in v2: > - Return error when a particular custom reset op is not implemented. (Dmitry) > > Akhil P Oommen (6): > dt-bindings: clk: qcom: Support gpu cx gdsc reset > clk: qcom: Allow custom reset ops > clk: qcom: gdsc: Add a reset op to poll gdsc collapse > clk: qcom: gpucc-sc7280: Add cx collapse reset support > dt-bindings: drm/msm/gpu: Add optional resets > arm64: dts: qcom: sc7280: Add Reset support for gpu > > .../devicetree/bindings/display/msm/gpu.yaml | 6 +++++ > arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++ > drivers/clk/qcom/gdsc.c | 23 ++++++++++++++---- > drivers/clk/qcom/gdsc.h | 7 ++++++ > drivers/clk/qcom/gpucc-sc7280.c | 10 ++++++++ > drivers/clk/qcom/reset.c | 27 +++++++++++++++++++++- > drivers/clk/qcom/reset.h | 8 +++++++ > include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ > 8 files changed, 82 insertions(+), 5 deletions(-) > > -- > 2.7.4 >
next prev parent reply other threads:[~2022-12-01 22:57 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-05 9:06 [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface Akhil P Oommen 2022-10-05 9:06 ` Akhil P Oommen 2022-10-05 9:06 ` [PATCH v7 1/6] dt-bindings: clk: qcom: Support gpu cx gdsc reset Akhil P Oommen 2022-10-05 9:06 ` Akhil P Oommen 2022-10-05 9:07 ` [PATCH v7 2/6] clk: qcom: Allow custom reset ops Akhil P Oommen 2022-10-05 9:07 ` Akhil P Oommen 2022-10-05 9:07 ` [PATCH v7 3/6] clk: qcom: gdsc: Add a reset op to poll gdsc collapse Akhil P Oommen 2022-10-05 9:07 ` Akhil P Oommen 2022-12-07 15:45 ` Ulf Hansson 2022-12-07 15:45 ` Ulf Hansson 2022-12-08 15:02 ` Akhil P Oommen 2022-12-08 15:02 ` Akhil P Oommen 2022-12-08 15:30 ` [Freedreno] " Akhil P Oommen 2022-12-08 15:30 ` Akhil P Oommen 2022-10-05 9:07 ` [PATCH v7 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support Akhil P Oommen 2022-10-05 9:07 ` Akhil P Oommen 2022-12-07 15:46 ` Ulf Hansson 2022-12-07 15:46 ` Ulf Hansson 2022-12-08 15:24 ` Akhil P Oommen 2022-12-08 15:24 ` Akhil P Oommen 2022-12-08 21:09 ` Bjorn Andersson 2022-12-08 21:09 ` Bjorn Andersson 2022-12-12 17:49 ` Akhil P Oommen 2022-12-12 17:49 ` Akhil P Oommen 2022-10-05 9:07 ` [PATCH v7 5/6] dt-bindings: drm/msm/gpu: Add optional resets Akhil P Oommen 2022-10-05 9:07 ` Akhil P Oommen 2022-10-05 9:07 ` [PATCH v7 6/6] arm64: dts: qcom: sc7280: Add Reset support for gpu Akhil P Oommen 2022-10-05 9:07 ` Akhil P Oommen 2022-11-07 16:54 ` [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface Akhil P Oommen 2022-11-07 16:54 ` Akhil P Oommen 2022-12-01 22:57 ` Bjorn Andersson [this message] 2022-12-01 22:57 ` Bjorn Andersson 2022-12-02 7:00 ` [Freedreno] " Akhil P Oommen 2022-12-02 7:00 ` Akhil P Oommen 2022-12-06 19:58 ` Akhil P Oommen 2022-12-06 19:58 ` Akhil P Oommen 2022-12-07 16:00 ` Ulf Hansson 2022-12-07 16:00 ` Ulf Hansson 2022-12-07 16:54 ` Bjorn Andersson 2022-12-07 16:54 ` Bjorn Andersson 2022-12-08 13:40 ` Ulf Hansson 2022-12-08 13:40 ` Ulf Hansson 2022-12-08 14:45 ` Akhil P Oommen 2022-12-08 14:45 ` Akhil P Oommen 2022-12-08 21:06 ` Bjorn Andersson 2022-12-08 21:06 ` Bjorn Andersson 2022-12-09 17:36 ` Ulf Hansson 2022-12-09 17:36 ` Ulf Hansson 2022-12-12 15:39 ` Ulf Hansson 2022-12-12 15:39 ` Ulf Hansson 2022-12-12 17:43 ` Akhil P Oommen 2022-12-12 17:43 ` Akhil P Oommen 2022-12-27 18:24 ` Bjorn Andersson 2022-12-27 18:24 ` Bjorn Andersson 2022-12-28 9:23 ` Akhil P Oommen 2022-12-28 9:23 ` Akhil P Oommen 2022-12-08 15:31 ` Akhil P Oommen 2022-12-08 15:31 ` Akhil P Oommen
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=20221201225705.46r2m35ketvzipox@builder.lan \ --to=andersson@kernel.org \ --cc=agross@kernel.org \ --cc=airlied@linux.ie \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=konrad.dybcio@somainline.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=p.zabel@pengutronix.de \ --cc=quic_abhinavk@quicinc.com \ --cc=quic_akhilpo@quicinc.com \ --cc=robdclark@gmail.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=sean@poorly.run \ --cc=swboyd@chromium.org \ --cc=ulf.hansson@linaro.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: linkBe 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.