From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:35:47
This is my set of patches for fixing OMAP for v3.3.
This is the complete series of patches I'm currently applying to _my_
tree to get v3.3-rc2 into a usable and sane state.
I want to see most of the problems uncovered in this series fixed sooner
rather than later, and certainly not taking three plus weeks to get into
mainline like this rather serious looking commit did:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
@@ -41,6 +41,11 @@ void __init omap_vp_init(struct voltagedomain *voltdm)u32val,sys_clk_rate,timeout,waittime;u32vddmin,vddmax,vstepmin,vstepmax;+if(!voltdm->pmic){+pr_err("%s: No PMIC info for vdd_%s\n",__func__,voltdm->name);+return;+}+if(!voltdm->read||!voltdm->write){pr_err("%s: No read/write API for accessing vdd_%s regs\n",__func__,voltdm->name);
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:37:08
arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/prm44xx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:37:29
While testing on my OMAP3430 platform, this error message was emitted:
omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Trying to find this message was difficult because it was wrapped across
several lines. It also mis-spells "required", doesn't read very well,
and has spaces lacking. Let's replace it with a more concise:
omap_vc_init_channel: No PMIC info for vdd_core
While we're here, fix a simple spelling error in a comment.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/vc.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
@@ -292,8 +292,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)u32val;if(!voltdm->pmic||!voltdm->pmic->uv_to_vsel){-pr_err("%s: PMIC info requried to configure vc for"-"vdd_%s not populated.Hence cannot initialize vc\n",+pr_err("%s: No PMIC info for vdd_%s\n",__func__,voltdm->name);return;}
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:37:49
On my OMAP4 platform, I'm getting this error message repeated several
times at boot:
omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.
This doesn't help identify what the problem is. Fix this message to
be more informative:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
This allows us to identify which voltage domains have a problem, and
what the I2C configuration state (a boolean, i2c_high_speed) setting
being used actually is.
omap4_iva_pmic and omap4_mpu_pmic both have it set true.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/vc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
@@ -265,8 +265,8 @@ static void __init omap_vc_i2c_init(struct voltagedomain *voltdm)if(initialized){if(voltdm->pmic->i2c_high_speed!=i2c_high_speed)-pr_warn("%s: I2C config for all channels must match.",-__func__);+pr_warn("%s: I2C config for vdd_%s does not match other channels (%u).",+__func__,voltdm->name,i2c_high_speed);return;}
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:38:29
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/mux.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:38:50
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:39:10
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/omap-headsmp.S | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:39:30
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:39:50
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/hsmmc.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:40:10
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/mux.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
@@ -145,7 +145,7 @@ static int __init _omap_mux_init_gpio(struct omap_mux_partition *partition,return0;}-int__initomap_mux_init_gpio(intgpio,intval)+intomap_mux_init_gpio(intgpio,intval){structomap_mux_partition*partition;intret;
@@ -159,9 +159,9 @@ int __init omap_mux_init_gpio(int gpio, int val)return-ENODEV;}-staticint__init_omap_mux_get_by_name(structomap_mux_partition*partition,-constchar*muxname,-structomap_mux**found_mux)+staticint_omap_mux_get_by_name(structomap_mux_partition*partition,+constchar*muxname,+structomap_mux**found_mux){structomap_mux*mux=NULL;structomap_mux_entry*e;
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:40:30
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/omap_hwmod.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
@@ -1517,8 +1517,8 @@ static int _enable(struct omap_hwmod *oh)if(oh->_state!=_HWMOD_STATE_INITIALIZED&&oh->_state!=_HWMOD_STATE_IDLE&&oh->_state!=_HWMOD_STATE_DISABLED){-WARN(1,"omap_hwmod: %s: enabled state can only be entered "-"from initialized, idle, or disabled state\n",oh->name);+WARN(1,"omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state\n",+oh->name);return-EINVAL;}
@@ -1600,8 +1600,8 @@ static int _idle(struct omap_hwmod *oh)pr_debug("omap_hwmod: %s: idling\n",oh->name);if(oh->_state!=_HWMOD_STATE_ENABLED){-WARN(1,"omap_hwmod: %s: idle state can only be entered from "-"enabled state\n",oh->name);+WARN(1,"omap_hwmod: %s: idle state can only be entered from enabled state\n",+oh->name);return-EINVAL;}
@@ -1682,8 +1682,8 @@ static int _shutdown(struct omap_hwmod *oh)if(oh->_state!=_HWMOD_STATE_IDLE&&oh->_state!=_HWMOD_STATE_ENABLED){-WARN(1,"omap_hwmod: %s: disabled state can only be entered "-"from idle, or enabled state\n",oh->name);+WARN(1,"omap_hwmod: %s: disabled state can only be entered from idle, or enabled state\n",+oh->name);return-EINVAL;}
@@ -2240,8 +2240,8 @@ void omap_hwmod_ocp_barrier(struct omap_hwmod *oh)BUG_ON(!oh);if(!oh->class->sysc||!oh->class->sysc->sysc_flags){-WARN(1,"omap_device: %s: OCP barrier impossible due to "-"device configuration\n",oh->name);+WARN(1,"omap_device: %s: OCP barrier impossible due to device configuration\n",+oh->name);return;}
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:40:51
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/board-4430sdp.c | 13 +++++++++----
arch/arm/mach-omap2/board-omap3evm.c | 23 ++++++++++++++++-------
arch/arm/mach-omap2/board-omap4panda.c | 6 ++++--
arch/arm/mach-omap2/board-zoom-peripherals.c | 6 ++++--
4 files changed, 33 insertions(+), 15 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 16:41:11
Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos)
has caused a regression on OMAP3 platforms.
When the UART is trying to transmit data, if we enter a low power mode,
transmission stops, which makes serial on OMAP3 unusable - a 'dmesg'
takes five minutes to be output at 115200 baud, at a rate of around a
block of 16 characters every couple of seconds.
Unfortunately, the commit above can't be reverted because of many other
changes in this area, so this implements a dirty fix by disabling
CPU idle in the places the original commit does, irrespective of the
UART state.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/cpuidle34xx.c | 2 ++
arch/arm/mach-omap2/pm34xx.c | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:06]:
While testing on my OMAP3430 platform, this error message was emitted:
omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Trying to find this message was difficult because it was wrapped across
several lines. It also mis-spells "required", doesn't read very well,
and has spaces lacking. Let's replace it with a more concise:
omap_vc_init_channel: No PMIC info for vdd_core
While we're here, fix a simple spelling error in a comment.
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:06]:
On my OMAP4 platform, I'm getting this error message repeated several
times at boot:
omap_vc_i2c_init: I2C config for all channels must match.
omap_vc_i2c_init: I2C config for all channels must match.
This doesn't help identify what the problem is. Fix this message to
be more informative:
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels (0).
This allows us to identify which voltage domains have a problem, and
what the I2C configuration state (a boolean, i2c_high_speed) setting
being used actually is.
omap4_iva_pmic and omap4_mpu_pmic both have it set true.
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:07]:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x15a4): Section mismatch in reference from the function omap_mux_init_signals() to the function .init.text:omap_mux_init_signal()
The function omap_mux_init_signals() references
the function __init omap_mux_init_signal().
This is often because omap_mux_init_signals lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Signed-off-by: Russell King <redacted>
I'll separate out the muxing part for v3.4. For the -rc series:
Acked-by: Tony Lindgren <tony@atomide.com>
* Russell King - ARM Linux [off-list ref] [120208 08:07]:
Found by review.
omap4_sdp4430_wifi_mux_init() is called by an __init marked function,
and only calls omap_mux_init_gpio() and omap_mux_init_signal() which
are both also an __init marked functions.
The only reason this doesn't issue a warning is because the compiler
inlines omap4_sdp4430_wifi_mux_init() into omap4_sdp4430_wifi_init().
So, lets add the __init annotation to ensure this remains safe should
the compiler choose not to inline.
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:08]:
WARNING: vmlinux.o(.text+0x1c664): Section mismatch in reference from the function omap_secondary_startup() to the function .cpuinit.text:secondary_startup()
The function omap_secondary_startup() references
the function __cpuinit secondary_startup().
This is often because omap_secondary_startup lacks a __cpuinit
annotation or the annotation of secondary_startup is wrong.
Unfortunately, fixing this causes a new warning which is harder to
solve:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x5328): Section mismatch in reference from the function omap4_hotplug_cpu() to the function .cpuinit.text:omap_secondary_startup()
The function omap4_hotplug_cpu() references
the function __cpuinit omap_secondary_startup().
This is often because omap4_hotplug_cpu lacks a __cpuinit
annotation or the annotation of omap_secondary_startup is wrong.
because omap4_hotplug_cpu() is used by power management code as well,
which may not end up using omap_secondary_startup().
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:08]:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xb798): Section mismatch in reference from the function omap_4430sdp_display_init() to the function .init.text:omap_display_init()
The function omap_4430sdp_display_init() references
the function __init omap_display_init().
This is often because omap_4430sdp_display_init lacks a __init
annotation or the annotation of omap_display_init is wrong.
Fix this by adding __init to omap_4430sdp_display_init().
Signed-off-by: Russell King <redacted>
* Russell King - ARM Linux [off-list ref] [120208 08:08]:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
sdp3430_twl_gpio_setup() is called via platform data from the
gpio-twl4030 module, which can be inserted and removed at runtime.
This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents
it being marked with an __init annotation.
As it calls omap2_hsmmc_init() unconditionally, the only resolution to
this warning is to remove the __init markings from omap2_hsmmc_init()
and its called functions. This addresses the functions in hsmmc.c.
Signed-off-by: Russell King <redacted>
We'll try to sort this out also properly for v3.4, meanwhile:
Acked-by: Tony Lindgren <tony@atomide.com>
* Russell King - ARM Linux [off-list ref] [120208 08:09]:
The previous commit causes new section mismatch warnings:
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb30): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb4c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_gpio()
The function omap_init_hsmmc() references
the function __init omap_mux_init_gpio().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_gpio is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb60): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb6c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb78): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb90): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdb9c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdba8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbc0): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbcc): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbd8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdbf8): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc04): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc10): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc28): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc34): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc40): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc58): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc64): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc70): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xdc7c): Section mismatch in reference from the function omap_init_hsmmc() to the function .init.text:omap_mux_init_signal()
The function omap_init_hsmmc() references
the function __init omap_mux_init_signal().
This is often because omap_init_hsmmc lacks a __init
annotation or the annotation of omap_mux_init_signal is wrong.
Again, as for omap2_hsmmc_init(), these functions are callable at
runtime via the gpio-twl4030.c driver, and so these can't be marked
__init.
These too will be back to __init for v3.4 when the mux stuff
is separated from omap2_hsmmc_init(). For -rc:
Acked-by: Tony Lindgren <tony@atomide.com>
On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
quoted
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Signed-off-by: Russell King <redacted>
Thanks, I'll queue this for 3.4.
Looks like Russell is willing to take potential flamage and argue
this should go into -rc because of the hard to find message.
Care to ack instead, or do you have objections to this being
merged during the -rc?
Regards,
Tony
* Russell King - ARM Linux [off-list ref] [120208 08:09]:
It's useful to print the error code when a called function fails so a
diagnosis of why it failed is possible. In this case, it fails because
we try to register some data for the wl12xx driver, but as the driver
is not configured, a stub function is used which simply returns -ENOSYS.
Let's do the simple thing for -rc and print the error code.
Also, the return code from platform_register_device() at each of these
sites was not being checked. Add some checking, and again print the
error code.
This should be fixed properly for the next merge window so we don't
issue error messages merely because a driver is not configured.
Signed-off-by: Russell King <redacted>
Looks right to me for -rc. Yes let's plan on fixing this for v3.4.
Acked-by: Tony Lindgren <tony@atomide.com>
* Russell King - ARM Linux [off-list ref] [120208 08:10]:
Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos)
has caused a regression on OMAP3 platforms.
When the UART is trying to transmit data, if we enter a low power mode,
transmission stops, which makes serial on OMAP3 unusable - a 'dmesg'
takes five minutes to be output at 115200 baud, at a rate of around a
block of 16 characters every couple of seconds.
Unfortunately, the commit above can't be reverted because of many other
changes in this area, so this implements a dirty fix by disabling
CPU idle in the places the original commit does, irrespective of the
UART state.
Argh, this is just too ugly. There has got to be a better fix for the
-rc series.
Looks like the patches to fix omap-serial.c are queued for v3.4,
so that won't help.
Kevin, what do you have for the -rc fix here to avoid the if (1)
hack?
Regards,
Tony
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
This is my set of patches for fixing OMAP for v3.3.
This is the complete series of patches I'm currently applying to _my_
tree to get v3.3-rc2 into a usable and sane state.
I've acked all but two. The if (1) hack must have some better
solution, then I'd like to see Paul's ack on the error formatting
patch.
Other than that go for it. Thanks for the nice series, too bad
these were not found earlier.
I want to see most of the problems uncovered in this series fixed sooner
rather than later, and certainly not taking three plus weeks to get into
mainline like this rather serious looking commit did:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
quoted
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Signed-off-by: Russell King <redacted>
Thanks, I'll queue this for 3.4.
Looks like Russell is willing to take potential flamage and argue
this should go into -rc because of the hard to find message.
Care to ack instead, or do you have objections to this being
merged during the -rc?
No objections.
Acked-by: Paul Walmsley <paul@pwsan.com>
- Paul
On Wed, 8 Feb 2012, Russell King - ARM Linux wrote:
quoted
While trying to debug my OMAP platforms, they emitted this message:
omap_hwmod: %s: enabled state can only be entered from initialized, idle, or disabled state
The following backtrace said it was from a function called '_enable',
which didn't provide much clue. Grepping didn't find it either.
The message is wrapped, so unwrap the message so grep can find it. Do
the same for three other messages in this file.
Signed-off-by: Russell King <redacted>
Thanks, I'll queue this for 3.4.
Looks like Russell is willing to take potential flamage and argue
this should go into -rc because of the hard to find message.
Care to ack instead, or do you have objections to this being
merged during the -rc?
No objections.
Acked-by: Paul Walmsley <paul@pwsan.com>
OK cool:
Acked-by: Tony Lindgren <tony@atomide.com>
Hi Russell,
On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
I agree this is a serious issue.
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
I am not sure as I don't keep track of all OMAP changes, but you make it sound
like a regression, is there any difference to 3.2 behavior?
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
Well, I am no professional to begin with, at least in the sense of getting paid
for it. That said I'm quite happy if I manage to find a few hours every weekend
to do the work. Given that the final thing should be tested in -next before I
ask Linus to pull, it is completely usual (and even quite fast) if things take
8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus
to pull directly for such issues.
This one was also somewhat special as I had to learn how to deal with PGP and
signed tags to make Linus happy.
Best regards,
Florian Tobias Schandinat
From: Russell King - ARM Linux <hidden> Date: 2012-02-08 22:59:23
On Wed, Feb 08, 2012 at 10:59:06AM -0800, Tony Lindgren wrote:
* Russell King - ARM Linux [off-list ref] [120208 08:10]:
quoted
Commit 2fd149645eb4 (ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos)
has caused a regression on OMAP3 platforms.
When the UART is trying to transmit data, if we enter a low power mode,
transmission stops, which makes serial on OMAP3 unusable - a 'dmesg'
takes five minutes to be output at 115200 baud, at a rate of around a
block of 16 characters every couple of seconds.
Unfortunately, the commit above can't be reverted because of many other
changes in this area, so this implements a dirty fix by disabling
CPU idle in the places the original commit does, irrespective of the
UART state.
Argh, this is just too ugly. There has got to be a better fix for the
-rc series.
That I'd agree on - because it is ugly and it's the best I could do
to revert the commit mentioned above short of reverting a whole raft
of other useful looking commits.
There's got to be a better solution.
Looks like the patches to fix omap-serial.c are queued for v3.4,
so that won't help.
Well, the fact of the matter is this is a regression, which means it
needs fixing for v3.3. A simple patch would be preferred over more
complex patches.
So, if there's no other solution but to put the omap-serial patches
in for v3.3, then that's the best solution for v3.3. First, someone
who understands this code needs to see whether there is a simpler
fix (eg, putting back what was there in a simpler form.)
However, leaving it in its current state for v3.3 is not acceptable.
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
This is better than Kevin's earlier patch because of the descriptive
error:
Acked-by: Tony Lindgren <tony@atomide.com>
Hmm looks like the patch from Ahilash that Kevin queued has the
also a test for missing uv_to_vsel:
if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel)
So there seems to be more to it than what Russell's patch is
doing.
Regards,
Tony
From: Russell King - ARM Linux <hidden> Date: 2012-02-09 00:53:34
On Wed, Feb 08, 2012 at 08:31:49PM +0000, Florian Tobias Schandinat wrote:
Hi Russell,
On 02/08/2012 04:35 PM, Russell King - ARM Linux wrote:
quoted
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd
Author: Tomi Valkeinen [off-list ref]
Date: Tue Jan 17 11:09:57 2012 +0200
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
I agree this is a serious issue.
quoted
which now has me wondering if, by trying to boot v3.3-rc2 on this board
during the past week, I have a destroyed HDMI interface on it.
I am not sure as I don't keep track of all OMAP changes, but you make it
sound like a regression, is there any difference to 3.2 behavior?
I've no idea when the problem was introduced, that's not the point that
I'm making. The point that I'm making is that the patch is dated January
17th, it was apparantly committed on the 26th, and it went into mainline
on the 8th February.
For a patch which fixes a _hardware_ _destruction_ issue, three weeks is
_FAR_ too long for it to take to get into mainline.
Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
4430 SDP platform, _including_ the HDMI code, and looking at the commit
it could be one of those platforms which is affected.
As I don't have a HDMI cable connected to the system, and I ran that
kernel overnight, and I tried opening each /dev/fb* device, what I'm now
wondering is: have I destroyed the HDMI PHY on my 4430SDP?
But that's not really the point. The point is, for someone to sit on such
a patch for weeks is, in my opinion, as good as saying to your users "I
don't care if you bust your hardware."
However, you raise another point, a much more serious one at that. Is
this problem also present in 3.2? The patch seems to apply almost cleanly
to that kernel version, so I guess it is. It fails to apply to v3.1
because of missing files, so I guess 3.1 is unaffected.
So, why isn't this patch copied to the stable people?
And why is there this seemingly lack of care for hardware destruction bugs?
Please, if it affects v3.2, PLEASE PLEASE PLEASE tell the stable people
who know nothing about this commit until I asked them this evening about
it.
quoted
So, a big thanks for sitting on that fix and exposing peoples hardware
to damage, that shows real professionalism.
Well, I am no professional to begin with, at least in the sense of getting paid
for it. That said I'm quite happy if I manage to find a few hours every weekend
to do the work. Given that the final thing should be tested in -next before I
ask Linus to pull, it is completely usual (and even quite fast) if things take
8-13 days on my end. If this isn't fast enough for Tomi, he'd better ask Linus
to pull directly for such issues.
For hardware destruction issues, once the problem has been identified, it
should be shouted about very loudly to get it upstream as quickly as
possible. I'm sure Linus would've even taken it in patch form.
(You do realise that Linus does apply patches as well as pulling trees?)
From: Tomi Valkeinen <hidden> Date: 2012-02-09 07:02:49
On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
4430 SDP platform, _including_ the HDMI code, and looking at the commit
it could be one of those platforms which is affected.
As I don't have a HDMI cable connected to the system, and I ran that
kernel overnight, and I tried opening each /dev/fb* device, what I'm now
wondering is: have I destroyed the HDMI PHY on my 4430SDP?
Probably not. I don't know the exact details of the HW bug (I wrote the
patch as it took too long for the person responsible for it to come up
with a decent patch), but my understanding is that the cable needs to be
plugged in at some point, and then removed.
Thinking about this now, I guess I should've sent queries to get a
proper description of the situation where the bug happens.
However, you raise another point, a much more serious one at that. Is
this problem also present in 3.2? The patch seems to apply almost cleanly
to that kernel version, so I guess it is. It fails to apply to v3.1
because of missing files, so I guess 3.1 is unaffected.
So, why isn't this patch copied to the stable people?
Good point, I'll take it to the stable people.
The problem is present in all kernels where we have the HDMI driver, so
2.6.39+.
For hardware destruction issues, once the problem has been identified, it
should be shouted about very loudly to get it upstream as quickly as
possible. I'm sure Linus would've even taken it in patch form.
(You do realise that Linus does apply patches as well as pulling trees?)
Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
On Thu, 2012-02-09 at 00:53 +0000, Russell King - ARM Linux wrote:
quoted
Moreover, only last Monday did I enable the OMAP2 DSS subsystem on the
4430 SDP platform, _including_ the HDMI code, and looking at the commit
it could be one of those platforms which is affected.
As I don't have a HDMI cable connected to the system, and I ran that
kernel overnight, and I tried opening each /dev/fb* device, what I'm now
wondering is: have I destroyed the HDMI PHY on my 4430SDP?
Probably not. I don't know the exact details of the HW bug (I wrote the
patch as it took too long for the person responsible for it to come up
with a decent patch), but my understanding is that the cable needs to be
plugged in at some point, and then removed.
Thinking about this now, I guess I should've sent queries to get a
proper description of the situation where the bug happens.
quoted
However, you raise another point, a much more serious one at that. Is
this problem also present in 3.2? The patch seems to apply almost cleanly
to that kernel version, so I guess it is. It fails to apply to v3.1
because of missing files, so I guess 3.1 is unaffected.
So, why isn't this patch copied to the stable people?
Good point, I'll take it to the stable people.
The problem is present in all kernels where we have the HDMI driver, so
2.6.39+.
Are there already backported patches out there for 3.0/3.1?
We are quite interested in this.
Regards,
Teresa
quoted
For hardware destruction issues, once the problem has been identified, it
should be shouted about very loudly to get it upstream as quickly as
possible. I'm sure Linus would've even taken it in patch form.
(You do realise that Linus does apply patches as well as pulling trees?)
From: Tomi Valkeinen <hidden> Date: 2012-02-09 10:24:35
On Thu, 2012-02-09 at 09:30 +0100, Teresa Gamez wrote:
Am Donnerstag, den 09.02.2012, 09:02 +0200 schrieb Tomi Valkeinen:
quoted
The problem is present in all kernels where we have the HDMI driver, so
2.6.39+.
Are there already backported patches out there for 3.0/3.1?
We are quite interested in this.
I pushed three branches to git://gitorious.org/linux-omap-dss2/linux.git
fixes/for-3.0-stable
fixes/for-3.1-stable
fixes/for-3.2-stable
Which contain the necessary backported patches for each version.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120209/d63a7694/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2012-02-09 16:44:20
On Wed, Feb 08, 2012 at 03:46:54PM -0800, Tony Lindgren wrote:
* Tony Lindgren [off-list ref] [120208 10:02]:
quoted
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
This is better than Kevin's earlier patch because of the descriptive
error:
Acked-by: Tony Lindgren <tony@atomide.com>
Hmm looks like the patch from Ahilash that Kevin queued has the
also a test for missing uv_to_vsel:
if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel)
So there seems to be more to it than what Russell's patch is
doing.
So, through the discussion in patch 5, do you want me to add the
second check to my patch 1?
* Russell King - ARM Linux [off-list ref] [120209 08:13]:
On Wed, Feb 08, 2012 at 03:46:54PM -0800, Tony Lindgren wrote:
quoted
* Tony Lindgren [off-list ref] [120208 10:02]:
quoted
* Russell King - ARM Linux [off-list ref] [120208 08:05]:
This is better than Kevin's earlier patch because of the descriptive
error:
Acked-by: Tony Lindgren <tony@atomide.com>
Hmm looks like the patch from Ahilash that Kevin queued has the
also a test for missing uv_to_vsel:
if (!voltdm->pmic || !voltdm->pmic->uv_to_vsel)
So there seems to be more to it than what Russell's patch is
doing.
So, through the discussion in patch 5, do you want me to add the
second check to my patch 1?
@@ -41,6 +41,11 @@ void __init omap_vp_init(struct voltagedomain *voltdm)u32val,sys_clk_rate,timeout,waittime;u32vddmin,vddmax,vstepmin,vstepmax;+if(!voltdm->pmic||!voltdm->pmic->uv_to_vsel){+pr_err("%s: No PMIC info for vdd_%s\n",__func__,voltdm->name);+return;+}+if(!voltdm->read||!voltdm->write){pr_err("%s: No read/write API for accessing vdd_%s regs\n",__func__,voltdm->name);
From: Russell King - ARM Linux <hidden> Date: 2012-02-09 18:01:45
While testing on my OMAP3430 platform, this error message was emitted:
omap_vc_init_channel: PMIC info requried to configure vc forvdd_core not populated.Hence cannot initialize vc
Trying to find this message was difficult because it was wrapped across
several lines. It also mis-spells "required", doesn't read very well,
and has spaces lacking. Let's replace it with a more concise:
omap_vc_init_channel: No PMIC info for vdd_core
While we're here, fix a simple spelling error in a comment.
Signed-off-by: Russell King <redacted>
---
arch/arm/mach-omap2/vc.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
@@ -292,9 +292,7 @@ void __init omap_vc_init_channel(struct voltagedomain *voltdm)u32val;if(!voltdm->pmic||!voltdm->pmic->uv_to_vsel){-pr_err("%s: PMIC info requried to configure vc for"-"vdd_%s not populated.Hence cannot initialize vc\n",-__func__,voltdm->name);+pr_err("%s: No PMIC info for vdd_%s\n",__func__,voltdm->name);return;}
Hi Tony,
On 2/8/2012 7:39 PM, Tony Lindgren wrote:
* Russell King - ARM Linux[off-list ref] [120208 08:06]:
quoted
arch/arm/mach-omap2/prm44xx.c:41: error: 'OMAP44XX_IRQ_PRCM' undeclared here (not in a function)
Can you please add something like "This happens when CONFIG_OF is
not selected".
quoted
Signed-off-by: Russell King<redacted>
Other than that:
Acked-by: Tony Lindgren<tony@atomide.com>
It looks like prm2xxx_3xxx.c does have the exact same issue than prm44xx.c.
arch/arm/mach-omap2/prm2xxx_3xxx.c:41:11: error: ?INT_34XX_PRCM_MPU_IRQ? undeclared here (not in a function)
Patch will follow.
Regards,
Benoit