From: Stephen Boyd <sboyd@codeaurora.org>
To: Bjorn Andersson <bjorn@kryo.se>
Cc: Rob Herring <robherring2@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Stanimir Varbanov <svarbanov@mm-sol.com>,
Arnd Bergmann <arnd@arndb.de>,
Rob Herring <rob.herring@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Mark Brown <broonie@linaro.org>
Subject: Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
Date: Wed, 27 Aug 2014 14:55:45 -0700 [thread overview]
Message-ID: <53FE53E1.9030605@codeaurora.org> (raw)
In-Reply-To: <CAJAp7OhoRQ1eWack1e=OL0cS4Fxmgxc7OWeNxcj1qt7Q-x-sQA@mail.gmail.com>
On 08/27/14 11:24, Bjorn Andersson wrote:
> On Tue, Jul 29, 2014 at 11:06 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 07/29, Rob Herring wrote:
> [..]
>>> You might as well do of_property_read_u32 in the below example.
>>>
>> Fair enough. The example is probably too simple. Things are
>> sometimes slightly more complicated and a simple
>> of_property_read_u32() isn't going to work in the case of
>> multiple reg values or when reg-names is in play.
>>
> But do we have such cases in the Qualcomm PMICs?
At the least we have reg-names users.
>
> The only case I've hit so far is for gpios and mpps, where it feels
> like reg should be base, size and not simply base reg of first gpio -
> but that's a different thing.
>
> Also, so far it seems like most drivers just code the base address in
> the driver, as we have very specific compatibles.
It would be nice if the drivers didn't have to do this. It annoys me
that platform drivers need to know that they're using DT to figure out
things that are standard platform features: registers, irqs, etc.
>
>
> How about we stop trying so hard to make this "perfect" and just merge
> something close to Josh's original proposal and ignore this problem?
> Currently all we're doing is delaying any possibility of getting
> drivers for the individual blocks merged.
> If we have the dt bindings require the reg to be there, we can discuss
> and change this all we want later!
What's Josh's original proposal? We've already punted on this for SSBI
PMICs and just required them to put registers in DT for use some day and
I don't see anyone blocking individual SPMI pmic drivers from merging
over this. So I guess I agree with you that we can move forward with the
other drivers. I'd still like to see us make this better though, so it
seems worthwhile to have the discussion and get to some conclusion.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2014-08-27 21:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 11:42 use IORESOURCE_REG resource type for non-translatable addresses in DT Stanimir Varbanov
[not found] ` <53D788A7.4020303-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-07-29 12:00 ` Arnd Bergmann
2014-07-29 14:06 ` Stanimir Varbanov
2014-07-29 15:29 ` Rob Herring
2014-07-29 23:45 ` Grant Likely
2014-07-30 1:07 ` Stephen Boyd
2014-07-30 2:53 ` Rob Herring
[not found] ` <CAL_JsqJjH0OH+X=fzwqAPeWarjoLev7v6Nv_QhAa+nZyztMnFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-30 6:06 ` Stephen Boyd
2014-08-27 16:27 ` Stanimir Varbanov
2014-08-27 18:24 ` Bjorn Andersson
2014-08-27 21:55 ` Stephen Boyd [this message]
2014-08-29 4:09 ` Bjorn Andersson
2014-08-28 7:58 ` Stanimir Varbanov
2014-09-02 15:45 ` [PATCH] RFC: add function for localbus address Stanimir Varbanov
2014-09-05 23:29 ` Stephen Boyd
2014-09-08 14:52 ` Grant Likely
2014-09-08 20:22 ` Stephen Boyd
2014-09-08 21:21 ` Mark Brown
2014-09-14 4:46 ` Grant Likely
2014-10-22 23:01 ` Stephen Boyd
2014-10-22 23:20 ` Russell King - ARM Linux
2014-10-22 23:53 ` Stephen Boyd
2014-10-22 23:51 ` Mark Brown
2014-09-09 15:07 ` Stanimir Varbanov
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=53FE53E1.9030605@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=arnd@arndb.de \
--cc=bjorn@kryo.se \
--cc=broonie@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@linaro.org \
--cc=robherring2@gmail.com \
--cc=svarbanov@mm-sol.com \
/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).