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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
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.

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

--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux