| Message ID | 1618574638-5117-3-git-send-email-sibis@codeaurora.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Use qmp_send to update co-processor load state | expand |
Quoting Sibi Sankar (2021-04-16 05:03:48) > The load state resources are expected to follow the life cycle of the > remote processor it tracks. However, modeling load state resources as > power-domains result in them getting turned off during system suspend > and thereby falling out of sync with the remote processors that are still > on. Fix this by replacing load state resource control through the generic > qmp message send interface instead. > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org> > --- Is it possible to keep this code around for a cycle so that there isn't the chance that someone is using the deprecated DT bindings with a new kernel? I worry that ripping the code out will cause them angst. Certainly we have to keep the code in place until DT is updated, so this patch should come last?
On 2021-04-18 07:31, Stephen Boyd wrote: > Quoting Sibi Sankar (2021-04-16 05:03:48) >> The load state resources are expected to follow the life cycle of the >> remote processor it tracks. However, modeling load state resources as >> power-domains result in them getting turned off during system suspend >> and thereby falling out of sync with the remote processors that are >> still >> on. Fix this by replacing load state resource control through the >> generic >> qmp message send interface instead. >> >> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> >> --- > > Is it possible to keep this code around for a cycle so that there isn't > the chance that someone is using the deprecated DT bindings with a new > kernel? I worry that ripping the code out will cause them angst. deprecated bindings with a newer kernel shouldn't cause any problems since it is the driver changes that make AOSS PD mandatory or not. So the newer kernel will just use qmp_send and leave the PD unused. > Certainly we have to keep the code in place until DT is updated, so > this > patch should come last? sure I don't mind, as long as it simplifies the merge process. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
On Tue 27 Apr 01:25 CDT 2021, Sibi Sankar wrote: > On 2021-04-18 07:31, Stephen Boyd wrote: > > Quoting Sibi Sankar (2021-04-16 05:03:48) > > > The load state resources are expected to follow the life cycle of the > > > remote processor it tracks. However, modeling load state resources as > > > power-domains result in them getting turned off during system suspend > > > and thereby falling out of sync with the remote processors that are > > > still > > > on. Fix this by replacing load state resource control through the > > > generic > > > qmp message send interface instead. > > > > > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org> > > > --- > > > > Is it possible to keep this code around for a cycle so that there isn't > > the chance that someone is using the deprecated DT bindings with a new > > kernel? I worry that ripping the code out will cause them angst. > > deprecated bindings with a newer kernel > shouldn't cause any problems since it is > the driver changes that make AOSS PD > mandatory or not. So the newer kernel will > just use qmp_send and leave the PD unused. > Maybe I'm missing something in your argument here, but I see two issues: * The changes here requires that the new qcom,qmp property is defined, or the qcom_qmp_get() will be unable to find the qmp instance. * Between patch 2 and 5 there's no load_state handling. Perhaps we can carry the power-domain handling as a fallback i qcom_qmp_get() fails, for a few releases? Other than the ordering and backwards compatibility issue I think this looks good. So can you please respin this based on the later revision of the qmp patch? (And fix Rob's request on the commit message) https://lore.kernel.org/linux-arm-msm/1620320818-2206-2-git-send-email-deesin@codeaurora.org/ Regards, Bjorn > > Certainly we have to keep the code in place until DT is updated, so this > > patch should come last? > > sure I don't mind, as long as it simplifies > the merge process. > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project.
On 2021-05-28 09:35, Bjorn Andersson wrote: > On Tue 27 Apr 01:25 CDT 2021, Sibi Sankar wrote: > >> On 2021-04-18 07:31, Stephen Boyd wrote: >> > Quoting Sibi Sankar (2021-04-16 05:03:48) >> > > The load state resources are expected to follow the life cycle of the >> > > remote processor it tracks. However, modeling load state resources as >> > > power-domains result in them getting turned off during system suspend >> > > and thereby falling out of sync with the remote processors that are >> > > still >> > > on. Fix this by replacing load state resource control through the >> > > generic >> > > qmp message send interface instead. >> > > >> > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org> >> > > --- >> > >> > Is it possible to keep this code around for a cycle so that there isn't >> > the chance that someone is using the deprecated DT bindings with a new >> > kernel? I worry that ripping the code out will cause them angst. >> >> deprecated bindings with a newer kernel >> shouldn't cause any problems since it is >> the driver changes that make AOSS PD >> mandatory or not. So the newer kernel will >> just use qmp_send and leave the PD unused. >> > > Maybe I'm missing something in your argument here, but I see two > issues: > * The changes here requires that the new qcom,qmp property is defined, > or the qcom_qmp_get() will be unable to find the qmp instance. > * Between patch 2 and 5 there's no load_state handling. > > Perhaps we can carry the power-domain handling as a fallback i > qcom_qmp_get() fails, for a few releases? The load_state implementation is currently broken i.e. it currently sends that the remoteproc is down during suspend. AFAIK it can be safely dropped without side-effects. I'll respin the series fixing Rob's comments. > > > Other than the ordering and backwards compatibility issue I think this > looks good. So can you please respin this based on the later revision > of > the qmp patch? (And fix Rob's request on the commit message) > > https://lore.kernel.org/linux-arm-msm/1620320818-2206-2-git-send-email-deesin@codeaurora.org/ > > Regards, > Bjorn > >> > Certainly we have to keep the code in place until DT is updated, so this >> > patch should come last? >> >> sure I don't mind, as long as it simplifies >> the merge process. >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> a Linux Foundation Collaborative Project. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c index 51b32f6d9bdb..f084ea9f6b66 100644 --- a/drivers/soc/qcom/qcom_aoss.c +++ b/drivers/soc/qcom/qcom_aoss.c @@ -2,7 +2,6 @@ /* * Copyright (c) 2019, Linaro Ltd */ -#include <dt-bindings/power/qcom-aoss-qmp.h> #include <linux/clk-provider.h> #include <linux/debugfs.h> #include <linux/interrupt.h> @@ -11,7 +10,6 @@ #include <linux/module.h> #include <linux/of_platform.h> #include <linux/platform_device.h> -#include <linux/pm_domain.h> #include <linux/thermal.h> #include <linux/slab.h> #include <linux/soc/qcom/qcom_aoss.h> @@ -68,7 +66,6 @@ struct qmp_cooling_device { * @event: wait_queue for synchronization with the IRQ * @tx_lock: provides synchronization between multiple callers of qmp_send() * @qdss_clk: QDSS clock hw struct - * @pd_data: genpd data * @cooling_devs: thermal cooling devices */ struct qmp { @@ -87,20 +84,12 @@ struct qmp { struct mutex tx_lock; struct clk_hw qdss_clk; - struct genpd_onecell_data pd_data; struct qmp_cooling_device *cooling_devs; #if IS_ENABLED(CONFIG_DEBUG_FS) struct dentry *debugfs_file; #endif /* CONFIG_DEBUG_FS */ }; -struct qmp_pd { - struct qmp *qmp; - struct generic_pm_domain pd; -}; - -#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd) - static void qmp_kick(struct qmp *qmp) { mbox_send_message(qmp->mbox_chan, NULL); @@ -329,95 +318,6 @@ static void qmp_qdss_clk_remove(struct qmp *qmp) clk_hw_unregister(&qmp->qdss_clk); } -static int qmp_pd_power_toggle(struct qmp_pd *res, bool enable) -{ - char buf[QMP_MSG_LEN] = {}; - - snprintf(buf, sizeof(buf), - "{class: image, res: load_state, name: %s, val: %s}", - res->pd.name, enable ? "on" : "off"); - return qmp_send(res->qmp, buf, sizeof(buf)); -} - -static int qmp_pd_power_on(struct generic_pm_domain *domain) -{ - return qmp_pd_power_toggle(to_qmp_pd_resource(domain), true); -} - -static int qmp_pd_power_off(struct generic_pm_domain *domain) -{ - return qmp_pd_power_toggle(to_qmp_pd_resource(domain), false); -} - -static const char * const sdm845_resources[] = { - [AOSS_QMP_LS_CDSP] = "cdsp", - [AOSS_QMP_LS_LPASS] = "adsp", - [AOSS_QMP_LS_MODEM] = "modem", - [AOSS_QMP_LS_SLPI] = "slpi", - [AOSS_QMP_LS_SPSS] = "spss", - [AOSS_QMP_LS_VENUS] = "venus", -}; - -static int qmp_pd_add(struct qmp *qmp) -{ - struct genpd_onecell_data *data = &qmp->pd_data; - struct device *dev = qmp->dev; - struct qmp_pd *res; - size_t num = ARRAY_SIZE(sdm845_resources); - int ret; - int i; - - res = devm_kcalloc(dev, num, sizeof(*res), GFP_KERNEL); - if (!res) - return -ENOMEM; - - data->domains = devm_kcalloc(dev, num, sizeof(*data->domains), - GFP_KERNEL); - if (!data->domains) - return -ENOMEM; - - for (i = 0; i < num; i++) { - res[i].qmp = qmp; - res[i].pd.name = sdm845_resources[i]; - res[i].pd.power_on = qmp_pd_power_on; - res[i].pd.power_off = qmp_pd_power_off; - - ret = pm_genpd_init(&res[i].pd, NULL, true); - if (ret < 0) { - dev_err(dev, "failed to init genpd\n"); - goto unroll_genpds; - } - - data->domains[i] = &res[i].pd; - } - - data->num_domains = i; - - ret = of_genpd_add_provider_onecell(dev->of_node, data); - if (ret < 0) - goto unroll_genpds; - - return 0; - -unroll_genpds: - for (i--; i >= 0; i--) - pm_genpd_remove(data->domains[i]); - - return ret; -} - -static void qmp_pd_remove(struct qmp *qmp) -{ - struct genpd_onecell_data *data = &qmp->pd_data; - struct device *dev = qmp->dev; - int i; - - of_genpd_del_provider(dev->of_node); - - for (i = 0; i < data->num_domains; i++) - pm_genpd_remove(data->domains[i]); -} - static int qmp_cdev_get_max_state(struct thermal_cooling_device *cdev, unsigned long *state) { @@ -636,13 +536,11 @@ static int qmp_probe(struct platform_device *pdev) if (ret) goto err_close_qmp; - ret = qmp_pd_add(qmp); - if (ret) - goto err_remove_qdss_clk; - ret = qmp_cooling_devices_register(qmp); - if (ret) + if (ret) { dev_err(&pdev->dev, "failed to register aoss cooling devices\n"); + goto err_remove_qdss_clk; + } platform_set_drvdata(pdev, qmp); @@ -674,7 +572,6 @@ static int qmp_remove(struct platform_device *pdev) #endif /* CONFIG_DEBUG_FS */ qmp_qdss_clk_remove(qmp); - qmp_pd_remove(qmp); qmp_cooling_devices_remove(qmp); qmp_close(qmp);
The load state resources are expected to follow the life cycle of the remote processor it tracks. However, modeling load state resources as power-domains result in them getting turned off during system suspend and thereby falling out of sync with the remote processors that are still on. Fix this by replacing load state resource control through the generic qmp message send interface instead. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> --- drivers/soc/qcom/qcom_aoss.c | 109 ++----------------------------------------- 1 file changed, 3 insertions(+), 106 deletions(-)