Re: [PATCH] pinctrl: msm: Add support for MSM TLMM pinmux

[Linus Walleij]

On Thu, Aug 15, 2013 at 11:28 PM, Hanumant Singh
<hanumant@xxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/