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: Thu, 29 Dec 2016 11:16:50 +0530 [thread overview]
Message-ID: <dad1f0c2-eaec-28a0-47d3-eadc27b1c100@codeaurora.org> (raw)
In-Reply-To: <20161228223509.GA17126@codeaurora.org>
On 12/29/2016 4:05 AM, Stephen Boyd wrote:
> On 12/23, Imran Khan wrote:
>> On 12/22/2016 6:01 AM, Stephen Boyd wrote:
>>>
>>> Raw numbers sounds fine, but how do we know what ODM it is to
>>> understand how to parse the numbers appropriately? Perhaps the
>>> smem DT entry needs to have a property indicating the ODM that
>>> has configured these numbers, and then we can have an ODM sysfs
>>> node that we use to expose that string property to userspace?
>>>
>> Okay smem DT entry can be used to provide ODM information but even after
>> having this feature, I am not sure if we can provide a code in the driver
>> that will act for all ODMs because we don't know how other ODMs will interpret
>> platform types and subtypes numbers.
>> Or do you mean here that we should keep string values corresponding to different
>> platform type and subtype numbers in the smem DT entry itself. We will use
>> socinfo from smem to get the raw number and then translate that raw number to
>> a string, using the mapping given in DT itself.
>>
>
> I mean in DT
>
> smem {
> compatible = "qcom,smem";
> qcom,odm = "odm_name";
> }
>
> And then in the driver code we look for the qcom,odm property and
> make a sysfs attribute called odm or something that exposes the
> string "odm_name" to userspace. Then we have some userspace
> database of odm string and platform type/subtype numbers that we
> can use to figure out what those numbers mean.
>
Okay. This approach is fine for me. In the mean time I had tried
one alternative approach which I wanted to share. So in the smem DT
entry we have something like:
smem {
compatible = "qcom,smem";
..............................
..............................
smem,plat-type = "Unknown", "Surf", "FFA", "Fluid",
"SVLTE_FFA", "SVLTE_SURF", "Unknown",
"MDM_MTP_NO_DISPLAY", "MTP", "Liquid",
"Dragon", "QRD", "Unknown","HRD", "DTV";
smem,qrd-plat-subtype = "QRD", "SKUAA", "SKUF", "SKUAB",
"SKUG";
smem,plat-subtype = "Unknown", "charm", "strange",
"strange_2a";
};
And back in the qcom_soc_init, we read these lists as per the value(index) obtained
from smem:
if(socinfo->v0_1.format >= 6) {
/* Get platform type and subtype here */
type = socinfo->v0_6.hw_platform_subtype;
if(type >= 0 && plat_type) {
if (socinfo->v0_3.hw_platform == HW_PLATFORM_QRD) {
type_max = of_property_count_strings(
device->of_node,
"smem,qrd-plat-subtype");
if(type < type_max) {
of_property_read_string_index(
device->of_node,
"smem,qrd-plat-subtype",
type, &plat_type->sub_type);
}
} else {
type_max = of_property_count_strings(
device->of_node,
"smem,plat-subtype");
if(type < type_max) {
of_property_read_string_index(
device->of_node,
"smem,plat-subtype",
type, &plat_type->sub_type);
}
}
}
}
if (socinfo->v0_1.format >= 3) {
/* Get only platform type */
type = socinfo->v0_3.hw_platform;
type_max = of_property_count_strings(
device->of_node, "smem,plat-type");
if((type >= 0 && type < type_max) && plat_type) {
of_property_read_string_index(device->of_node,
"smem,plat-type", type,
&plat_type->type);
}
}
Could you please also provide your feedback about this approach? Just wanted to share
this before going ahead with final implementation.
Regards,
Imran
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a\nmember of the Code Aurora Forum, hosted by The Linux Foundation
prev parent reply other threads:[~2016-12-29 5:46 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
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 [this message]
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=dad1f0c2-eaec-28a0-47d3-eadc27b1c100@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).