Re: [PATCH V5 1/7] soc: qcom: geni: Support for ICC voting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/8/2020 10:43 PM, Matthias Kaehlcke wrote:
Hi Akash,

note: my comments below are clearly entering bikeshed territory. Please
take what you agree with and feel free to ignore the rest.

On Fri, May 08, 2020 at 12:03:33PM +0530, Akash Asthana wrote:
Add necessary macros and structure variables to support ICC BW
voting from individual SE drivers.

Signed-off-by: Akash Asthana <akashast@xxxxxxxxxxxxxx>
---
Changes in V2:
  - As per Bjorn's comment dropped enums for ICC paths, given the three
    paths individual members

Changes in V3:
  - Add geni_icc_get, geni_icc_vote_on and geni_icc_vote_off as helper API.
  - Add geni_icc_path structure in common header

Changes in V4:
  - As per Bjorn's comment print error message in geni_icc_get if return
    value is not -EPROBE_DEFER.
  - As per Bjorn's comment remove NULL on path before calling icc_set_bw
    API.
  - As per Bjorn's comment drop __func__ print.
  - As per Matthias's comment, make ICC path a array instead of individual
    member entry in geni_se struct.

Note: I have ignored below check patch suggestion because it was throwing
       compilation error as 'icc_ddr' is not compile time comstant.

WARNING: char * array declaration might be better as static const
  - FILE: drivers/soc/qcom/qcom-geni-se.c:726:
  - const char *icc_names[] = {"qup-core", "qup-config", icc_ddr};

Changes in V5:
  - As per Matthias's comment defined enums for ICC paths.
  - Integrate icc_enable/disable with power on/off call for driver.
  - As per Matthias's comment added icc_path_names array to print icc path name
    in failure case.
  - As per Georgi's suggestion assume peak_bw = avg_bw if not mentioned.

  drivers/soc/qcom/qcom-geni-se.c | 92 +++++++++++++++++++++++++++++++++++++++++
  include/linux/qcom-geni-se.h    | 42 +++++++++++++++++++
  2 files changed, 134 insertions(+)

diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index 7d622ea..63403bf 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -92,6 +92,9 @@ struct geni_wrapper {
  	struct clk_bulk_data ahb_clks[NUM_AHB_CLKS];
  };
+static const char * const icc_path_names[] = {"qup-core", "qup-config",
+								"qup-memory"};
nit: the indentation is a bit odd. I would align it either with "qup-core" or
at a tab stop nearby.
ok

+
  #define QUP_HW_VER_REG			0x4
/* Common SE registers */
@@ -720,6 +723,95 @@ void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t iova, size_t len)
  }
  EXPORT_SYMBOL(geni_se_rx_dma_unprep);
+int geni_icc_get(struct geni_se *se, const char *icc_ddr)
+{
+	int i, icc_err;
nit: the 'icc_' prefix doesn't add value here, just 'err' would be less
'noisy' IMO.
ok

+	const char *icc_names[] = {"qup-core", "qup-config", icc_ddr};
nit: you could avoid repeating the first to strings by referencing
icc_path_names[GENI_TO_CORE] and icc_path_names[CPU_TO_GENI]. Not sure
if it's really better, it avoids the redundant names, but is slightly
less readable.
I thought of that but current implementation looks neater to me.

+
+	for (i = 0; i < ARRAY_SIZE(se->icc_paths); i++) {
+		if (!icc_names[i])
+			continue;
+
+		se->icc_paths[i].path = devm_of_icc_get(se->dev, icc_names[i]);
+		if (IS_ERR(se->icc_paths[i].path))
+			goto icc_get_failure;
nit: since there is only a single label it isn't really necessary to be so
precise. 'goto err' is very common in the kernel, 'err_icc_get' would be
another alternative.
okay

+	}
+
+	return 0;
+
+icc_get_failure:
+	icc_err = PTR_ERR(se->icc_paths[i].path);
+	if (icc_err != -EPROBE_DEFER)
+		dev_err_ratelimited(se->dev, "Failed to get ICC path:%s, ret:%d\n",
All the logs in this patch result in something like "... path:qup-core, ret:42".
For humans I think it is more intuitive to parse "... path 'qup-core': 42".

ok

Thanks for review and feedback

Regards,

Akash


Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx>

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux