[PATCH V5 RESEND 0/5] PM: domains: Add control for switching back and forth to HW control

[PATCH V5 RESEND 0/5] PM: domains: Add control for switching back and forth to HW control

[Jagadeesh Kona]

This series adds support for dev_pm_genpd_set_hwmode() and dev_pm_genpd_get_hwmode() APIs
and support in gdsc provider drivers to register respective callbacks and venus consumer
driver example using above API to switch the power domain(GDSC) to HW/SW modes dynamically
at runtime.

This is resend of V5 series, added R-By tags received in V5 for 1st & 2nd patches.

Link to V5: https://lore.kernel.org/all/20240315111046.22136-1-quic_jkona@quicinc.com/

Changes in V5:
- Updated 1st patch as per V4 review comments to synchronize the initial HW mode state by
  invoking ->get_hwmode_dev()callback in genpd_add_device()
- With above change, SW cached hwmode will contain correct value initially, and it will be
  updated everytime mode is changed in set_hwmode, hence updated dev_pm_genpd_get_hwmode()
  to just return SW cached hwmode in 1st patch
- Updated commit text for 1st, 3rd, 4th and 5th patches
- Updated 3rd and 5th patches as per review comments received on V4 series
- Added R-By tags received in older series to 1st and 2nd patches

Previous series:
V4: https://lore.kernel.org/all/20240122-gdsc-hwctrl-v4-0-9061e8a7aa07@linaro.org/
V3: https://lore.kernel.org/lkml/20230823114528.3677667-1-abel.vesa@linaro.org/ 
V2: https://lore.kernel.org/lkml/20230816145741.1472721-1-abel.vesa@linaro.org/
V1: https://lore.kernel.org/all/20230628105652.1670316-1-abel.vesa@linaro.org/

Abel Vesa (1):
  PM: domains: Add the domain HW-managed mode to the summary

Jagadeesh Kona (3):
  clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode
  clk: qcom: Use HW_CTRL_TRIGGER flag to switch video GDSC to HW mode
  venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on
    V6

Ulf Hansson (1):
  PM: domains: Allow devices attached to genpd to be managed by HW

 drivers/clk/qcom/gdsc.c                       | 37 +++++++++
 drivers/clk/qcom/gdsc.h                       |  1 +
 drivers/clk/qcom/videocc-sc7280.c             |  2 +-
 drivers/clk/qcom/videocc-sm8250.c             |  4 +-
 .../media/platform/qcom/venus/pm_helpers.c    | 39 ++++++----
 drivers/pmdomain/core.c                       | 78 ++++++++++++++++++-
 include/linux/pm_domain.h                     | 17 ++++
 7 files changed, 157 insertions(+), 21 deletions(-)

-- 
2.43.0

[PATCH V5 RESEND 1/5] PM: domains: Allow devices attached to genpd to be managed by HW

[Jagadeesh Kona]

From: Ulf Hansson <ulf.hansson@linaro.org>

Some power-domains may be capable of relying on the HW to control the power
for a device that's hooked up to it. Typically, for these kinds of
configurations the consumer driver should be able to change the behavior of
power domain at runtime, control the power domain in SW mode for certain
configurations and handover the control to HW mode for other usecases.

To allow a consumer driver to change the behaviour of the PM domain for its
device, let's provide a new function, dev_pm_genpd_set_hwmode(). Moreover,
let's add a corresponding optional genpd callback, ->set_hwmode_dev(),
which the genpd provider should implement if it can support switching
between HW controlled mode and SW controlled mode. Similarly, add the
dev_pm_genpd_get_hwmode() to allow consumers to read the current mode and
its corresponding optional genpd callback, ->get_hwmode_dev(), which the
genpd provider can also implement to synchronize the initial HW mode
state in genpd_add_device() by reading back the mode from the hardware.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
---
 drivers/pmdomain/core.c   | 64 +++++++++++++++++++++++++++++++++++++++
 include/linux/pm_domain.h | 17 +++++++++++
 2 files changed, 81 insertions(+)

diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4215ffd9b11c..70d8634dd9e8 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -578,6 +578,68 @@ void dev_pm_genpd_synced_poweroff(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(dev_pm_genpd_synced_poweroff);
 
+/**
+ * dev_pm_genpd_set_hwmode() - Set the HW mode for the device and its PM domain.
+ *
+ * @dev: Device for which the HW-mode should be changed.
+ * @enable: Value to set or unset the HW-mode.
+ *
+ * Some PM domains can rely on HW signals to control the power for a device. To
+ * allow a consumer driver to switch the behaviour for its device in runtime,
+ * which may be beneficial from a latency or energy point of view, this function
+ * may be called.
+ *
+ * It is assumed that the users guarantee that the genpd wouldn't be detached
+ * while this routine is getting called.
+ *
+ * Return: Returns 0 on success and negative error values on failures.
+ */
+int dev_pm_genpd_set_hwmode(struct device *dev, bool enable)
+{
+	struct generic_pm_domain *genpd;
+	int ret = 0;
+
+	genpd = dev_to_genpd_safe(dev);
+	if (!genpd)
+		return -ENODEV;
+
+	if (!genpd->set_hwmode_dev)
+		return -EOPNOTSUPP;
+
+	genpd_lock(genpd);
+
+	if (dev_gpd_data(dev)->hw_mode == enable)
+		goto out;
+
+	ret = genpd->set_hwmode_dev(genpd, dev, enable);
+	if (!ret)
+		dev_gpd_data(dev)->hw_mode = enable;
+
+out:
+	genpd_unlock(genpd);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_set_hwmode);
+
+/**
+ * dev_pm_genpd_get_hwmode() - Get the HW mode setting for the device.
+ *
+ * @dev: Device for which the current HW-mode setting should be fetched.
+ *
+ * This helper function allows consumer drivers to fetch the current HW mode
+ * setting of its the device.
+ *
+ * It is assumed that the users guarantee that the genpd wouldn't be detached
+ * while this routine is getting called.
+ *
+ * Return: Returns the HW mode setting of device from SW cached hw_mode.
+ */
+bool dev_pm_genpd_get_hwmode(struct device *dev)
+{
+	return dev_gpd_data(dev)->hw_mode;
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_get_hwmode);
+
 static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
 {
 	unsigned int state_idx = genpd->state_idx;
@@ -1676,6 +1738,8 @@ static int genpd_add_device(struct generic_pm_domain *genpd, struct device *dev,
 
 	gpd_data->cpu = genpd_get_cpu(genpd, base_dev);
 
+	gpd_data->hw_mode = genpd->get_hwmode_dev ? genpd->get_hwmode_dev(genpd, dev) : false;
+
 	ret = genpd->attach_dev ? genpd->attach_dev(genpd, dev) : 0;
 	if (ret)
 		goto out;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 772d3280d35f..797b3987b37b 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -175,6 +175,10 @@ struct generic_pm_domain {
 	int (*set_performance_state)(struct generic_pm_domain *genpd,
 				     unsigned int state);
 	struct gpd_dev_ops dev_ops;
+	int (*set_hwmode_dev)(struct generic_pm_domain *domain,
+			      struct device *dev, bool enable);
+	bool (*get_hwmode_dev)(struct generic_pm_domain *domain,
+			      struct device *dev);
 	int (*attach_dev)(struct generic_pm_domain *domain,
 			  struct device *dev);
 	void (*detach_dev)(struct generic_pm_domain *domain,
@@ -237,6 +241,7 @@ struct generic_pm_domain_data {
 	unsigned int performance_state;
 	unsigned int default_pstate;
 	unsigned int rpm_pstate;
+	bool hw_mode;
 	void *data;
 };
 
@@ -266,6 +271,8 @@ int dev_pm_genpd_remove_notifier(struct device *dev);
 void dev_pm_genpd_set_next_wakeup(struct device *dev, ktime_t next);
 ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev);
 void dev_pm_genpd_synced_poweroff(struct device *dev);
+int dev_pm_genpd_set_hwmode(struct device *dev, bool enable);
+bool dev_pm_genpd_get_hwmode(struct device *dev);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;
@@ -334,6 +341,16 @@ static inline ktime_t dev_pm_genpd_get_next_hrtimer(struct device *dev)
 static inline void dev_pm_genpd_synced_poweroff(struct device *dev)
 { }
 
+static inline int dev_pm_genpd_set_hwmode(struct device *dev, bool enable)
+{
+	return -EOPNOTSUPP;
+}
+
+static inline bool dev_pm_genpd_get_hwmode(struct device *dev)
+{
+	return false;
+}
+
 #define simple_qos_governor		(*(struct dev_power_governor *)(NULL))
 #define pm_domain_always_on_gov		(*(struct dev_power_governor *)(NULL))
 #endif
-- 
2.43.0

Re: [PATCH V5 RESEND 1/5] PM: domains: Allow devices attached to genpd to be managed by HW

[Taniya Das]

On 4/13/2024 8:50 PM, Jagadeesh Kona wrote:
> Some power-domains may be capable of relying on the HW to control the power
> for a device that's hooked up to it. Typically, for these kinds of
> configurations the consumer driver should be able to change the behavior of
> power domain at runtime, control the power domain in SW mode for certain
> configurations and handover the control to HW mode for other usecases.
> 
> To allow a consumer driver to change the behaviour of the PM domain for its
> device, let's provide a new function, dev_pm_genpd_set_hwmode(). Moreover,
> let's add a corresponding optional genpd callback, ->set_hwmode_dev(),
> which the genpd provider should implement if it can support switching
> between HW controlled mode and SW controlled mode. Similarly, add the
> dev_pm_genpd_get_hwmode() to allow consumers to read the current mode and
> its corresponding optional genpd callback, ->get_hwmode_dev(), which the
> genpd provider can also implement to synchronize the initial HW mode
> state in genpd_add_device() by reading back the mode from the hardware.
> 
> Signed-off-by: Ulf Hansson<ulf.hansson@linaro.org>
> Signed-off-by: Abel Vesa<abel.vesa@linaro.org>
> Signed-off-by: Jagadeesh Kona<quic_jkona@quicinc.com>
> Reviewed-by: Dmitry Baryshkov<dmitry.baryshkov@linaro.org>
> Reviewed-by: Dhruva Gole<d-gole@ti.com>
> ---
>   drivers/pmdomain/core.c   | 64 +++++++++++++++++++++++++++++++++++++++
>   include/linux/pm_domain.h | 17 +++++++++++
>   2 files changed, 81 insertions(+)

Reviewed-by: Taniya Das <quic_tdas@quicinc.com>

-- 
Thanks & Regards,
Taniya Das.

[PATCH V5 RESEND 2/5] PM: domains: Add the domain HW-managed mode to the summary

[Jagadeesh Kona]

From: Abel Vesa <abel.vesa@linaro.org>

Now that genpd supports dynamically switching the control for an
attached device between hardware- and software-mode, let's add this
information to the genpd summary under managed by column in debugfs.

Suggested-by: Taniya Das <quic_tdas@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
---
 drivers/pmdomain/core.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 70d8634dd9e8..18a101215c9c 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -3173,6 +3173,15 @@ static void rtpm_status_str(struct seq_file *s, struct device *dev)
 	seq_printf(s, "%-25s  ", p);
 }
 
+static void mode_status_str(struct seq_file *s, struct device *dev)
+{
+	struct generic_pm_domain_data *gpd_data;
+
+	gpd_data = to_gpd_data(dev->power.subsys_data->domain_data);
+
+	seq_printf(s, "%20s", gpd_data->hw_mode ? "HW" : "SW");
+}
+
 static void perf_status_str(struct seq_file *s, struct device *dev)
 {
 	struct generic_pm_domain_data *gpd_data;
@@ -3231,6 +3240,7 @@ static int genpd_summary_one(struct seq_file *s,
 		seq_printf(s, "\n    %-50s  ", kobj_path);
 		rtpm_status_str(s, pm_data->dev);
 		perf_status_str(s, pm_data->dev);
+		mode_status_str(s, pm_data->dev);
 		kfree(kobj_path);
 	}
 
@@ -3247,8 +3257,8 @@ static int summary_show(struct seq_file *s, void *data)
 	int ret = 0;
 
 	seq_puts(s, "domain                          status          children                           performance\n");
-	seq_puts(s, "    /device                                             runtime status\n");
-	seq_puts(s, "----------------------------------------------------------------------------------------------\n");
+	seq_puts(s, "    /device                                             runtime status                           managed by\n");
+	seq_puts(s, "------------------------------------------------------------------------------------------------------------\n");
 
 	ret = mutex_lock_interruptible(&gpd_list_lock);
 	if (ret)
-- 
2.43.0

Re: [PATCH V5 RESEND 2/5] PM: domains: Add the domain HW-managed mode to the summary

[Taniya Das]

On 4/13/2024 8:50 PM, Jagadeesh Kona wrote:
> Now that genpd supports dynamically switching the control for an
> attached device between hardware- and software-mode, let's add this
> information to the genpd summary under managed by column in debugfs.
> 
> Suggested-by: Taniya Das<quic_tdas@quicinc.com>
> Signed-off-by: Abel Vesa<abel.vesa@linaro.org>
> Signed-off-by: Jagadeesh Kona<quic_jkona@quicinc.com>
> Reviewed-by: Ulf Hansson<ulf.hansson@linaro.org>
> Reviewed-by: Dmitry Baryshkov<dmitry.baryshkov@linaro.org>
> Reviewed-by: Bjorn Andersson<andersson@kernel.org>
> Reviewed-by: Dhruva Gole<d-gole@ti.com>
> ---
>   drivers/pmdomain/core.c | 14 ++++++++++++--
>   1 file changed, 12 insertions(+), 2 deletions(-)

Reviewed-by: Taniya Das <quic_tdas@quicinc.com>

-- 
Thanks & Regards,
Taniya Das.

[PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Jagadeesh Kona]

Some GDSC client drivers require the GDSC mode to be switched dynamically
to HW mode at runtime to gain the power benefits. Typically such client
drivers require the GDSC to be brought up in SW mode initially to enable
the required dependent clocks and configure the hardware to proper state.
Once initial hardware set up is done, they switch the GDSC to HW mode to
save power. At the end of usecase, they switch the GDSC back to SW mode
and disable the GDSC.

Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
get_hwmode_dev callbacks for GDSC's whose respective client drivers
require the GDSC mode to be switched dynamically at runtime using
dev_pm_genpd_set_hwmode() API.

Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
 drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
 drivers/clk/qcom/gdsc.h |  1 +
 2 files changed, 38 insertions(+)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index df9618ab7eea..c5f6be8181d8 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain)
 	return 0;
 }
 
+static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode)
+{
+	struct gdsc *sc = domain_to_gdsc(domain);
+	int ret;
+
+	ret = gdsc_hwctrl(sc, mode);
+	if (ret)
+		return ret;
+
+	/* Wait for 1usec for mode transition to properly complete */
+	udelay(1);
+
+	/*
+	 * When GDSC is switched to HW mode, HW can disable the GDSC.
+	 * When GDSC is switched back to SW mode, the GDSC will be enabled
+	 * again, hence need to poll for GDSC to complete the power up.
+	 */
+	if (!mode)
+		return gdsc_poll_status(sc, GDSC_ON);
+
+	return 0;
+}
+
+static bool gdsc_get_hwmode(struct generic_pm_domain *domain, struct device *dev)
+{
+	struct gdsc *sc = domain_to_gdsc(domain);
+	u32 val;
+
+	regmap_read(sc->regmap, sc->gdscr, &val);
+
+	return !!(val & HW_CONTROL_MASK);
+}
+
 static int gdsc_init(struct gdsc *sc)
 {
 	u32 mask, val;
@@ -451,6 +484,10 @@ static int gdsc_init(struct gdsc *sc)
 		sc->pd.power_off = gdsc_disable;
 	if (!sc->pd.power_on)
 		sc->pd.power_on = gdsc_enable;
+	if (sc->flags & HW_CTRL_TRIGGER) {
+		sc->pd.set_hwmode_dev = gdsc_set_hwmode;
+		sc->pd.get_hwmode_dev = gdsc_get_hwmode;
+	}
 
 	ret = pm_genpd_init(&sc->pd, NULL, !on);
 	if (ret)
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 803512688336..1e2779b823d1 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -67,6 +67,7 @@ struct gdsc {
 #define ALWAYS_ON	BIT(6)
 #define RETAIN_FF_ENABLE	BIT(7)
 #define NO_RET_PERIPH	BIT(8)
+#define HW_CTRL_TRIGGER	BIT(9)
 	struct reset_controller_dev	*rcdev;
 	unsigned int			*resets;
 	unsigned int			reset_count;
-- 
2.43.0

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Bryan O'Donoghue]

On 13/04/2024 16:20, Jagadeesh Kona wrote:
> Some GDSC client drivers require the GDSC mode to be switched dynamically
> to HW mode at runtime to gain the power benefits. Typically such client
> drivers require the GDSC to be brought up in SW mode initially to enable
> the required dependent clocks and configure the hardware to proper state.
> Once initial hardware set up is done, they switch the GDSC to HW mode to
> save power. At the end of usecase, they switch the GDSC back to SW mode
> and disable the GDSC.
> 
> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
> get_hwmode_dev callbacks for GDSC's whose respective client drivers
> require the GDSC mode to be switched dynamically at runtime using
> dev_pm_genpd_set_hwmode() API.
> 
> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---
>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>   drivers/clk/qcom/gdsc.h |  1 +
>   2 files changed, 38 insertions(+)
> 
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index df9618ab7eea..c5f6be8181d8 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain)
>   	return 0;
>   }
>   
> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode)
> +{
> +	struct gdsc *sc = domain_to_gdsc(domain);
> +	int ret;
> +
> +	ret = gdsc_hwctrl(sc, mode);
> +	if (ret)
> +		return ret;
> +
> +	/* Wait for 1usec for mode transition to properly complete */
> +	udelay(1);

A delay I suspect you don't need - if the HW spec says "takes 1 usec for 
this to take effect" that's 1 usec from io write completion from APSS to 
another system agent.

You poll for the state transition down below anyway.

I'd be pretty certain that's a redundant delay.

> +
> +	/*
> +	 * When GDSC is switched to HW mode, HW can disable the GDSC.
> +	 * When GDSC is switched back to SW mode, the GDSC will be enabled
> +	 * again, hence need to poll for GDSC to complete the power up.
> +	 */
> +	if (!mode)
> +		return gdsc_poll_status(sc, GDSC_ON);
> +
> +	return 0;
> +}

Other than that, seems fine.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Jagadeesh Kona]

On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>> Some GDSC client drivers require the GDSC mode to be switched dynamically
>> to HW mode at runtime to gain the power benefits. Typically such client
>> drivers require the GDSC to be brought up in SW mode initially to enable
>> the required dependent clocks and configure the hardware to proper state.
>> Once initial hardware set up is done, they switch the GDSC to HW mode to
>> save power. At the end of usecase, they switch the GDSC back to SW mode
>> and disable the GDSC.
>>
>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>> require the GDSC mode to be switched dynamically at runtime using
>> dev_pm_genpd_set_hwmode() API.
>>
>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>> ---
>>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>   drivers/clk/qcom/gdsc.h |  1 +
>>   2 files changed, 38 insertions(+)
>>
>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>> index df9618ab7eea..c5f6be8181d8 100644
>> --- a/drivers/clk/qcom/gdsc.c
>> +++ b/drivers/clk/qcom/gdsc.c
>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain 
>> *domain)
>>       return 0;
>>   }
>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct 
>> device *dev, bool mode)
>> +{
>> +    struct gdsc *sc = domain_to_gdsc(domain);
>> +    int ret;
>> +
>> +    ret = gdsc_hwctrl(sc, mode);
>> +    if (ret)
>> +        return ret;
>> +
>> +    /* Wait for 1usec for mode transition to properly complete */
>> +    udelay(1);
> 
> A delay I suspect you don't need - if the HW spec says "takes 1 usec for 
> this to take effect" that's 1 usec from io write completion from APSS to 
> another system agent.
> 
> You poll for the state transition down below anyway.
> 
> I'd be pretty certain that's a redundant delay.
> 

Thanks Bryan for your review!

This 1usec delay is needed every time GDSC is moved in and out of HW 
control mode and the reason for same is explained in one of the older 
gdsc driver change at below link

https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/ 


Thanks,
Jagadeesh

>> +
>> +    /*
>> +     * When GDSC is switched to HW mode, HW can disable the GDSC.
>> +     * When GDSC is switched back to SW mode, the GDSC will be enabled
>> +     * again, hence need to poll for GDSC to complete the power up.
>> +     */
>> +    if (!mode)
>> +        return gdsc_poll_status(sc, GDSC_ON);
>> +
>> +    return 0;
>> +}
> 
> Other than that, seems fine.
> 
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> 

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Bryan O'Donoghue]

On 24/04/2024 10:47, Jagadeesh Kona wrote:
> 
> 
> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>> Some GDSC client drivers require the GDSC mode to be switched 
>>> dynamically
>>> to HW mode at runtime to gain the power benefits. Typically such client
>>> drivers require the GDSC to be brought up in SW mode initially to enable
>>> the required dependent clocks and configure the hardware to proper 
>>> state.
>>> Once initial hardware set up is done, they switch the GDSC to HW mode to
>>> save power. At the end of usecase, they switch the GDSC back to SW mode
>>> and disable the GDSC.
>>>
>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>>> require the GDSC mode to be switched dynamically at runtime using
>>> dev_pm_genpd_set_hwmode() API.
>>>
>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>> ---
>>>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>>   drivers/clk/qcom/gdsc.h |  1 +
>>>   2 files changed, 38 insertions(+)
>>>
>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>> index df9618ab7eea..c5f6be8181d8 100644
>>> --- a/drivers/clk/qcom/gdsc.c
>>> +++ b/drivers/clk/qcom/gdsc.c
>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain 
>>> *domain)
>>>       return 0;
>>>   }
>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct 
>>> device *dev, bool mode)
>>> +{
>>> +    struct gdsc *sc = domain_to_gdsc(domain);
>>> +    int ret;
>>> +
>>> +    ret = gdsc_hwctrl(sc, mode);
>>> +    if (ret)
>>> +        return ret;
>>> +
>>> +    /* Wait for 1usec for mode transition to properly complete */
>>> +    udelay(1);
>>
>> A delay I suspect you don't need - if the HW spec says "takes 1 usec 
>> for this to take effect" that's 1 usec from io write completion from 
>> APSS to another system agent.
>>
>> You poll for the state transition down below anyway.
>>
>> I'd be pretty certain that's a redundant delay.
>>
> 
> Thanks Bryan for your review!
> 
> This 1usec delay is needed every time GDSC is moved in and out of HW 
> control mode and the reason for same is explained in one of the older 
> gdsc driver change at below link
> 
> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/
> 

Right.

If that is your precedent then you seem to be missing the mb(); between

gdsc_hwctrl();

/* mb(); here */

and this

udelay(1);

---
bod

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Jagadeesh Kona]

On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote:
> On 24/04/2024 10:47, Jagadeesh Kona wrote:
>>
>>
>> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
>>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>>> Some GDSC client drivers require the GDSC mode to be switched 
>>>> dynamically
>>>> to HW mode at runtime to gain the power benefits. Typically such client
>>>> drivers require the GDSC to be brought up in SW mode initially to 
>>>> enable
>>>> the required dependent clocks and configure the hardware to proper 
>>>> state.
>>>> Once initial hardware set up is done, they switch the GDSC to HW 
>>>> mode to
>>>> save power. At the end of usecase, they switch the GDSC back to SW mode
>>>> and disable the GDSC.
>>>>
>>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>>>> require the GDSC mode to be switched dynamically at runtime using
>>>> dev_pm_genpd_set_hwmode() API.
>>>>
>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>>> ---
>>>>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>>>   drivers/clk/qcom/gdsc.h |  1 +
>>>>   2 files changed, 38 insertions(+)
>>>>
>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>>> index df9618ab7eea..c5f6be8181d8 100644
>>>> --- a/drivers/clk/qcom/gdsc.c
>>>> +++ b/drivers/clk/qcom/gdsc.c
>>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct 
>>>> generic_pm_domain *domain)
>>>>       return 0;
>>>>   }
>>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct 
>>>> device *dev, bool mode)
>>>> +{
>>>> +    struct gdsc *sc = domain_to_gdsc(domain);
>>>> +    int ret;
>>>> +
>>>> +    ret = gdsc_hwctrl(sc, mode);
>>>> +    if (ret)
>>>> +        return ret;
>>>> +
>>>> +    /* Wait for 1usec for mode transition to properly complete */
>>>> +    udelay(1);
>>>
>>> A delay I suspect you don't need - if the HW spec says "takes 1 usec 
>>> for this to take effect" that's 1 usec from io write completion from 
>>> APSS to another system agent.
>>>
>>> You poll for the state transition down below anyway.
>>>
>>> I'd be pretty certain that's a redundant delay.
>>>
>>
>> Thanks Bryan for your review!
>>
>> This 1usec delay is needed every time GDSC is moved in and out of HW 
>> control mode and the reason for same is explained in one of the older 
>> gdsc driver change at below link
>>
>> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/
>>
> 
> Right.
> 
> If that is your precedent then you seem to be missing the mb(); between
> 
> gdsc_hwctrl();
> 
> /* mb(); here */
> 
> and this
> 
> udelay(1);
> 

Sorry, earlier I shared the link to base patch series which has mb() 
used, but in the mainlined series of the same patch mb() is removed as 
per the review comments.

Please find the mainlined series link:-
https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/

Thanks,
Jagadeesh

> ---
> bod

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Konrad Dybcio]

