On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak rnayak@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.
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