linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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