All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>
Cc: sboyd@codeaurora.org, agross@codeaurora.org,
	linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org
Subject: Re: [RFC PATCH v2 1/3] remoteproc: qcom: make adsp resource handling generic.
Date: Fri, 20 Jan 2017 10:38:26 -0800	[thread overview]
Message-ID: <20170120183826.GA10531@minitux> (raw)
In-Reply-To: <1484928636-27351-2-git-send-email-akdwived@codeaurora.org>

On Fri 20 Jan 08:10 PST 2017, Avaneesh Kumar Dwivedi wrote:

> This patch make resource handling generic in adsp remoteproc driver.
> Resources which were initialized with hard definition are being
> initialized now based on compatible string. Generic way of resource
> initialization and handling is required so that slpi processor boot
> support can also be enabled with same driver.
> 

I think adding a "generic way of resource initialization and handling"
is overkill for this driver, at this point in time at least.

> Signed-off-by: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org>
> ---
>  drivers/remoteproc/qcom_adsp_pil.c | 259 +++++++++++++++++++++++++++++--------
>  1 file changed, 208 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_adsp_pil.c b/drivers/remoteproc/qcom_adsp_pil.c
> index 43a4ed2..ab2632b 100644
> --- a/drivers/remoteproc/qcom_adsp_pil.c
> +++ b/drivers/remoteproc/qcom_adsp_pil.c
> @@ -32,9 +32,26 @@
>  #include "qcom_mdt_loader.h"
>  #include "remoteproc_internal.h"
>  
> -#define ADSP_CRASH_REASON_SMEM		423
> -#define ADSP_FIRMWARE_NAME		"adsp.mdt"
> -#define ADSP_PAS_ID			1
> +struct reg_info {
> +	struct regulator *reg;
> +	int uV;
> +	int uA;
> +};
> +
> +struct regulator_res {
> +	const char *supply;
> +	int uV;
> +	int uA;
> +};

As far as I can see we have 2 variables:

1) Do we have px-supply?

We could just always devm_regualator_get("px"), in the adsp case this
would give us a dummy regulator that we can still
regulator_enable/disable. So we can keep the code unconditional.

If we want to save the reader of the kernel log a printout about a dummy
voltage we can carry a "bool has_px" in the adsp_data.

The mechanism for controlling corner voltages will be something other
than the regulator api, so let's not design the driver for
voltage/current selection yet.

2) Do we have aggre2_noc clock?

This info we can carry with a bool in the data struct, making the
devm_clk_get("aggre2") depend on this or leave the clk NULL - also
calling this unconditionally.

> +
> +struct generic_rproc_res {

Please name this "adsp_data".

> +	int crash_reason_smem;
> +	const char *firmware_name;
> +	int fw_pas_id;

"pas_id" is enough.

> +	struct regulator_res reg_res[3];
> +	char **clocks_name;
> +};
> +
>  
>  struct qcom_adsp {
>  	struct device *dev;
> @@ -49,9 +66,13 @@ struct qcom_adsp {
>  	struct qcom_smem_state *state;
>  	unsigned stop_bit;
>  
> -	struct clk *xo;
> +	struct clk *clocks[3];
> +	int clk_count;
> +	struct reg_info regulators[3];
> +	int reg_count;
>  
> -	struct regulator *cx_supply;
> +	int fw_pas_id;

"pas_id"

> +	int crash_reason_smem;
>  
>  	struct completion start_done;
>  	struct completion stop_done;
> @@ -62,6 +83,136 @@ struct qcom_adsp {
>  	size_t mem_size;
>  };
>  
[..]
>  
> -static int adsp_init_clock(struct qcom_adsp *adsp)
> -{
> -	int ret;
> -
> -	adsp->xo = devm_clk_get(adsp->dev, "xo");
> -	if (IS_ERR(adsp->xo)) {
> -		ret = PTR_ERR(adsp->xo);
> -		if (ret != -EPROBE_DEFER)
> -			dev_err(adsp->dev, "failed to get xo clock");
> -		return ret;
> -	}
> -

Just do:
	if (adsp->has_aggre2_clk) {
		adsp->aggre2_clk = devm_clk_get(..);
		...
	}

> -	return 0;
> -}
> -
> -static int adsp_init_regulator(struct qcom_adsp *adsp)
> -{
> -	adsp->cx_supply = devm_regulator_get(adsp->dev, "cx");
> -	if (IS_ERR(adsp->cx_supply))
> -		return PTR_ERR(adsp->cx_supply);
> -
> -	regulator_set_load(adsp->cx_supply, 100000);

If you just request "px" unconditionally here we will get a print in the
log informing us that we got a dummy regulator. If we want to be fancy
and not have that you can do a boolean.

> -
> -	return 0;
> -}
> -
[..]
>  
> +static const struct generic_rproc_res adsp_resource_init = {
> +		.crash_reason_smem = 423,
> +		.firmware_name = "adsp.mdt",
> +		.fw_pas_id = 1,
> +		.reg_res = (struct regulator_res[]) {
> +			{
> +				.supply = "vdd_cx",
> +			},
> +			{},
> +			{}
> +		},
> +		.clocks_name = (char*[]){
> +			"xo",
> +			NULL
> +		},
> +};

Please leave this a empty line between these.

>  static const struct of_device_id adsp_of_match[] = {
> -	{ .compatible = "qcom,msm8974-adsp-pil" },
> -	{ .compatible = "qcom,msm8996-adsp-pil" },
> +	{ .compatible = "qcom,msm8974-adsp-pil", .data = &adsp_resource_init},
> +	{ .compatible = "qcom,msm8996-adsp-pil", .data = &adsp_resource_init},
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(of, adsp_of_match);

Regards,
Bjorn

  reply	other threads:[~2017-01-20 18:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-20 16:10 [RFC PATCH v2 0/3] remoteproc: qcom: Introduce Qualcomm low pass sensor peripheral loader Avaneesh Kumar Dwivedi
2017-01-20 16:10 ` [RFC PATCH v2 1/3] remoteproc: qcom: make adsp resource handling generic Avaneesh Kumar Dwivedi
2017-01-20 18:38   ` Bjorn Andersson [this message]
2017-01-24 11:42     ` Dwivedi, Avaneesh Kumar (avani)
2017-01-20 16:10 ` [RFC PATCH v2 2/3] remoteproc: qcom: Add slpi boot support in adsp rproc driver Avaneesh Kumar Dwivedi
2017-01-20 16:10 ` [RFC PATCH v2 3/3] arm64: dts: msm8996: Add SLPI SMP2P dt node Avaneesh Kumar Dwivedi
2017-01-20 18:15   ` Bjorn Andersson
2017-01-24 12:13     ` Dwivedi, Avaneesh Kumar (avani)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170120183826.GA10531@minitux \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@codeaurora.org \
    --cc=akdwived@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.