From: Stephen Boyd <sboyd@codeaurora.org>
To: Imran Khan <kimran@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 16:31:22 -0800 [thread overview]
Message-ID: <20161222003122.GY8288@codeaurora.org> (raw)
In-Reply-To: <1305f89c-2f9b-aa0b-4e22-951bf8af9344@codeaurora.org>
On 12/21, Imran Khan wrote:
> On 12/21/2016 4:20 AM, Stephen Boyd wrote:
> >
> > 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.
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?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2016-12-22 0:43 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 [this message]
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=20161222003122.GY8288@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=david.brown@linaro.org \
--cc=kimran@codeaurora.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 \
/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).