Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 11:28 PM, Hanumant Singh
wrote:
> On 8/15/2013 1:47 PM, Linus Walleij wrote:
>> 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.
That sounds very close to two GPIO pins actually but I guess they
are not configured as "GPIO" in the data sheet sense when you do
this?
> 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 last part is correct, the function setting is the same on all
three cases :-)
Define one group per pin in this case, example something
like this (using the examples in Documentation/pinctrl.txt
as a base):
static const unsigned pan_res_pos_a[] = { 4 };
static const unsigned pan_res_pos_b[] = { 5 };
static const unsigned pan_res_pos_c[] = { 7 };
static const unsigned pan_irq_pos_a[] = { 2 };
static const unsigned pan_irq_pos_b[] = { 9 };
Next define the function and applicable groups:
static const struct foo_group foo_groups[] = {
{
.name = "pan_res_pos_a_grp",
.pins = pan_res_pos_a_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_a_pins),
},
{
.name = "pan_res_pos_b_grp",
.pins = pan_res_pos_b_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_b_pins),
},
{
.name = "pan_res_pos_c_grp",
.pins = pan_res_pos_c_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_c_pins),
},
{
.name = "pan_irq_pos_a_grp",
.pins = pan_irq_pos_a_pins,
.num_pins = ARRAY_SIZE(pan_irq_pos_a_pins),
},
{
.name = "pan_irq_pos_b_grp",
.pins = pan_irq_pos_b_pins,
.num_pins = ARRAY_SIZE(pan_irq_pos_b_pins),
},
};
static const char * const panel_groups[] = { "pan_res_pos_a_grp",
"pan_res_pos_b_grp", "pan_res_pos_c_grp",
"pan_irq_pos_a_grp", "pan_irq_pos_b_grp"
};
static const struct foo_pmx_func foo_functions[] = {
{
.name = "panel",
.groups = panel_groups,
.num_groups = ARRAY_SIZE(panel_groups),
},
};
Then in your DTS you combine the function "panel" with
the two groups you want, i.e. for your examples:
1: "panel" + "pan_res_pos_b_grp" + "pan_irq_pos_b_grp"
2: "panel" + "pan_res_pos_a_grp" + "pan_irq_pos_b_grp"
3: "panel" + "pan_res_pos_c_grp" + "pan_irq_pos_a_grp"
So in each case the function "panel" is combined with two
groups enabling the correct pins for a certain state, e.g.
the "default" state. Each line above corresponds to a
state.
> The DT entry will correspond to the different states of these pins for the
> different boards.
>
> Is this understanding correct?
See above.
>> 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.
No settings. The SoC files will contain the available groups and
functions. How these are combined is defined by the device tree
(or even platform data). The pinctrl SoC files define what is
*possible* and the configuration from DTS or platform data
define what to do with the possibilities.
> 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.
Sure any order you prefer, let's get a base support in that
looks fine and then we can start refining it.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 11:28 PM, Hanumant Singh
hanum...@codeaurora.org wrote:
On 8/15/2013 1:47 PM, Linus Walleij wrote:
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.
That sounds very close to two GPIO pins actually but I guess they
are not configured as GPIO in the data sheet sense when you do
this?
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 last part is correct, the function setting is the same on all
three cases :-)
Define one group per pin in this case, example something
like this (using the examples in Documentation/pinctrl.txt
as a base):
static const unsigned pan_res_pos_a[] = { 4 };
static const unsigned pan_res_pos_b[] = { 5 };
static const unsigned pan_res_pos_c[] = { 7 };
static const unsigned pan_irq_pos_a[] = { 2 };
static const unsigned pan_irq_pos_b[] = { 9 };
Next define the function and applicable groups:
static const struct foo_group foo_groups[] = {
{
.name = pan_res_pos_a_grp,
.pins = pan_res_pos_a_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_a_pins),
},
{
.name = pan_res_pos_b_grp,
.pins = pan_res_pos_b_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_b_pins),
},
{
.name = pan_res_pos_c_grp,
.pins = pan_res_pos_c_pins,
.num_pins = ARRAY_SIZE(pan_res_pos_c_pins),
},
{
.name = pan_irq_pos_a_grp,
.pins = pan_irq_pos_a_pins,
.num_pins = ARRAY_SIZE(pan_irq_pos_a_pins),
},
{
.name = pan_irq_pos_b_grp,
.pins = pan_irq_pos_b_pins,
.num_pins = ARRAY_SIZE(pan_irq_pos_b_pins),
},
};
static const char * const panel_groups[] = { pan_res_pos_a_grp,
pan_res_pos_b_grp, pan_res_pos_c_grp,
pan_irq_pos_a_grp, pan_irq_pos_b_grp
};
static const struct foo_pmx_func foo_functions[] = {
{
.name = panel,
.groups = panel_groups,
.num_groups = ARRAY_SIZE(panel_groups),
},
};
Then in your DTS you combine the function panel with
the two groups you want, i.e. for your examples:
1: panel + pan_res_pos_b_grp + pan_irq_pos_b_grp
2: panel + pan_res_pos_a_grp + pan_irq_pos_b_grp
3: panel + pan_res_pos_c_grp + pan_irq_pos_a_grp
So in each case the function panel is combined with two
groups enabling the correct pins for a certain state, e.g.
the default state. Each line above corresponds to a
state.
The DT entry will correspond to the different states of these pins for the
different boards.
Is this understanding correct?
See above.
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.
No settings. The SoC files will contain the available groups and
functions. How these are combined is defined by the device tree
(or even platform data). The pinctrl SoC files define what is
*possible* and the configuration from DTS or platform data
define what to do with the possibilities.
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.
Sure any order you prefer, let's get a base support in that
looks fine and then we can start refining it.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 4:10 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 02:58:31PM -0700, Hanumant Singh wrote: On 8/15/2013 2:50 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh 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? Also in this implementation I will have. 1) pinctrl-msm.c => DT parsing and interface to framework. 2) pinctrl-msm-tlmm.c => Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmm.c. The idea is that we should be able to plug in the next TLMM version 4, with the pintypes that it supports and its register programming semantics without any changes to the DT parsing or interface to the framework. The DT information describes the states of the pingroups. How we handle them with respect to the pinctrl framework, does not change with different versions of the TLMM. Okay, although I think that might be a bit too much indirection too soon. I'd rather the strategy be to have a straightforward driver supporting TLMMv3 only (with MSM8974 support), and only worry about introducing a generic TLMM parsing layer when we actually have a need for it. If nothing else, I'd at least suggest that you rename pinctrl-msm.c to pinctrl-msm-tlmm.c, if it's going to be housing the TLMM-generic DT parsing code. Actually we already have a request from Bjorn to support TLMMv2 which has different pin types and register semantics. 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 02:58:31PM -0700, Hanumant Singh wrote: > On 8/15/2013 2:50 PM, Josh Cartwright wrote: > >On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: > >>On 8/14/2013 12:29 PM, Linus Walleij wrote: > >>>On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote: > On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh > 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? > >> > >>Also in this implementation I will have. > >>1) pinctrl-msm.c => DT parsing and interface to framework. > >>2) pinctrl-msm-tlmm.c => Register programming and pin types > >>supported by a particular TLMM pinmux version. > > > >It isn't clear to me what you are trying to separate out between 1) and > >2). Seems like there should only be pinctrl-msm-tlmm.c. > > > The idea is that we should be able to plug in the next TLMM version 4, with > the pintypes that it supports and its register programming semantics without > any changes to the DT parsing or interface to the framework. The DT > information describes the states of the pingroups. > How we handle them with respect to the pinctrl framework, does not change > with different versions of the TLMM. Okay, although I think that might be a bit too much indirection too soon. I'd rather the strategy be to have a straightforward driver supporting TLMMv3 only (with MSM8974 support), and only worry about introducing a generic TLMM parsing layer when we actually have a need for it. If nothing else, I'd at least suggest that you rename pinctrl-msm.c to pinctrl-msm-tlmm.c, if it's going to be housing the TLMM-generic DT parsing code. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 2:50 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh wrote: As a general note on the patch, the pins and pin groups are defined by the soc, I'm therefore not convinced that these should be configured >from the devicetree. It's at least not how it's done in other platforms. Now we are three people sayin the same thing so it should be a good hint to the implementer :-) 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? Also in this implementation I will have. 1) pinctrl-msm.c => DT parsing and interface to framework. 2) pinctrl-msm-tlmm.c => Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmm.c. The idea is that we should be able to plug in the next TLMM version 4, with the pintypes that it supports and its register programming semantics without any changes to the DT parsing or interface to the framework. The DT information describes the states of the pingroups. How we handle them with respect to the pinctrl framework, does not change with different versions of the TLMM. 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: > On 8/14/2013 12:29 PM, Linus Walleij wrote: > >On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote: > >>On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh > >>wrote: > > > >>As a general note on the patch, the pins and pin groups are defined by > >>the soc, I'm therefore not convinced that these should be configured > >>from the devicetree. It's at least not how it's done in other > >>platforms. > > > >Now we are three people sayin the same thing so it should > >be a good hint to the implementer :-) > > > > 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? > > Also in this implementation I will have. > 1) pinctrl-msm.c => DT parsing and interface to framework. > 2) pinctrl-msm-tlmm.c => Register programming and pin types > supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmm.c. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 1:47 PM, Linus Walleij wrote:
On Thu, Aug 15, 2013 at 7:44 PM, Hanumant Singh 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.c => Register programming and pin types
supported by a particular TLMM pinmux version.
3) pinctrl-.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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 7:44 PM, Hanumant Singh 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.)
> Also in this implementation I will have.
> 1) pinctrl-msm.c => DT parsing and interface to framework.
> 2) pinctrl-msm-tlmm.c => Register programming and pin types
> supported by a particular TLMM pinmux version.
> 3) pinctrl-.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.
> I don't override the default values, since resistor values are not
> configurable. I only care about which config option is chosen to program it
> as pull up/down or disable.
That sounds correct.
>> Actually the data should be more carefully handled for each
>> config option I think.
>>
> Not sure I follow. Based on my use mentioned above, what do you suggest for
> the read? Should I return default config value, which is what I am doing ?
Here:
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ mask = TLMMV3_GP_PULL_MASK;
+ shft = TLMMV3_GP_PULL_SHFT;
+ data = TLMMV3_NO_PULL;
data should just be zero. (Maybe TLMMV3_NO_PULL is
zero? But anyway...)
+ if (!write) {
+ val >>= shft;
+ val &= mask;
+ data = rval_to_pull(val);
Dito.
Because it has no meaning in the framework.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/14/2013 12:29 PM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh wrote:
As a general note on the patch, the pins and pin groups are defined by
the soc, I'm therefore not convinced that these should be configured
from the devicetree. It's at least not how it's done in other
platforms.
Now we are three people sayin the same thing so it should
be a good hint to the implementer :-)
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?
Also in this implementation I will have.
1) pinctrl-msm.c => DT parsing and interface to framework.
2) pinctrl-msm-tlmm.c => Register programming and pin types
supported by a particular TLMM pinmux version.
3) pinctrl-.c => All the pins/pin groups supported by a given SOC.
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.
+ /* Get mask and shft values for this config type */
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ mask = TLMMV3_GP_PULL_MASK;
+ shft = TLMMV3_GP_PULL_SHFT;
+ data = TLMMV3_NO_PULL;
+ if (!write) {
+ val >>= shft;
+ val &= mask;
+ data = rval_to_pull(val);
I assume this should return a "boolean" whether or not this mode is
selected; if so you should return 1 here iff (val & 0x3) == 3. I
assume the same goes for the sdc config function?
@Linus, could you please confirm this interpretation of the get_config
for pull config.
On bias disable the argument is ignored so it doesn't matter, it
should just be set to zero.
I don't override the default values, since resistor values are not
configurable. I only care about which config option is chosen to program
it as pull up/down or disable.
Actually the data should be more carefully handled for each
config option I think.
Not sure I follow. Based on my use mentioned above, what do you suggest
for the read? Should I return default config value, which is what I am
doing ?
Yours,
Linus Walleij
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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/14/2013 12:29 PM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@codeaurora.org wrote:
As a general note on the patch, the pins and pin groups are defined by
the soc, I'm therefore not convinced that these should be configured
from the devicetree. It's at least not how it's done in other
platforms.
Now we are three people sayin the same thing so it should
be a good hint to the implementer :-)
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?
Also in this implementation I will have.
1) pinctrl-msm.c = DT parsing and interface to framework.
2) pinctrl-msm-tlmmversion.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.
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.
+ /* Get mask and shft values for this config type */
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ mask = TLMMV3_GP_PULL_MASK;
+ shft = TLMMV3_GP_PULL_SHFT;
+ data = TLMMV3_NO_PULL;
+ if (!write) {
+ val = shft;
+ val = mask;
+ data = rval_to_pull(val);
I assume this should return a boolean whether or not this mode is
selected; if so you should return 1 here iff (val 0x3) == 3. I
assume the same goes for the sdc config function?
@Linus, could you please confirm this interpretation of the get_config
for pull config.
On bias disable the argument is ignored so it doesn't matter, it
should just be set to zero.
I don't override the default values, since resistor values are not
configurable. I only care about which config option is chosen to program
it as pull up/down or disable.
Actually the data should be more carefully handled for each
config option I think.
Not sure I follow. Based on my use mentioned above, what do you suggest
for the read? Should I return default config value, which is what I am
doing ?
Yours,
Linus Walleij
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.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 7:44 PM, Hanumant Singh hanum...@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.)
Also in this implementation I will have.
1) pinctrl-msm.c = DT parsing and interface to framework.
2) pinctrl-msm-tlmmversion.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.
I don't override the default values, since resistor values are not
configurable. I only care about which config option is chosen to program it
as pull up/down or disable.
That sounds correct.
Actually the data should be more carefully handled for each
config option I think.
Not sure I follow. Based on my use mentioned above, what do you suggest for
the read? Should I return default config value, which is what I am doing ?
Here:
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ mask = TLMMV3_GP_PULL_MASK;
+ shft = TLMMV3_GP_PULL_SHFT;
+ data = TLMMV3_NO_PULL;
data should just be zero. (Maybe TLMMV3_NO_PULL is
zero? But anyway...)
+ if (!write) {
+ val = shft;
+ val = mask;
+ data = rval_to_pull(val);
Dito.
Because it has no meaning in the framework.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 1:47 PM, Linus Walleij wrote:
On Thu, Aug 15, 2013 at 7:44 PM, Hanumant Singh hanum...@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-tlmmversion.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.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@codeaurora.org wrote: As a general note on the patch, the pins and pin groups are defined by the soc, I'm therefore not convinced that these should be configured from the devicetree. It's at least not how it's done in other platforms. Now we are three people sayin the same thing so it should be a good hint to the implementer :-) 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? Also in this implementation I will have. 1) pinctrl-msm.c = DT parsing and interface to framework. 2) pinctrl-msm-tlmmversion.c = Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmmversion.c. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 2:50 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@codeaurora.org wrote: As a general note on the patch, the pins and pin groups are defined by the soc, I'm therefore not convinced that these should be configured from the devicetree. It's at least not how it's done in other platforms. Now we are three people sayin the same thing so it should be a good hint to the implementer :-) 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? Also in this implementation I will have. 1) pinctrl-msm.c = DT parsing and interface to framework. 2) pinctrl-msm-tlmmversion.c = Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmmversion.c. The idea is that we should be able to plug in the next TLMM version 4, with the pintypes that it supports and its register programming semantics without any changes to the DT parsing or interface to the framework. The DT information describes the states of the pingroups. How we handle them with respect to the pinctrl framework, does not change with different versions of the TLMM. 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Thu, Aug 15, 2013 at 02:58:31PM -0700, Hanumant Singh wrote: On 8/15/2013 2:50 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@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? Also in this implementation I will have. 1) pinctrl-msm.c = DT parsing and interface to framework. 2) pinctrl-msm-tlmmversion.c = Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmmversion.c. The idea is that we should be able to plug in the next TLMM version 4, with the pintypes that it supports and its register programming semantics without any changes to the DT parsing or interface to the framework. The DT information describes the states of the pingroups. How we handle them with respect to the pinctrl framework, does not change with different versions of the TLMM. Okay, although I think that might be a bit too much indirection too soon. I'd rather the strategy be to have a straightforward driver supporting TLMMv3 only (with MSM8974 support), and only worry about introducing a generic TLMM parsing layer when we actually have a need for it. If nothing else, I'd at least suggest that you rename pinctrl-msm.c to pinctrl-msm-tlmm.c, if it's going to be housing the TLMM-generic DT parsing code. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 8/15/2013 4:10 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 02:58:31PM -0700, Hanumant Singh wrote: On 8/15/2013 2:50 PM, Josh Cartwright wrote: On Thu, Aug 15, 2013 at 10:44:03AM -0700, Hanumant Singh wrote: On 8/14/2013 12:29 PM, Linus Walleij wrote: On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@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? Also in this implementation I will have. 1) pinctrl-msm.c = DT parsing and interface to framework. 2) pinctrl-msm-tlmmversion.c = Register programming and pin types supported by a particular TLMM pinmux version. It isn't clear to me what you are trying to separate out between 1) and 2). Seems like there should only be pinctrl-msm-tlmmversion.c. The idea is that we should be able to plug in the next TLMM version 4, with the pintypes that it supports and its register programming semantics without any changes to the DT parsing or interface to the framework. The DT information describes the states of the pingroups. How we handle them with respect to the pinctrl framework, does not change with different versions of the TLMM. Okay, although I think that might be a bit too much indirection too soon. I'd rather the strategy be to have a straightforward driver supporting TLMMv3 only (with MSM8974 support), and only worry about introducing a generic TLMM parsing layer when we actually have a need for it. If nothing else, I'd at least suggest that you rename pinctrl-msm.c to pinctrl-msm-tlmm.c, if it's going to be housing the TLMM-generic DT parsing code. Actually we already have a request from Bjorn to support TLMMv2 which has different pin types and register semantics. 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson wrote:
> On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh
> wrote:
> As a general note on the patch, the pins and pin groups are defined by
> the soc, I'm therefore not convinced that these should be configured
> from the devicetree. It's at least not how it's done in other
> platforms.
Now we are three people sayin the same thing so it should
be a good hint to the implementer :-)
> After talking to Linus a little bit I concluded that the way the
> design idea behind pinmux is that you have pins and you have
> functions;
> * pins are your 117 gp-pins and with some imagination your sd pins, so
> that's fine.
> * the function is some functionality provided by the hard
> Then you can set up muxes between these two. Therefore I think your
> use of the word "function" in the patch is what normally is called a
> mux. It might be worth sorting this out, to make it easier to maintain
> this code down the road.
>
> @Linus, can you please confirm my understanding of the design?
Yes, we have pins in groups which are just group = pin [a, b, ... , n]
and we have functions which is e.g. "I2C block 1". To push a function
out on the pins we connect the function with a group of pins.
For a function such as a UART, we connect 2 or 4 pins ... those will
provide TX+RX or maybe TX+RX+CTS+RTS if we want to be fancy.
So the mapping table combines this group with this function and
that becomes a setting such as "default" ...
You only have to do it a few times and then you get the hang
of it :-)
I wish we could have come up with something simpler than
this but it appears the world is complex, this was the common
denominator of all the worlds pinmuxes: they enable a group
of pins for a certain function (an IP core).
>> +static int msm_tlmm_v3_sdc_cfg(uint pin_no, unsigned long *config,
>> + void __iomem *reg_base,
>> + bool write)
>
> I strongly recommend you split this function into a get_config and
> set_config. It took me plenty of time to get my head around what
> you're doing here.
>
> I would also suggest that you do:
>
> val = readl()
> switch () {
> fix val in various ways
> }
> writel(val)
>
> Instead of maintaining mask and shift throughout the function.
Agree. And if you want to have performance as well:
readl_relaxed() ... writel() is preferred. (Not that it matters
much uless in a critical path.)
>> + /* Get mask and shft values for this config type */
>> + switch (id) {
>> + case PIN_CONFIG_BIAS_DISABLE:
>> + mask = TLMMV3_GP_PULL_MASK;
>> + shft = TLMMV3_GP_PULL_SHFT;
>> + data = TLMMV3_NO_PULL;
>> + if (!write) {
>> + val >>= shft;
>> + val &= mask;
>> + data = rval_to_pull(val);
>
> I assume this should return a "boolean" whether or not this mode is
> selected; if so you should return 1 here iff (val & 0x3) == 3. I
> assume the same goes for the sdc config function?
>
> @Linus, could you please confirm this interpretation of the get_config
> for pull config.
On bias disable the argument is ignored so it doesn't matter, it
should just be set to zero.
Actually the data should be more carefully handled for each
config option I think.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Wed, Aug 7, 2013 at 6:00 PM, Stephen Warren wrote: > On 08/06/2013 05:45 PM, Hanumant Singh wrote: >> Any comments on this? > > No. As I said, I personally want to see all the pingroups defined in the > pinctrl driver. But, if someone else acks/... the patches without it, I > probably won't nack it. I agree with Stephen that I want to see the groups defined in a (per-SoC) in-kernel driver, not as DT data. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Wed, Aug 7, 2013 at 6:00 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/06/2013 05:45 PM, Hanumant Singh wrote: Any comments on this? No. As I said, I personally want to see all the pingroups defined in the pinctrl driver. But, if someone else acks/... the patches without it, I probably won't nack it. I agree with Stephen that I want to see the groups defined in a (per-SoC) in-kernel driver, not as DT data. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Tue, Jul 30, 2013 at 1:39 AM, Bjorn Andersson bj...@kryo.se wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@codeaurora.org
wrote:
As a general note on the patch, the pins and pin groups are defined by
the soc, I'm therefore not convinced that these should be configured
from the devicetree. It's at least not how it's done in other
platforms.
Now we are three people sayin the same thing so it should
be a good hint to the implementer :-)
After talking to Linus a little bit I concluded that the way the
design idea behind pinmux is that you have pins and you have
functions;
* pins are your 117 gp-pins and with some imagination your sd pins, so
that's fine.
* the function is some functionality provided by the hard
Then you can set up muxes between these two. Therefore I think your
use of the word function in the patch is what normally is called a
mux. It might be worth sorting this out, to make it easier to maintain
this code down the road.
@Linus, can you please confirm my understanding of the design?
Yes, we have pins in groups which are just group = pin [a, b, ... , n]
and we have functions which is e.g. I2C block 1. To push a function
out on the pins we connect the function with a group of pins.
For a function such as a UART, we connect 2 or 4 pins ... those will
provide TX+RX or maybe TX+RX+CTS+RTS if we want to be fancy.
So the mapping table combines this group with this function and
that becomes a setting such as default ...
You only have to do it a few times and then you get the hang
of it :-)
I wish we could have come up with something simpler than
this but it appears the world is complex, this was the common
denominator of all the worlds pinmuxes: they enable a group
of pins for a certain function (an IP core).
+static int msm_tlmm_v3_sdc_cfg(uint pin_no, unsigned long *config,
+ void __iomem *reg_base,
+ bool write)
I strongly recommend you split this function into a get_config and
set_config. It took me plenty of time to get my head around what
you're doing here.
I would also suggest that you do:
val = readl()
switch () {
fix val in various ways
}
writel(val)
Instead of maintaining mask and shift throughout the function.
Agree. And if you want to have performance as well:
readl_relaxed() ... writel() is preferred. (Not that it matters
much uless in a critical path.)
+ /* Get mask and shft values for this config type */
+ switch (id) {
+ case PIN_CONFIG_BIAS_DISABLE:
+ mask = TLMMV3_GP_PULL_MASK;
+ shft = TLMMV3_GP_PULL_SHFT;
+ data = TLMMV3_NO_PULL;
+ if (!write) {
+ val = shft;
+ val = mask;
+ data = rval_to_pull(val);
I assume this should return a boolean whether or not this mode is
selected; if so you should return 1 here iff (val 0x3) == 3. I
assume the same goes for the sdc config function?
@Linus, could you please confirm this interpretation of the get_config
for pull config.
On bias disable the argument is ignored so it doesn't matter, it
should just be set to zero.
Actually the data should be more carefully handled for each
config option I think.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/29/2013 4:39 PM, Bjorn Andersson wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh wrote:
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
Thanks! I was about to write an implementation for v2 myself when I
found your patch. I hacked a little bit on it and got it to work on my
8960 based board.
Sorry for the delayed response. Right now the focus is to add support
for the pinmux on the snapdragon 800 soc which uses the V3.
This driver is split into two parts: the pinctrl interface
and the TLMM version specific implementation. The pinctrl
interface parses the device tree and registers with the pinctrl
subsytem. The TLMM version specific implementation supports
pin configuration/register programming for the different
pin types present on a given TLMM pinmux version.
Add support only for TLMM version 3 pinmux right now,
as well as, only two of the different pin types present on the
TLMM v3 pinmux.
Pintype 1: General purpose pins.
Pintype 2: SDC pins.
It seems that the gp pins of TLMM v3 have the same layout and offsets
as the once in v2. Unless I'm missing something I think this patch
should be structured (and have appropriate naming) in a way that we
can support both of them.
No, Actually there are significant differences in the v2 and v3 register
offsets and even hardware capabilities.
We are currently trying to add support for our snapdragon 800
soc which uses V3.
As a general note on the patch, the pins and pin groups are defined by
the soc, I'm therefore not convinced that these should be configured
from the devicetree. It's at least not how it's done in other
platforms.
I have been having a email discussion with Stephen Warren on this.
After talking to Linus a little bit I concluded that the way the
design idea behind pinmux is that you have pins and you have
functions;
* pins are your 117 gp-pins and with some imagination your sd pins, so
that's fine.
* the function is some functionality provided by the hard
Then you can set up muxes between these two. Therefore I think your
use of the word "function" in the patch is what normally is called a
mux. It might be worth sorting this out, to make it easier to maintain
this code down the road.
@Linus, can you please confirm my understanding of the design?
I am not sure that the use of the term func is misleading. You can look
at the samsung-pinctrl.txt documentation for a similar use of the term.
+Example 2: Spi pin entries within the pincontroller node
+ pinctrl@fd511000 {
+
+ ..
+ pmx-spi-bus {
+ /*
+* MOSI, MISO and CLK lines
+* all sharing same function and config
+* settings for each configuration node.
+*/
+ qcom,pins = < 0>, < 1>, < 3>;
+ qcom,num-grp-pins = <3>;
qcom,num-grp-pins is not used by the code, please remove it.
Will do
+ qcom,pin-func = <1>;
+ label = "spi-bus";
+
+ /* Active configuration of bus pins */
+ spi-bus-active: spi-bus-active {
+ /*
+* Property names as specified in
+* pinctrl-bindings.txt
+*/
+ drive-strength = <8>; /* 8 MA */
+ bias-disable; /* No PULL */
+ };
+ /* Sleep configuration of bus pins */
+ spi-bus-sleep: spi-bus-sleep {
+ /*
+* Property values as specified in HW
+* manual.
+*/
+ drive-strength = <2>; /* 2 MA */
+ bias-disable;
+ };
+ };
+
+ pmx-spi-cs {
+ /*
+* Chip select for SPI
+* different config
+* settings as compared to bus pins.
+*/
+ qcom,pins = < 2>;
Make Gp lower case.
Will do
+Example 3: A SPI client node that supports 'active' and 'sleep' states.
+
+ spi_0: spi@f9923000 { /* BLSP1 QUP1 */
+ compatible = "qcom,spi-qup-v2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg-names = "spi_physical", "spi_bam_physical";
+ reg = <0xf9923000 0x1000>,
+ <0xf9904000 0xF000>;
+ interrupt-names = "spi_irq", "spi_bam_irq";
+
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 08/06/2013 05:45 PM, Hanumant Singh wrote: > On 7/31/2013 5:17 PM, Hanumant Singh wrote: >> On 7/31/2013 2:06 PM, Stephen Warren wrote: >>> On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: > 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. > Any feedback for the rest of the patch? >>> >>> I'm certainly waiting for this aspect of the patch to be resolved; I >>> think it will impact the rest of the patch so much that it's not worth >>> reviewing until we decide on where to represent the pin groups (some DT >>> parsing could would be removed if we put the pin group definitions into >>> the driver, hence wouldn't need to be reviewed, and likewise there's be >>> some new tables to review). >>> >> >> I am trying to look at examples of what you are suggesting. >> I was looking at the exynos implementation, and just from a brief glance >> it seems like there too the pin grouping is being specified in the >> device tree, using what looks like labels of the pins. >> The labels are matched to group structures in soc specific files? >> >> By having the pin groupings in DT I am able to reuse the driver without >> any SOC based code bloat. >> As I mentioned earlier, we have entire families of SOCs using the same >> TLMM hardware. >> Its not a guarantee that for a given TLMM version, >> the pin groupings on that hardware are the same for every SOC that its >> in. Its infact most likely that I wont be able to use the pin groupings >> from one SOC to the next even if they both use the same TLMM. >> It will very quickly lead to a bloat of >> pinctrl-.c (containing the pin groupings replicated for each >> soc) >> which use TLMM version specific register programming implementation >> pinctrl-tlmm-.c >> and the DT parsing and interface to framework (which remains unchanged). >> pinctrl-msm.c. >> >> Thanks >> Hanumant >> > > Any comments on this? No. As I said, I personally want to see all the pingroups defined in the pinctrl driver. But, if someone else acks/... the patches without it, I probably won't nack it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 08/06/2013 05:45 PM, Hanumant Singh wrote: On 7/31/2013 5:17 PM, Hanumant Singh wrote: On 7/31/2013 2:06 PM, Stephen Warren wrote: On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). I am trying to look at examples of what you are suggesting. I was looking at the exynos implementation, and just from a brief glance it seems like there too the pin grouping is being specified in the device tree, using what looks like labels of the pins. The labels are matched to group structures in soc specific files? By having the pin groupings in DT I am able to reuse the driver without any SOC based code bloat. As I mentioned earlier, we have entire families of SOCs using the same TLMM hardware. Its not a guarantee that for a given TLMM version, the pin groupings on that hardware are the same for every SOC that its in. Its infact most likely that I wont be able to use the pin groupings from one SOC to the next even if they both use the same TLMM. It will very quickly lead to a bloat of pinctrl-msm_soc.c (containing the pin groupings replicated for each soc) which use TLMM version specific register programming implementation pinctrl-tlmm-version.c and the DT parsing and interface to framework (which remains unchanged). pinctrl-msm.c. Thanks Hanumant Any comments on this? No. As I said, I personally want to see all the pingroups defined in the pinctrl driver. But, if someone else acks/... the patches without it, I probably won't nack it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/29/2013 4:39 PM, Bjorn Andersson wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh hanum...@codeaurora.org wrote:
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
Thanks! I was about to write an implementation for v2 myself when I
found your patch. I hacked a little bit on it and got it to work on my
8960 based board.
Sorry for the delayed response. Right now the focus is to add support
for the pinmux on the snapdragon 800 soc which uses the V3.
This driver is split into two parts: the pinctrl interface
and the TLMM version specific implementation. The pinctrl
interface parses the device tree and registers with the pinctrl
subsytem. The TLMM version specific implementation supports
pin configuration/register programming for the different
pin types present on a given TLMM pinmux version.
Add support only for TLMM version 3 pinmux right now,
as well as, only two of the different pin types present on the
TLMM v3 pinmux.
Pintype 1: General purpose pins.
Pintype 2: SDC pins.
It seems that the gp pins of TLMM v3 have the same layout and offsets
as the once in v2. Unless I'm missing something I think this patch
should be structured (and have appropriate naming) in a way that we
can support both of them.
No, Actually there are significant differences in the v2 and v3 register
offsets and even hardware capabilities.
We are currently trying to add support for our snapdragon 800
soc which uses V3.
As a general note on the patch, the pins and pin groups are defined by
the soc, I'm therefore not convinced that these should be configured
from the devicetree. It's at least not how it's done in other
platforms.
I have been having a email discussion with Stephen Warren on this.
After talking to Linus a little bit I concluded that the way the
design idea behind pinmux is that you have pins and you have
functions;
* pins are your 117 gp-pins and with some imagination your sd pins, so
that's fine.
* the function is some functionality provided by the hard
Then you can set up muxes between these two. Therefore I think your
use of the word function in the patch is what normally is called a
mux. It might be worth sorting this out, to make it easier to maintain
this code down the road.
@Linus, can you please confirm my understanding of the design?
I am not sure that the use of the term func is misleading. You can look
at the samsung-pinctrl.txt documentation for a similar use of the term.
+Example 2: Spi pin entries within the pincontroller node
+ pinctrl@fd511000 {
+
+ ..
+ pmx-spi-bus {
+ /*
+* MOSI, MISO and CLK lines
+* all sharing same function and config
+* settings for each configuration node.
+*/
+ qcom,pins = gp 0, gp 1, gp 3;
+ qcom,num-grp-pins = 3;
qcom,num-grp-pins is not used by the code, please remove it.
Will do
+ qcom,pin-func = 1;
+ label = spi-bus;
+
+ /* Active configuration of bus pins */
+ spi-bus-active: spi-bus-active {
+ /*
+* Property names as specified in
+* pinctrl-bindings.txt
+*/
+ drive-strength = 8; /* 8 MA */
+ bias-disable; /* No PULL */
+ };
+ /* Sleep configuration of bus pins */
+ spi-bus-sleep: spi-bus-sleep {
+ /*
+* Property values as specified in HW
+* manual.
+*/
+ drive-strength = 2; /* 2 MA */
+ bias-disable;
+ };
+ };
+
+ pmx-spi-cs {
+ /*
+* Chip select for SPI
+* different config
+* settings as compared to bus pins.
+*/
+ qcom,pins = Gp 2;
Make Gp lower case.
Will do
+Example 3: A SPI client node that supports 'active' and 'sleep' states.
+
+ spi_0: spi@f9923000 { /* BLSP1 QUP1 */
+ compatible = qcom,spi-qup-v2;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg-names = spi_physical, spi_bam_physical;
+ reg = 0xf9923000 0x1000,
+ 0xf9904000 0xF000;
+ interrupt-names = spi_irq, spi_bam_irq;
+ interrupts =
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/31/2013 5:17 PM, Hanumant Singh wrote: On 7/31/2013 2:06 PM, Stephen Warren wrote: On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). I am trying to look at examples of what you are suggesting. I was looking at the exynos implementation, and just from a brief glance it seems like there too the pin grouping is being specified in the device tree, using what looks like labels of the pins. The labels are matched to group structures in soc specific files? By having the pin groupings in DT I am able to reuse the driver without any SOC based code bloat. As I mentioned earlier, we have entire families of SOCs using the same TLMM hardware. Its not a guarantee that for a given TLMM version, the pin groupings on that hardware are the same for every SOC that its in. Its infact most likely that I wont be able to use the pin groupings from one SOC to the next even if they both use the same TLMM. It will very quickly lead to a bloat of pinctrl-.c (containing the pin groupings replicated for each soc) which use TLMM version specific register programming implementation pinctrl-tlmm-.c and the DT parsing and interface to framework (which remains unchanged). pinctrl-msm.c. Thanks Hanumant Any comments on this? 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/31/2013 5:17 PM, Hanumant Singh wrote: On 7/31/2013 2:06 PM, Stephen Warren wrote: On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). I am trying to look at examples of what you are suggesting. I was looking at the exynos implementation, and just from a brief glance it seems like there too the pin grouping is being specified in the device tree, using what looks like labels of the pins. The labels are matched to group structures in soc specific files? By having the pin groupings in DT I am able to reuse the driver without any SOC based code bloat. As I mentioned earlier, we have entire families of SOCs using the same TLMM hardware. Its not a guarantee that for a given TLMM version, the pin groupings on that hardware are the same for every SOC that its in. Its infact most likely that I wont be able to use the pin groupings from one SOC to the next even if they both use the same TLMM. It will very quickly lead to a bloat of pinctrl-msm_soc.c (containing the pin groupings replicated for each soc) which use TLMM version specific register programming implementation pinctrl-tlmm-version.c and the DT parsing and interface to framework (which remains unchanged). pinctrl-msm.c. Thanks Hanumant Any comments on this? 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/31/2013 2:06 PM, Stephen Warren wrote: On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). I am trying to look at examples of what you are suggesting. I was looking at the exynos implementation, and just from a brief glance it seems like there too the pin grouping is being specified in the device tree, using what looks like labels of the pins. The labels are matched to group structures in soc specific files? By having the pin groupings in DT I am able to reuse the driver without any SOC based code bloat. As I mentioned earlier, we have entire families of SOCs using the same TLMM hardware. Its not a guarantee that for a given TLMM version, the pin groupings on that hardware are the same for every SOC that its in. Its infact most likely that I wont be able to use the pin groupings from one SOC to the next even if they both use the same TLMM. It will very quickly lead to a bloat of pinctrl-.c (containing the pin groupings replicated for each soc) which use TLMM version specific register programming implementation pinctrl-tlmm-.c and the DT parsing and interface to framework (which remains unchanged). pinctrl-msm.c. 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 07/31/2013 01:46 PM, Hanumant Singh wrote: > On 7/30/2013 8:59 PM, Stephen Warren wrote: >> 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. >> > > Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/31/2013 2:06 PM, Stephen Warren wrote: On 07/31/2013 01:46 PM, Hanumant Singh wrote: On 7/30/2013 8:59 PM, Stephen Warren wrote: 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. Any feedback for the rest of the patch? I'm certainly waiting for this aspect of the patch to be resolved; I think it will impact the rest of the patch so much that it's not worth reviewing until we decide on where to represent the pin groups (some DT parsing could would be removed if we put the pin group definitions into the driver, hence wouldn't need to be reviewed, and likewise there's be some new tables to review). I am trying to look at examples of what you are suggesting. I was looking at the exynos implementation, and just from a brief glance it seems like there too the pin grouping is being specified in the device tree, using what looks like labels of the pins. The labels are matched to group structures in soc specific files? By having the pin groupings in DT I am able to reuse the driver without any SOC based code bloat. As I mentioned earlier, we have entire families of SOCs using the same TLMM hardware. Its not a guarantee that for a given TLMM version, the pin groupings on that hardware are the same for every SOC that its in. Its infact most likely that I wont be able to use the pin groupings from one SOC to the next even if they both use the same TLMM. It will very quickly lead to a bloat of pinctrl-msm_soc.c (containing the pin groupings replicated for each soc) which use TLMM version specific register programming implementation pinctrl-tlmm-version.c and the DT parsing and interface to framework (which remains unchanged). pinctrl-msm.c. 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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? Thanks Hanumant that are valid for that -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. 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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/29/2013 9:37 AM, Linus Walleij wrote: On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh wrote: Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. I guess this is the v4 patch set? Please include a small changelog so I can keep track of things... Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 This thing is not interesting to the kernel community. diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..0f17a94 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt This needs to be broken out and sent for separate review on the devicet...@vger.kernel.org mailing list. +Required Properties + - qcom,pin-type-*: identifies the pin type. Pin types supported are + qcom,pin-type-gp (General purpose) + qcom,pin-type-sdc (SDC) I am wondering if it it would not be simpler to split this driver in two, one for the GP pins and one for the SDC pins. Having this tag on each and every pin seems *very* awkward. If you have two drivers and two device tree nodes, one for GP pins and one for SDC pins, just separated by different compatible strings and different memory regs, things will look simpler and be easier to maintain I think. Unless there is some strong cross-dependency between GP and SDC please explore this approach. Actually we have had this discussion. There are more pin types on a TLMM then just these 2. The registers are interleaved. They are no separated at a clean page boundary. Also there is mode register that governs the function mode of the "unifunction"/single function pins like SDC. This register is again interspersed in the address map. Having it the way it is right now, will help me add clean support for other pintypes on a given TLMM version. +- Pin groups as child nodes: The pin mux (selecting pin function + mode) and pin config (pull up/down, driver strength, direction) settings are + represented as child nodes of the pin-controller node. There is no limit on + the count of these child nodes. + + Required Properties +-qcom,pins: phandle specifying pin type and a pin number. +-qcom,num-grp-pins: number of pins in the group. +-label: name to to identify the pin group. + + Optional Properties +-qcom,pin-func: function setting for the pin group. After some scratching my head I realize that you are trying to reimplement parts of pinctrl-single.c. I.e. you try to put all the definitions of groups and functions into the devicetree instead of having this in the driver as tables. If this is what you want to do you should use pinctrl-single.c. It might be possible to use pinctrl-single.c only for the GP pins. I would prefer not to split the driver into one driver for its own pintype for above reasons. Also there isn't just one register per pin for gp pins, there are more registers. For example to configure direction, I have to touch additional registers then just the config register. Also for future TLMM version, we are very likely to move away from single config register. But if there is something complex about the hardware that make pinctrl-single.c not fit the bill I advice you to encode the lists of groups and functions into the driver instead. Also, split this in a per-soc manner (compare the other drivers) so you can support plugging one file per SoC for the different MSM chips using this pin controller. 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. Thanks Hanumant -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 7/29/2013 9:37 AM, Linus Walleij wrote: On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh hanum...@codeaurora.org wrote: Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. I guess this is the v4 patch set? Please include a small changelog so I can keep track of things... Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 This thing is not interesting to the kernel community. diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..0f17a94 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt This needs to be broken out and sent for separate review on the devicet...@vger.kernel.org mailing list. +Required Properties + - qcom,pin-type-*: identifies the pin type. Pin types supported are + qcom,pin-type-gp (General purpose) + qcom,pin-type-sdc (SDC) I am wondering if it it would not be simpler to split this driver in two, one for the GP pins and one for the SDC pins. Having this tag on each and every pin seems *very* awkward. If you have two drivers and two device tree nodes, one for GP pins and one for SDC pins, just separated by different compatible strings and different memory regs, things will look simpler and be easier to maintain I think. Unless there is some strong cross-dependency between GP and SDC please explore this approach. Actually we have had this discussion. There are more pin types on a TLMM then just these 2. The registers are interleaved. They are no separated at a clean page boundary. Also there is mode register that governs the function mode of the unifunction/single function pins like SDC. This register is again interspersed in the address map. Having it the way it is right now, will help me add clean support for other pintypes on a given TLMM version. +- Pin groups as child nodes: The pin mux (selecting pin function + mode) and pin config (pull up/down, driver strength, direction) settings are + represented as child nodes of the pin-controller node. There is no limit on + the count of these child nodes. + + Required Properties +-qcom,pins: phandle specifying pin type and a pin number. +-qcom,num-grp-pins: number of pins in the group. +-label: name to to identify the pin group. + + Optional Properties +-qcom,pin-func: function setting for the pin group. After some scratching my head I realize that you are trying to reimplement parts of pinctrl-single.c. I.e. you try to put all the definitions of groups and functions into the devicetree instead of having this in the driver as tables. If this is what you want to do you should use pinctrl-single.c. It might be possible to use pinctrl-single.c only for the GP pins. I would prefer not to split the driver into one driver for its own pintype for above reasons. Also there isn't just one register per pin for gp pins, there are more registers. For example to configure direction, I have to touch additional registers then just the config register. Also for future TLMM version, we are very likely to move away from single config register. But if there is something complex about the hardware that make pinctrl-single.c not fit the bill I advice you to encode the lists of groups and functions into the driver instead. Also, split this in a per-soc manner (compare the other drivers) so you can support plugging one file per SoC for the different MSM chips using this pin controller. 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. Thanks Hanumant -- Sent by an employee of the Qualcomm Innovation Center, Inc.
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. 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. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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? Thanks Hanumant that are valid for that -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 07/29/2013 10:37 AM, Linus Walleij wrote: > On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh > wrote: > >> Add a new device tree enabled pinctrl driver for >> Qualcomm MSM SoC's. This driver provides an extensible >> framework to interface all MSM's that use a TLMM pinmux, >> with the pinctrl subsytem. >> >> This driver is split into two parts: the pinctrl interface >> and the TLMM version specific implementation. The pinctrl >> interface parses the device tree and registers with the pinctrl >> subsytem. The TLMM version specific implementation supports >> pin configuration/register programming for the different >> pin types present on a given TLMM pinmux version. >> >> Add support only for TLMM version 3 pinmux right now, >> as well as, only two of the different pin types present on the >> TLMM v3 pinmux. >> Pintype 1: General purpose pins. >> Pintype 2: SDC pins. > > I guess this is the v4 patch set? > > Please include a small changelog so I can keep track of > things... > > >> Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 > > This thing is not interesting to the kernel community. > >> diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt >> b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt >> new file mode 100644 >> index 000..0f17a94 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt > > This needs to be broken out and sent for separate review on > the devicet...@vger.kernel.org mailing list. It certainly should be reviewed there, although I don't think the binding .txt file needs to be a separate patch. At present, it's quite typical to include the binding doc with the first driver that implements it, although that may change in the future; we'll see. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh wrote: > Add a new device tree enabled pinctrl driver for > Qualcomm MSM SoC's. This driver provides an extensible > framework to interface all MSM's that use a TLMM pinmux, > with the pinctrl subsytem. > > This driver is split into two parts: the pinctrl interface > and the TLMM version specific implementation. The pinctrl > interface parses the device tree and registers with the pinctrl > subsytem. The TLMM version specific implementation supports > pin configuration/register programming for the different > pin types present on a given TLMM pinmux version. > > Add support only for TLMM version 3 pinmux right now, > as well as, only two of the different pin types present on the > TLMM v3 pinmux. > Pintype 1: General purpose pins. > Pintype 2: SDC pins. I guess this is the v4 patch set? Please include a small changelog so I can keep track of things... > Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 This thing is not interesting to the kernel community. > diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt > new file mode 100644 > index 000..0f17a94 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt This needs to be broken out and sent for separate review on the devicet...@vger.kernel.org mailing list. > +Required Properties > + - qcom,pin-type-*: identifies the pin type. Pin types supported are > + qcom,pin-type-gp (General purpose) > + qcom,pin-type-sdc (SDC) I am wondering if it it would not be simpler to split this driver in two, one for the GP pins and one for the SDC pins. Having this tag on each and every pin seems *very* awkward. If you have two drivers and two device tree nodes, one for GP pins and one for SDC pins, just separated by different compatible strings and different memory regs, things will look simpler and be easier to maintain I think. Unless there is some strong cross-dependency between GP and SDC please explore this approach. > +- Pin groups as child nodes: The pin mux (selecting pin function > + mode) and pin config (pull up/down, driver strength, direction) settings > are > + represented as child nodes of the pin-controller node. There is no limit on > + the count of these child nodes. > + > + Required Properties > +-qcom,pins: phandle specifying pin type and a pin number. > +-qcom,num-grp-pins: number of pins in the group. > +-label: name to to identify the pin group. > + > + Optional Properties > +-qcom,pin-func: function setting for the pin group. After some scratching my head I realize that you are trying to reimplement parts of pinctrl-single.c. I.e. you try to put all the definitions of groups and functions into the devicetree instead of having this in the driver as tables. If this is what you want to do you should use pinctrl-single.c. It might be possible to use pinctrl-single.c only for the GP pins. But if there is something complex about the hardware that make pinctrl-single.c not fit the bill I advice you to encode the lists of groups and functions into the driver instead. Also, split this in a per-soc manner (compare the other drivers) so you can support plugging one file per SoC for the different MSM chips using this pin controller. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh hanum...@codeaurora.org wrote: Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. I guess this is the v4 patch set? Please include a small changelog so I can keep track of things... Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 This thing is not interesting to the kernel community. diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..0f17a94 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt This needs to be broken out and sent for separate review on the devicet...@vger.kernel.org mailing list. +Required Properties + - qcom,pin-type-*: identifies the pin type. Pin types supported are + qcom,pin-type-gp (General purpose) + qcom,pin-type-sdc (SDC) I am wondering if it it would not be simpler to split this driver in two, one for the GP pins and one for the SDC pins. Having this tag on each and every pin seems *very* awkward. If you have two drivers and two device tree nodes, one for GP pins and one for SDC pins, just separated by different compatible strings and different memory regs, things will look simpler and be easier to maintain I think. Unless there is some strong cross-dependency between GP and SDC please explore this approach. +- Pin groups as child nodes: The pin mux (selecting pin function + mode) and pin config (pull up/down, driver strength, direction) settings are + represented as child nodes of the pin-controller node. There is no limit on + the count of these child nodes. + + Required Properties +-qcom,pins: phandle specifying pin type and a pin number. +-qcom,num-grp-pins: number of pins in the group. +-label: name to to identify the pin group. + + Optional Properties +-qcom,pin-func: function setting for the pin group. After some scratching my head I realize that you are trying to reimplement parts of pinctrl-single.c. I.e. you try to put all the definitions of groups and functions into the devicetree instead of having this in the driver as tables. If this is what you want to do you should use pinctrl-single.c. It might be possible to use pinctrl-single.c only for the GP pins. But if there is something complex about the hardware that make pinctrl-single.c not fit the bill I advice you to encode the lists of groups and functions into the driver instead. Also, split this in a per-soc manner (compare the other drivers) so you can support plugging one file per SoC for the different MSM chips using this pin controller. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 07/29/2013 10:37 AM, Linus Walleij wrote: On Wed, Jul 24, 2013 at 11:41 PM, Hanumant Singh hanum...@codeaurora.org wrote: Add a new device tree enabled pinctrl driver for Qualcomm MSM SoC's. This driver provides an extensible framework to interface all MSM's that use a TLMM pinmux, with the pinctrl subsytem. This driver is split into two parts: the pinctrl interface and the TLMM version specific implementation. The pinctrl interface parses the device tree and registers with the pinctrl subsytem. The TLMM version specific implementation supports pin configuration/register programming for the different pin types present on a given TLMM pinmux version. Add support only for TLMM version 3 pinmux right now, as well as, only two of the different pin types present on the TLMM v3 pinmux. Pintype 1: General purpose pins. Pintype 2: SDC pins. I guess this is the v4 patch set? Please include a small changelog so I can keep track of things... Change-Id: I065d874cd2c6fd002d5b3cb4b355445bb6912bf4 This thing is not interesting to the kernel community. diff --git a/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt new file mode 100644 index 000..0f17a94 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt This needs to be broken out and sent for separate review on the devicet...@vger.kernel.org mailing list. It certainly should be reviewed there, although I don't think the binding .txt file needs to be a separate patch. At present, it's quite typical to include the binding doc with the first driver that implements it, although that may change in the future; we'll see. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 06/27/2013 01:26 AM, Linus Walleij wrote: > On Tue, Jun 25, 2013 at 7:41 PM, hanumant wrote: >> On 06/24/2013 05:18 AM, Linus Walleij wrote: > + The following pin configurations are properties are supported by SDC pins + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin. + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin. + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin. + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin. + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin. + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin. + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin. + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin. + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin. + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin. + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin. + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin. >>> >>> I don't understand why each sdc thing needs its own definition >>> for everything. Please use the generic pin config bindings, call the >>> generic parser function and then reject if someone tries to config >>> something that is not supported. >> >> The register semantics of SDC1 clk, command, and data lines, pull up and >> drive strength attributes differ from SDC2 clk, command and data lines. > > The register semantics does not have anything to do with the > representation in the device tree. The register semantics is a matter > for the driver, the device tree tells how to configure that driver, > the idea is not to name all species of config registers in the device > tree but to configure them, logically. Fair enough. I think this is possible to do. > >> In general the TLMM v3 has more pin types then just the general/multi >> purpose(gp) and SDC pin types above. >> There are some pin types on the TLMM, whose config attributes do not >> fall under the cattegories supported by generic pin config. > > One does not exclude the other. Some aspect of a pin > may be configured using the generic bindings, some aspect > need vendor-specific extensions. > >> These attributes in some cases happen to be protocol specific. >> Hence I would prefer to go with a custom config pack and unpack >> implementation rather then the generic one. > > I disagree, but I'm open to negotiations :-) How does this sound?. If the attributes of a pin type can be defined using the generic configs, I will use the generic configs and parser. If the attributes are entirely protocol/MSM specific, I will use custom configs and parsers. In terms of attributes of pins, all the pin types on the TLMM fall into either one of those categories, but never in both. 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, hosted by The Linux Foundation -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Tue, Jun 25, 2013 at 7:41 PM, hanumant wrote: > On 06/24/2013 05:18 AM, Linus Walleij wrote: >>> + The following pin configurations are properties are supported by SDC pins >>> + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin. >>> + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin. >>> + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin. >>> + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin. >>> + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin. >>> + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin. >>> + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin. >>> + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin. >>> + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin. >>> + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin. >>> + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin. >>> + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin. >> >> I don't understand why each sdc thing needs its own definition >> for everything. Please use the generic pin config bindings, call the >> generic parser function and then reject if someone tries to config >> something that is not supported. > > The register semantics of SDC1 clk, command, and data lines, pull up and > drive strength attributes differ from SDC2 clk, command and data lines. The register semantics does not have anything to do with the representation in the device tree. The register semantics is a matter for the driver, the device tree tells how to configure that driver, the idea is not to name all species of config registers in the device tree but to configure them, logically. > In general the TLMM v3 has more pin types then just the general/multi > purpose(gp) and SDC pin types above. > There are some pin types on the TLMM, whose config attributes do not > fall under the cattegories supported by generic pin config. One does not exclude the other. Some aspect of a pin may be configured using the generic bindings, some aspect need vendor-specific extensions. > These attributes in some cases happen to be protocol specific. > Hence I would prefer to go with a custom config pack and unpack > implementation rather then the generic one. I disagree, but I'm open to negotiations :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Tue, Jun 25, 2013 at 7:41 PM, hanumant hanum...@codeaurora.org wrote: On 06/24/2013 05:18 AM, Linus Walleij wrote: + The following pin configurations are properties are supported by SDC pins + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin. + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin. + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin. + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin. + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin. + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin. + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin. + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin. + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin. + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin. + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin. + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin. I don't understand why each sdc thing needs its own definition for everything. Please use the generic pin config bindings, call the generic parser function and then reject if someone tries to config something that is not supported. The register semantics of SDC1 clk, command, and data lines, pull up and drive strength attributes differ from SDC2 clk, command and data lines. The register semantics does not have anything to do with the representation in the device tree. The register semantics is a matter for the driver, the device tree tells how to configure that driver, the idea is not to name all species of config registers in the device tree but to configure them, logically. In general the TLMM v3 has more pin types then just the general/multi purpose(gp) and SDC pin types above. There are some pin types on the TLMM, whose config attributes do not fall under the cattegories supported by generic pin config. One does not exclude the other. Some aspect of a pin may be configured using the generic bindings, some aspect need vendor-specific extensions. These attributes in some cases happen to be protocol specific. Hence I would prefer to go with a custom config pack and unpack implementation rather then the generic one. I disagree, but I'm open to negotiations :-) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 06/27/2013 01:26 AM, Linus Walleij wrote: On Tue, Jun 25, 2013 at 7:41 PM, hanumant hanum...@codeaurora.org wrote: On 06/24/2013 05:18 AM, Linus Walleij wrote: + The following pin configurations are properties are supported by SDC pins + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin. + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin. + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin. + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin. + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin. + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin. + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin. + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin. + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin. + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin. + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin. + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin. I don't understand why each sdc thing needs its own definition for everything. Please use the generic pin config bindings, call the generic parser function and then reject if someone tries to config something that is not supported. The register semantics of SDC1 clk, command, and data lines, pull up and drive strength attributes differ from SDC2 clk, command and data lines. The register semantics does not have anything to do with the representation in the device tree. The register semantics is a matter for the driver, the device tree tells how to configure that driver, the idea is not to name all species of config registers in the device tree but to configure them, logically. Fair enough. I think this is possible to do. In general the TLMM v3 has more pin types then just the general/multi purpose(gp) and SDC pin types above. There are some pin types on the TLMM, whose config attributes do not fall under the cattegories supported by generic pin config. One does not exclude the other. Some aspect of a pin may be configured using the generic bindings, some aspect need vendor-specific extensions. These attributes in some cases happen to be protocol specific. Hence I would prefer to go with a custom config pack and unpack implementation rather then the generic one. I disagree, but I'm open to negotiations :-) How does this sound?. If the attributes of a pin type can be defined using the generic configs, I will use the generic configs and parser. If the attributes are entirely protocol/MSM specific, I will use custom configs and parsers. In terms of attributes of pins, all the pin types on the TLMM fall into either one of those categories, but never in both. 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, hosted by The Linux Foundation -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 06/24/2013 05:18 AM, Linus Walleij wrote:
>> +
>> + - qcom,gp-pull: Pull up/down configuration.
>> + - qcom,gp-drv: Drive strength configuration.
>> + - qcom,gp-dir: Pull up/down configuration in power down mode.
>
> Rebase this to use the generic pin config mappings and parsing
> code that can be found in the "devel" branch of the pinctrl tree.
>
>> + The following pin configurations are properties are supported by SDC pins
>> + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin.
>> + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin.
>> + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin.
>> + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin.
>> + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin.
>> + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin.
>> + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin.
>> + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin.
>> + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin.
>> + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin.
>> + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin.
>> + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin.
>
> I don't understand why each sdc thing needs its own definition
> for everything. Please use the generic pin config bindings, call the
> generic parser function and then reject if someone tries to config
> something that is not supported.
>
The register semantics of SDC1 clk, command, and data lines, pull up and
drive strength attributes differ from SDC2 clk, command and data lines.
In general the TLMM v3 has more pin types then just the general/multi
purpose(gp) and SDC pin types above.
There are some pin types on the TLMM, whose config attributes do not
fall under the cattegories supported by generic pin config.
These attributes in some cases happen to be protocol specific.
Hence I would prefer to go with a custom config pack and unpack
implementation rather then the generic one.
>
>> +Example 4: Set up the default pin state for spi controller.
>> +
>> + static inline int msm_spi_request_pins{struct msm_spi *dd)
>> + {
>> + /* ... */
>> + dd->pinctrl = devm_pinctrl_get_select_default(>dev);
>> + }
>
> Nowadays the device core will do this, so this is not any good
> advice. (See commit ab78029ecc347debbd737f06688d788bd9d60c1d)
I will modify this.
>
> I will look closer at this when it uses generic pinconf and
> generic pinconf DT bindings, let's target v3.12.
>
> Yours,
> Linus Walleij
>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On 06/24/2013 05:18 AM, Linus Walleij wrote:
+
+ - qcom,gp-pull: Pull up/down configuration.
+ - qcom,gp-drv: Drive strength configuration.
+ - qcom,gp-dir: Pull up/down configuration in power down mode.
Rebase this to use the generic pin config mappings and parsing
code that can be found in the devel branch of the pinctrl tree.
+ The following pin configurations are properties are supported by SDC pins
+ - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin.
+ - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin.
+ - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin.
+ - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin.
+ - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin.
+ - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin.
+ - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin.
+ - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin.
+ - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin.
+ - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin.
+ - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin.
+ - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin.
I don't understand why each sdc thing needs its own definition
for everything. Please use the generic pin config bindings, call the
generic parser function and then reject if someone tries to config
something that is not supported.
The register semantics of SDC1 clk, command, and data lines, pull up and
drive strength attributes differ from SDC2 clk, command and data lines.
In general the TLMM v3 has more pin types then just the general/multi
purpose(gp) and SDC pin types above.
There are some pin types on the TLMM, whose config attributes do not
fall under the cattegories supported by generic pin config.
These attributes in some cases happen to be protocol specific.
Hence I would prefer to go with a custom config pack and unpack
implementation rather then the generic one.
+Example 4: Set up the default pin state for spi controller.
+
+ static inline int msm_spi_request_pins{struct msm_spi *dd)
+ {
+ /* ... */
+ dd-pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ }
Nowadays the device core will do this, so this is not any good
advice. (See commit ab78029ecc347debbd737f06688d788bd9d60c1d)
I will modify this.
I will look closer at this when it uses generic pinconf and
generic pinconf DT bindings, let's target v3.12.
Yours,
Linus Walleij
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Fri, Jun 21, 2013 at 11:52 PM, Hanumant Singh
wrote:
> Add a new device tree enabled pinctrl driver for
> Qualcomm MSM SoC's. This driver provides an extensible
> framework to interface all MSM's that use a TLMM pinmux,
> with the pinctrl subsytem.
This is really nice.
> + The pin group node must additionally have a pin configuration node as its
> own
> + child node. There can be more then one such configuration node for a pin
> group
> + node. There can be one or more configurations within the configuration
> + node. These configurations are applied to all pins mentoned above using the
> + "qcom,pins" property. These configurations are specific to the pintype of
> the
> + pins. The following pin configuration properties are supported by general
> + purpose pins.
> +
> + - qcom,gp-pull: Pull up/down configuration.
> + - qcom,gp-drv: Drive strength configuration.
> + - qcom,gp-dir: Pull up/down configuration in power down mode.
Rebase this to use the generic pin config mappings and parsing
code that can be found in the "devel" branch of the pinctrl tree.
> + The following pin configurations are properties are supported by SDC pins
> + - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin.
> + - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin.
> + - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin.
> + - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin.
> + - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin.
> + - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin.
> + - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin.
> + - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin.
> + - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin.
> + - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin.
> + - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin.
> + - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin.
I don't understand why each sdc thing needs its own definition
for everything. Please use the generic pin config bindings, call the
generic parser function and then reject if someone tries to config
something that is not supported.
> + spi-bus {
> + /*
> +* MOSI, MISO and CLK lines
> +* all sharing same function and config
> +* settings for each configuration node.
> +*/
> + qcom,pins = < 0>, < 1>, < 3>;
> + qcom,pin-func = <1>;
> +
> + /* Active configuration of bus pins */
> + spi-bus-active: spi-bus-active {
> + qcom,gp-drv = <3>; /* 8 MA */
> + qcom,gp-pull = <0>; /* No PULL */
This would be:
drive-strength = <8>;
bias-disable;
With the generic bindings I believe.
> +Example 4: Set up the default pin state for spi controller.
> +
> + static inline int msm_spi_request_pins{struct msm_spi *dd)
> + {
> + /* ... */
> + dd->pinctrl = devm_pinctrl_get_select_default(>dev);
> + }
Nowadays the device core will do this, so this is not any good
advice. (See commit ab78029ecc347debbd737f06688d788bd9d60c1d)
I will look closer at this when it uses generic pinconf and
generic pinconf DT bindings, let's target v3.12.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux
On Fri, Jun 21, 2013 at 11:52 PM, Hanumant Singh
hanum...@codeaurora.org wrote:
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
This is really nice.
+ The pin group node must additionally have a pin configuration node as its
own
+ child node. There can be more then one such configuration node for a pin
group
+ node. There can be one or more configurations within the configuration
+ node. These configurations are applied to all pins mentoned above using the
+ qcom,pins property. These configurations are specific to the pintype of
the
+ pins. The following pin configuration properties are supported by general
+ purpose pins.
+
+ - qcom,gp-pull: Pull up/down configuration.
+ - qcom,gp-drv: Drive strength configuration.
+ - qcom,gp-dir: Pull up/down configuration in power down mode.
Rebase this to use the generic pin config mappings and parsing
code that can be found in the devel branch of the pinctrl tree.
+ The following pin configurations are properties are supported by SDC pins
+ - qcom,sdc1-clk-pull: Pull up/down configuration SDC1 clock pin.
+ - qcom,sdc1-clk-drv: Drive strength configuration for SDC1 clock pin.
+ - qcom,sdc1-cmd-pull: Pull up/down configuration for SDC1 command pin.
+ - qcom,sdc1-cmd-drv: Drive strength configuration for SDC1 command pin.
+ - qcom,sdc1-data-pull: Pull up/down configuration for SDC1 data pin.
+ - qcom,sdc1-data-drv: Drive strength configuration for SDC1 data pin.
+ - qcom,sdc2-clk-pull: Pull up/down configuration SDC2 clock pin.
+ - qcom,sdc2-clk-drv: Drive strength configuration for SDC2 clock pin.
+ - qcom,sdc2-cmd-pull: Pull up/down configuration for SDC2 command pin.
+ - qcom,sdc2-cmd-drv: Drive strength configuration for SDC2 command pin.
+ - qcom,sdc2-data-pull: Pull up/down configuration for SDC2 data pin.
+ - qcom,sdc2-data-drv: Drive strength configuration for SDC2 data pin.
I don't understand why each sdc thing needs its own definition
for everything. Please use the generic pin config bindings, call the
generic parser function and then reject if someone tries to config
something that is not supported.
+ spi-bus {
+ /*
+* MOSI, MISO and CLK lines
+* all sharing same function and config
+* settings for each configuration node.
+*/
+ qcom,pins = gp 0, gp 1, gp 3;
+ qcom,pin-func = 1;
+
+ /* Active configuration of bus pins */
+ spi-bus-active: spi-bus-active {
+ qcom,gp-drv = 3; /* 8 MA */
+ qcom,gp-pull = 0; /* No PULL */
This would be:
drive-strength = 8;
bias-disable;
With the generic bindings I believe.
+Example 4: Set up the default pin state for spi controller.
+
+ static inline int msm_spi_request_pins{struct msm_spi *dd)
+ {
+ /* ... */
+ dd-pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ }
Nowadays the device core will do this, so this is not any good
advice. (See commit ab78029ecc347debbd737f06688d788bd9d60c1d)
I will look closer at this when it uses generic pinconf and
generic pinconf DT bindings, let's target v3.12.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
