From: Jagadeesh Kona <[email protected]>
The current HW_CTRL flag switches the video GDSC to HW control mode as
part of GDSC enable itself, instead of that use HW_CTRL_TRIGGER flag to
give consumer drivers more control and switch the GDSC mode as and when
required.
HW_CTRL_TRIGGER flag allows consumer drivers to switch the video GDSC to
HW/SW control modes at runtime using dev_pm_genpd_set_hwmode API.
Signed-off-by: Jagadeesh Kona <[email protected]>
Signed-off-by: Abel Vesa <[email protected]>
---
drivers/clk/qcom/videocc-sc7180.c | 2 +-
drivers/clk/qcom/videocc-sc7280.c | 2 +-
drivers/clk/qcom/videocc-sdm845.c | 4 ++--
drivers/clk/qcom/videocc-sm8250.c | 4 ++--
drivers/clk/qcom/videocc-sm8550.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/qcom/videocc-sc7180.c b/drivers/clk/qcom/videocc-sc7180.c
index 5b9b54f616b8..51439f7ba70c 100644
--- a/drivers/clk/qcom/videocc-sc7180.c
+++ b/drivers/clk/qcom/videocc-sc7180.c
@@ -166,7 +166,7 @@ static struct gdsc vcodec0_gdsc = {
.pd = {
.name = "vcodec0_gdsc",
},
- .flags = HW_CTRL,
+ .flags = HW_CTRL_TRIGGER,
.pwrsts = PWRSTS_OFF_ON,
};
diff --git a/drivers/clk/qcom/videocc-sc7280.c b/drivers/clk/qcom/videocc-sc7280.c
index 615695d82319..3d07b1e95986 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-sdm845.c b/drivers/clk/qcom/videocc-sdm845.c
index c77a4dd5d39c..dad011c48973 100644
--- a/drivers/clk/qcom/videocc-sdm845.c
+++ b/drivers/clk/qcom/videocc-sdm845.c
@@ -260,7 +260,7 @@ static struct gdsc vcodec0_gdsc = {
},
.cxcs = (unsigned int []){ 0x890, 0x930 },
.cxc_count = 2,
- .flags = HW_CTRL | POLL_CFG_GDSCR,
+ .flags = HW_CTRL_TRIGGER | POLL_CFG_GDSCR,
.pwrsts = PWRSTS_OFF_ON,
};
@@ -271,7 +271,7 @@ static struct gdsc vcodec1_gdsc = {
},
.cxcs = (unsigned int []){ 0x8d0, 0x950 },
.cxc_count = 2,
- .flags = HW_CTRL | POLL_CFG_GDSCR,
+ .flags = HW_CTRL_TRIGGER | POLL_CFG_GDSCR,
.pwrsts = PWRSTS_OFF_ON,
};
diff --git a/drivers/clk/qcom/videocc-sm8250.c b/drivers/clk/qcom/videocc-sm8250.c
index ad46c4014a40..c1b73d852f1c 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,
};
diff --git a/drivers/clk/qcom/videocc-sm8550.c b/drivers/clk/qcom/videocc-sm8550.c
index f3c9dfaee968..404c6600edae 100644
--- a/drivers/clk/qcom/videocc-sm8550.c
+++ b/drivers/clk/qcom/videocc-sm8550.c
@@ -322,7 +322,7 @@ static struct gdsc video_cc_mvs0_gdsc = {
},
.pwrsts = PWRSTS_OFF_ON,
.parent = &video_cc_mvs0c_gdsc.pd,
- .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL,
+ .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
};
static struct gdsc video_cc_mvs1c_gdsc = {
@@ -347,7 +347,7 @@ static struct gdsc video_cc_mvs1_gdsc = {
},
.pwrsts = PWRSTS_OFF_ON,
.parent = &video_cc_mvs1c_gdsc.pd,
- .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL,
+ .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
};
static struct clk_regmap *video_cc_sm8550_clocks[] = {
--
2.34.1
On Wed, 1 Nov 2023 at 11:06, Abel Vesa <[email protected]> wrote:
>
> From: Jagadeesh Kona <[email protected]>
>
> The current HW_CTRL flag switches the video GDSC to HW control mode as
> part of GDSC enable itself, instead of that use HW_CTRL_TRIGGER flag to
> give consumer drivers more control and switch the GDSC mode as and when
> required.
>
> HW_CTRL_TRIGGER flag allows consumer drivers to switch the video GDSC to
> HW/SW control modes at runtime using dev_pm_genpd_set_hwmode API.
Will existing venus driver continue to work with this patch being applied?
>
> Signed-off-by: Jagadeesh Kona <[email protected]>
> Signed-off-by: Abel Vesa <[email protected]>
> ---
> drivers/clk/qcom/videocc-sc7180.c | 2 +-
> drivers/clk/qcom/videocc-sc7280.c | 2 +-
> drivers/clk/qcom/videocc-sdm845.c | 4 ++--
> drivers/clk/qcom/videocc-sm8250.c | 4 ++--
> drivers/clk/qcom/videocc-sm8550.c | 4 ++--
> 5 files changed, 8 insertions(+), 8 deletions(-)
--
With best wishes
Dmitry
On Wed, Nov 01, 2023 at 11:04:10AM +0200, Abel Vesa wrote:
> From: Jagadeesh Kona <[email protected]>
>
> The current HW_CTRL flag switches the video GDSC to HW control mode as
> part of GDSC enable itself, instead of that use HW_CTRL_TRIGGER flag to
> give consumer drivers more control and switch the GDSC mode as and when
> required.
>
> HW_CTRL_TRIGGER flag allows consumer drivers to switch the video GDSC to
> HW/SW control modes at runtime using dev_pm_genpd_set_hwmode API.
>
This states what the code currently does, and what the new code will do.
But I don't find that it adequately describes _why_ this is done.
In the current implementation, the hardware is might collapse the GDSC
anytime between gdsc_enable() and gdsc_disable(). By giving "drivers
more control" the time spent in this state is reduced to some fraction
of that span, which to me implies higher power consumption.
Under the assumption that we don't want to consume more power without
reason, I'm forced to guess that there might be some scenarios that we
want this feature to keep the GDSC non-collapsed against the indication
of the hardware - to avoid some instability somewhere, perhaps?
Regards,
Bjorn
> Signed-off-by: Jagadeesh Kona <[email protected]>
> Signed-off-by: Abel Vesa <[email protected]>
> ---
> drivers/clk/qcom/videocc-sc7180.c | 2 +-
> drivers/clk/qcom/videocc-sc7280.c | 2 +-
> drivers/clk/qcom/videocc-sdm845.c | 4 ++--
> drivers/clk/qcom/videocc-sm8250.c | 4 ++--
> drivers/clk/qcom/videocc-sm8550.c | 4 ++--
> 5 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/qcom/videocc-sc7180.c b/drivers/clk/qcom/videocc-sc7180.c
> index 5b9b54f616b8..51439f7ba70c 100644
> --- a/drivers/clk/qcom/videocc-sc7180.c
> +++ b/drivers/clk/qcom/videocc-sc7180.c
> @@ -166,7 +166,7 @@ static struct gdsc vcodec0_gdsc = {
> .pd = {
> .name = "vcodec0_gdsc",
> },
> - .flags = HW_CTRL,
> + .flags = HW_CTRL_TRIGGER,
> .pwrsts = PWRSTS_OFF_ON,
> };
>
> diff --git a/drivers/clk/qcom/videocc-sc7280.c b/drivers/clk/qcom/videocc-sc7280.c
> index 615695d82319..3d07b1e95986 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-sdm845.c b/drivers/clk/qcom/videocc-sdm845.c
> index c77a4dd5d39c..dad011c48973 100644
> --- a/drivers/clk/qcom/videocc-sdm845.c
> +++ b/drivers/clk/qcom/videocc-sdm845.c
> @@ -260,7 +260,7 @@ static struct gdsc vcodec0_gdsc = {
> },
> .cxcs = (unsigned int []){ 0x890, 0x930 },
> .cxc_count = 2,
> - .flags = HW_CTRL | POLL_CFG_GDSCR,
> + .flags = HW_CTRL_TRIGGER | POLL_CFG_GDSCR,
> .pwrsts = PWRSTS_OFF_ON,
> };
>
> @@ -271,7 +271,7 @@ static struct gdsc vcodec1_gdsc = {
> },
> .cxcs = (unsigned int []){ 0x8d0, 0x950 },
> .cxc_count = 2,
> - .flags = HW_CTRL | POLL_CFG_GDSCR,
> + .flags = HW_CTRL_TRIGGER | POLL_CFG_GDSCR,
> .pwrsts = PWRSTS_OFF_ON,
> };
>
> diff --git a/drivers/clk/qcom/videocc-sm8250.c b/drivers/clk/qcom/videocc-sm8250.c
> index ad46c4014a40..c1b73d852f1c 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,
> };
>
> diff --git a/drivers/clk/qcom/videocc-sm8550.c b/drivers/clk/qcom/videocc-sm8550.c
> index f3c9dfaee968..404c6600edae 100644
> --- a/drivers/clk/qcom/videocc-sm8550.c
> +++ b/drivers/clk/qcom/videocc-sm8550.c
> @@ -322,7 +322,7 @@ static struct gdsc video_cc_mvs0_gdsc = {
> },
> .pwrsts = PWRSTS_OFF_ON,
> .parent = &video_cc_mvs0c_gdsc.pd,
> - .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
> };
>
> static struct gdsc video_cc_mvs1c_gdsc = {
> @@ -347,7 +347,7 @@ static struct gdsc video_cc_mvs1_gdsc = {
> },
> .pwrsts = PWRSTS_OFF_ON,
> .parent = &video_cc_mvs1c_gdsc.pd,
> - .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
> };
>
> static struct clk_regmap *video_cc_sm8550_clocks[] = {
>
> --
> 2.34.1
>
On 11/10/2023 2:02 PM, Jagadeesh Kona wrote:
>
>
> On 11/4/2023 1:45 AM, Bjorn Andersson wrote:
>> On Wed, Nov 01, 2023 at 11:04:10AM +0200, Abel Vesa wrote:
>>> From: Jagadeesh Kona <[email protected]>
>>>
>>> The current HW_CTRL flag switches the video GDSC to HW control mode as
>>> part of GDSC enable itself, instead of that use HW_CTRL_TRIGGER flag to
>>> give consumer drivers more control and switch the GDSC mode as and when
>>> required.
>>>
>>> HW_CTRL_TRIGGER flag allows consumer drivers to switch the video GDSC to
>>> HW/SW control modes at runtime using dev_pm_genpd_set_hwmode API.
>>>
>>
>> This states what the code currently does, and what the new code will do.
>> But I don't find that it adequately describes _why_ this is done.
>>
>>
>> In the current implementation, the hardware is might collapse the GDSC
>> anytime between gdsc_enable() and gdsc_disable(). By giving "drivers
>> more control" the time spent in this state is reduced to some fraction
>> of that span, which to me implies higher power consumption.
>>
>> Under the assumption that we don't want to consume more power without
>> reason, I'm forced to guess that there might be some scenarios that we
>> want this feature to keep the GDSC non-collapsed against the indication
>> of the hardware - to avoid some instability somewhere, perhaps?
>>
>
> Thanks Bjorn for your review. Sure, will update commit text with details in next
> series.
>
> Normally, consumers will enable the GDSC and then the required clocks. If GDSC
> is moved to HW mode in gdsc_enable() itself, the subsequent clocks enablement
> that are dependent on GDSC might fail since GDSC could be turned off by HW. The
> consumers can still switch the GDSC to HW mode with new API right after the
> clocks are enabled and the control will be taken back to SW mode just before
> disabling the GDSC, so even with the newer implementation, HW can collapse the
> GDSC anytime for most of the duration between gdsc_enable() and gdsc_disable().
> This API adds more flexibility for consumer drivers to control the GDSC mode as
> per their
> requirements.
There is one more scenario where the driver would like GDSC in driver
controlled. Let say video hardware, which is under vcodec0_gdsc, have registers
to be programmed by TZ. In such scenario, the GDSC should be non collapsed,
while TZ programs those registers precisely while loading the firmware and
bringing hardware out of reset.
Regards,
Vikash