[2/4] media: venus: Use dev_pm_domain_attach|detach_list() for OPP PM domain
Commit Message
Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
and manage the device-link, let's avoid the boilerplate-code by converting
into dev_pm_domain_attach|detach_list.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/media/platform/qcom/venus/core.c | 8 ++---
drivers/media/platform/qcom/venus/core.h | 6 +---
.../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
3 files changed, 14 insertions(+), 31 deletions(-)
Comments
Hi Ulf,
Thank you for the patch!
On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
> Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
> and manage the device-link, let's avoid the boilerplate-code by converting
> into dev_pm_domain_attach|detach_list.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/media/platform/qcom/venus/core.c | 8 ++---
> drivers/media/platform/qcom/venus/core.h | 6 +---
> .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
> 3 files changed, 14 insertions(+), 31 deletions(-)
>
Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
I'll pick it through linux-media.
On Tue, 20 Aug 2024 at 22:48, Stanimir Varbanov
<stanimir.k.varbanov@gmail.com> wrote:
>
> Hi Ulf,
>
> Thank you for the patch!
>
> On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
> > Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
> > and manage the device-link, let's avoid the boilerplate-code by converting
> > into dev_pm_domain_attach|detach_list.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/media/platform/qcom/venus/core.c | 8 ++---
> > drivers/media/platform/qcom/venus/core.h | 6 +---
> > .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
> > 3 files changed, 14 insertions(+), 31 deletions(-)
> >
>
> Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
Thanks!
>
> I'll pick it through linux-media.
Please don't.
I should have stated that this depends on another series [1] - and
they need either to go together or we need to defer $subject patch
until the next release cycle.
Kind regards
Uffe
On Wed, 21 Aug 2024 at 10:56, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Tue, 20 Aug 2024 at 22:48, Stanimir Varbanov
> <stanimir.k.varbanov@gmail.com> wrote:
> >
> > Hi Ulf,
> >
> > Thank you for the patch!
> >
> > On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
> > > Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
> > > and manage the device-link, let's avoid the boilerplate-code by converting
> > > into dev_pm_domain_attach|detach_list.
> > >
> > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > ---
> > > drivers/media/platform/qcom/venus/core.c | 8 ++---
> > > drivers/media/platform/qcom/venus/core.h | 6 +---
> > > .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
> > > 3 files changed, 14 insertions(+), 31 deletions(-)
> > >
> >
> > Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
>
> Thanks!
>
> >
> > I'll pick it through linux-media.
>
> Please don't.
>
> I should have stated that this depends on another series [1] - and
> they need either to go together or we need to defer $subject patch
> until the next release cycle.
>
> Kind regards
> Uffe
Forgot the link, here it is:
[1]
https://lore.kernel.org/all/20240718234319.356451-1-ulf.hansson@linaro.org/
Hi Ulf,
On 21.08.24 г. 11:56 ч., Ulf Hansson wrote:
> On Tue, 20 Aug 2024 at 22:48, Stanimir Varbanov
> <stanimir.k.varbanov@gmail.com> wrote:
>>
>> Hi Ulf,
>>
>> Thank you for the patch!
>>
>> On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
>>> Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
>>> and manage the device-link, let's avoid the boilerplate-code by converting
>>> into dev_pm_domain_attach|detach_list.
>>>
>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> ---
>>> drivers/media/platform/qcom/venus/core.c | 8 ++---
>>> drivers/media/platform/qcom/venus/core.h | 6 +---
>>> .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
>>> 3 files changed, 14 insertions(+), 31 deletions(-)
>>>
>>
>> Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
>
> Thanks!
>
>>
>> I'll pick it through linux-media.
>
> Please don't.
>
> I should have stated that this depends on another series [1] - and
> they need either to go together or we need to defer $subject patch
> until the next release cycle.
Sure, then I guess we will deffer venus patch until the preparation
series is merged to avoid conflicts. Thank you!
>
> Kind regards
> Uffe
On Thu, 22 Aug 2024 at 20:05, Stanimir Varbanov
<stanimir.k.varbanov@gmail.com> wrote:
>
> Hi Ulf,
>
> On 21.08.24 г. 11:56 ч., Ulf Hansson wrote:
> > On Tue, 20 Aug 2024 at 22:48, Stanimir Varbanov
> > <stanimir.k.varbanov@gmail.com> wrote:
> >>
> >> Hi Ulf,
> >>
> >> Thank you for the patch!
> >>
> >> On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
> >>> Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
> >>> and manage the device-link, let's avoid the boilerplate-code by converting
> >>> into dev_pm_domain_attach|detach_list.
> >>>
> >>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> >>> ---
> >>> drivers/media/platform/qcom/venus/core.c | 8 ++---
> >>> drivers/media/platform/qcom/venus/core.h | 6 +---
> >>> .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
> >>> 3 files changed, 14 insertions(+), 31 deletions(-)
> >>>
> >>
> >> Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
> >
> > Thanks!
> >
> >>
> >> I'll pick it through linux-media.
> >
> > Please don't.
> >
> > I should have stated that this depends on another series [1] - and
> > they need either to go together or we need to defer $subject patch
> > until the next release cycle.
>
> Sure, then I guess we will deffer venus patch until the preparation
> series is merged to avoid conflicts. Thank you!
Assuming the preparation series gets accepted, maybe we can give it a
try via my pmdomain tree? Or do expect to land a lot of code that
could conflict?
I also realized that I already have a different series [1] queued in
my pmdomain tree from Dikshita Agarwal (reviewed by Bryan), that moves
an existing call for dev_pm_domain_attach() to the new
devm_pm_domain_attach() helper. So far I haven't received any reports
about conflicts from linux-next, so it looks good I think.
Kind regards
Uffe
[1]
https://lore.kernel.org/all/CAPDyKFqsHL3uatmLZaRzZ_GfkZw-+fURQNSEgvmrf-ini+WHng@mail.gmail.com/
Hi Ulf,
On 23.08.24 г. 0:40 ч., Ulf Hansson wrote:
> On Thu, 22 Aug 2024 at 20:05, Stanimir Varbanov
> <stanimir.k.varbanov@gmail.com> wrote:
>>
>> Hi Ulf,
>>
>> On 21.08.24 г. 11:56 ч., Ulf Hansson wrote:
>>> On Tue, 20 Aug 2024 at 22:48, Stanimir Varbanov
>>> <stanimir.k.varbanov@gmail.com> wrote:
>>>>
>>>> Hi Ulf,
>>>>
>>>> Thank you for the patch!
>>>>
>>>> On 23.07.24 г. 17:46 ч., Ulf Hansson wrote:
>>>>> Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
>>>>> and manage the device-link, let's avoid the boilerplate-code by converting
>>>>> into dev_pm_domain_attach|detach_list.
>>>>>
>>>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>>>>> ---
>>>>> drivers/media/platform/qcom/venus/core.c | 8 ++---
>>>>> drivers/media/platform/qcom/venus/core.h | 6 +---
>>>>> .../media/platform/qcom/venus/pm_helpers.c | 31 ++++++-------------
>>>>> 3 files changed, 14 insertions(+), 31 deletions(-)
>>>>>
>>>>
>>>> Acked-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com>
>>>
>>> Thanks!
>>>
>>>>
>>>> I'll pick it through linux-media.
>>>
>>> Please don't.
>>>
>>> I should have stated that this depends on another series [1] - and
>>> they need either to go together or we need to defer $subject patch
>>> until the next release cycle.
>>
>> Sure, then I guess we will deffer venus patch until the preparation
>> series is merged to avoid conflicts. Thank you!
>
> Assuming the preparation series gets accepted, maybe we can give it a
> try via my pmdomain tree? Or do expect to land a lot of code that
> could conflict?
Please take it via pmdomain tree. Thank you!
>
> I also realized that I already have a different series [1] queued in
> my pmdomain tree from Dikshita Agarwal (reviewed by Bryan), that moves
> an existing call for dev_pm_domain_attach() to the new
> devm_pm_domain_attach() helper. So far I haven't received any reports
> about conflicts from linux-next, so it looks good I think.
>
> Kind regards
> Uffe
>
> [1]
> https://lore.kernel.org/all/CAPDyKFqsHL3uatmLZaRzZ_GfkZw-+fURQNSEgvmrf-ini+WHng@mail.gmail.com/
@@ -709,7 +709,7 @@ static const struct venus_resources sdm845_res_v2 = {
.vcodec_clks_num = 2,
.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0", "vcodec1" },
.vcodec_pmdomains_num = 3,
- .opp_pmdomain = (const char *[]) { "cx", NULL },
+ .opp_pmdomain = (const char *[]) { "cx" },
.vcodec_num = 2,
.max_load = 3110400, /* 4096x2160@90 */
.hfi_version = HFI_VERSION_4XX,
@@ -758,7 +758,7 @@ static const struct venus_resources sc7180_res = {
.vcodec_clks_num = 2,
.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
.vcodec_pmdomains_num = 2,
- .opp_pmdomain = (const char *[]) { "cx", NULL },
+ .opp_pmdomain = (const char *[]) { "cx" },
.vcodec_num = 1,
.hfi_version = HFI_VERSION_4XX,
.vpu_version = VPU_VERSION_AR50,
@@ -815,7 +815,7 @@ static const struct venus_resources sm8250_res = {
.vcodec_clks_num = 1,
.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
.vcodec_pmdomains_num = 2,
- .opp_pmdomain = (const char *[]) { "mx", NULL },
+ .opp_pmdomain = (const char *[]) { "mx" },
.vcodec_num = 1,
.max_load = 7833600,
.hfi_version = HFI_VERSION_6XX,
@@ -874,7 +874,7 @@ static const struct venus_resources sc7280_res = {
.vcodec_clks_num = 2,
.vcodec_pmdomains = (const char *[]) { "venus", "vcodec0" },
.vcodec_pmdomains_num = 2,
- .opp_pmdomain = (const char *[]) { "cx", NULL },
+ .opp_pmdomain = (const char *[]) { "cx" },
.vcodec_num = 1,
.hfi_version = HFI_VERSION_6XX,
.vpu_version = VPU_VERSION_IRIS2_1,
@@ -132,9 +132,7 @@ struct venus_format {
* @vcodec1_clks: an array of vcodec1 struct clk pointers
* @video_path: an interconnect handle to video to/from memory path
* @cpucfg_path: an interconnect handle to cpu configuration path
- * @has_opp_table: does OPP table exist
* @pmdomains: a pointer to a list of pmdomains
- * @opp_dl_venus: an device-link for device OPP
* @opp_pmdomain: an OPP power-domain
* @resets: an array of reset signals
* @vdev_dec: a reference to video device structure for decoder instances
@@ -185,10 +183,8 @@ struct venus_core {
struct clk *vcodec1_clks[VIDC_VCODEC_CLKS_NUM_MAX];
struct icc_path *video_path;
struct icc_path *cpucfg_path;
- bool has_opp_table;
struct dev_pm_domain_list *pmdomains;
- struct device_link *opp_dl_venus;
- struct device *opp_pmdomain;
+ struct dev_pm_domain_list *opp_pmdomain;
struct reset_control *resets[VIDC_RESETS_NUM_MAX];
struct video_device *vdev_dec;
struct video_device *vdev_enc;
@@ -857,7 +857,6 @@ static int venc_power_v4(struct device *dev, int on)
static int vcodec_domains_get(struct venus_core *core)
{
int ret;
- struct device **opp_virt_dev;
struct device *dev = core->dev;
const struct venus_resources *res = core->res;
struct dev_pm_domain_attach_data vcodec_data = {
@@ -865,6 +864,11 @@ static int vcodec_domains_get(struct venus_core *core)
.num_pd_names = res->vcodec_pmdomains_num,
.pd_flags = PD_FLAG_NO_DEV_LINK,
};
+ struct dev_pm_domain_attach_data opp_pd_data = {
+ .pd_names = res->opp_pmdomain,
+ .num_pd_names = 1,
+ .pd_flags = PD_FLAG_DEV_LINK_ON,
+ };
if (!res->vcodec_pmdomains_num)
goto skip_pmdomains;
@@ -874,24 +878,14 @@ static int vcodec_domains_get(struct venus_core *core)
return ret;
skip_pmdomains:
- if (!core->res->opp_pmdomain)
+ if (!res->opp_pmdomain)
return 0;
/* Attach the power domain for setting performance state */
- ret = devm_pm_opp_attach_genpd(dev, res->opp_pmdomain, &opp_virt_dev);
+ ret = dev_pm_domain_attach_list(dev, &opp_pd_data, &core->opp_pmdomain);
if (ret)
goto opp_attach_err;
- core->opp_pmdomain = *opp_virt_dev;
- core->opp_dl_venus = device_link_add(dev, core->opp_pmdomain,
- DL_FLAG_RPM_ACTIVE |
- DL_FLAG_PM_RUNTIME |
- DL_FLAG_STATELESS);
- if (!core->opp_dl_venus) {
- ret = -ENODEV;
- goto opp_attach_err;
- }
-
return 0;
opp_attach_err:
@@ -902,12 +896,7 @@ static int vcodec_domains_get(struct venus_core *core)
static void vcodec_domains_put(struct venus_core *core)
{
dev_pm_domain_detach_list(core->pmdomains);
-
- if (!core->has_opp_table)
- return;
-
- if (core->opp_dl_venus)
- device_link_del(core->opp_dl_venus);
+ dev_pm_domain_detach_list(core->opp_pmdomain);
}
static int core_resets_reset(struct venus_core *core)
@@ -996,9 +985,7 @@ static int core_get_v4(struct venus_core *core)
if (core->res->opp_pmdomain) {
ret = devm_pm_opp_of_add_table(dev);
- if (!ret) {
- core->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(dev, "invalid OPP table in device tree\n");
return ret;
}