lkml.org 
[lkml]   [2016]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6] soc: qcom: Add SoC info driver
From
Date
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

\
 
 \ /
  Last update: 2016-12-29 06:48    [W:0.070 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site