From: Hanumant Singh <hanumant@codeaurora.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn@kryo.se>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
Date: Thu, 15 Aug 2013 14:28:37 -0700 [thread overview]
Message-ID: <520D4805.8070007@codeaurora.org> (raw)
In-Reply-To: <CACRpkdYVQ-Yk_b0cW0-sB6eGkpkgfFsnd3NXQmCYCuiLmm5qww@mail.gmail.com>
On 8/15/2013 1:47 PM, Linus Walleij wrote:
> On Thu, Aug 15, 2013 at 7:44 PM, Hanumant Singh <hanumant@codeaurora.org> wrote:
>
>> Ok i can switch to using pin groups defined in per soc files.
>> But in our case we have one soc going into different types of boards.
>> (atleast 3). In each of the boards the same external devices end up using
>> different pins. For ex camera on board 1 uses different pin group
>> then the same camera on board 2. Both having the same SOC.
>> So in this case the design would be to have all possible pin groups
>> for different boards enumerated in the same soc-pinctrl.c file?
>
> Sorry I don't get this at all.
>
> What pin groups and functions that exist on a SoC is what you put into
> a SoC driver. Because this is a hardware characteristic.
>
> How these are combined on a board into different states is what you put
> into the device tree. (Or platform data.)
>
For example lets say for a given SOC A it goes into boards 1, 2, and 3.
Each of the boards has a display panel. The display panel uses two pins
1) a reset pin 2) an interrupt pin.
In the combination of SOC A + board 1
- Display panel reset = pin no 5.
- Display panel interrupt = pin no 9.
In combination of SOC A + board 2
- Display panel reset = pin no 4.
- Display panel interrupt = pin no 9.
In combination of SOC A + board 3
- Display panel reset = pin no 7.
- Display panel interrupt = pin no 2.
The pin groupings to be used by the display panel can be {5,9}, {4,9},
or {7,2}
These different pin groups and their function setting will be present in
soc-pinctrl.c. The function setting is the same on all 3 cases.
The DT entry will correspond to the different states of these pins for
the different boards.
Is this understanding correct?
>> Also in this implementation I will have.
>> 1) pinctrl-msm.c => DT parsing and interface to framework.
>> 2) pinctrl-msm-tlmm<version>.c => Register programming and pin types
>> supported by a particular TLMM pinmux version.
>> 3) pinctrl-<soc>.c => All the pins/pin groups supported by a given SOC.
>
> Seems OK.
>
>> As I
>> mentioned we will have a bloat of these, since we have entire families of
>> SOC using a given TLMM version but with unique pin groupings.
>
> Bring 'em on. But is that really different groups you are talking about,
> and not just combinations of groups with functions for a certain board
> as I describe above?
>
> If you have many SoC subdrivers, consider creating a subdir as some
> drivers already have.
Actually the SOC files, as I see it, will only contain the different pin
groupings and the function setting for a given soc. The real driver
implementation will be in 1) and 2) (the device being the TLMM pinmux
version 3). I will currently refrain from creating a special msm
directory. Maybe that can be a step 2) once we start adding more SOC's?
I will be starting the patch with msm8974 SOC only.
Thanks
Hanumant
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
next prev parent reply other threads:[~2013-08-15 21:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-24 21:41 [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux Hanumant Singh
2013-07-29 16:37 ` 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
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
2013-07-29 23:39 ` Bjorn Andersson
2013-08-07 18:07 ` Hanumant Singh
2013-08-14 19:29 ` Linus Walleij
2013-08-15 17:44 ` Hanumant Singh
2013-08-15 20:47 ` Linus Walleij
2013-08-15 21:28 ` Hanumant Singh [this message]
2013-08-28 8:32 ` Linus Walleij
2013-08-15 21:50 ` Josh Cartwright
2013-08-15 21:58 ` Hanumant Singh
2013-08-15 23:10 ` Josh Cartwright
2013-08-15 23:14 ` Hanumant Singh
-- strict thread matches above, loose matches on Subject: below --
2013-06-21 21:52 Hanumant Singh
2013-06-24 12:18 ` Linus Walleij
2013-06-25 17:41 ` hanumant
2013-06-27 8:26 ` Linus Walleij
2013-06-27 15:17 ` hanumant
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=520D4805.8070007@codeaurora.org \
--to=hanumant@codeaurora.org \
--cc=bjorn@kryo.se \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.