Re: [PATCH 4/6] clk: qcom: gxclkctl: Remove GX/GMxC rail votes to align with IFPC

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 4/7/26 11:30 AM, Taniya Das wrote:
> The GX GDSC control is handled through a dedicated clock controller,
> and the enable/disable sequencing depends on correct rail voting.
> The driver votes for the GX/GMxC rails and CX GDSC before toggling
> the GX GDSC. Currently, during GMU runtime PM resume, rails remain
> enabled due to upstream votes propagated via RPM-enabled devlinks
> and explicit pm_runtime votes on GX GDSC.
> 
> This is not an expected behaviour of IFPC(Inter Frame Power Collapse)
> requirements of GPU as GMU firmware is expected to control these rails,
> except during the GPU/GMU recovery via the OS and that is where the GX
> GDSC should be voting for the rails (GX/GMxC and CX GDSC) before
> toggling the GX GDSC.
> 
> Thus, disable runtime PM after successfully registering the clock
> controller.
> 
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
>  drivers/clk/qcom/gxclkctl-kaanapali.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/qcom/gxclkctl-kaanapali.c b/drivers/clk/qcom/gxclkctl-kaanapali.c
> index d7cf6834dd77c2a5320ffb8548cdb515be237bdc..d470ade11b0d11eb40843fe84c809e71646dce27 100644
> --- a/drivers/clk/qcom/gxclkctl-kaanapali.c
> +++ b/drivers/clk/qcom/gxclkctl-kaanapali.c
> @@ -7,6 +7,7 @@
>  #include <linux/mod_devicetable.h>
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/regmap.h>
>  
>  #include <dt-bindings/clock/qcom,kaanapali-gxclkctl.h>
> @@ -61,7 +62,15 @@ MODULE_DEVICE_TABLE(of, gx_clkctl_kaanapali_match_table);
>  
>  static int gx_clkctl_kaanapali_probe(struct platform_device *pdev)
>  {
> -	return qcom_cc_probe(pdev, &gx_clkctl_kaanapali_desc);
> +	int ret;
> +
> +	ret = qcom_cc_probe(pdev, &gx_clkctl_kaanapali_desc);
> +	if (ret)
> +		return ret;
> +
> +	pm_runtime_disable(&pdev->dev);

My understanding is that this works because we have more than one domain
associated with the nod (so the generic code that would otherwise enable a
single one so long as the device is resumed doesn't apply) and your previous
patch ensures that after probe, the clock controller is being put to sleep,
right before pm_runtime_disable() executes.

Is that right?

Konrad