[RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Rajendra Nayak]

On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
> On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak<rnayak at ti.com>  wrote:
>
> (...)
>> + * The OMAP control module has a device-control sub-module
>> + * which handles all pin/padmuxing for OMAP. The sub-module
>> + * is further split into a 'core' instance within the CORE
>> + * powerdomain and a 'wkup' instance within the WAKEUP
>> + * powerdomain (which is always powered on)
> (...)
>> +/* omap4 core pads */
>> +static const struct pinctrl_pin_desc omap4_core_pads[] = {
>> +       PINCTRL_PIN(0, "c12"),
>> +       PINCTRL_PIN(1, "d12"),
>> +       PINCTRL_PIN(2, "c13"),
> (...)
>> +/* omap4 wkup pads */
>> +static const struct pinctrl_pin_desc omap4_wkup_pads[] = {
>> +       PINCTRL_PIN(0, "c12"),
>> +       PINCTRL_PIN(1, "d12"),
>> +       PINCTRL_PIN(2, "c13"),
> (...)
>
> I have a hard time wrapping my head around why you need to define
> all the same pads twice and adding two almost identical pin
> controllers.

Oops, I seem to have completely messed up with the omap4_wkup_pads
table.. It should have been just these pins from the table

+	PINCTRL_PIN(50, "h4"),
+	PINCTRL_PIN(51, "j2"),
+	PINCTRL_PIN(52, "g2"),
+	PINCTRL_PIN(53, "j1"),
+	PINCTRL_PIN(54, "k1"),
+	PINCTRL_PIN(55, "ag9"),
+	PINCTRL_PIN(56, "af9"),
+	PINCTRL_PIN(57, "ah6"),
+	PINCTRL_PIN(58, "ag8"),
+	PINCTRL_PIN(59, "ad1"),
+	PINCTRL_PIN(60, "ad2"),
+	PINCTRL_PIN(61, "ad3"),
+	PINCTRL_PIN(62, "ad4"),
+	PINCTRL_PIN(63, "ac2"),
+	PINCTRL_PIN(64, "ac3"),
+	PINCTRL_PIN(65, "ag7"),
+	PINCTRL_PIN(66, "ae7"),
+	PINCTRL_PIN(67, "af7"),
+	PINCTRL_PIN(68, "ah7"),
+	PINCTRL_PIN(69, "ag6"),
+	PINCTRL_PIN(70, "af8"),
+	PINCTRL_PIN(71, "ae8"),
+	PINCTRL_PIN(72, "ah2"),
+	PINCTRL_PIN(73, "ag1"),
+	PINCTRL_PIN(74, "ae3"),
+	PINCTRL_PIN(75, "ah1"),
+	PINCTRL_PIN(76, "ae1"),
+	PINCTRL_PIN(77, "ae2"),

But somehow I ended up with having the first 49 pins duplicated from
the omap4_core_pads table.
Will fix up, and sorry for all the confusion.

>
> Probably it's just me lacking understanding ...
>
> My recent thinking about wakeups is rather (built on experience with
> the hardware I've seen) that you define a number of states for each
> pinmux group so it can be set in say active, low_power and sleep
> state, which will reconfigure the pads associated with each mux for
> respective mode.
>
> In the current pin config patch set we also have a
> PIN_CONFIG_WAKEUP property that can be set on a per-pin
> basis to say configure that a specific pin shall trigger a wakeup
> of the system if it's in sleep state.
>
> So my idea is that when you switch states of pin muxes, say from
> active to sleeping, the subsystem will call the driver to reprogram
> the pins to sleep mode, typically grounding some pins, biasing
> some other pins and setting the wakeup property of some
> pins.
>
> So is this really two different sets of registers for the same pads at
> totally different places in memory, or is this some way of modeling
> different modes for the same pads? If it's the latter we need some
> better abstraction than doing it all twice.

These are different pads/pins and controlled through different set of
registers.

>
> Yours,
> Linus Walleij