Message ID | 20240723144610.564273-3-ulf.hansson@linaro.org (mailing list archive) |
---|---|
State | New |
Delegated to: | viresh kumar |
Headers | show |
Series | OPP: Re-work code to drop _opp_attach|detach_genpd() | expand |
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/
diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index ce206b709754..a422bbb3b610 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -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, diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h index 6a77de374454..aec587e6294f 100644 --- a/drivers/media/platform/qcom/venus/core.h +++ b/drivers/media/platform/qcom/venus/core.h @@ -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; diff --git a/drivers/media/platform/qcom/venus/pm_helpers.c b/drivers/media/platform/qcom/venus/pm_helpers.c index 502822059498..e133683871aa 100644 --- a/drivers/media/platform/qcom/venus/pm_helpers.c +++ b/drivers/media/platform/qcom/venus/pm_helpers.c @@ -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; }
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(-)