pmdomain: qcom: rpmhpd: Skip retention level for Power Domainscommit ddab91f4b2de5c5b46e312a90107d9353087d8ea upstream.In the cases where the power domain connected to logics is allowed totransi
pmdomain: qcom: rpmhpd: Skip retention level for Power Domainscommit ddab91f4b2de5c5b46e312a90107d9353087d8ea upstream.In the cases where the power domain connected to logics is allowed totransition from a level(L)-->power collapse(0)-->retention(1) orvice versa retention(1)-->power collapse(0)-->level(L) will cause thelogic to lose the configurations. The ARC does not support retentionto collapse transition on MxC rails.The targets from SM8450 onwards the PLL logics of clock controllers areconnected to MxC rails and the recommended configurations are carriedout during the clock controller probes. The MxC transition as mentionedabove should be skipped to ensure the PLL settings are intact acrossclock controller power on & off.On older targets that do not split MX into MxA and MxC does not collapsethe logic and it is parked always at RETENTION, thus this issue is neverobserved on those targets.Cc: stable@vger.kernel.org # v5.17Reviewed-by: Bjorn Andersson <andersson@kernel.org>Signed-off-by: Taniya Das <quic_tdas@quicinc.com>Link: https://lore.kernel.org/r/20240625-avoid_mxc_retention-v2-1-af9c2f549a5f@quicinc.comSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl[ Upstream commit 883957bee580b723fd87d49ac73e0c84fc03a446 ]On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather ishandled by an externa
pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl[ Upstream commit 883957bee580b723fd87d49ac73e0c84fc03a446 ]On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather ishandled by an external regulator (max20411). Drop gfx.lvl from the listof power-domains exposed on this platform.Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-domains")Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>Acked-by: Ulf Hansson <ulf.hansson@linaro.org>Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>Link: https://lore.kernel.org/r/20240125-sa8295p-gpu-v4-4-7011c2a63037@quicinc.comSigned-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>Signed-off-by: Sasha Levin <sashal@kernel.org>
pmdomain: qcom: rpmhpd: Fix enabled_corner aggregationcommit 2a93c6cbd5a703d44c414a3c3945a87ce11430ba upstream.Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enablethe domain")
pmdomain: qcom: rpmhpd: Fix enabled_corner aggregationcommit 2a93c6cbd5a703d44c414a3c3945a87ce11430ba upstream.Commit 'e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enablethe domain")' aimed to make sure that a power-domain that is beingenabled without any particular performance-state requested will at leastturn the rail on, to avoid filling DeviceTree with otherwise unnecessaryrequired-opps properties.But in the event that aggregation happens on a disabled power-domain, withan enabled peer without performance-state, both the local and peercorner are 0. The peer's enabled_corner is not considered, with theresult that the underlying (shared) resource is disabled.One case where this can be observed is when the display stack keeps mmcxenabled (but without a particular performance-state vote) in order toaccess registers and sync_state happens in the rpmhpd driver. As mmcx_aois flushed the state of the peer (mmcx) is not considered and mmcx_aoends up turning off "mmcx.lvl" underneath mmcx. This has been observedseveral times, but has been painted over in DeviceTree by adding anexplicit vote for the lowest non-disabled performance-state.Fixes: e3e56c050ab6 ("soc: qcom: rpmhpd: Make power_on actually enable the domain")Reported-by: Johan Hovold <johan@kernel.org>Closes: https://lore.kernel.org/linux-arm-msm/ZdMwZa98L23mu3u6@hovoldconsulting.com/Cc: <stable@vger.kernel.org>Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>Reviewed-by: Stephen Boyd <swboyd@chromium.org>Tested-by: Johan Hovold <johan+linaro@kernel.org>Link: https://lore.kernel.org/r/20240226-rpmhpd-enable-corner-fix-v1-1-68c004cec48c@quicinc.comSigned-off-by: Ulf Hansson <ulf.hansson@linaro.org>Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pmdomain: Rename the genpd subsystem to pmdomainIt has been pointed out that naming a subsystem "genpd" isn't veryself-explanatory and the acronym itself that means Generic PM Domain, isknown onl
pmdomain: Rename the genpd subsystem to pmdomainIt has been pointed out that naming a subsystem "genpd" isn't veryself-explanatory and the acronym itself that means Generic PM Domain, isknown only by a limited group of people.In a way to improve the situation, let's rename the subsystem to pmdomain,which ideally should indicate that this is about so called Power Domains or"PM domains" as we often also use within the Linux Kernel terminology.Suggested-by: Rafael J. Wysocki <rafael@kernel.org>Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>Reviewed-by: Linus Walleij <linus.walleij@linaro.org>Acked-by: Arnd Bergmann <arnd@arndb.de>Acked-by: Heiko Stuebner <heiko@sntech.de>Acked-by: Rafael J. Wysocki <rafael@kernel.org>Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>Link: https://lore.kernel.org/r/20230912221127.487327-1-ulf.hansson@linaro.org