clk: qcom: Update the force mem core bit for GPU clocks

Message ID 1666159535-6447-1-git-send-email-quic_c_skakit@quicinc.com
State New
Headers
Series clk: qcom: Update the force mem core bit for GPU clocks |

Commit Message

Satya Priya Oct. 19, 2022, 6:05 a.m. UTC
  From: Taniya Das <quic_tdas@quicinc.com>

There are few GPU clocks which are powering up the memories
and thus enable the FORCE_MEM_PERIPH always for these clocks
to force the periph_on signal to remain active during halt
state of the clock.

Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280")
Fixes: 3e0f01d6c7e7 ("clk: qcom: Add graphics clock controller driver for SC7280")
Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com>
---
 drivers/clk/qcom/gcc-sc7280.c   | 1 +
 drivers/clk/qcom/gpucc-sc7280.c | 1 +
 2 files changed, 2 insertions(+)
  

Comments

Stephen Boyd Oct. 28, 2022, 12:23 a.m. UTC | #1
Quoting Satya Priya (2022-10-18 23:05:35)
> From: Taniya Das <quic_tdas@quicinc.com>
>
> There are few GPU clocks which are powering up the memories
> and thus enable the FORCE_MEM_PERIPH always for these clocks
> to force the periph_on signal to remain active during halt
> state of the clock.
>
> Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280")
> Fixes: 3e0f01d6c7e7 ("clk: qcom: Add graphics clock controller driver for SC7280")
> Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
> Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com>
> ---

Applied to clk-fixes
  
Stephen Boyd Oct. 28, 2022, 12:24 a.m. UTC | #2
Quoting Satya Priya (2022-10-18 23:05:35)
> From: Taniya Das <quic_tdas@quicinc.com>
>
> There are few GPU clocks which are powering up the memories
> and thus enable the FORCE_MEM_PERIPH always for these clocks
> to force the periph_on signal to remain active during halt
> state of the clock.

I take it that missing this causes GPU to lose state when it suspends
and that confuses the driver?
  
Satya Priya Nov. 7, 2022, 5:38 a.m. UTC | #3
On 10/28/2022 5:54 AM, Stephen Boyd wrote:
> Quoting Satya Priya (2022-10-18 23:05:35)
>> From: Taniya Das <quic_tdas@quicinc.com>
>>
>> There are few GPU clocks which are powering up the memories
>> and thus enable the FORCE_MEM_PERIPH always for these clocks
>> to force the periph_on signal to remain active during halt
>> state of the clock.
> I take it that missing this causes GPU to lose state when it suspends
> and that confuses the driver?


It is more related to GPU SMMU states and the stability issues that are 
encountered.
  
Doug Anderson Nov. 7, 2022, 5 p.m. UTC | #4
Hi,

On Sun, Nov 6, 2022 at 9:38 PM Satya Priya Kakitapalli (Temp)
<quic_c_skakit@quicinc.com> wrote:
>
>
> On 10/28/2022 5:54 AM, Stephen Boyd wrote:
> > Quoting Satya Priya (2022-10-18 23:05:35)
> >> From: Taniya Das <quic_tdas@quicinc.com>
> >>
> >> There are few GPU clocks which are powering up the memories
> >> and thus enable the FORCE_MEM_PERIPH always for these clocks
> >> to force the periph_on signal to remain active during halt
> >> state of the clock.
> > I take it that missing this causes GPU to lose state when it suspends
> > and that confuses the driver?
>
>
> It is more related to GPU SMMU states and the stability issues that are
> encountered.

I see a very similar code sequence for sc7180. Is any similar fix
needed for sc7180, or is this something unique for sc7280?

-Doug
  
Satya Priya Nov. 8, 2022, 5:59 a.m. UTC | #5
Hi Doug,


On 11/7/2022 10:30 PM, Doug Anderson wrote:
> Hi,
>
> On Sun, Nov 6, 2022 at 9:38 PM Satya Priya Kakitapalli (Temp)
> <quic_c_skakit@quicinc.com> wrote:
>>
>> On 10/28/2022 5:54 AM, Stephen Boyd wrote:
>>> Quoting Satya Priya (2022-10-18 23:05:35)
>>>> From: Taniya Das <quic_tdas@quicinc.com>
>>>>
>>>> There are few GPU clocks which are powering up the memories
>>>> and thus enable the FORCE_MEM_PERIPH always for these clocks
>>>> to force the periph_on signal to remain active during halt
>>>> state of the clock.
>>> I take it that missing this causes GPU to lose state when it suspends
>>> and that confuses the driver?
>>
>> It is more related to GPU SMMU states and the stability issues that are
>> encountered.
> I see a very similar code sequence for sc7180. Is any similar fix
> needed for sc7180, or is this something unique for sc7280?


This is not needed for sc7180, it is related to sc7280 only.
  

Patch

diff --git a/drivers/clk/qcom/gcc-sc7280.c b/drivers/clk/qcom/gcc-sc7280.c
index 8afb757..46d41eb 100644
--- a/drivers/clk/qcom/gcc-sc7280.c
+++ b/drivers/clk/qcom/gcc-sc7280.c
@@ -3467,6 +3467,7 @@  static int gcc_sc7280_probe(struct platform_device *pdev)
 	regmap_update_bits(regmap, 0x28004, BIT(0), BIT(0));
 	regmap_update_bits(regmap, 0x28014, BIT(0), BIT(0));
 	regmap_update_bits(regmap, 0x71004, BIT(0), BIT(0));
+	regmap_update_bits(regmap, 0x7100C, BIT(13), BIT(13));
 
 	ret = qcom_cc_register_rcg_dfs(regmap, gcc_dfs_clocks,
 			ARRAY_SIZE(gcc_dfs_clocks));
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..1490cd4 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -463,6 +463,7 @@  static int gpu_cc_sc7280_probe(struct platform_device *pdev)
 	 */
 	regmap_update_bits(regmap, 0x1170, BIT(0), BIT(0));
 	regmap_update_bits(regmap, 0x1098, BIT(0), BIT(0));
+	regmap_update_bits(regmap, 0x1098, BIT(13), BIT(13));
 
 	return qcom_cc_really_probe(pdev, &gpu_cc_sc7280_desc, regmap);
 }