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 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.