devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Hanumant Singh <hanumant@codeaurora.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Bjorn Andersson <Bjorn.Andersson@sonymobile.com>,
	"Bird, Tim" <Tim.Bird@sonymobile.com>,
	ext Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
Date: Tue, 30 Jul 2013 21:59:40 -0600	[thread overview]
Message-ID: <51F88BAC.2020001@wwwdotorg.org> (raw)
In-Reply-To: <51F85690.9060701@codeaurora.org>

On 07/30/2013 06:13 PM, Hanumant Singh wrote:
> On 7/30/2013 5:08 PM, Stephen Warren wrote:
>> On 07/30/2013 06:01 PM, Hanumant Singh wrote:
>>> On 7/30/2013 2:22 PM, Stephen Warren wrote:
>>>> On 07/30/2013 03:10 PM, hanumant wrote:
>>>> ...
>>>>> We actually have the same TLMM pinmux used by several socs of a
>>>>> family.
>>>>> The number of pins on each soc may vary.
>>>>> Also a given soc gets used in a number of boards.
>>>>> The device tree for a given soc is split into the different boards
>>>>> that
>>>>> its in ie the boards inherit a common soc.dtsi but have separate dts.
>>>>> The boards for the same soc may use different pin groups for
>>>>> accomplishing a function, since we have multiple i2c, spi uart etc
>>>>> peripheral instances on a soc. A different instance of each of the
>>>>> above
>>>>> peripherals, can be used in different boards, utilizing different
>>>>> or subset of same pin groups.
>>>>> Thus I would need to have multiple C files for one soc, based on the
>>>>> boards that it goes into.
>>>>
>>>> The pinctrl driver should be exposing the raw capabilities of the HW.
>>>> All the board-specific configuration should be expressed in DT. So, the
>>>> driver shouldn't have to know anything about different boards at
>>>> compile-time.
>>>>
>>> I agree, so I wanted to keep the pin grouping information in DT, we
>>> already have a board based differentiation of dts files in DT, for the
>>> same soc.
>>
>> That's the opposite of what I was saying. Pin groups are a feature of
>> the SoC design, not the board.
>>
> Sorry I guess I wasn't clear.
> Right now I have a soc-pinctrl.dtsi containing pin groupings.
> This will be "inherited" by soc-boardtype.dts.
> The pinctrl client device nodes in soc-boardtype.dts will point to pin
> groupings in soc-pinctrl.dtsi that are valid for that particular boardtype.
> Is this a valid design?

OK, so you have two types of child node inside the pinctrl DT node; some
define the pin groups the SoC has (in soc.dtsi) and some define pinctrl
states that reference the pin group nodes and are referenced by the
client nodes.

That's probably fine. However, I'd still question putting the pin group
nodes in DT at all; I'm not convinced it's better than just putting
those into the driver itself. You end up with the same data tables after
parsing the DT anyway.


  reply	other threads:[~2013-07-31  3:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1374702089-2832-1-git-send-email-hanumant@codeaurora.org>
2013-07-29 16:37 ` [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux Linus Walleij
2013-07-29 17:32   ` Stephen Warren
2013-07-30 21:10   ` hanumant
2013-07-30 21:22     ` Stephen Warren
2013-07-31  0:01       ` Hanumant Singh
2013-07-31  0:08         ` Stephen Warren
2013-07-31  0:13           ` Hanumant Singh
2013-07-31  3:59             ` Stephen Warren [this message]
2013-07-31 19:46               ` Hanumant Singh
2013-07-31 21:06                 ` Stephen Warren
2013-08-01  0:17                   ` Hanumant Singh
2013-08-06 23:45                     ` Hanumant Singh
2013-08-07 16:00                       ` Stephen Warren
2013-08-14 19:16                         ` Linus Walleij

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=51F88BAC.2020001@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=Bjorn.Andersson@sonymobile.com \
    --cc=Tim.Bird@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hanumant@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony@atomide.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).