* gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4
@ 2011-02-21 13:58 Koyamangalath, Abhilash
2011-02-22 9:53 ` Anand Gadiyar
0 siblings, 1 reply; 3+ messages in thread
From: Koyamangalath, Abhilash @ 2011-02-21 13:58 UTC (permalink / raw)
To: linux-omap@vger.kernel.org
There is this boot-time message on the am3517evm (and possibly
other omap 35xx based boards as well)
[ 0.000000] _omap_mux_init_gpio: Multiple gpio paths
(2) for gpio126
I realized that this happens due to dual mappings for gpio_126 in arch/arm/mach-omap2/mux34xx.c:
static struct omap_mux __initdata omap3_muxmodes[] = {
:
_OMAP3_MUXENTRY(CAM_STROBE, 126,
"cam_strobe", NULL, NULL, NULL,
"gpio_126", "hw_dbg11", NULL, "safe_mode"),
:
_OMAP3_MUXENTRY(SDMMC1_DAT4, 126,
"sdmmc1_dat4", NULL, "sim_io", NULL,
"gpio_126", NULL, NULL, "safe_mode"),
:
#if defined(CONFIG_OMAP_MUX) && defined(CONFIG_OMAP_PACKAGE_CBB) static struct omap_mux __initdata omap3_cbb_subset[] = {
:
_OMAP3_MUXENTRY(CAM_STROBE, 126,
"cam_strobe", NULL, NULL, NULL,
"gpio_126", NULL, NULL, "safe_mode"),
Removing one instance of CAM_STROBE from omap3_muxmodes rids us
of this (pr_info) message and should be fine as this is defined in
omap3_xxx_subset as well. But I'm concerned if this would break things
on the other omap3 boards?
For completeness, I've listed my patch (only for the CBB package) below
(this also modifies the Mode 5 value of CAM_STROBE from NULL to hw_dbg11
in omap3_cbb_subset, which is incorrect right now); please comment:
---
arch/arm/mach-omap2/mux34xx.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c index 440c98e..2517141 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -86,9 +86,6 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
_OMAP3_MUXENTRY(CAM_PCLK, 97,
"cam_pclk", NULL, NULL, NULL,
"gpio_97", "hw_dbg2", NULL, "safe_mode"),
- _OMAP3_MUXENTRY(CAM_STROBE, 126,
- "cam_strobe", NULL, NULL, NULL,
- "gpio_126", "hw_dbg11", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_VS, 95,
"cam_vs", NULL, NULL, NULL,
"gpio_95", "hw_dbg1", NULL, "safe_mode"), @@ -1299,7 +1296,7 @@ static struct omap_mux __initdata omap3_cbb_subset[] = {
"gpio_97", NULL, NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_STROBE, 126,
"cam_strobe", NULL, NULL, NULL,
- "gpio_126", NULL, NULL, "safe_mode"),
+ "gpio_126", "hw_dbg11", NULL, "safe_mode"),
_OMAP3_MUXENTRY(CAM_VS, 95,
"cam_vs", NULL, NULL, NULL,
"gpio_95", NULL, NULL, "safe_mode"),
--
1.6.2.4
^ permalink raw reply [flat|nested] 3+ messages in thread* RE: gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4
2011-02-21 13:58 gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4 Koyamangalath, Abhilash
@ 2011-02-22 9:53 ` Anand Gadiyar
2011-02-24 21:19 ` Tony Lindgren
0 siblings, 1 reply; 3+ messages in thread
From: Anand Gadiyar @ 2011-02-22 9:53 UTC (permalink / raw)
To: Abhilash Koyamangalath, linux-omap
Koyamangalath, Abhilash wrote:
> There is this boot-time message on the am3517evm (and possibly
> other omap 35xx based boards as well)
> [ 0.000000] _omap_mux_init_gpio: Multiple gpio paths
> (2) for gpio126
> I realized that this happens due to dual mappings for
> gpio_126 in arch/arm/mach-omap2/mux34xx.c:
>
> static struct omap_mux __initdata omap3_muxmodes[] = {
> :
> _OMAP3_MUXENTRY(CAM_STROBE, 126,
> "cam_strobe", NULL, NULL, NULL,
> "gpio_126", "hw_dbg11", NULL, "safe_mode"),
> :
> _OMAP3_MUXENTRY(SDMMC1_DAT4, 126,
> "sdmmc1_dat4", NULL, "sim_io", NULL,
> "gpio_126", NULL, NULL, "safe_mode"),
> :
> #if defined(CONFIG_OMAP_MUX) &&
> defined(CONFIG_OMAP_PACKAGE_CBB) static struct omap_mux
> __initdata omap3_cbb_subset[] = {
> :
> _OMAP3_MUXENTRY(CAM_STROBE, 126,
> "cam_strobe", NULL, NULL, NULL,
> "gpio_126", NULL, NULL, "safe_mode"),
>
> Removing one instance of CAM_STROBE from omap3_muxmodes rids us
> of this (pr_info) message and should be fine as this is defined in
> omap3_xxx_subset as well. But I'm concerned if this would
> break things
> on the other omap3 boards?
>
> For completeness, I've listed my patch (only for the CBB
> package) below
> (this also modifies the Mode 5 value of CAM_STROBE from NULL
> to hw_dbg11
> in omap3_cbb_subset, which is incorrect right now); please comment:
>
> ---
The GPIO 126 signal is available on two pads of that package.
You will therefore need to update the caller to use
omap_mux_init_signal specifying the full name as "cam_strobe.gpio_126"
or equivalent.
I'm not sure if you can do something similar using omap_mux_init_gpio.
Dropping an entry from the table is not the right way to go.
- Anand
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4
2011-02-22 9:53 ` Anand Gadiyar
@ 2011-02-24 21:19 ` Tony Lindgren
0 siblings, 0 replies; 3+ messages in thread
From: Tony Lindgren @ 2011-02-24 21:19 UTC (permalink / raw)
To: Anand Gadiyar; +Cc: Abhilash Koyamangalath, linux-omap
* Anand Gadiyar <gadiyar@ti.com> [110222 01:51]:
> Koyamangalath, Abhilash wrote:
>
> The GPIO 126 signal is available on two pads of that package.
> You will therefore need to update the caller to use
> omap_mux_init_signal specifying the full name as "cam_strobe.gpio_126"
> or equivalent.
Yes, that's the right way to fix it.
> I'm not sure if you can do something similar using omap_mux_init_gpio.
No, that one only understands numbers.
> Dropping an entry from the table is not the right way to go.
Right.
Tony
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-02-24 21:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-21 13:58 gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4 Koyamangalath, Abhilash
2011-02-22 9:53 ` Anand Gadiyar
2011-02-24 21:19 ` Tony Lindgren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox