On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak <rnayak@xxxxxx> 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.
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.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
