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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox