Message ID | 20240822224547.385095-1-ulf.hansson@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | OPP/pmdomain: Assign required_devs for required OPPs through genpd | expand |
On 23-08-24, 00:45, Ulf Hansson wrote: > Changes in v3: > - Combine the two series [1] and [2] into one. > - A few minor changes to consumer drivers. > - Clarification in commit messages. > > Through dev_pm_opp_set_config() the _opp_attach_genpd() allows consumer > drivers to attach a device to its PM domains. Their corresponding virtual > devices that are created by genpd during attach, are later being assigned > as the required_devs for the corresponding required OPPs. In principle, > using dev_pm_opp_set_config() for this works fine. > > However, attaching a device to its PM domains is in general better done > with dev_pm_domain_attach|detach_list(). To avoid having two different ways > to manage this, this series prepare for the removal of _opp_attach_genpd(). > > Moreover, it converts the few existing users of the _opp_attach_genpd() into > dev|devm__pm_domain_attach(), allowing the final patch to drop the redundant > code that becomes redundant. > > To test this, I have used a QEMU setup, with local PM test-drivers to try to > test all various combinations of single/multi power/performance PM domains for > a device. Hopefully I have covered it all, but I would certainly appreciate if > someone could help to run a slew of tests on some HWs. > > Note, due to dependencies I think this whole series is best funneled together > through my pmdomain tree. If you think there may be issues with this approach, > please let me know so we can figure out the best merging strategy. > > Kind regards > Ulf Hansson > > [1] > https://lore.kernel.org/all/20240718234319.356451-1-ulf.hansson@linaro.org/ > [2] > https://lore.kernel.org/all/20240723144610.564273-1-ulf.hansson@linaro.org/ > > > Ulf Hansson (10): > OPP: Fix support for required OPPs for multiple PM domains > OPP: Rework _set_required_devs() to manage a single device per call > pmdomain: core: Manage the default required OPP from a separate > function > OPP/pmdomain: Set the required_dev for a required OPP during genpd > attach > pmdomain: core: Drop the redundant dev_to_genpd_dev() > OPP: Drop redundant code in _link_required_opps() > drm/tegra: gr3d: Convert into devm_pm_domain_attach_list() > media: venus: Convert into devm_pm_domain_attach_list() for OPP PM > domain > cpufreq: qcom-nvmem: Convert to dev_pm_domain_attach|detach_list() > OPP: Drop redundant _opp_attach|detach_genpd() Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
On Fri, 23 Aug 2024 at 00:46, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > Changes in v3: > - Combine the two series [1] and [2] into one. > - A few minor changes to consumer drivers. > - Clarification in commit messages. > > Through dev_pm_opp_set_config() the _opp_attach_genpd() allows consumer > drivers to attach a device to its PM domains. Their corresponding virtual > devices that are created by genpd during attach, are later being assigned > as the required_devs for the corresponding required OPPs. In principle, > using dev_pm_opp_set_config() for this works fine. > > However, attaching a device to its PM domains is in general better done > with dev_pm_domain_attach|detach_list(). To avoid having two different ways > to manage this, this series prepare for the removal of _opp_attach_genpd(). > > Moreover, it converts the few existing users of the _opp_attach_genpd() into > dev|devm__pm_domain_attach(), allowing the final patch to drop the redundant > code that becomes redundant. > > To test this, I have used a QEMU setup, with local PM test-drivers to try to > test all various combinations of single/multi power/performance PM domains for > a device. Hopefully I have covered it all, but I would certainly appreciate if > someone could help to run a slew of tests on some HWs. > > Note, due to dependencies I think this whole series is best funneled together > through my pmdomain tree. If you think there may be issues with this approach, > please let me know so we can figure out the best merging strategy. > > Kind regards > Ulf Hansson FYI This series has been cooking in linux-next via my pmdomain tree for a while - and lately we have received some bug reports. Rather than rushing to fix the issues on top, because the merge window is getting closer, I decided that it was better to drop the whole series from my next branch for now. I will continue to work on a new version of the series and post it as soon as I can.. [...] Kind regards Uffe