On 4/24/24 12:27, Jagadeesh Kona wrote:
> 
> 
> On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote:
>> On 24/04/2024 10:47, Jagadeesh Kona wrote:
>>>
>>>
>>> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
>>>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>>>> Some GDSC client drivers require the GDSC mode to be switched dynamically
>>>>> to HW mode at runtime to gain the power benefits. Typically such client
>>>>> drivers require the GDSC to be brought up in SW mode initially to enable
>>>>> the required dependent clocks and configure the hardware to proper state.
>>>>> Once initial hardware set up is done, they switch the GDSC to HW mode to
>>>>> save power. At the end of usecase, they switch the GDSC back to SW mode
>>>>> and disable the GDSC.
>>>>>
>>>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>>>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>>>>> require the GDSC mode to be switched dynamically at runtime using
>>>>> dev_pm_genpd_set_hwmode() API.
>>>>>
>>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>>>> ---
>>>>>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>>>>   drivers/clk/qcom/gdsc.h |  1 +
>>>>>   2 files changed, 38 insertions(+)
>>>>>
>>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>>>> index df9618ab7eea..c5f6be8181d8 100644
>>>>> --- a/drivers/clk/qcom/gdsc.c
>>>>> +++ b/drivers/clk/qcom/gdsc.c
>>>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain)
>>>>>       return 0;
>>>>>   }
>>>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode)
>>>>> +{
>>>>> +    struct gdsc *sc = domain_to_gdsc(domain);
>>>>> +    int ret;
>>>>> +
>>>>> +    ret = gdsc_hwctrl(sc, mode);
>>>>> +    if (ret)
>>>>> +        return ret;
>>>>> +
>>>>> +    /* Wait for 1usec for mode transition to properly complete */
>>>>> +    udelay(1);
>>>>
>>>> A delay I suspect you don't need - if the HW spec says "takes 1 usec for this to take effect" that's 1 usec from io write completion from APSS to another system agent.
>>>>
>>>> You poll for the state transition down below anyway.
>>>>
>>>> I'd be pretty certain that's a redundant delay.
>>>>
>>>
>>> Thanks Bryan for your review!
>>>
>>> This 1usec delay is needed every time GDSC is moved in and out of HW control mode and the reason for same is explained in one of the older gdsc driver change at below link
>>>
>>> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/
>>>
>>
>> Right.
>>
>> If that is your precedent then you seem to be missing the mb(); between
>>
>> gdsc_hwctrl();
>>
>> /* mb(); here */
>>
>> and this
>>
>> udelay(1);
>>
> 
> Sorry, earlier I shared the link to base patch series which has mb() used, but in the mainlined series of the same patch mb() is removed as per the review comments.
> 
> Please find the mainlined series link:-
> https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/

Mostly because mb is a solution to a different problem. See this talk
for more details:

https://youtu.be/i6DayghhA8Q

Konrad

Re: [PATCH V5 RESEND 3/5] clk: qcom: gdsc: Add set and get hwmode callbacks to switch GDSC mode

[Konrad Dybcio]

On 4/24/24 14:22, Konrad Dybcio wrote:
> 
> 
> On 4/24/24 12:27, Jagadeesh Kona wrote:
>>
>>
>> On 4/24/2024 3:25 PM, Bryan O'Donoghue wrote:
>>> On 24/04/2024 10:47, Jagadeesh Kona wrote:
>>>>
>>>>
>>>> On 4/24/2024 5:18 AM, Bryan O'Donoghue wrote:
>>>>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>>>>> Some GDSC client drivers require the GDSC mode to be switched dynamically
>>>>>> to HW mode at runtime to gain the power benefits. Typically such client
>>>>>> drivers require the GDSC to be brought up in SW mode initially to enable
>>>>>> the required dependent clocks and configure the hardware to proper state.
>>>>>> Once initial hardware set up is done, they switch the GDSC to HW mode to
>>>>>> save power. At the end of usecase, they switch the GDSC back to SW mode
>>>>>> and disable the GDSC.
>>>>>>
>>>>>> Introduce HW_CTRL_TRIGGER flag to register the set_hwmode_dev and
>>>>>> get_hwmode_dev callbacks for GDSC's whose respective client drivers
>>>>>> require the GDSC mode to be switched dynamically at runtime using
>>>>>> dev_pm_genpd_set_hwmode() API.
>>>>>>
>>>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>>>>> ---
>>>>>>   drivers/clk/qcom/gdsc.c | 37 +++++++++++++++++++++++++++++++++++++
>>>>>>   drivers/clk/qcom/gdsc.h |  1 +
>>>>>>   2 files changed, 38 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
>>>>>> index df9618ab7eea..c5f6be8181d8 100644
>>>>>> --- a/drivers/clk/qcom/gdsc.c
>>>>>> +++ b/drivers/clk/qcom/gdsc.c
>>>>>> @@ -363,6 +363,39 @@ static int gdsc_disable(struct generic_pm_domain *domain)
>>>>>>       return 0;
>>>>>>   }
>>>>>> +static int gdsc_set_hwmode(struct generic_pm_domain *domain, struct device *dev, bool mode)
>>>>>> +{
>>>>>> +    struct gdsc *sc = domain_to_gdsc(domain);
>>>>>> +    int ret;
>>>>>> +
>>>>>> +    ret = gdsc_hwctrl(sc, mode);
>>>>>> +    if (ret)
>>>>>> +        return ret;
>>>>>> +
>>>>>> +    /* Wait for 1usec for mode transition to properly complete */
>>>>>> +    udelay(1);
>>>>>
>>>>> A delay I suspect you don't need - if the HW spec says "takes 1 usec for this to take effect" that's 1 usec from io write completion from APSS to another system agent.
>>>>>
>>>>> You poll for the state transition down below anyway.
>>>>>
>>>>> I'd be pretty certain that's a redundant delay.
>>>>>
>>>>
>>>> Thanks Bryan for your review!
>>>>
>>>> This 1usec delay is needed every time GDSC is moved in and out of HW control mode and the reason for same is explained in one of the older gdsc driver change at below link
>>>>
>>>> https://lore.kernel.org/all/1484027679-18397-1-git-send-email-rnayak@codeaurora.org/
>>>>
>>>
>>> Right.
>>>
>>> If that is your precedent then you seem to be missing the mb(); between
>>>
>>> gdsc_hwctrl();
>>>
>>> /* mb(); here */
>>>
>>> and this
>>>
>>> udelay(1);
>>>
>>
>> Sorry, earlier I shared the link to base patch series which has mb() used, but in the mainlined series of the same patch mb() is removed as per the review comments.
>>
>> Please find the mainlined series link:-
>> https://lore.kernel.org/all/1485145581-517-1-git-send-email-rnayak@codeaurora.org/
> 
> Mostly because mb is a solution to a different problem. See this talk
> for more details:
> 
> https://youtu.be/i6DayghhA8Q

(long story short: you want to read back the register right after
writing to make sure things arrive at the hardware when you
expect it to)

Konrad

[PATCH V5 RESEND 4/5] clk: qcom: Use HW_CTRL_TRIGGER flag to switch video GDSC to HW mode

[Jagadeesh Kona]

The HW_CTRL_TRIGGER flag provides flexibility to switch the GDSC
mode as per the consumers requirement compared to HW_CTRL flag which
directly switches the GDSC mode as part of gdsc enable/disable.
Hence use HW_CTRL_TRIGGER flag for vcodec GDSC's to allow venus driver
to switch the vcodec GDSC to HW/SW control modes at runtime using
dev_pm_genpd_set_hwmode() API.

Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
 drivers/clk/qcom/videocc-sc7280.c | 2 +-
 drivers/clk/qcom/videocc-sm8250.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/qcom/videocc-sc7280.c b/drivers/clk/qcom/videocc-sc7280.c
index cdd59c6f60df..d55613a47ff7 100644
--- a/drivers/clk/qcom/videocc-sc7280.c
+++ b/drivers/clk/qcom/videocc-sc7280.c
@@ -236,7 +236,7 @@ static struct gdsc mvs0_gdsc = {
 		.name = "mvs0_gdsc",
 	},
 	.pwrsts = PWRSTS_OFF_ON,
-	.flags = HW_CTRL | RETAIN_FF_ENABLE,
+	.flags = HW_CTRL_TRIGGER | RETAIN_FF_ENABLE,
 };
 
 static struct gdsc mvsc_gdsc = {
diff --git a/drivers/clk/qcom/videocc-sm8250.c b/drivers/clk/qcom/videocc-sm8250.c
index 016b596e03b3..cac10ccd362e 100644
--- a/drivers/clk/qcom/videocc-sm8250.c
+++ b/drivers/clk/qcom/videocc-sm8250.c
@@ -293,7 +293,7 @@ static struct gdsc mvs0_gdsc = {
 	.pd = {
 		.name = "mvs0_gdsc",
 	},
-	.flags = HW_CTRL,
+	.flags = HW_CTRL_TRIGGER,
 	.pwrsts = PWRSTS_OFF_ON,
 };
 
@@ -302,7 +302,7 @@ static struct gdsc mvs1_gdsc = {
 	.pd = {
 		.name = "mvs1_gdsc",
 	},
-	.flags = HW_CTRL,
+	.flags = HW_CTRL_TRIGGER,
 	.pwrsts = PWRSTS_OFF_ON,
 };
 
-- 
2.43.0

Re: [PATCH V5 RESEND 4/5] clk: qcom: Use HW_CTRL_TRIGGER flag to switch video GDSC to HW mode

[Konrad Dybcio]

On 4/13/24 17:20, Jagadeesh Kona wrote:
> The HW_CTRL_TRIGGER flag provides flexibility to switch the GDSC
> mode as per the consumers requirement compared to HW_CTRL flag which
> directly switches the GDSC mode as part of gdsc enable/disable.
> Hence use HW_CTRL_TRIGGER flag for vcodec GDSC's to allow venus driver
> to switch the vcodec GDSC to HW/SW control modes at runtime using
> dev_pm_genpd_set_hwmode() API.
> 
> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---

The commit title states clk: qcom: yet the only files changed are:

>   drivers/clk/qcom/videocc-sc7280.c | 2 +-
>   drivers/clk/qcom/videocc-sm8250.c | 4 ++--

With no explanation as to why anywhere

Konrad

Re: [PATCH V5 RESEND 4/5] clk: qcom: Use HW_CTRL_TRIGGER flag to switch video GDSC to HW mode

[Jagadeesh Kona]

On 4/23/2024 4:24 AM, Konrad Dybcio wrote:
> 
> 
> On 4/13/24 17:20, Jagadeesh Kona wrote:
>> The HW_CTRL_TRIGGER flag provides flexibility to switch the GDSC
>> mode as per the consumers requirement compared to HW_CTRL flag which
>> directly switches the GDSC mode as part of gdsc enable/disable.
>> Hence use HW_CTRL_TRIGGER flag for vcodec GDSC's to allow venus driver
>> to switch the vcodec GDSC to HW/SW control modes at runtime using
>> dev_pm_genpd_set_hwmode() API.
>>
>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>> ---
> 
> The commit title states clk: qcom: yet the only files changed are:
>

Thanks Konrad for your review! As there are 2 files with similar 
changes, I didn't mention file names in the commit title.

>>   drivers/clk/qcom/videocc-sc7280.c | 2 +-
>>   drivers/clk/qcom/videocc-sm8250.c | 4 ++--
> 
> With no explanation as to why anywhere
>

Sure, will update the target specific details in the commit text of next 
series.

Thanks,
Jagadeesh

> Konrad

[PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

The Venus driver requires vcodec GDSC to be ON in SW mode for clock
operations and move it back to HW mode to gain power benefits. Earlier,
as there is no interface to switch the GDSC mode from GenPD framework,
the GDSC is moved to HW control mode as part of GDSC enable callback and
venus driver is writing to its POWER_CONTROL register to keep the GDSC ON
from SW whereever required. But the POWER_CONTROL register addresses
are not constant and can vary across the variants.

Also as per the HW recommendation, the GDSC mode switching needs to be
controlled from respective GDSC register and this is a uniform approach
across all the targets. Hence use dev_pm_genpd_set_hwmode() API which
controls GDSC mode switching using its respective GDSC register.

In venus V6 variants, the vcodec gdsc gets enabled in SW mode by default
with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW
mode again after enable, hence add check to avoid switching gdsc to SW mode
again after gdsc enable. Similarly add check to avoid switching GDSC to HW
mode before disabling the GDSC, so GDSC gets enabled in SW mode in the next
enable.

Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
 .../media/platform/qcom/venus/pm_helpers.c    | 39 +++++++++++--------
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c
index 502822059498..4ce76ce6dd4d 100644
--- a/drivers/media/platform/qcom/venus/pm_helpers.c
+++ b/drivers/media/platform/qcom/venus/pm_helpers.c
@@ -412,10 +412,9 @@ static int vcodec_control_v4(struct venus_core *core, u32 coreid, bool enable)
 	u32 val;
 	int ret;
 
-	if (IS_V6(core)) {
-		ctrl = core->wrapper_base + WRAPPER_CORE_POWER_CONTROL_V6;
-		stat = core->wrapper_base + WRAPPER_CORE_POWER_STATUS_V6;
-	} else if (coreid == VIDC_CORE_ID_1) {
+	if (IS_V6(core))
+		return dev_pm_genpd_set_hwmode(core->pmdomains->pd_devs[coreid], !enable);
+	else if (coreid == VIDC_CORE_ID_1) {
 		ctrl = core->wrapper_base + WRAPPER_VCODEC0_MMCC_POWER_CONTROL;
 		stat = core->wrapper_base + WRAPPER_VCODEC0_MMCC_POWER_STATUS;
 	} else {
@@ -451,9 +450,11 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask)
 
 		vcodec_clks_disable(core, core->vcodec0_clks);
 
-		ret = vcodec_control_v4(core, VIDC_CORE_ID_1, false);
-		if (ret)
-			return ret;
+		if (!IS_V6(core)) {
+			ret = vcodec_control_v4(core, VIDC_CORE_ID_1, false);
+			if (ret)
+				return ret;
+		}
 
 		ret = pm_runtime_put_sync(core->pmdomains->pd_devs[1]);
 		if (ret < 0)
@@ -467,9 +468,11 @@ static int poweroff_coreid(struct venus_core *core, unsigned int coreid_mask)
 
 		vcodec_clks_disable(core, core->vcodec1_clks);
 
-		ret = vcodec_control_v4(core, VIDC_CORE_ID_2, false);
-		if (ret)
-			return ret;
+		if (!IS_V6(core)) {
+			ret = vcodec_control_v4(core, VIDC_CORE_ID_2, false);
+			if (ret)
+				return ret;
+		}
 
 		ret = pm_runtime_put_sync(core->pmdomains->pd_devs[2]);
 		if (ret < 0)
@@ -488,9 +491,11 @@ static int poweron_coreid(struct venus_core *core, unsigned int coreid_mask)
 		if (ret < 0)
 			return ret;
 
-		ret = vcodec_control_v4(core, VIDC_CORE_ID_1, true);
-		if (ret)
-			return ret;
+		if (!IS_V6(core)) {
+			ret = vcodec_control_v4(core, VIDC_CORE_ID_1, true);
+			if (ret)
+				return ret;
+		}
 
 		ret = vcodec_clks_enable(core, core->vcodec0_clks);
 		if (ret)
@@ -506,9 +511,11 @@ static int poweron_coreid(struct venus_core *core, unsigned int coreid_mask)
 		if (ret < 0)
 			return ret;
 
-		ret = vcodec_control_v4(core, VIDC_CORE_ID_2, true);
-		if (ret)
-			return ret;
+		if (!IS_V6(core)) {
+			ret = vcodec_control_v4(core, VIDC_CORE_ID_2, true);
+			if (ret)
+				return ret;
+		}
 
 		ret = vcodec_clks_enable(core, core->vcodec1_clks);
 		if (ret)
-- 
2.43.0

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 13/04/2024 16:20, Jagadeesh Kona wrote:
> The Venus driver requires vcodec GDSC to be ON in SW mode for clock
> operations and move it back to HW mode to gain power benefits. Earlier,
> as there is no interface to switch the GDSC mode from GenPD framework,
> the GDSC is moved to HW control mode as part of GDSC enable callback and
> venus driver is writing to its POWER_CONTROL register to keep the GDSC ON
> from SW whereever required. But the POWER_CONTROL register addresses
> are not constant and can vary across the variants.
> 
> Also as per the HW recommendation, the GDSC mode switching needs to be
> controlled from respective GDSC register and this is a uniform approach
> across all the targets. Hence use dev_pm_genpd_set_hwmode() API which
> controls GDSC mode switching using its respective GDSC register.
> 
> In venus V6 variants, the vcodec gdsc gets enabled in SW mode by default
> with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW
> mode again after enable, hence add check to avoid switching gdsc to SW mode
> again after gdsc enable. Similarly add check to avoid switching GDSC to HW
> mode before disabling the GDSC, so GDSC gets enabled in SW mode in the next
> enable.
> 
> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> ---

When I tested this out on sm8250 a few months ago it was broken.

I don't quite see in your commit logs, how the breakage was addressed.

Can you provide some details ?

---
bod

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

On 4/14/2024 6:09 PM, Bryan O'Donoghue wrote:
> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>> The Venus driver requires vcodec GDSC to be ON in SW mode for clock
>> operations and move it back to HW mode to gain power benefits. Earlier,
>> as there is no interface to switch the GDSC mode from GenPD framework,
>> the GDSC is moved to HW control mode as part of GDSC enable callback and
>> venus driver is writing to its POWER_CONTROL register to keep the GDSC ON
>> from SW whereever required. But the POWER_CONTROL register addresses
>> are not constant and can vary across the variants.
>>
>> Also as per the HW recommendation, the GDSC mode switching needs to be
>> controlled from respective GDSC register and this is a uniform approach
>> across all the targets. Hence use dev_pm_genpd_set_hwmode() API which
>> controls GDSC mode switching using its respective GDSC register.
>>
>> In venus V6 variants, the vcodec gdsc gets enabled in SW mode by default
>> with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW
>> mode again after enable, hence add check to avoid switching gdsc to SW 
>> mode
>> again after gdsc enable. Similarly add check to avoid switching GDSC 
>> to HW
>> mode before disabling the GDSC, so GDSC gets enabled in SW mode in the 
>> next
>> enable.
>>
>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>> ---
> 
> When I tested this out on sm8250 a few months ago it was broken.
> 
> I don't quite see in your commit logs, how the breakage was addressed.
> 
> Can you provide some details ?
> 

Thanks Bryan for your review!

In earlier series, venus driver is switching the vcodec GDSC to HW 
control mode before disabling the GDSC by invoking 
vcodec_control_v4(..., false) in poweroff_coreid(). Due to this, the 
subsequent GDSC enable from venus driver is failing while polling for 
GDSC power ON status, since GDSC is under HW control mode and HW can 
keep the GDSC in disabled state.

Now a check is added in poweroff_coreid() to avoid switching the GDSC to 
HW control mode before disabling the GDSC for Venus V6 variants that use 
this new API. Hence during the next GDSC enable, GDSC will be in SW mode 
and GDSC will powerup properly.

Thanks,
Jagadeesh

> ---
> bod
> 

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 14/04/2024 15:52, Jagadeesh Kona wrote:
> 
> 
> On 4/14/2024 6:09 PM, Bryan O'Donoghue wrote:
>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>> The Venus driver requires vcodec GDSC to be ON in SW mode for clock
>>> operations and move it back to HW mode to gain power benefits. Earlier,
>>> as there is no interface to switch the GDSC mode from GenPD framework,
>>> the GDSC is moved to HW control mode as part of GDSC enable callback and
>>> venus driver is writing to its POWER_CONTROL register to keep the 
>>> GDSC ON
>>> from SW whereever required. But the POWER_CONTROL register addresses
>>> are not constant and can vary across the variants.
>>>
>>> Also as per the HW recommendation, the GDSC mode switching needs to be
>>> controlled from respective GDSC register and this is a uniform approach
>>> across all the targets. Hence use dev_pm_genpd_set_hwmode() API which
>>> controls GDSC mode switching using its respective GDSC register.
>>>
>>> In venus V6 variants, the vcodec gdsc gets enabled in SW mode by default
>>> with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW
>>> mode again after enable, hence add check to avoid switching gdsc to 
>>> SW mode
>>> again after gdsc enable. Similarly add check to avoid switching GDSC 
>>> to HW
>>> mode before disabling the GDSC, so GDSC gets enabled in SW mode in 
>>> the next
>>> enable.
>>>
>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>> ---
>>
>> When I tested this out on sm8250 a few months ago it was broken.
>>
>> I don't quite see in your commit logs, how the breakage was addressed.
>>
>> Can you provide some details ?
>>
> 
> Thanks Bryan for your review!
> 
> In earlier series, venus driver is switching the vcodec GDSC to HW 
> control mode before disabling the GDSC by invoking 
> vcodec_control_v4(..., false) in poweroff_coreid(). Due to this, the 
> subsequent GDSC enable from venus driver is failing while polling for 
> GDSC power ON status, since GDSC is under HW control mode and HW can 
> keep the GDSC in disabled state.
> 
> Now a check is added in poweroff_coreid() to avoid switching the GDSC to 
> HW control mode before disabling the GDSC for Venus V6 variants that use 
> this new API. Hence during the next GDSC enable, GDSC will be in SW mode 
> and GDSC will powerup properly.

Right so the intention is to have HW GDSC control during playback only - 
and then revert to SW control when no stream is active, right ?

I tried your series on today's -next.

Here is -next without your changes

https://drive.google.com/file/d/1PFuLOlEp582rBQUvuwc9PNZUBxn1ioYf/view?usp=sharing

and here is -next with your changes

https://drive.google.com/file/d/1PHR4rZnWUH9Wp2B-itT5yCUXIMOMZrwM/view?usp=sharing

The first time I tried that test the stopping/stuttering was worse.

So yes the original crash was fixed but, this looks like a performance 
regression to me.

Here's the tree I tested with.

https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/linux-next-24-05-23-review?ref_type=heads

---
bod

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

On 4/24/2024 5:46 AM, Bryan O'Donoghue wrote:
> On 14/04/2024 15:52, Jagadeesh Kona wrote:
>>
>>
>> On 4/14/2024 6:09 PM, Bryan O'Donoghue wrote:
>>> On 13/04/2024 16:20, Jagadeesh Kona wrote:
>>>> The Venus driver requires vcodec GDSC to be ON in SW mode for clock
>>>> operations and move it back to HW mode to gain power benefits. Earlier,
>>>> as there is no interface to switch the GDSC mode from GenPD framework,
>>>> the GDSC is moved to HW control mode as part of GDSC enable callback 
>>>> and
>>>> venus driver is writing to its POWER_CONTROL register to keep the 
>>>> GDSC ON
>>>> from SW whereever required. But the POWER_CONTROL register addresses
>>>> are not constant and can vary across the variants.
>>>>
>>>> Also as per the HW recommendation, the GDSC mode switching needs to be
>>>> controlled from respective GDSC register and this is a uniform approach
>>>> across all the targets. Hence use dev_pm_genpd_set_hwmode() API which
>>>> controls GDSC mode switching using its respective GDSC register.
>>>>
>>>> In venus V6 variants, the vcodec gdsc gets enabled in SW mode by 
>>>> default
>>>> with new HW_CTRL_TRIGGER flag and there is no need to switch it to SW
>>>> mode again after enable, hence add check to avoid switching gdsc to 
>>>> SW mode
>>>> again after gdsc enable. Similarly add check to avoid switching GDSC 
>>>> to HW
>>>> mode before disabling the GDSC, so GDSC gets enabled in SW mode in 
>>>> the next
>>>> enable.
>>>>
>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
>>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>>> ---
>>>
>>> When I tested this out on sm8250 a few months ago it was broken.
>>>
>>> I don't quite see in your commit logs, how the breakage was addressed.
>>>
>>> Can you provide some details ?
>>>
>>
>> Thanks Bryan for your review!
>>
>> In earlier series, venus driver is switching the vcodec GDSC to HW 
>> control mode before disabling the GDSC by invoking 
>> vcodec_control_v4(..., false) in poweroff_coreid(). Due to this, the 
>> subsequent GDSC enable from venus driver is failing while polling for 
>> GDSC power ON status, since GDSC is under HW control mode and HW can 
>> keep the GDSC in disabled state.
>>
>> Now a check is added in poweroff_coreid() to avoid switching the GDSC 
>> to HW control mode before disabling the GDSC for Venus V6 variants 
>> that use this new API. Hence during the next GDSC enable, GDSC will be 
>> in SW mode and GDSC will powerup properly.
> 
> Right so the intention is to have HW GDSC control during playback only - 
> and then revert to SW control when no stream is active, right ?
> 
> I tried your series on today's -next.
> 
> Here is -next without your changes
> 
> https://drive.google.com/file/d/1PFuLOlEp582rBQUvuwc9PNZUBxn1ioYf/view?usp=sharing
> 
> and here is -next with your changes
> 
> https://drive.google.com/file/d/1PHR4rZnWUH9Wp2B-itT5yCUXIMOMZrwM/view?usp=sharing
> 
> The first time I tried that test the stopping/stuttering was worse.
> 
> So yes the original crash was fixed but, this looks like a performance 
> regression to me.
> 

Thanks Bryan for testing this series. Can you please confirm if this 
issue is observed in every run or only seen during the first run? Also 
please let me know on which platform this issue is observed?

Thanks,
Jagadeesh


> Here's the tree I tested with.
> 
> https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/linux-next-24-05-23-review?ref_type=heads
> 
> ---
> bod
> 

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 24/04/2024 10:45, Jagadeesh Kona wrote:
> 
> Thanks Bryan for testing this series. Can you please confirm if this 
> issue is observed in every run or only seen during the first run? Also 
> please let me know on which platform this issue is observed?
> 
> Thanks,
> Jagadeesh

rb5/sm8250

My observation was on a previous _boot_ the stuttering was worse. There 
is in the video capture three times that I count where the video halts 
briefly, I guess we need to vote or set an OPP so the firmware knows not 
to power-collapse quite so aggressively.

---
bod

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Konrad Dybcio]

On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>
>> Thanks Bryan for testing this series. Can you please confirm if this issue is observed in every run or only seen during the first run? Also please let me know on which platform this issue is observed?
>>
>> Thanks,
>> Jagadeesh
> 
> rb5/sm8250
> 
> My observation was on a previous _boot_ the stuttering was worse. There is in the video capture three times that I count where the video halts briefly, I guess we need to vote or set an OPP so the firmware knows not to power-collapse quite so aggressively.

We seem to be having some qualcomm-wide variance on perf/pwr usage on some
odd boots.. Any chance you could try like 5 times and see if it was a fluke?

Konrad

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 30/04/2024 21:01, Konrad Dybcio wrote:
> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>
>>> Thanks Bryan for testing this series. Can you please confirm if this issue is observed in every run or only seen during the first run? Also please let me know on which platform this issue is observed?
>>>
>>> Thanks,
>>> Jagadeesh
>>
>> rb5/sm8250
>>
>> My observation was on a previous _boot_ the stuttering was worse. There is in the video capture three times that I count where the video halts briefly, I guess we need to vote or set an OPP so the firmware knows not to power-collapse quite so aggressively.
> 
> We seem to be having some qualcomm-wide variance on perf/pwr usage on some
> odd boots.. Any chance you could try like 5 times and see if it was a fluke?
> 
> Konrad

Sure.

The first time I tried it, it was much worse.

The second time, captured in the video is only noticeable because I was 
*looking* for this specific error i.e. I don't think I would have 
noticed the error on the second run, had I not seen the first run.

I'll find some time to do 5x with and 5x without.

---
bod

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 01/05/2024 10:14, Bryan O'Donoghue wrote:
> On 30/04/2024 21:01, Konrad Dybcio wrote:
>> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>>
>>>> Thanks Bryan for testing this series. Can you please confirm if this 
>>>> issue is observed in every run or only seen during the first run? 
>>>> Also please let me know on which platform this issue is observed?
>>>>
>>>> Thanks,
>>>> Jagadeesh
>>>
>>> rb5/sm8250
>>>
>>> My observation was on a previous _boot_ the stuttering was worse. 
>>> There is in the video capture three times that I count where the 
>>> video halts briefly, I guess we need to vote or set an OPP so the 
>>> firmware knows not to power-collapse quite so aggressively.
>>
>> We seem to be having some qualcomm-wide variance on perf/pwr usage on 
>> some
>> odd boots.. Any chance you could try like 5 times and see if it was a 
>> fluke?
>>
>> Konrad
> 
> Sure.
> 
> The first time I tried it, it was much worse.
> 
> The second time, captured in the video is only noticeable because I was 
> *looking* for this specific error i.e. I don't think I would have 
> noticed the error on the second run, had I not seen the first run.
> 
> I'll find some time to do 5x with and 5x without.
> 
> ---
> bod

ping bod please remember to do this thanks

---
bod

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

On 5/10/2024 6:31 PM, Bryan O'Donoghue wrote:
> On 01/05/2024 10:14, Bryan O'Donoghue wrote:
>> On 30/04/2024 21:01, Konrad Dybcio wrote:
>>> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>>>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>>>
>>>>> Thanks Bryan for testing this series. Can you please confirm if 
>>>>> this issue is observed in every run or only seen during the first 
>>>>> run? Also please let me know on which platform this issue is observed?
>>>>>
>>>>> Thanks,
>>>>> Jagadeesh
>>>>
>>>> rb5/sm8250
>>>>
>>>> My observation was on a previous _boot_ the stuttering was worse. 
>>>> There is in the video capture three times that I count where the 
>>>> video halts briefly, I guess we need to vote or set an OPP so the 
>>>> firmware knows not to power-collapse quite so aggressively.
>>>
>>> We seem to be having some qualcomm-wide variance on perf/pwr usage on 
>>> some
>>> odd boots.. Any chance you could try like 5 times and see if it was a 
>>> fluke?
>>>
>>> Konrad
>>
>> Sure.
>>
>> The first time I tried it, it was much worse.
>>
>> The second time, captured in the video is only noticeable because I 
>> was *looking* for this specific error i.e. I don't think I would have 
>> noticed the error on the second run, had I not seen the first run.
>>
>> I'll find some time to do 5x with and 5x without.
>>
>> ---
>> bod
> 
> ping bod please remember to do this thanks
> 

Hi Bryan, Could you please let me know if you got a chance to check the 
above? Thank you!

Thanks,
Jagadeesh

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

On 5/31/2024 5:26 PM, Jagadeesh Kona wrote:
> 
> 
> On 5/10/2024 6:31 PM, Bryan O'Donoghue wrote:
>> On 01/05/2024 10:14, Bryan O'Donoghue wrote:
>>> On 30/04/2024 21:01, Konrad Dybcio wrote:
>>>> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>>>>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>>>>
>>>>>> Thanks Bryan for testing this series. Can you please confirm if 
>>>>>> this issue is observed in every run or only seen during the first 
>>>>>> run? Also please let me know on which platform this issue is 
>>>>>> observed?
>>>>>>
>>>>>> Thanks,
>>>>>> Jagadeesh
>>>>>
>>>>> rb5/sm8250
>>>>>
>>>>> My observation was on a previous _boot_ the stuttering was worse. 
>>>>> There is in the video capture three times that I count where the 
>>>>> video halts briefly, I guess we need to vote or set an OPP so the 
>>>>> firmware knows not to power-collapse quite so aggressively.
>>>>
>>>> We seem to be having some qualcomm-wide variance on perf/pwr usage 
>>>> on some
>>>> odd boots.. Any chance you could try like 5 times and see if it was 
>>>> a fluke?
>>>>
>>>> Konrad
>>>
>>> Sure.
>>>
>>> The first time I tried it, it was much worse.
>>>
>>> The second time, captured in the video is only noticeable because I 
>>> was *looking* for this specific error i.e. I don't think I would have 
>>> noticed the error on the second run, had I not seen the first run.
>>>
>>> I'll find some time to do 5x with and 5x without.
>>>
>>> ---
>>> bod
>>
>> ping bod please remember to do this thanks
>>
> 
> Hi Bryan, Could you please let me know if you got a chance to check the 
> above? Thank you!
> 

Hi Bryan, Kindly can you please help confirm if this is a real issue or 
observed as a fluke? so we can go ahead and mainline these changes.

Thanks,
Jagadeesh

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Bryan O'Donoghue]

On 17/06/2024 03:31, Jagadeesh Kona wrote:
> 
> 
> On 5/31/2024 5:26 PM, Jagadeesh Kona wrote:
>>
>>
>> On 5/10/2024 6:31 PM, Bryan O'Donoghue wrote:
>>> On 01/05/2024 10:14, Bryan O'Donoghue wrote:
>>>> On 30/04/2024 21:01, Konrad Dybcio wrote:
>>>>> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>>>>>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>>>>>
>>>>>>> Thanks Bryan for testing this series. Can you please confirm if 
>>>>>>> this issue is observed in every run or only seen during the first 
>>>>>>> run? Also please let me know on which platform this issue is 
>>>>>>> observed?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jagadeesh
>>>>>>
>>>>>> rb5/sm8250
>>>>>>
>>>>>> My observation was on a previous _boot_ the stuttering was worse. 
>>>>>> There is in the video capture three times that I count where the 
>>>>>> video halts briefly, I guess we need to vote or set an OPP so the 
>>>>>> firmware knows not to power-collapse quite so aggressively.
>>>>>
>>>>> We seem to be having some qualcomm-wide variance on perf/pwr usage 
>>>>> on some
>>>>> odd boots.. Any chance you could try like 5 times and see if it was 
>>>>> a fluke?
>>>>>
>>>>> Konrad
>>>>
>>>> Sure.
>>>>
>>>> The first time I tried it, it was much worse.
>>>>
>>>> The second time, captured in the video is only noticeable because I 
>>>> was *looking* for this specific error i.e. I don't think I would 
>>>> have noticed the error on the second run, had I not seen the first run.
>>>>
>>>> I'll find some time to do 5x with and 5x without.
>>>>
>>>> ---
>>>> bod
>>>
>>> ping bod please remember to do this thanks
>>>
>>
>> Hi Bryan, Could you please let me know if you got a chance to check 
>> the above? Thank you!
>>
> 
> Hi Bryan, Kindly can you please help confirm if this is a real issue or 
> observed as a fluke? so we can go ahead and mainline these changes.
> 
> Thanks,
> Jagadeesh

So I'm happier with this patchset when I run gstreamer instead of ffmpeg.

There doesn't appear to be a discernable difference between before/after 
on framerate or subjective UX with/without this set.

gst-launch-1.0 -vvv -e filesrc location=sample-5s.mp4 ! qtdemux ! 
parsebin ! v4l2h264dec ! autovideosink

Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

Re: [PATCH V5 RESEND 5/5] venus: pm_helpers: Use dev_pm_genpd_set_hwmode to switch GDSC mode on V6

[Jagadeesh Kona]

On 6/17/2024 3:21 PM, Bryan O'Donoghue wrote:
> On 17/06/2024 03:31, Jagadeesh Kona wrote:
>>
>>
>> On 5/31/2024 5:26 PM, Jagadeesh Kona wrote:
>>>
>>>
>>> On 5/10/2024 6:31 PM, Bryan O'Donoghue wrote:
>>>> On 01/05/2024 10:14, Bryan O'Donoghue wrote:
>>>>> On 30/04/2024 21:01, Konrad Dybcio wrote:
>>>>>> On 24.04.2024 11:50 AM, Bryan O'Donoghue wrote:
>>>>>>> On 24/04/2024 10:45, Jagadeesh Kona wrote:
>>>>>>>>
>>>>>>>> Thanks Bryan for testing this series. Can you please confirm if 
>>>>>>>> this issue is observed in every run or only seen during the 
>>>>>>>> first run? Also please let me know on which platform this issue 
>>>>>>>> is observed?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Jagadeesh
>>>>>>>
>>>>>>> rb5/sm8250
>>>>>>>
>>>>>>> My observation was on a previous _boot_ the stuttering was worse. 
>>>>>>> There is in the video capture three times that I count where the 
>>>>>>> video halts briefly, I guess we need to vote or set an OPP so the 
>>>>>>> firmware knows not to power-collapse quite so aggressively.
>>>>>>
>>>>>> We seem to be having some qualcomm-wide variance on perf/pwr usage 
>>>>>> on some
>>>>>> odd boots.. Any chance you could try like 5 times and see if it 
>>>>>> was a fluke?
>>>>>>
>>>>>> Konrad
>>>>>
>>>>> Sure.
>>>>>
>>>>> The first time I tried it, it was much worse.
>>>>>
>>>>> The second time, captured in the video is only noticeable because I 
>>>>> was *looking* for this specific error i.e. I don't think I would 
>>>>> have noticed the error on the second run, had I not seen the first 
>>>>> run.
>>>>>
>>>>> I'll find some time to do 5x with and 5x without.
>>>>>
>>>>> ---
>>>>> bod
>>>>
>>>> ping bod please remember to do this thanks
>>>>
>>>
>>> Hi Bryan, Could you please let me know if you got a chance to check 
>>> the above? Thank you!
>>>
>>
>> Hi Bryan, Kindly can you please help confirm if this is a real issue 
>> or observed as a fluke? so we can go ahead and mainline these changes.
>>
>> Thanks,
>> Jagadeesh
> 
> So I'm happier with this patchset when I run gstreamer instead of ffmpeg.
> 
> There doesn't appear to be a discernable difference between before/after 
> on framerate or subjective UX with/without this set.
> 
> gst-launch-1.0 -vvv -e filesrc location=sample-5s.mp4 ! qtdemux ! 
> parsebin ! v4l2h264dec ! autovideosink
> 
> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>

Thanks a lot Bryan for helping with the testing.

Thanks,
Jagadeesh