From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752171AbcL2Fq6 (ORCPT ); Thu, 29 Dec 2016 00:46:58 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:54550 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945AbcL2Fq4 (ORCPT ); Thu, 29 Dec 2016 00:46:56 -0500 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org BB9CE61223 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=kimran@codeaurora.org Subject: Re: [PATCH v6] soc: qcom: Add SoC info driver To: Stephen Boyd References: <1481555889-29380-1-git-send-email-kimran@codeaurora.org> <20161214002617.GS5423@codeaurora.org> <20161217012615.GV5423@codeaurora.org> <05cdb699-6406-cff8-cce6-fcedf6ac6c4e@codeaurora.org> <20161220225007.GD5423@codeaurora.org> <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org> <20161222003122.GY8288@codeaurora.org> <20161228223509.GA17126@codeaurora.org> Cc: andy.gross@linaro.org, lee.jones@linaro.org, David Brown , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org From: Imran Khan Message-ID: Date: Thu, 29 Dec 2016 11:16:50 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161228223509.GA17126@codeaurora.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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