Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Thu, Nov 24, 2011 at 8:54 PM, Tony Lindgren t...@atomide.com wrote: We should probably pass over the static board specific mapping as platform_data to the pinmux device and make it be part of struct pinctrl_dev. Then new driver instances can have their own pctldev-mapping and we can support both platform_data and device tree based drivers on the same system. That sounds like a real good idea and I think it'll work fine. You can use the map in mach-u300/core.c as guinea pig for refactoring if you like. I think that's the only map that's in-tree ftm. Thanks, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren t...@atomide.com wrote: Note that with device tree things get simpler for muxing as we can get rid of the hardcoded grouping of pins in mux drivers. Instead of hardcoded pingroups, the groups can be created dynamically based on what the driver DT entries have. Yes, I know too little about DT to figure out how these should come in. The reason why we want to avoid hardcoded pin groups is because trying to map all the pad combinations in the pinmux driver is not a scalable way to go. And it's not even possible at least on omaps because of the huge number of combinations with alternative pins and multiple packages. Yes, that's a solid case! FYI I'm playing with a DT based pinmux-simple.c driver that should be pretty generic and work for all kinds of hardware hopefully. I love it. It will be few days before I can post anything though, there are some pinctrl fwk issues to deal with first. Like the hardcoded pinmux_maps that assumes that dev entries are static. This means that multiple instances of pinmux drivers won't work.. I'm not following, but I guess I will understand when I see the patches. The idea behind the current map concept is that you get either a string or struct device * to identify the pin controller and mapped device, that's as far as I thought it out, sorry for any inherent limitations, they're not intentional... Thanks, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Wed, Nov 23, 2011 at 1:28 AM, Stephen Warren swar...@nvidia.com wrote: Describing the HW doesn't necessarily mean that each device needs to describe what pinmux pins it uses; one could quite easily have the pinmux describe what settings the various pins should have and which drivers will use those pins. That would map very well to the pinctrl subsystem's mapping table, and at least Tegra's existing pinmux tables, which are both just a big array of settings which end up getting provided to drivers. That sounds true. It's also something that is cleanly cut out as a very well defined and abstract piece of hardware information to live in the device tree and which would be useful for any OS using DT. I'd have to see the device trees and corresponding map bindings before I understand it fully though. Just my €0.01 Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Hi, * Linus Walleij linus.wall...@linaro.org [24 01:29]: On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren t...@atomide.com wrote: Note that with device tree things get simpler for muxing as we can get rid of the hardcoded grouping of pins in mux drivers. Instead of hardcoded pingroups, the groups can be created dynamically based on what the driver DT entries have. Yes, I know too little about DT to figure out how these should come in. The reason why we want to avoid hardcoded pin groups is because trying to map all the pad combinations in the pinmux driver is not a scalable way to go. And it's not even possible at least on omaps because of the huge number of combinations with alternative pins and multiple packages. Yes, that's a solid case! So far it seems that device tree simplifies things here quite a bit in at least two ways: - We by default have automatically generated 1:1 mapping of devices to groups (of course others can be added too) - We should be able to support new SoC packages with different pin on existing kernels, like distro kernels, just by modifying the the device tree data ;) FYI I'm playing with a DT based pinmux-simple.c driver that should be pretty generic and work for all kinds of hardware hopefully. I love it. Still need few more days with these patches.. It will be few days before I can post anything though, there are some pinctrl fwk issues to deal with first. Like the hardcoded pinmux_maps that assumes that dev entries are static. This means that multiple instances of pinmux drivers won't work.. I'm not following, but I guess I will understand when I see the patches. The idea behind the current map concept is that you get either a string or struct device * to identify the pin controller and mapped device, that's as far as I thought it out, sorry for any inherent limitations, they're not intentional... Yeah we can sort those out afterwards. We should probably pass over the static board specific mapping as platform_data to the pinmux device and make it be part of struct pinctrl_dev. Then new driver instances can have their own pctldev-mapping and we can support both platform_data and device tree based drivers on the same system. Anyways, I'll try to get the initial patches working with just one instance to start with so we have something to play with. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 16:28 Tue 22 Nov , Stephen Warren wrote:
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...
I agreee here
as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration
so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
pins = mii;
or
pins = rmii;
or if I want to use the alternative config
pins = mii_alt;
or
pins = rmii_alt;
and then in the dtsi I describe the pin used for those configs
which is soc specifific not board
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Note that we should use the actual signal names, not package specific
pad names. This way they have a high likelyhood to work for new packages
too by just mapping the signals to the new package.
How would this handle the situation where you can mux a signal to multiple
pins? IIRC omap3 and am335x can do funny stuff with the display pins like being
able to map the blue bits to different pinblocks.
regards,
Koen
signature.asc
Description: Message signed with OpenPGP using GPGMail
RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Koen Kooi
Sent: Wednesday, November 23, 2011 8:51 PM
To: Tony Lindgren
Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux-
o...@vger.kernel.org; linaro-...@lists.linaro.org;
linus.wall...@stericsson.com; linux-samsung-soc; devicetree-
disc...@lists.ozlabs.org
Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Note that we should use the actual signal names, not package specific
pad names. This way they have a high likelyhood to work for new packages
too by just mapping the signals to the new package.
How would this handle the situation where you can mux a signal to multiple
pins? IIRC omap3 and am335x can do funny stuff with the display pins like
being able to map the blue bits to different pinblocks.
That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and
G0-G7; what changes is pixel format.
AM335x LCDC is completely different IP altogether and spec doesn't map
Colors to pins. It barely maps bit0 from memory to pinX.
Now you call it as a standard or legacy or may be due to SGX software,
the pixel format we use is BGR (as in memory).
It is completely depends on how you interface the pins to LCD (considering)
Software support/requirement.
Thanks,
Vaibhav
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Hi Linus,
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
For now, the Samsung GPIO, Pinconfig and Pinmux information is
represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
All existing dt support in samsung drivers use this format and it
works fine. But I could not complete work on time and pull request for
samsung-dt support for 3.2 was delayed and hence rejected. So for now,
it is out of tree but available in linux-next.
i2c@1C004000 {
compatible = ...;
reg = 0x... 0x..;
gpios = gpa0 2 2 3 0,
gpa0 3 2 3 0;
...
};
The format of the gpio specifier is
[Pad Controller phandle] [pin number within the controller] [Pin Mux
Function] [Pull Up/Down] [Drive Strength]
From a perspective of writing a 'gpios' property for a device node,
this is quite simple. Looking up the hardware manual of the SoC can
provide all the values that should be used in the gpio specifier.
That may not be as simple as it seems if all you have is the
device tree and no manual, but I get the picture.
The GPIO/PinCtrl driver can provide a translate function that picks up
the values for the gpio specifier and writes the same value to the
pad-controller registers. But, this a deviation from the existing
pinctrl subsystem code which mainly relies on name of the pin-group
and pin-function.
Does this seem to be a feasible option for specifying
gpio/pinconfig/pinmux dt bindings?
I would prefer the above to use the nice generic enums from the
pin control subsystem's pinmux and pinconf properties in the
end so the device tree on its own is understandable without
any manual whatsoever, but we'll see about that.
This may lead to linux specific information getting into the device
tree. And that might not be acceptable.
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
Thanks,
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
So for example in the pinctrl-coh901xxx.c example driver I have
locally defined registers presets like:
#define U300_FLOATING_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_HIGH_IMPEDANCE, \
.output = false, \
}
#define U300_PULL_UP_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_PULL_UP, \
.output = false, \
}
Then this type of stuff shall keep its custom format in the device
tree, and the driver for coh901xxx reads that out.
Thanks for helping me understand this crucial assumption of how
it works...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Note that we should use the actual signal names, not package specific
pad names. This way they have a high likelyhood to work for new packages
too by just mapping the signals to the new package.
So for example in the pinctrl-coh901xxx.c example driver I have
locally defined registers presets like:
#define U300_FLOATING_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_HIGH_IMPEDANCE, \
.output = false, \
}
#define U300_PULL_UP_INPUT { \
.bias_mode = PIN_CONFIG_BIAS_PULL_UP, \
.output = false, \
}
I think things like above should also be set in the node for the
driver because it is board specific. For example, if you have an
external pull on the board for some line, then the internal pull
needs to be disabled.
I don't know how we should describe the driver set values though,
maybe something like:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
pin-values = 0x7 0x7 ;
};
Note that with device tree things get simpler for muxing as we can
get rid of the hardcoded grouping of pins in mux drivers. Instead of
hardcoded pingroups, the groups can be created dynamically based on
what the driver DT entries have.
The reason why we want to avoid hardcoded pin groups is because trying
to map all the pad combinations in the pinmux driver is not a scalable
way to go. And it's not even possible at least on omaps because of the
huge number of combinations with alternative pins and multiple packages.
Then this type of stuff shall keep its custom format in the device
tree, and the driver for coh901xxx reads that out.
Thanks for helping me understand this crucial assumption of how
it works...
FYI I'm playing with a DT based pinmux-simple.c driver that should
be pretty generic and work for all kinds of hardware hopefully.
It will be few days before I can post anything though, there are
some pinctrl fwk issues to deal with first. Like the hardcoded
pinmux_maps that assumes that dev entries are static. This means
that multiple instances of pinmux drivers won't work..
Cheers,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...
--
nvpublic
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Tue, Nov 15, 2011 at 5:33 AM, Rajendra Nayak rna...@ti.com wrote:
On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [14 04:05]:
+static const struct pinctrl_pin_desc omap4_core_pads[] = {
+ PINCTRL_PIN(0, c12),
+ PINCTRL_PIN(1, d12),
+ PINCTRL_PIN(2, c13),
...
Let's not even plan on adding this data here. We already have
about 6000 lines of pinmux data for omaps even without this patch.
But the plan is to get rid of those 6000 lines of pinmux data that
exists today for OMAP. I did not remove it now, because I still need
to take care of the pull up/down configurations which are missing.
Once thats in place, we can get rid of the existing data completely.
Linus,
Is there a plan to move even the data that exists in the pinmux
drivers today (including the function/pin-groups definition)
eventually to DT? Or is it just the 'mapping' data to map
devices to functions (that today is done from board files) which
alone will be moved?
Not for the U300 driver, for the simple reason that it cannot
use device tree. So both methods of providing the data need
to be allowed - either as static data (the U300 driver does not
even have platform data, the pin data is encoded in the driver
itself since it's tied to U300 and not used for any other systems
or variants) or as device tree lookups.
That said I have no clue on how to make the DT bindings
FTM, patches and suggestions welcome.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak rna...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayakrna...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 17 November 2011 13:38, Linus Walleij linus.wall...@linaro.org wrote:
Linus,
Is there a plan to move even the data that exists in the pinmux
drivers today (including the function/pin-groups definition)
eventually to DT? Or is it just the 'mapping' data to map
devices to functions (that today is done from board files) which
alone will be moved?
Not for the U300 driver, for the simple reason that it cannot
use device tree. So both methods of providing the data need
to be allowed - either as static data (the U300 driver does not
even have platform data, the pin data is encoded in the driver
itself since it's tied to U300 and not used for any other systems
or variants) or as device tree lookups.
That said I have no clue on how to make the DT bindings
FTM, patches and suggestions welcome.
For now, the Samsung GPIO, Pinconfig and Pinmux information is
represented in device tree as listed below.
i2c@1C004000 {
compatible = ...;
reg = 0x... 0x..;
gpios = gpa0 2 2 3 0,
gpa0 3 2 3 0;
...
};
The format of the gpio specifier is
[Pad Controller phandle] [pin number within the controller] [Pin Mux
Function] [Pull Up/Down] [Drive Strength]
From a perspective of writing a 'gpios' property for a device node,
this is quite simple. Looking up the hardware manual of the SoC can
provide all the values that should be used in the gpio specifier.
The GPIO/PinCtrl driver can provide a translate function that picks up
the values for the gpio specifier and writes the same value to the
pad-controller registers. But, this a deviation from the existing
pinctrl subsystem code which mainly relies on name of the pin-group
and pin-function.
Does this seem to be a feasible option for specifying
gpio/pinconfig/pinmux dt bindings?
Thanks.
Thomas.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
For now, the Samsung GPIO, Pinconfig and Pinmux information is
represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
i2c@1C004000 {
compatible = ...;
reg = 0x... 0x..;
gpios = gpa0 2 2 3 0,
gpa0 3 2 3 0;
...
};
The format of the gpio specifier is
[Pad Controller phandle] [pin number within the controller] [Pin Mux
Function] [Pull Up/Down] [Drive Strength]
From a perspective of writing a 'gpios' property for a device node,
this is quite simple. Looking up the hardware manual of the SoC can
provide all the values that should be used in the gpio specifier.
That may not be as simple as it seems if all you have is the
device tree and no manual, but I get the picture.
The GPIO/PinCtrl driver can provide a translate function that picks up
the values for the gpio specifier and writes the same value to the
pad-controller registers. But, this a deviation from the existing
pinctrl subsystem code which mainly relies on name of the pin-group
and pin-function.
Does this seem to be a feasible option for specifying
gpio/pinconfig/pinmux dt bindings?
I would prefer the above to use the nice generic enums from the
pin control subsystem's pinmux and pinconf properties in the
end so the device tree on its own is understandable without
any manual whatsoever, but we'll see about that.
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
* Rajendra Nayak rna...@ti.com [14 04:05]:
--- /dev/null
+++ b/drivers/pinctrl/pinmux-omap.c
@@ -0,0 +1,735 @@
+
+/* omap4 core pads */
+static const struct pinctrl_pin_desc omap4_core_pads[] = {
+ PINCTRL_PIN(0, c12),
+ PINCTRL_PIN(1, d12),
+ PINCTRL_PIN(2, c13),
...
Let's not even plan on adding this data here. We already have
about 6000 lines of pinmux data for omaps even without this patch.
Instead, just write something as a separate patch that populates
omap pinmux data from the existing data until we have the data
coming from DT.
+/* omap4 wkup pads */
+static const struct pinctrl_pin_desc omap4_wkup_pads[] = {
+ PINCTRL_PIN(0, c12),
+ PINCTRL_PIN(1, d12),
+ PINCTRL_PIN(2, c13),
...
This too needs to go.
+static const unsigned hdmi_pins[] = {
+ 44, /* HDMI_HPD */
+ 45, /* HDMI_CEC */
+ 46, /* HDMI_DDC_SCL */
+ 47, /* HDMI_DDC_SDA */
+};
+
+static const unsigned hdmi_muxmodes[] = {
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+};
+
+static const unsigned sdmmc5_pins[] = {
+ 132, /* WLAN SDIO: MMC5 CMD */
+ 133, /* WLAN SDIO: MMC5 CLK */
+ 134, /* WLAN SDIO: MMC5 DAT0 */
+ 135, /* WLAN SDIO: MMC5 DAT1 */
+ 136, /* WLAN SDIO: MMC5 DAT2 */
+ 137, /* WLAN SDIO: MMC5 DAT3 */
+};
+
+static const unsigned sdmmc5_muxmodes[] = {
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+ OMAP_MUX_MODE0,
+};
+
+static const unsigned dispc2_pins[] = {
+ 145, /* dispc2_data23 */
+ 146, /* dispc2_data22 */
+ 147, /* dispc2_data21 */
...
And all of the above.. The same goes for all the static package
specific data.
+/* handle 8 bit registers too, for now only worry about 16bit ones*/
+static u16 omap_pmx_read(struct omap_pmx *opmx, unsigned pin)
+{
+ return __raw_readw(opmx-virtbase + (pin * 2));
+}
+
+static void omap_pmx_write(u16 val, struct omap_pmx *opmx, unsigned pin)
+{
+ __raw_writew(val, opmx-virtbase + (pin * 2));
+}
Might as well fix this one since we already have it working.
The rest looks OK to me as a minimal driver. I don't know if
we should still populate it with platform_data though, that
seems already broken as it's omap4 only. Might as well go with
the DT support to start with.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
* Rajendra Nayakrna...@ti.com [14 04:05]:
--- /dev/null
+++ b/drivers/pinctrl/pinmux-omap.c
@@ -0,0 +1,735 @@
+
+/* omap4 core pads */
+static const struct pinctrl_pin_desc omap4_core_pads[] = {
+ PINCTRL_PIN(0, c12),
+ PINCTRL_PIN(1, d12),
+ PINCTRL_PIN(2, c13),
...
Let's not even plan on adding this data here. We already have
about 6000 lines of pinmux data for omaps even without this patch.
Instead, just write something as a separate patch that populates
omap pinmux data from the existing data until we have the data
coming from DT.
But the plan is to get rid of those 6000 lines of pinmux data that
exists today for OMAP. I did not remove it now, because I still need
to take care of the pull up/down configurations which are missing.
Once thats in place, we can get rid of the existing data completely.
Linus,
Is there a plan to move even the data that exists in the pinmux
drivers today (including the function/pin-groups definition)
eventually to DT? Or is it just the 'mapping' data to map
devices to functions (that today is done from board files) which
alone will be moved?
regards,
Rajendra
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
