From: Imran Khan <kimran@codeaurora.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: andy.gross@linaro.org, lee.jones@linaro.org,
David Brown <david.brown@linaro.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-soc@vger.kernel.org
Subject: Re: [PATCH v6] soc: qcom: Add SoC info driver
Date: Wed, 21 Dec 2016 12:40:48 +0530 [thread overview]
Message-ID: <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org> (raw)
In-Reply-To: <20161220225007.GD5423@codeaurora.org>
On 12/21/2016 4:20 AM, Stephen Boyd wrote:
> On 12/18, Imran Khan wrote:
>>
>> I had discussed this with Bjorn and it was recommended to keep it out of
>> smem.h. If needed I can move it back there.
>
> Ok no worries from me then if this has already been discussed.
>
>>
>> Yes. The numbers used here can have different meaning for different ODMs.
>> But these attributes (hw_patform type/subtype etc.) are outside the
>> generic soc_device_attribute so I think the interpretation of these numbers
>> can very well be ODM specific. We can try to keep only those types here that
>> are relevant for newer platforms but we intend to keep these attributes
>> nonetheless.
>
> I'll wait to see what the next patch version has. We will
> probably need to have some way to know which ODM the kernel is
> running on, so we can interpret the platform type/subtype fields
> properly. That part seems to be lacking from this patch right
> now. We assume it's always qcom as the ODM, which isn't true.
>
Now I get this point. So far we don't have any mechanism in the driver that
gives ODM information. As far as generic soc_device_attribute's vendor field
is concerned we use Qualcomm since this will be true for SoC.
For hardware type and sub-types the various relevant values in SMEM are numeric
values and indeed it would be very difficult to estimate how some other ODM
will use the same number.
So for the h/w types and sub-types can we keep the numeric values rather than
showing strings as attribute values. We can leave the interpretation of these
values to ODM specific code.
Will wait for your feedback so that I can take care of it accordingly in the
next patch set.
Regards,
Imran
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2016-12-21 7:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-12 15:17 [PATCH v6] soc: qcom: Add SoC info driver Imran Khan
2016-12-13 19:17 ` Bjorn Andersson
2016-12-14 0:26 ` Stephen Boyd
2016-12-15 16:29 ` Imran Khan
2016-12-17 1:26 ` Stephen Boyd
2016-12-18 18:12 ` Imran Khan
2016-12-20 22:50 ` Stephen Boyd
2016-12-21 7:10 ` Imran Khan [this message]
2016-12-22 0:31 ` Stephen Boyd
2016-12-22 21:23 ` Imran Khan
2016-12-28 22:35 ` Stephen Boyd
2016-12-29 5:46 ` Imran Khan
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=1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org \
--to=kimran@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=david.brown@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@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).