From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: "Dwivedi, Avaneesh Kumar (avani)" <akdwived@codeaurora.org>
Cc: sboyd@codeaurora.org, agross@codeaurora.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [RESEND PATCH v4 1/7] remoteproc: qcom: Add and initialize private data for hexagon dsp.
Date: Fri, 9 Dec 2016 11:32:45 -0800 [thread overview]
Message-ID: <20161209193245.GZ30492@tuxbot> (raw)
In-Reply-To: <ce526527-b79f-263a-6695-1d3d81ddad5f@codeaurora.org>
On Fri 09 Dec 03:42 PST 2016, Dwivedi, Avaneesh Kumar (avani) wrote:
> >So in this first patch I would suggest that you add the msm8974 and
> >msm8916 compatibles, a res-struct containing only hexagon_mba_image and
> >the change from patch 2 where you change rproc_alloc() to use the
> >hexagon_mba_image.
> ok. so i am going to add additional compatible string while also keeping
> existing compatible as below.
Yes, we need to keep the qcom,q6v5-pil and your change below looks to
get it right.
> Also compatible string i have changed but is it OK to keep
> resource instance named as "qdsp6v5_5_0_0_res" as below?
>
Please update their naming based on the platform name as well, it will
cause less confusion in the future.
> +static const struct rproc_hexagon_res qdsp6v5_5_0_0_res = {
> + .hexagon_mba_image = "mba.mbn",
> +};
A single empty line between each struct makes things easier to read.
> +static const struct rproc_hexagon_res qdsp6v5_5_1_1_res = {
> + .hexagon_mba_image = "mba.b00",
> +};
> static const struct of_device_id q6v5_of_match[] = {
> - { .compatible = "qcom,q6v5-pil", },
> + { .compatible = "qcom,q6v5-pil", .data = &qdsp6v5_5_0_0_res},
> + { .compatible = "qcom,msm8916-mss-pil", .data = &qdsp6v5_5_0_0_res},
> + { .compatible = "qcom,msm8974-mss-pil", .data = &qdsp6v5_5_1_1_res},
> { },
> };
[..]
> >As far as I can see these numbers are 1:1 with specific platforms, which
> >we use as part of other bindings. So I think we should follow the naming
> >scheme we use for e.g. the ADSP PIL.
> In very few cases same hexagon chip is used in more than one msm platform
> i.e. one-to-many
> example q6v56 1.8 is used on msm8952 as well as on msm8940, but generally
> it is one to one mapping with msm platform.
Okay, thanks for the summary.
In these rare cases we can have two compatibles referencing the same
struct.
> >
> >And let's replace the q6v5 part with "mss", as e.g. msm8974 adsp also is
> >a "q6v5".
> >
> >So please add:
> >"qcom,msm8916-mss-pil",
> >"qcom,msm8974-mss-pil",
> >"qcom,msm8996-mss-pil"
> OK.
> >
> >The compatible "qcom,q6v5-pil" is already introduced in the
> >msm8916.dtsi, so make that compatible be equivalent to
> >"qcom,msm8916-mss-pil" (but let's have both for clarity).
> so i will keep "qcom,msm8916-mss-pil" as well as "qcom,q6v5-pil" both in
> code.
Sound good.
Regards,
Bjorn
next prev parent reply other threads:[~2016-12-09 19:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-24 10:00 [RESEND PATCH v4 0/7]remoteproc: qcom: Add support to hexagon v56 1.5.0 in qcom hexagon rproc driver Avaneesh Kumar Dwivedi
2016-11-24 10:00 ` [RESEND PATCH v4 1/7] remoteproc: qcom: Add and initialize private data for hexagon dsp Avaneesh Kumar Dwivedi
2016-12-08 21:37 ` Bjorn Andersson
2016-12-09 11:42 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-09 19:32 ` Bjorn Andersson [this message]
2016-11-24 10:00 ` [RESEND PATCH v4 2/7] remoteproc: qcom: Initialize proxy and active clock's and regulator's Avaneesh Kumar Dwivedi
2016-12-09 2:36 ` Bjorn Andersson
2016-12-09 15:53 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 3/7] remoteproc: qcom: Modify regulator enable and disable interface Avaneesh Kumar Dwivedi
2016-12-09 2:44 ` Bjorn Andersson
2016-12-12 8:21 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 4/7] remoteproc: qcom: Modify clock enable and disable routine Avaneesh Kumar Dwivedi
2016-12-09 2:57 ` Bjorn Andersson
2016-12-12 8:23 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 5/7] remoteproc: qcom: Modify reset sequence for hexagon to support v56 1.5.0 Avaneesh Kumar Dwivedi
2016-12-09 4:35 ` Bjorn Andersson
2016-12-12 12:45 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-13 18:09 ` Bjorn Andersson
2016-12-13 19:45 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-13 22:07 ` Bjorn Andersson
2016-12-14 15:50 ` Dwivedi, Avaneesh Kumar (avani)
2016-12-14 20:13 ` Bjorn Andersson
2016-11-24 10:00 ` [RESEND PATCH v4 6/7] remoteproc: qcom: Modify stop routine to limit MX current for v56 1.5 Avaneesh Kumar Dwivedi
2016-12-09 4:42 ` Bjorn Andersson
2016-12-12 13:04 ` Dwivedi, Avaneesh Kumar (avani)
2016-11-24 10:00 ` [RESEND PATCH v4 7/7] clk: qcom: Add GCC_MSS_RESET support to reset MSS in v56 1.5.0 Avaneesh Kumar Dwivedi
2016-12-08 19:51 ` Bjorn Andersson
2016-12-12 13:05 ` 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=20161209193245.GZ30492@tuxbot \
--to=bjorn.andersson@linaro.org \
--cc=agross@codeaurora.org \
--cc=akdwived@codeaurora.org \
--cc=linux-arm-msm@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;
as well as URLs for NNTP newsgroup(s).