[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200604170906.GP4525@google.com>
Date: Thu, 4 Jun 2020 10:09:06 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: Pradeep P V K <ppvk@...eaurora.org>
Cc: bjorn.andersson@...aro.org, adrian.hunter@...el.com,
robh+dt@...nel.org, ulf.hansson@...aro.org,
vbadigan@...eaurora.org, sboyd@...nel.org,
georgi.djakov@...aro.org, linux-mmc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-mmc-owner@...r.kernel.org,
rnayak@...eaurora.org, sibis@...eaurora.org, matthias@...omium.org
Subject: Re: [PATCH V2 1/2] mmc: sdhci-msm: Add interconnect bandwidth
scaling support
On Thu, Jun 04, 2020 at 04:44:42PM +0530, Pradeep P V K wrote:
> Interconnect bandwidth scaling support is now added as a
> part of OPP [1]. So, make sure interconnect driver is ready
> before handling interconnect scaling.
>
> This change is based on
> [1] [Patch v8] Introduce OPP bandwidth bindings
> (https://lkml.org/lkml/2020/5/12/493)
>
> [2] [Patch v3] mmc: sdhci-msm: Fix error handling
> for dev_pm_opp_of_add_table()
> (https://lkml.org/lkml/2020/5/5/491)
>
> Signed-off-by: Pradeep P V K <ppvk@...eaurora.org>
> ---
> drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index b277dd7..a13ff1b 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -14,6 +14,7 @@
> #include <linux/slab.h>
> #include <linux/iopoll.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/interconnect.h>
>
> #include "sdhci-pltfm.h"
> #include "cqhci.h"
> @@ -2070,6 +2071,18 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> }
> msm_host->bulk_clks[0].clk = clk;
>
> + /* Make sure that ICC driver is ready for interconnect bandwdith
> + * scaling before registering the device for OPP.
> + */
> + ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
> + if (ret) {
> + if (ret == -EPROBE_DEFER)
> + dev_info(&pdev->dev, "defer icc path: %d\n", ret);
I already commented on this on v1:
This log seems to add little more than noise, or are there particular reasons
why it is useful in this driver? Most drivers just return silently in case of
deferred probing.
If you think the log is really needed please explain why.
Powered by blists - more mailing lists