[PATCH] OMAP3 EVM: remove out-of-bounds array access of gpio_leds.
From: Arnout Vandecappelle (Essensium/Mind) arn...@mind.be The omap3evm BSP enables a GPIO LED on the twl4030 chip. However, the static gpio_leds array doesn't have an entry for it. This is most likely a copy-and-paste error, because it has been in there since the first commit of the omap3evm BSP (53c5ec31). Signed-off-by: Arnout Vandecappelle (Essensium/Mind) arn...@mind.be --- Please CC me, I'm not on the list. Since I don't have access to an OMAP3EVM board or schematics, I couldn't actually test if my fix is correct. I discovered the error because I'm using this BSP for an AM37xEVM board - which has the LED connected to a different GPIO. It works on the AM37xEVM board if I replace the assignment with the correct GPIO number (8). --- arch/arm/mach-omap2/board-omap3evm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index ec00b2e..f6f5cd4 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -381,7 +381,7 @@ static int omap3evm_twl_gpio_setup(struct device *dev, gpio_request_one(gpio + 7, GPIOF_OUT_INIT_LOW, EN_DVI); /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */ - gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; + gpio_leds[0].gpio = gpio + TWL4030_GPIO_MAX + 1; platform_device_register(leds_gpio); -- 1.7.8.3 -- 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
[PATCH] OMAP2 PM: do RCU locking for opp_get_voltage()
From: Arnout Vandecappelle (Essensium/Mind) arn...@mind.be
According to the documentation of opp_get_voltage(), it must be called
with rcu_read_lock() held. The OMAP2 power manager doesn't do this.
The locking error is caught by PROVE_RCU.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) arn...@mind.be
---
Please CC me, I'm not on the list.
I was very surprised by this error, because this is the only user of
opp_get_voltage().
Regards,
Arnout
---
arch/arm/mach-omap2/pm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 00bff46..bce2bdc 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -174,14 +174,17 @@ static int __init omap2_set_init_voltage(char *vdd_name,
char *clk_name,
freq = clk-rate;
clk_put(clk);
+ rcu_read_lock();
opp = opp_find_freq_ceil(dev, freq);
if (IS_ERR(opp)) {
pr_err(%s: unable to find boot up OPP for vdd_%s\n,
__func__, vdd_name);
+ rcu_read_unlock();
goto exit;
}
bootup_volt = opp_get_voltage(opp);
+ rcu_read_unlock();
if (!bootup_volt) {
pr_err(%s: unable to find voltage corresponding
to the bootup OPP for vdd_%s\n, __func__, vdd_name);
--
1.7.8.3
--
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: [PATCH 2/3 v5] arm: omap: am335x: enable phy controls
Hi,
On Mon, Feb 13, 2012 at 04:26:19AM +, Gupta, Ajay Kumar wrote:
Hi,
* Ajay Kumar Gupta ajay.gu...@ti.com [120207 19:55]:
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++
---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-
omap2/omap_phy_internal.c
index 4c90477..7129408 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -266,7 +266,11 @@ void ti81xx_musb_phy_power(u8 on)
void __iomem *scm_base = NULL;
u32 usbphycfg;
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ if (cpu_is_ti81xx())
+ scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ else if (cpu_is_am33xx())
+ scm_base = ioremap(AM33XX_SCM_BASE, SZ_2K);
+
if (!scm_base) {
pr_err(system control module ioremap failed\n);
return;
@@ -278,16 +282,19 @@ void ti81xx_musb_phy_power(u8 on)
if (cpu_is_ti816x()) {
usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN |
USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL |
USBPHY_DMOPBUFCTL);
+ } else if (cpu_is_ti814x() || cpu_is_am33xx()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN);
+ usbphycfg |= USBPHY_OTGVDET_EN |
USBPHY_OTGSESSEND_EN;
+ if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_DPINPUT |
USBPHY_DMINPUT);
+ usbphycfg |= USBPHY_DPOPBUFCTL
+ | USBPHY_DMOPBUFCTL;
+ }
}
} else {
if (cpu_is_ti816x())
usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
+ else if (cpu_is_ti814x() || cpu_is_am33xx())
usbphycfg |= USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN;
Please remove all the cpu_is_ calls from the *_phy_power
functions.
You should need those only in *_phy_init to set the right flags
once, not every time you enable or disable the phy.
Tony,
This is a common function used by ti814x, ti816x and am335x and they
have mostly the same bit map but a few bits are different so we would
need to have cpu_is_.
We use this *_phy_power(1) for phy on/init and *_phy_power(0) for phy
off and don't have separate *_phy_init(). Even in that case we would
require
cpu_is_() as phy power down bit is different for ti816x and same
for ti814x and am335x.
Please let me know how should we handle this.
use cpu_is_() to set a flag, and check on the flag.
Are you saying save the flags once in a local static flag and use
the same later on?
Ajay
--
balbi
--
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: [PATCH 2/3 v5] arm: omap: am335x: enable phy controls
On Mon, Feb 13, 2012 at 09:40:26AM +, Gupta, Ajay Kumar wrote:
Hi,
On Mon, Feb 13, 2012 at 04:26:19AM +, Gupta, Ajay Kumar wrote:
Hi,
* Ajay Kumar Gupta ajay.gu...@ti.com [120207 19:55]:
Switch on the phy for am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 21 ++
---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-
omap2/omap_phy_internal.c
index 4c90477..7129408 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -266,7 +266,11 @@ void ti81xx_musb_phy_power(u8 on)
void __iomem *scm_base = NULL;
u32 usbphycfg;
- scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ if (cpu_is_ti81xx())
+ scm_base = ioremap(TI81XX_SCM_BASE, SZ_2K);
+ else if (cpu_is_am33xx())
+ scm_base = ioremap(AM33XX_SCM_BASE, SZ_2K);
+
if (!scm_base) {
pr_err(system control module ioremap failed\n);
return;
@@ -278,16 +282,19 @@ void ti81xx_musb_phy_power(u8 on)
if (cpu_is_ti816x()) {
usbphycfg |= TI816X_USBPHY0_NORMAL_MODE;
usbphycfg = ~TI816X_USBPHY_REFCLK_OSC;
- } else if (cpu_is_ti814x()) {
- usbphycfg = ~(USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN
- | USBPHY_DPINPUT | USBPHY_DMINPUT);
- usbphycfg |= (USBPHY_OTGVDET_EN |
USBPHY_OTGSESSEND_EN
- | USBPHY_DPOPBUFCTL |
USBPHY_DMOPBUFCTL);
+ } else if (cpu_is_ti814x() || cpu_is_am33xx()) {
+ usbphycfg = ~(USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN);
+ usbphycfg |= USBPHY_OTGVDET_EN |
USBPHY_OTGSESSEND_EN;
+ if (cpu_is_ti814x()) {
+ usbphycfg = ~(USBPHY_DPINPUT |
USBPHY_DMINPUT);
+ usbphycfg |= USBPHY_DPOPBUFCTL
+ | USBPHY_DMOPBUFCTL;
+ }
}
} else {
if (cpu_is_ti816x())
usbphycfg = ~TI816X_USBPHY0_NORMAL_MODE;
- else if (cpu_is_ti814x())
+ else if (cpu_is_ti814x() || cpu_is_am33xx())
usbphycfg |= USBPHY_CM_PWRDN |
USBPHY_OTG_PWRDN;
Please remove all the cpu_is_ calls from the *_phy_power
functions.
You should need those only in *_phy_init to set the right flags
once, not every time you enable or disable the phy.
Tony,
This is a common function used by ti814x, ti816x and am335x and they
have mostly the same bit map but a few bits are different so we would
need to have cpu_is_.
We use this *_phy_power(1) for phy on/init and *_phy_power(0) for phy
off and don't have separate *_phy_init(). Even in that case we would
require
cpu_is_() as phy power down bit is different for ti816x and same
for ti814x and am335x.
Please let me know how should we handle this.
use cpu_is_() to set a flag, and check on the flag.
Are you saying save the flags once in a local static flag and use
the same later on?
that's correct.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] usb: musb: fix pm_runtime mismatch
On Thu, Jan 12, 2012 at 5:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jan 12, 2012 at 1:56 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Dec 19, 2011 at 10:01 PM, Felipe Contreras felipe.contre...@nokia.com wrote: From: Felipe Contreras felipe.contre...@gmail.com In musb_init_controller() there's a pm_runtime_put(), but there's no pm_runtime_get(), which creates a mismatch that causes the driver to sleep when it shouldn't. This patch is causing problems here, the device never suspends, I've verified musb_runtime_suspend and omap2430_runtime_suspend are never called in my setup, unless I revert this patch. I'm using musb with ethernet gadget; cable removal also doesn't suspend musb. It seems pm_runtime_put() that was removed was balancing out pm_runtime_get in musb_platform_init(), which is called at the beginning of musb_init_controller(). I think this pm_runtime_get() from musb_platform_init() should be moved to musb_init_controller() to stop confusing people and pm_runtime_put() needs to be brought back. I can do a patch if nobody objects. You mean have both get and put in musb_init_controller()? That's OK, it would be balanced then, but you would have to remove the pm_runtime_put() from omap2430_remove() that presumably was balancing the pm_runtime_get_sync() in omap2430_musb_init(). This was introduced in 7acc619[1], but it wasn't triggered in my setup until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW; when PM is working as it was supposed to. However, it seems most of the time this is used in a way that keeps the counter above 0, so nobody noticed. Also, it seems to depend on the configuration used in versions before 3.1, but not later (or in it). I found the problem by loading isp1704_charger before any usb gadgets: http://article.gmane.org/gmane.linux.kernel/1226122 isp1704_charger seems to be doing otg_io_read(), and it's perfectly normal that musb can be suspended at the time isp1704 decides to do this. I think proper fix is to wake up must on musb_ulpi_read() and musb_ulpi_write() instead. I guess so. If you send these patches I can give them a try. Sent them a week ago, would be nice if you tried them. -- Gražvydas -- 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: [PATCH 0/9] usb: gadget: generic map/unmap routines
Hi, On Tue, Jan 24, 2012 at 01:45:21PM +0200, Felipe Balbi wrote: Hi all, here's a rebased version of generic map/unmap patchset. Also available on generic-map-unmap branch of my tree, some of the patches have been tested before and already have a Tested-by tag. Felipe Balbi (9): usb: gadget: add generic map/unmap request utilities usb: dwc3: gadget: use generic map/unmap routines usb: gadget: langwell: use generic map/unmap functions usb: renesas: gadget: use generic map/unmap routines usb: gadget: amd5536: use generic map/unmap routines usb: gadget: r8a66597: use generic map/unmap routines usb: gadget: net2272: use generic map/umap routines usb: gadget: net2280: use generic map/unmap routines usb: gadget: goku: use generic map/unmap routines Tomorrow, will complete 3 weeks since I re-sent these patches. Since nobody has had any issues with them, I'm considering people are happy, so I'll queued them up for v3.4 merge window. -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] OMAPDSS: Export functions to enable dynamic linking
Hi, On Sat, 2012-02-11 at 17:55 -0600, Ricardo Neri wrote: The functions dss_init_hdmi_ip_ops and dss_has_feature are used by the ASoC HDMI codec. Both the ASoC codec and DSS may be built as separate kernel modules. Hence, these two functions need to be available for dynamic linking. Neither of those functions should be exported, they are omapdss internal. And you had to hack around to make those usable by adding drivers/video/omap2/dss into the include path. Anything that is exported from omapdss should be added to include/video/omapdss.h. Users of omapdss should never include anything from drivers/video/omap2/dss. But as I said, neither of those functions should be exported, they are clearly omapdss internal functions. For dss_has_feature we probably need a new function to convey the information about the hdmi features that the audio side needs. Or perhaps it can be in the ip_data. For dss_init_hdmi_ip_ops I don't see why the audio part should see it. Initializing the ops should clearly be done by omapdss automatically. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
Afzal Update SRAM start size for am33xx SoC's.
Afzal Note: cpu_is_34xx() is true for am33xx also. Doing
Afzal cpu_is_am33xx() check after cpu_is_34xx() will not
Afzal achieve what we want due to the above reason.
Afzal Hence cpu_is_am33xx() is done before cpu_is_34xx()
Afzal } else {
Afzal - if (cpu_is_omap34xx()) {
Afzal + if (cpu_is_am33xx()) {
Afzal + omap_sram_start = AM33XX_SRAM_PA;
Afzal + omap_sram_size = 0x1; /* 64K */
Afzal + } else if (cpu_is_omap34xx()) {
Afzal omap_sram_start = OMAP3_SRAM_PA;
Afzal omap_sram_size = 0x1; /* 64K */
I don't particular know the omap sram stuff, but doesn't the 33xx have
2x 64K blocks of SRAM?
Afzal +static inline int am33xx_sram_init(void)
Afzal +{
Afzal + return 0;
I know you mentioned it in the commit message, but it might be good with
a comment here as well that this dummy function is needed to not get the 34xx
init function called for 33xx, so it doesn't get removed when somebody
decides to cleanup.
Afzal +}
Afzal +
Afzal int __init omap_sram_init(void)
Afzal {
Afzal omap_detect_sram();
Afzal @@ -379,6 +387,8 @@ int __init omap_sram_init(void)
Afzal omap242x_sram_init();
Afzal else if (cpu_is_omap2430())
Afzal omap243x_sram_init();
Afzal + else if (cpu_is_am33xx())
Afzal + am33xx_sram_init();
Afzal else if (cpu_is_omap34xx())
Afzal omap34xx_sram_init();
--
Bye, Peter Korsgaard
--
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: Possible circular locking dependency (3.3-rc2)
Hi,
On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi ba...@ti.com wrote:
Hi guys,
I have just triggered the folllowing:
[ 84.860321] ==
[ 84.860321] [ INFO: possible circular locking dependency detected ]
[ 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted
[ 84.860321] ---
[ 84.860321] bash/949 is trying to acquire lock:
[ 84.860321] (sysfs_lock){+.+.+.}, at: [c0275358]
gpio_value_store+0x24/0xcc
[ 84.860321]
[ 84.860321] but task is already holding lock:
[ 84.860321] (s_active#22){.+}, at: [c016996c]
sysfs_write_file+0xdc/0x184
[ 84.911468]
[ 84.911468] which lock already depends on the new lock.
[ 84.911468]
[ 84.920043]
[ 84.920043] the existing dependency chain (in reverse order) is:
[ 84.920043]
[ 84.927886] - #1 (s_active#22){.+}:
[ 84.927886] [c008f640] check_prevs_add+0xdc/0x150
[ 84.927886] [c008fc18] validate_chain.clone.24+0x564/0x694
[ 84.927886] [c0090cdc] __lock_acquire+0x49c/0x980
[ 84.951660] [c0091838] lock_acquire+0x98/0x100
[ 84.951660] [c016a8e8] sysfs_deactivate+0xb0/0x100
[ 84.962982] [c016b1b4] sysfs_addrm_finish+0x2c/0x6c
[ 84.962982] [c016b8bc] sysfs_remove_dir+0x84/0x98
[ 84.962982] [c02590d8] kobject_del+0x10/0x78
[ 84.974670] [c02c29e8] device_del+0x140/0x170
[ 84.974670] [c02c2a24] device_unregister+0xc/0x18
[ 84.985382] [c0276894] gpio_unexport+0xbc/0xdc
[ 84.985382] [c02768c8] gpio_free+0x14/0xfc
[ 85.001708] [c0276a28] unexport_store+0x78/0x8c
[ 85.001708] [c02c5af8] class_attr_store+0x18/0x24
[ 85.007293] [c0169990] sysfs_write_file+0x100/0x184
[ 85.018981] [c0109d48] vfs_write+0xb4/0x148
[ 85.018981] [c0109fd0] sys_write+0x40/0x70
[ 85.018981] [c0013cc0] ret_fast_syscall+0x0/0x3c
[ 85.035003]
[ 85.035003] - #0 (sysfs_lock){+.+.+.}:
[ 85.035003] [c008f54c] check_prev_add+0x680/0x698
[ 85.035003] [c008f640] check_prevs_add+0xdc/0x150
[ 85.052093] [c008fc18] validate_chain.clone.24+0x564/0x694
[ 85.052093] [c0090cdc] __lock_acquire+0x49c/0x980
[ 85.052093] [c0091838] lock_acquire+0x98/0x100
[ 85.069885] [c047e280] mutex_lock_nested+0x3c/0x2f4
[ 85.069885] [c0275358] gpio_value_store+0x24/0xcc
[ 85.069885] [c02c18dc] dev_attr_store+0x18/0x24
[ 85.087158] [c0169990] sysfs_write_file+0x100/0x184
[ 85.087158] [c0109d48] vfs_write+0xb4/0x148
[ 85.098297] [c0109fd0] sys_write+0x40/0x70
[ 85.098297] [c0013cc0] ret_fast_syscall+0x0/0x3c
[ 85.109069]
[ 85.109069] other info that might help us debug this:
[ 85.109069]
[ 85.117462] Possible unsafe locking scenario:
[ 85.117462]
[ 85.117462] CPU0 CPU1
[ 85.128417]
[ 85.128417] lock(s_active#22);
[ 85.128417] lock(sysfs_lock);
[ 85.128417] lock(s_active#22);
[ 85.142486] lock(sysfs_lock);
[ 85.151794]
[ 85.151794] *** DEADLOCK ***
[ 85.151794]
[ 85.151794] 2 locks held by bash/949:
[ 85.158020] #0: (buffer-mutex){+.+.+.}, at: [c01698b8]
sysfs_write_file+0x28/0x184
[ 85.170349] #1: (s_active#22){.+}, at: [c016996c]
sysfs_write_file+0xdc/0x184
[ 85.170349]
[ 85.178588] stack backtrace:
[ 85.178588] [c001b824] (unwind_backtrace+0x0/0xf0) from [c008de64]
(print_circular_bug+0x100/0x114)
[ 85.193023] [c008de64] (print_circular_bug+0x100/0x114) from
[c008f54c] (check_prev_add+0x680/0x698)
[ 85.193023] [c008f54c] (check_prev_add+0x680/0x698) from [c008f640]
(check_prevs_add+0xdc/0x150)
[ 85.212524] [c008f640] (check_prevs_add+0xdc/0x150) from [c008fc18]
(validate_chain.clone.24+0x564/0x694)
[ 85.212524] [c008fc18] (validate_chain.clone.24+0x564/0x694) from
[c0090cdc] (__lock_acquire+0x49c/0x980)
[ 85.233306] [c0090cdc] (__lock_acquire+0x49c/0x980) from [c0091838]
(lock_acquire+0x98/0x100)
[ 85.233306] [c0091838] (lock_acquire+0x98/0x100) from [c047e280]
(mutex_lock_nested+0x3c/0x2f4)
[ 85.242614] [c047e280] (mutex_lock_nested+0x3c/0x2f4) from [c0275358]
(gpio_value_store+0x24/0xcc)
[ 85.261840] [c0275358] (gpio_value_store+0x24/0xcc) from [c02c18dc]
(dev_attr_store+0x18/0x24)
[ 85.261840] [c02c18dc] (dev_attr_store+0x18/0x24) from [c0169990]
(sysfs_write_file+0x100/0x184)
[ 85.271240] [c0169990] (sysfs_write_file+0x100/0x184) from [c0109d48]
(vfs_write+0xb4/0x148)
[ 85.290008] [c0109d48] (vfs_write+0xb4/0x148) from [c0109fd0]
(sys_write+0x40/0x70)
[ 85.298400] [c0109fd0] (sys_write+0x40/0x70) from [c0013cc0]
(ret_fast_syscall+0x0/0x3c)
-bash: echo: write error: Operation not permitted
the way to trigger is:
Re: [PATCH v2] usb: musb: fix pm_runtime mismatch
On Mon, Feb 13, 2012 at 2:54 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Thu, Jan 12, 2012 at 5:40 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Thu, Jan 12, 2012 at 1:56 PM, Grazvydas Ignotas nota...@gmail.com wrote: On Mon, Dec 19, 2011 at 10:01 PM, Felipe Contreras felipe.contre...@nokia.com wrote: From: Felipe Contreras felipe.contre...@gmail.com In musb_init_controller() there's a pm_runtime_put(), but there's no pm_runtime_get(), which creates a mismatch that causes the driver to sleep when it shouldn't. This patch is causing problems here, the device never suspends, I've verified musb_runtime_suspend and omap2430_runtime_suspend are never called in my setup, unless I revert this patch. I'm using musb with ethernet gadget; cable removal also doesn't suspend musb. It seems pm_runtime_put() that was removed was balancing out pm_runtime_get in musb_platform_init(), which is called at the beginning of musb_init_controller(). I think this pm_runtime_get() from musb_platform_init() should be moved to musb_init_controller() to stop confusing people and pm_runtime_put() needs to be brought back. I can do a patch if nobody objects. You mean have both get and put in musb_init_controller()? That's OK, it would be balanced then, but you would have to remove the pm_runtime_put() from omap2430_remove() that presumably was balancing the pm_runtime_get_sync() in omap2430_musb_init(). This was introduced in 7acc619[1], but it wasn't triggered in my setup until 18a2689[2] was merged to Linus' branch at point df0914[3]. IOW; when PM is working as it was supposed to. However, it seems most of the time this is used in a way that keeps the counter above 0, so nobody noticed. Also, it seems to depend on the configuration used in versions before 3.1, but not later (or in it). I found the problem by loading isp1704_charger before any usb gadgets: http://article.gmane.org/gmane.linux.kernel/1226122 isp1704_charger seems to be doing otg_io_read(), and it's perfectly normal that musb can be suspended at the time isp1704 decides to do this. I think proper fix is to wake up must on musb_ulpi_read() and musb_ulpi_write() instead. I guess so. If you send these patches I can give them a try. Sent them a week ago, would be nice if you tried them. Sorry, I just started hacking with my N900 again. I will probably test them later today. Cheers. -- Felipe Contreras -- 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: [PATCH v2 2/2] ARM: OMAP: sram: Add am33xx SRAM support (minimal)
On Mon, Feb 13, 2012 at 19:54:05, Peter Korsgaard wrote:
Afzal == Afzal Mohammed af...@ti.com writes:
Afzal From: Vaibhav Bedia vaibhav.be...@ti.com
Afzal Update SRAM start size for am33xx SoC's.
This is a really awkward quoting style :|
I don't particular know the omap sram stuff, but doesn't the 33xx have
2x 64K blocks of SRAM?
Yes, but since the lower 64KB will not be available on non-GP device and
only A8 can access it, for now we make use of the higher 64KB which is referred
to as the OCMC RAM in the TRM. This will also enable SRAM usage by other drivers
like PRU and McASP.
Afzal +static inline int am33xx_sram_init(void)
Afzal +{
Afzal + return 0;
I know you mentioned it in the commit message, but it might be good with
a comment here as well that this dummy function is needed to not get the 34xx
init function called for 33xx, so it doesn't get removed when somebody
decides to cleanup.
You are right in saying that the dummy function is needed to avoid 34xx SRAM
init.
We'll have some PM related code coming in soon and hopefully the SRAM code
won't change
Without us noticing ;)
Regards,
Vaibhav B.
--
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
[PATCH 1/4] ARM: OMAP2+: board-generic: Remove un-needed .atag_offset for DT_MACHINE
Some .atag_offset entries were wrongly added during a merge conflict
resolution in 3.3.
Remove them all, since DT boot does not use that attribute anymore.
Replace as well the #if... by #ifdef for consistency.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index ad49762..d32b593 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -91,14 +91,13 @@ static void __init omap3_init(void)
}
#endif
-#if defined(CONFIG_SOC_OMAP2420)
+#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
ti,omap2420,
NULL,
};
DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened Device Tree))
- .atag_offset= 0x100,
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
@@ -111,14 +110,13 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420
(Flattened Device Tree))
MACHINE_END
#endif
-#if defined(CONFIG_SOC_OMAP2430)
+#ifdef CONFIG_SOC_OMAP2430
static const char *omap243x_boards_compat[] __initdata = {
ti,omap2430,
NULL,
};
DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened Device Tree))
- .atag_offset= 0x100,
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
@@ -131,14 +129,13 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430
(Flattened Device Tree))
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
NULL,
};
DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device Tree))
- .atag_offset= 0x100,
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
@@ -151,14 +148,13 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
MACHINE_END
#endif
-#if defined(CONFIG_ARCH_OMAP4)
+#ifdef CONFIG_ARCH_OMAP4
static const char *omap4_boards_compat[] __initdata = {
ti,omap4,
NULL,
};
DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device Tree))
- .atag_offset= 0x100,
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
--
1.7.0.4
--
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
[PATCH 2/4] ARM: OMAP2+: omap_device: Replace dev_warn by dev_dbg in omap_device_build_from_dt
This warning becomes a little bit too verbose with the increase of
device nodes in some DTS files.
Change it to debug only.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 80d5e4c..125de17 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -343,7 +343,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
oh_cnt = of_property_count_strings(node, ti,hwmods);
if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
- dev_warn(pdev-dev, No 'hwmods' to build omap_device\n);
+ dev_dbg(pdev-dev, No 'hwmods' to build omap_device\n);
return -ENODEV;
}
--
1.7.0.4
--
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
[PATCH 3/4] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+* In the case of DT, the PMIC and SR initialization will be done using
+* a completely different mechanism.
+* Disable this part if a DT blob is available.
+*/
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
--
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
[PATCH 4/4] ARM: OMAP1: kconfig: Enable IRQ_DOMAIN by default for OMAP1 platforms
The devices that can act as an interrupt controller like the GPIO are going to be handled using the IRQ domain mechanism in order to avoid the static IRQ mapping done so far inside plat-omap/irqs.h. Enable IRQ_DOMAIN by default to allow the drivers shared with OMAP2+ to compile properly on OMAP1 platforms. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 734009a..e289dd2 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -14,6 +14,7 @@ config ARCH_OMAP1 select CLKDEV_LOOKUP select CLKSRC_MMIO select GENERIC_IRQ_CHIP + select IRQ_DOMAIN select HAVE_IDE select NEED_MACH_MEMORY_H help -- 1.7.0.4 -- 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: OMAP34xx
Thus spake Tony Lindgren (t...@atomide.com): * Paul Walmsley p...@pwsan.com [120209 17:48]: Kevin and I just doublechecked OMAP37xx BeagleBoard xM here with Tony's testing branch; it works. Rex, care to confirm this is also the case for you with your custom .config? Yes, it works. Thanks! take care! /rex. -- 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
[PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616f04d1f5da0e07bec4e0092f227 added the requirement
that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 44 +++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index 9970331..da8399e 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -19,6 +19,8 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/smsc911x.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include plat/board.h
#include plat/gpmc.h
@@ -42,6 +44,43 @@ static struct smsc911x_platform_config gpmc_smsc911x_config
= {
.flags = SMSC911X_USE_16BIT,
};
+static struct regulator_consumer_supply gpmc_smsc911x_supply[] = {
+ REGULATOR_SUPPLY(vddvario, smsc911x.0),
+ REGULATOR_SUPPLY(vdd33a, smsc911x.0),
+};
+
+/* Generic regulator definition to satisfy smsc911x */
+static struct regulator_init_data gpmc_smsc911x_reg_init_data = {
+ .constraints = {
+ .min_uV = 330,
+ .max_uV = 330,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(gpmc_smsc911x_supply),
+ .consumer_supplies = gpmc_smsc911x_supply,
+};
+
+static struct fixed_voltage_config gpmc_smsc911x_fixed_reg_data = {
+ .supply_name= gpmc_smsc911x,
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .startup_delay = 0,
+ .enable_high= 0,
+ .enabled_at_boot= 1,
+ .init_data = gpmc_smsc911x_reg_init_data,
+};
+
+static struct platform_device gpmc_smsc911x_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 0,
+ .dev = {
+ .platform_data = gpmc_smsc911x_fixed_reg_data,
+ },
+};
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +94,11 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ if (platform_device_register(gpmc_smsc911x_regulator) 0) {
+ pr_err(Unable to register smsc911x regulators\n);
+ return;
+ }
+
if (gpmc_cs_request(gpmc_cfg-cs, SZ_16M, cs_mem_base) 0) {
pr_err(Failed to request GPMC mem region\n);
return;
--
1.7.5.4
--
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: [PATCH] omap: board-omap3evm: add required smsc911x regulators
On Fri, Feb 10, 2012 at 02:53:41PM -0800, Tony Lindgren wrote: * Matt Porter mpor...@ti.com [120210 10:19]: On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote: * Matt Porter m...@ohporter.com [120208 13:35]: This fixes smsc911x support on omap3evm that has been broken since the smsc911x driver was updated to require the existence of vdd33a and vddvario supplies. Great. Few comments: 1. Could you please include the smsc911x commit and subject here too so it clearly shows the regression? Sure. Will do for v2. 2. Also, why don't you add this fixed regulator to gpmc-smsc911.c? That way it gets fixed for other too, like zoom2/3. Ok, so I considered that at first and had two concerns that made me just do it in the omap3evm specific way and see what the feedback was. 1) If we do a generic implementation in gpmc-smsc911x.c, there needs to be a way to override it. Another board may have a variable supply that feeds this consumer. 2) Technically, this omap3evm specific implementation matches the hardware in that the osk_3v3 rail is software controllable. Granted, I commented that we simply don't hook up the gpio at this time since this real hardware regulator has always been silently asserted on by the nature of the reset state of the TWL GPIOs and the board level pull downs as well. OK So that said, I don't need #2 to make omap3evm work and I don't think anybody cares yet to actually turn that regulator off (as it will kill other things that appear to not have regulator support anyway). It looks like you talked me into respinning it as a generic implementation. Only question is whether I should bother consider not-yet-existing boards that may not want that generic regulator. Well for future boards the regulator should come from device tree, so for now it should be safe to add it to gpmc-smsc911.c. Ok, sounds good. Posted an updated version. -Matt -- 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Feb 13, 2012 at 11:43:42AM -0500, Matt Porter wrote:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616f04d1f5da0e07bec4e0092f227 added the requirement
that platforms provide vdd33a and vddvario supplies.
Thanks. Only one comment on this.
+static struct platform_device gpmc_smsc911x_regulator = {
+ .name = reg-fixed-voltage,
+ .id = 0,
$ grep -A1 reg-fixed-voltage arch/arm/*omap* -r
arch/arm/mach-omap2/board-omap3evm.c: .name = reg-fixed-voltage,
arch/arm/mach-omap2/board-omap3evm.c- .id = 1,
--
arch/arm/mach-omap2/board-zoom-peripherals.c: .name =
reg-fixed-voltage,
arch/arm/mach-omap2/board-zoom-peripherals.c- .id = 1,
--
arch/arm/mach-omap2/board-overo.c: .name = reg-fixed-voltage,
arch/arm/mach-omap2/board-overo.c- .id = 1,
--
arch/arm/mach-omap2/board-omap4panda.c: .name = reg-fixed-voltage,
arch/arm/mach-omap2/board-omap4panda.c- .id = 1,
--
arch/arm/mach-omap2/board-rm680.c: .name =
reg-fixed-voltage,
arch/arm/mach-omap2/board-rm680.c- .dev= {
--
arch/arm/mach-omap2/board-igep0020.c: .name = reg-fixed-voltage,
arch/arm/mach-omap2/board-igep0020.c- .id = 0,
--
arch/arm/mach-omap2/board-4430sdp.c:.name = reg-fixed-voltage,
arch/arm/mach-omap2/board-4430sdp.c-.id = -1,
--
arch/arm/mach-omap2/board-4430sdp.c:.name = reg-fixed-voltage,
arch/arm/mach-omap2/board-4430sdp.c-.id = 1,
--
arch/arm/mach-omap2/board-omap3pandora.c: .name =
reg-fixed-voltage,
arch/arm/mach-omap2/board-omap3pandora.c- .id = 1,
igep0020.c does this:
static struct omap_smsc911x_platform_data smsc911x_cfg = {
.cs = IGEP2_SMSC911X_CS,
.gpio_irq = IGEP2_SMSC911X_GPIO,
.gpio_reset = -EINVAL,
.flags = SMSC911X_USE_32BIT | SMSC911X_SAVE_MAC_ADDRESS,
};
static inline void __init igep2_init_smsc911x(void)
{
gpmc_smsc911x_init(smsc911x_cfg);
}
so it seems to use the gpmc_smsc stuff as well. So we're ending up with
two reg-fixed-voltage devices both with ID 0. That's not going to work,
and the driver model/sysfs will give you a nice warning there about that.
I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum
similar to what I did for 8250 to control the allocation of platform
device IDs for this, otherwise we're going to keep on running over this
problem.
/*
* Allocate 8250 platform device IDs. Nothing is implied by
* the numbering here, except for the legacy entry being -1.
*/
enum {
PLAT8250_DEV_LEGACY = -1,
PLAT8250_DEV_PLATFORM,
PLAT8250_DEV_PLATFORM1,
PLAT8250_DEV_PLATFORM2,
PLAT8250_DEV_FOURPORT,
PLAT8250_DEV_ACCENT,
PLAT8250_DEV_BOCA,
PLAT8250_DEV_EXAR_ST16C554,
PLAT8250_DEV_HUB6,
PLAT8250_DEV_MCA,
PLAT8250_DEV_AU1X00,
PLAT8250_DEV_SM501,
};
Added Mark for his comment.
--
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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Feb 13, 2012 at 04:52:09PM +, Russell King - ARM Linux wrote: I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum similar to what I did for 8250 to control the allocation of platform device IDs for this, otherwise we're going to keep on running over this problem. Added Mark for his comment. Hrm, seems slightly icky but the enum will work if we can decide how to add elements to the enum since it'll be easy to bloat a lot it if it's central. It's tempting to suggest just using a random number to assign the IDs randomly rather than have a central registry but obviously there's no guarantees there. signature.asc Description: Digital signature
[PATCH] ks8851: Fix NOHZ local_softirq_pending 08 warning
This fix a similar problem as in 72092cc45378176ba700034c91b7af2db524df26 and 481a8199142c050b72bff8a1956a49fd0a75bbe0 (can: fix NOHZ local_softirq_pending 08 warning). This fix replaces netif_rx() with netif_rx_ni() which has to be used from process/softirq context. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: David S. Miller da...@davemloft.net --- drivers/net/ethernet/micrel/ks8851.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c index 6b35e7d..0c3e400 100644 --- a/drivers/net/ethernet/micrel/ks8851.c +++ b/drivers/net/ethernet/micrel/ks8851.c @@ -583,7 +583,7 @@ static void ks8851_rx_pkts(struct ks8851_net *ks) ks8851_dbg_dumpkkt(ks, rxpkt); skb-protocol = eth_type_trans(skb, ks-netdev); - netif_rx(skb); + netif_rx_ni(skb); ks-netdev-stats.rx_packets++; ks-netdev-stats.rx_bytes += rxlen; -- 1.7.0.4 -- 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
[GIT PULL] omap fixes for v3.3-rc3
Hi Arnd and Olof, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This contains a DT boot fix that was found sitting in the omap DT branch, omap2 related PM fix for serial port, and few compile and warning fixes. Note that Russell also has a series of omap fixes queued up that will get merged via his tree. There should not be any conflicts between these two series. Regards, Tony The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d: Linus Torvalds (1): Linux 3.3-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Benoit Cousson (1): ARM: OMAP2+: board-generic: Add missing handle_irq callbacks Igor Grinberg (1): ARM: OMAP3: cm-t35: fix section mismatch warning Paul Walmsley (1): ARM: OMAP2xxx: PM: fix OMAP2xxx-specific UART idle bug in v3.3 Santosh Shilimkar (1): ARM: OMAP2: Fix the OMAP2 only build break seen with 2011+ ARM tool-chains Tony Lindgren (1): Merge branch 'fixes-dt' into fixes arch/arm/mach-omap2/Makefile |4 ++-- arch/arm/mach-omap2/board-cm-t35.c|2 +- arch/arm/mach-omap2/board-generic.c |4 arch/arm/mach-omap2/pm24xx.c |8 +--- arch/arm/plat-omap/include/plat/omap-secure.h |2 +- 5 files changed, 9 insertions(+), 11 deletions(-) -- 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
* Mark Brown broo...@opensource.wolfsonmicro.com [120213 08:25]: On Mon, Feb 13, 2012 at 04:52:09PM +, Russell King - ARM Linux wrote: I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum similar to what I did for 8250 to control the allocation of platform device IDs for this, otherwise we're going to keep on running over this problem. Added Mark for his comment. Hrm, seems slightly icky but the enum will work if we can decide how to add elements to the enum since it'll be easy to bloat a lot it if it's central. It's tempting to suggest just using a random number to assign the IDs randomly rather than have a central registry but obviously there's no guarantees there. Can't we just leave out the .id and have it automatically assigned? 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: OMAP34xx
* Russell King - ARM Linux li...@arm.linux.org.uk [120212 03:13]: Here's another issue which kautobuildv2 just found, as I've now added randconfig to the suite of OMAP4430 SDP builds. Obviously, as it's using a different configuration each time, it's going to find different issues on each run. For this, the seed config has the following extra lines compared with allnoconfig: CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_THUMB2_KERNEL=n The reason for the last line is that -mauto-it is not supported by my toolchain, so if it were to be enabled, it would cause an immediate build failure. The second to late line ensures that we don't end up with randconfig having to dream up a value for CONFIG_PHYS_OFFSET, which it can't do. The seed configs can now be viewed or downloaded from the build site. 8 From: Russell King rmk+ker...@arm.linux.org.uk ARM: OMAP: fix missing __devexit_p() annotations Missing __devexit_p() annotations in driver structures for remove functions marked with __devexit is waiting for build errors to happen, such as: `omap_system_dma_remove' referenced in section `.data' of arch/arm/plat-omap/built-in.o: defined in discarded section `.devexit.text' of arch/arm/plat-omap/built-in.o Add the necessary annotation, and as a result of audit, fix others which are also missing in arch/arm/*omap*. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tony Lindgren t...@atomide.com -- 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Feb 13, 2012 at 09:52:34AM -0800, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [120213 08:25]: On Mon, Feb 13, 2012 at 04:52:09PM +, Russell King - ARM Linux wrote: I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum similar to what I did for 8250 to control the allocation of platform device IDs for this, otherwise we're going to keep on running over this problem. Added Mark for his comment. Hrm, seems slightly icky but the enum will work if we can decide how to add elements to the enum since it'll be easy to bloat a lot it if it's central. It's tempting to suggest just using a random number to assign the IDs randomly rather than have a central registry but obviously there's no guarantees there. Can't we just leave out the .id and have it automatically assigned? Unfortunately, there's no such infrastructure in the driver model. -- 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
* Russell King - ARM Linux li...@arm.linux.org.uk [120213 09:31]: On Mon, Feb 13, 2012 at 09:52:34AM -0800, Tony Lindgren wrote: * Mark Brown broo...@opensource.wolfsonmicro.com [120213 08:25]: On Mon, Feb 13, 2012 at 04:52:09PM +, Russell King - ARM Linux wrote: I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum similar to what I did for 8250 to control the allocation of platform device IDs for this, otherwise we're going to keep on running over this problem. Added Mark for his comment. Hrm, seems slightly icky but the enum will work if we can decide how to add elements to the enum since it'll be easy to bloat a lot it if it's central. It's tempting to suggest just using a random number to assign the IDs randomly rather than have a central registry but obviously there's no guarantees there. Can't we just leave out the .id and have it automatically assigned? Unfortunately, there's no such infrastructure in the driver model. Hmm OK, -1 seems to be just used for name in platform_device_add(). 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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Feb 13, 2012 at 08:56:18AM -0800, Mark Brown wrote:
On Mon, Feb 13, 2012 at 04:52:09PM +, Russell King - ARM Linux wrote:
I think OMAP (or even the reg-fixed-voltage folk) needs to create an enum
similar to what I did for 8250 to control the allocation of platform
device IDs for this, otherwise we're going to keep on running over this
problem.
Added Mark for his comment.
Hrm, seems slightly icky but the enum will work if we can decide how to
add elements to the enum since it'll be easy to bloat a lot it if it's
central. It's tempting to suggest just using a random number to assign
the IDs randomly rather than have a central registry but obviously
there's no guarantees there.
Another option might be to provide a generic platform device helper
that instantiates a per-named-platform-device id list that simply
provides the next available id sequentially as requests for platform
device registration arrive.
arch init:
platform_create_id_list_create(reg-fixed-voltage);
platform init:
/* I = 0..N, .id filled in by _autoid() registration */
static struct platform_device my_fixed_regulatorN = {
.name = reg-fixed-voltage,
.dev = ...
}
platform_device_register_autoid(my_fixed_regulator0);
platform_device_register_autoid(my_fixed_regulator1);
platform_device_register_autoid(my_fixed_regulator2);
...
platform_device_register_autoid(my_fixed_regulatorN);
Something like this might be able to solve this once for the platform
device users don't need a fixed enum id. It would require changes to
platform_device_register() to update the list as static assignment
of ids occurs so those will not be used by the _autoid() method.
-Matt
--
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: [PATCH] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
On Mon, Feb 13, 2012 at 10:14:10AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120213 09:31]: On Mon, Feb 13, 2012 at 09:52:34AM -0800, Tony Lindgren wrote: Can't we just leave out the .id and have it automatically assigned? It'd be nice but... Unfortunately, there's no such infrastructure in the driver model. Hmm OK, -1 seems to be just used for name in platform_device_add(). -1 is a valid ID also, it means there's only one of these things so don't display a number. Which is sad but there we are. I'm at ELC/ABS so I might try and find Greg in person here to see if we can come up with something better, it seems like this is something the core ought to be able to help with in much the same way that the USB stuff can. signature.asc Description: Digital signature
Re: [PATCH 2/2] pinctrl: Add simple pinmux driver using device tree data
* Dong Aisheng donga...@gmail.com [120210 16:02]:
Hi Tony,
On Fri, Feb 10, 2012 at 12:05:03PM -0800, Tony Lindgren wrote:
Hi Dong,
* Dong Aisheng donga...@gmail.com [120207 17:22]:
On 2/4/12, Tony Lindgren t...@atomide.com wrote:
The most difference may be the function enable due to hw difference.
But i see that for DT case, it seems function and group creation may
also be a problem.
What all do you see as a problem with group creation? Just the
naming?
I said from different SoC's pointer of view.
Not only naming, but also if group and function created in driver or dt file
and their map parsing.
+ sprintf(name, %lx,
+ (unsigned long)smux-res-start + offset);
+ pin-name = name;
I'm wondering how about other people do not want the reg address to be
PIN name?
It's less meaningful.
How about try adding optional pinctrl-simple,pin-name entry that you
can add to each mux entry?
Put it in pinctrl device node?
Then how do we name each pin?
And for IMX, currently we name all pins in driver.
I still can not find a good reason that i should name all pins in dt file.
But do you actually need the pin names in kernel? :)
Yes, we indeed have such a case.
For IMX, some special pins mux still need a setting called 'select input'
which
is controlled in other registers.
But a rough idea in my mind that may choose different way to fix this issue.
It's a little like:
pinctrl_usdhc4: pinconfig-usdhc4 {
mux =
MX6Q_SD4_CMD 0 SELECT_INPUT
MX6Q_SD4_CLK 0 0
MX6Q_SD4_DAT0 1 0
MX6Q_SD4_DAT1 1 0
MX6Q_SD4_DAT2 1 SELECT_INPUT
MX6Q_SD4_DAT3 1 0
MX6Q_SD4_DAT4 1 0
MX6Q_SD4_DAT5 1 0
MX6Q_SD4_DAT6 1 0
MX6Q_SD4_DAT7 1 0;
}
This format would not make the dts writer to take too much care of
register address
and value. For this case, the #pinmux-cells would be 3;
It is a little different from OMAP.
If you don't want to keep the extra register entry around, then you
could have a custom .data entry in the pinctrl driver that contains
the mapping of these special registers.
For your proposal, I'm afraid it is a little too much depend on the SoC
register
layout. We need to find a flexible enough way to cover all possible
register layout
difference for all SoCs.
(Considering one register controls multi muxs?)
Most likely those special cases are best handled in hardware specific
drivers.
Note that for more complex mapping you may want to add a hardware
specific .data entry that corresponds to the compatible flag, let's
say for conf range offset to mux range offset.
+ res = smux_rename_function(function, np-full_name);
A little unclear for rename here.
Can we find a better way?
You might want to play with parsing optional names from .dts file.
I don't need the names and they slow down the parsing. For the names,
we can show them with userspace tools using debugfs.
For reference, this is what I get under debugfs function entry
after the rename:
function: /ocp/serial@0x4802, groups = [ pinconfig-uart3 ]
The name looks reasonable to me.
+static int __init smux_parse_one_pinctrl_entry(struct smux_device
*smux,
+ struct device_node *np)
+{
+ int count = 0;
+
+ do {
...
+ } while (++count);
This 'while' is for what? Define multi pinctrl properties?
Yes each client device might request multiple muxes, let's say
two pingroups from two different pinctrl driver instances.
You mean like this?
serial@4802 {
pinctrl = pmx_uart3_x;
pinctrl = pmx_uart3_y;
};
Did i misunderstand?
I still can not understand why need this.
The pinctrl properly in device node can support multi pinmuxs .
serial@4802 {
pinctrl = pmx_uart3_x pmx_uart3_y;
It's good to me that the consensus we reached at Linaro Connect is much like
my proposal in above URL. :)
I meant like what you have in the second option here, the count is
used to parse each entry.
+ val = of_get_property(pdev-dev.of_node,
+ pinctrl-simple,function-off, len);
+ if (!val || len != 4) {
+ dev_err(smux-dev, function off mode not specified\n);
+ ret = -EINVAL;
How about other SoCs not support function off mode?
Maybe disable should not do anything if function-off is not specified?
IIRC currently pinctrl must need a disable function, if that, yes.
However i think we may change it in the future that make .disable function
optinal.
Sounds good to me.
+free:
+ devm_kfree(smux-dev, smux);
+
For devm_* routines, do you still need this error checking?
IIRC, the resource will be automatically released if probe failed.
I guess, are there some recommendations somewhere for that?
I
Re: How do I get slimbus hwmod information?
Paul, Sorry it has taken so long reply. Unavoidable and sudden interruption. On Mon, Jan 30, 2012 at 02:43:34PM -0700, Paul Walmsley wrote: On Mon, 30 Jan 2012, Marc Butler wrote: On Wed, Jan 25, 2012 at 12:46:50PM -0700, Paul Walmsley wrote: The driver shouldn't have any hwmod code in it. Any I believe I came to the conclusion that I need the hwmod support, inorder to build out the platform_* infrastructure the driver needs, to query/configure resources. The driver itself does not call hwmod directly. That sounds right. The other thing that the omap_device/hwmod infrastructure is good for is device reset and power management. Device reset probably won't need any driver modifications; the driver can just start under the assumption that everything has been reset to the POR values documented in the TRM. In terms of power management, your driver should use the pm_runtime*() functions to play nicely with the rest of the system :-) pm_runtime*() will call into omap_device*() which will call into omap_hwmod*() to ensure that clocks and other PM infrastructure are appropriately disabled, enabled, etc. I'm delaying all but the simplest power management for the time being. The complexity is staggering, without even considering interaction the ABE, etc. I'm new to OMAP and need to stay in the wading pool for the time being, lest I drown. :) Yes. N.B., AFAIK Tony Lindgren isn't taking any more board_*.c patches for mainline - the goal is to move all of that stuff to DT eventually. So if you're interested in submitting to mainline (which I hope you are :-) ) you might want to writethe driver to be able to use either platform_data or DT data for configuration. This might involve working on DT bindings; it might be worth including Liam Girdwood l...@ti.com and Peter Ujfalusi peter.ujfal...@ti.com on those discussions. They would also know if someone inside TI may have already written Slimbus drivers that haven't yet made it to mainline, but which may have wound up in some Android-related tree. Based on your suggestion, we are looking at DT, however we may also need hwmod support for older trees. There is no mention of Slimbus in any of the Android trees, so far AFIAK. Thanks for the contacts. This is definitely intended to be submitted to the mainline. There is however a huge amount of work to be done. :) One other brief note is that there are some very interesting power management options that may be possible in the audio path that we may not have full support for in the PM infrastructure layers. Stuff like DPLL chaining and IP blocks with externally-driven functional clocks. I believe Mike Turquette mturque...@ti.com may have explored this area a bit, although perhaps not specifically with Slimbus. If there is any interaction of these features with Slimbus (which there may not be), I'd suggest pushing support for those features off to a second phase, and we should probably have a group discussion about how to handle those cases cleanly :-) As mentioned earlier, I am deferring all but the simplest PM this without ignoring it outright. -- 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: [PATCH] ks8851: Fix NOHZ local_softirq_pending 08 warning
From: Benoit Cousson b-cous...@ti.com Date: Mon, 13 Feb 2012 18:37:12 +0100 This fix a similar problem as in 72092cc45378176ba700034c91b7af2db524df26 and 481a8199142c050b72bff8a1956a49fd0a75bbe0 (can: fix NOHZ local_softirq_pending 08 warning). This fix replaces netif_rx() with netif_rx_ni() which has to be used from process/softirq context. Signed-off-by: Benoit Cousson b-cous...@ti.com Applied. -- 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: OMAP34xx
Hi,
* Tony Lindgren t...@atomide.com [120207 21:01]:
* Russell King - ARM Linux li...@arm.linux.org.uk [120207 01:39]:
On Mon, Feb 06, 2012 at 10:13:15AM -0800, Tony Lindgren wrote:
FYI, I'm now seeing the same warning as Igor posted with
omap2plus_defconfig using the same compiler as Igor:
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
Still no other warnings though.
If you're not getting the twl4030_power_init() you still need to
investigate why. For example, are you sure you're building with
CONFIG_TWL4030_POWER enabled?
Yes it's enabled in omap2plus_defconfig. Same results with one
of your defconfigs. Below is the output from compiler above.
Secondly, check what you're actually getting:
$ arm-linux-objdump -t ../build/omap4/drivers/mfd/twl4030-power.o | grep
twl4030_power_init
00c0 g F .init.text 066c twl4030_power_init
0650 g F .init.text 01a0 twl4030_power_init
$ arm-linux-objdump -r ../build/omap4/drivers/mfd/twl-core.o | grep
'twl4030_power_init\|^RELOC'
RELOCATION RECORDS FOR [.text]:
RELOCATION RECORDS FOR [.init.text]:
RELOCATION RECORDS FOR [.exit.text]:
RELOCATION RECORDS FOR [.devinit.text]:
0258 R_ARM_PC24twl4030_power_init
I'll post a patch to fix this, it's caused by missing
handling in modpost.c.
then, quite simply, your build setup is broken and can't be relied
upon to give proper warnings.
Right, no luck yet getting crosstool-ng built plain gcc working..
Yesterday ftp.gnu.org was down and the script is using that. Have
to continue with that when I get a chance.
The gnu.org ftp issue was a firewall issue on my build box..
Got the compiler build going further with the following fix to
crosstool-ng in case others are having similar issues. Will send
that separately to crosstool-ng mailing list.
Regards,
Tony
--- a/scripts/build/debug/200-duma.sh Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/200-duma.sh Mon Feb 13 12:36:06 2012 -0800
@@ -4,7 +4,7 @@
# Downloading an non-existing file from sourceforge will give you an
# HTML file containing an error message, instead of returning a 404.
# Sigh...
-CT_GetFile duma_${CT_DUMA_VERSION} .tar.gz
http://mesh.dl.sourceforge.net/sourceforge/duma/
+CT_GetFile duma_${CT_DUMA_VERSION} .tar.gz
http://dfn.dl.sourceforge.net/sourceforge/duma/
# Downloading from sourceforge may leave garbage, cleanup
CT_DoExecLog ALL rm -f ${CT_TARBALLS_DIR}/showfiles.php*
}
--- a/scripts/build/debug/300-gdb.shThu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/300-gdb.shMon Feb 13 12:36:06 2012 -0800
@@ -62,7 +62,7 @@
if [ ${do_expat} = y ]; then
CT_GetFile expat-${CT_DEBUG_GDB_EXPAT_VERSION} .tar.gz\
-
http://mesh.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
+
http://dfn.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
fi
}
--- a/scripts/build/debug/500-strace.sh Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/500-strace.sh Mon Feb 13 12:36:06 2012 -0800
@@ -1,7 +1,7 @@
# Build script for strace
do_debug_strace_get() {
-CT_GetFile strace-${CT_STRACE_VERSION}
http://mesh.dl.sourceforge.net/sourceforge/strace/
+CT_GetFile strace-${CT_STRACE_VERSION}
http://dfn.dl.sourceforge.net/sourceforge/strace/
# Downloading from sourceforge leaves garbage, cleanup
CT_DoExecLog ALL rm -f ${CT_TARBALLS_DIR}/showfiles.php*
}
--
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
[PATCH] modpost: Fix section warnings for ARM for many compilers
It turns out that many compilers don't show section warnings on ARM currently because handling for ARM_CALL relocs are missing from modpost.c. Based on commit c2e26114 ([ARM] 3205/1: Handle new EABI relocations when loading kernel modules) it seems that R_ARM_PC24, R_ARM_CALL and R_ARM_JUMP24 can be handled the same way. As modpost.c includes elf.h, we need to also consider that at least Debian libc6-dev is missing defines for both R_ARM_CALL and R_ARM_JUMP24 in /usr/include/elf.h. So for now let's just use the numbers in modpost.c. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Ben Hutchings b...@decadent.org.uk Cc: Anders Kaseorg ande...@ksplice.com Cc: Greg KH gre...@linuxfoundation.org Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- Anybody got better ideas for dealing with the missing elf.h defines? --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1505,6 +1505,8 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) (elf-symtab_start + ELF_R_SYM(r-r_info)); break; case R_ARM_PC24: + case 28:/* R_ARM_CALL */ + case 29:/* R_ARM_JUMP24 */ /* From ARM ABI: ((S + A) | T) - P */ r-r_addend = (int)(long)(elf-hdr + sechdr-sh_offset + -- 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: [PATCH] modpost: Fix section warnings for ARM for many compilers
On Mon, Feb 13, 2012 at 01:24:01PM -0800, Tony Lindgren wrote: It turns out that many compilers don't show section warnings on ARM currently because handling for ARM_CALL relocs are missing from modpost.c. Based on commit c2e26114 ([ARM] 3205/1: Handle new EABI relocations when loading kernel modules) it seems that R_ARM_PC24, R_ARM_CALL and R_ARM_JUMP24 can be handled the same way. As modpost.c includes elf.h, we need to also consider that at least Debian libc6-dev is missing defines for both R_ARM_CALL and R_ARM_JUMP24 in /usr/include/elf.h. Huh, even unstable's /usr/include/elf.h doesn't have these symbols. So for now let's just use the numbers in modpost.c. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Ben Hutchings b...@decadent.org.uk Cc: Anders Kaseorg ande...@ksplice.com Cc: Greg KH gre...@linuxfoundation.org Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- Anybody got better ideas for dealing with the missing elf.h defines? Maybe: #ifndef R_ARM_CALL #warning you're elf.h include is outdated #define R_ARM_CALL 28 #endif Best regards Uwe --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -1505,6 +1505,8 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r) (elf-symtab_start + ELF_R_SYM(r-r_info)); break; case R_ARM_PC24: + case 28:/* R_ARM_CALL */ + case 29:/* R_ARM_JUMP24 */ /* From ARM ABI: ((S + A) | T) - P */ r-r_addend = (int)(long)(elf-hdr + sechdr-sh_offset + -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: [PATCH] modpost: Fix section warnings for ARM for many compilers
On Mon, Feb 13, 2012 at 11:26:52PM +0100, Uwe Kleine-König wrote: On Mon, Feb 13, 2012 at 01:24:01PM -0800, Tony Lindgren wrote: It turns out that many compilers don't show section warnings on ARM currently because handling for ARM_CALL relocs are missing from modpost.c. Based on commit c2e26114 ([ARM] 3205/1: Handle new EABI relocations when loading kernel modules) it seems that R_ARM_PC24, R_ARM_CALL and R_ARM_JUMP24 can be handled the same way. As modpost.c includes elf.h, we need to also consider that at least Debian libc6-dev is missing defines for both R_ARM_CALL and R_ARM_JUMP24 in /usr/include/elf.h. Huh, even unstable's /usr/include/elf.h doesn't have these symbols. So for now let's just use the numbers in modpost.c. Cc: Rusty Russell ru...@rustcorp.com.au Cc: Ben Hutchings b...@decadent.org.uk Cc: Anders Kaseorg ande...@ksplice.com Cc: Greg KH gre...@linuxfoundation.org Cc: Russell King rmk+ker...@arm.linux.org.uk Signed-off-by: Tony Lindgren t...@atomide.com --- Anybody got better ideas for dealing with the missing elf.h defines? Maybe: #ifndef R_ARM_CALL #warning you're elf.h include is outdated You are elf.h include is outdated does not make sense. Why are you calling Tony an elf.h include? -- 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: [GIT PULL] omap fixes for v3.3-rc3
On Monday 13 February 2012, Tony Lindgren wrote: Hi Arnd and Olof, Please pull omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes This contains a DT boot fix that was found sitting in the omap DT branch, omap2 related PM fix for serial port, and few compile and warning fixes. Note that Russell also has a series of omap fixes queued up that will get merged via his tree. There should not be any conflicts between these two series. Thanks, merged into the fixes branch. Arnd -- 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: [PATCH 3.3 v2] I2C: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, Feb 08, 2012 at 01:18:21PM +0200, Luciano Coelho wrote:
Since commit 6145197 (i2c: OMAP: Add DT support for i2c controller),
building i2c_omap.c breaks if CONFIG_OF is not set:
drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared
(first use in this function)
drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is
reported only once
drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.)
This is because the definition of omap_i2c_of_match is #ifdef'd on
CONFIG_OF, but the usage of it is not.
Since the places where omap_ic2_of_match are prepared to get NULL
pointers if CONFIG_OF is not defined, we can simply define it to NULL.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
v2: changed the commit log to use abbrev sha and include the commit subject
drivers/i2c/busses/i2c-omap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f713eac..fd200eb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+static const struct of_device_id *omap_i2c_of_match = NULL;
#endif
of_match_ptr(_ptr) will go to NULL if CONFIG_OF is not set, use that please.
--
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
[PATCH 1/3] ARM: OMAP2+: Move SDRC related functions from io.h into local common.h
These should be local to omap2/3/4. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/common.h |5 + arch/arm/plat-omap/include/plat/io.h |4 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index febffde..5aa1acb 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -235,5 +235,10 @@ static inline u32 omap4_mpuss_read_prev_context_state(void) return 0; } #endif + +struct omap_sdrc_params; +extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0, + struct omap_sdrc_params *sdrc_cs1); + #endif /* __ASSEMBLER__ */ #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */ diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index 0696bae..f5b386b 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -266,10 +266,6 @@ extern void omap_writeb(u8 v, u32 pa); extern void omap_writew(u16 v, u32 pa); extern void omap_writel(u32 v, u32 pa); -struct omap_sdrc_params; -extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0, - struct omap_sdrc_params *sdrc_cs1); - extern void __init omap_init_consistent_dma_size(void); #endif -- 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
[PATCH 0/3] Move most of omap io.h into omap-iomap.h
Hi all, This is intended as clean-up before we apply Rob Herring's series to remove mach/io.h. Regards, Tony --- Tony Lindgren (3): ARM: OMAP2+: Move SDRC related functions from io.h into local common.h ARM: OMAP: Introduce omap-iomap.h and convert files depending on current io.h to use it ARM: OMAP: Move most of io.h to omap-iomap.h arch/arm/mach-omap1/ams-delta-fiq-handler.S|1 arch/arm/mach-omap1/ams-delta-fiq.c|3 arch/arm/mach-omap1/board-ams-delta.c |7 + arch/arm/mach-omap1/board-fsample.c|7 + arch/arm/mach-omap1/board-h2.c |7 - arch/arm/mach-omap1/board-h3.c |9 + arch/arm/mach-omap1/board-htcherald.c |5 - arch/arm/mach-omap1/board-innovator.c |7 + arch/arm/mach-omap1/board-nokia770.c |7 + arch/arm/mach-omap1/board-osk.c|8 - arch/arm/mach-omap1/board-palmte.c |5 - arch/arm/mach-omap1/board-palmtt.c | 10 + arch/arm/mach-omap1/board-palmz71.c| 10 + arch/arm/mach-omap1/board-perseus2.c |7 + arch/arm/mach-omap1/board-sx1.c|7 + arch/arm/mach-omap1/board-voiceblue.c |7 + arch/arm/mach-omap1/clock.c|1 arch/arm/mach-omap1/clock_data.c |1 arch/arm/mach-omap1/devices.c |8 + arch/arm/mach-omap1/dma.c |1 arch/arm/mach-omap1/flash.c|1 arch/arm/mach-omap1/fpga.c |4 arch/arm/mach-omap1/id.c |2 arch/arm/mach-omap1/include/mach/entry-macro.S |4 arch/arm/mach-omap1/io.c |2 arch/arm/mach-omap1/irq.c |5 - arch/arm/mach-omap1/lcd_dma.c |4 arch/arm/mach-omap1/mcbsp.c|4 arch/arm/mach-omap1/pm.c |6 - arch/arm/mach-omap1/reset.c|4 arch/arm/mach-omap1/sleep.S|5 + arch/arm/mach-omap1/sram.S |4 arch/arm/mach-omap1/time.c |4 arch/arm/mach-omap1/timer32k.c |8 + arch/arm/mach-omap1/usb.c |1 arch/arm/mach-omap2/board-flash.c |1 arch/arm/mach-omap2/clock2420_data.c |1 arch/arm/mach-omap2/clock2430.c|1 arch/arm/mach-omap2/clock2430_data.c |1 arch/arm/mach-omap2/clock3xxx_data.c |1 arch/arm/mach-omap2/clock44xx_data.c |2 arch/arm/mach-omap2/cm2xxx_3xxx.c |3 arch/arm/mach-omap2/cm44xx.c |3 arch/arm/mach-omap2/cminst44xx.c |3 arch/arm/mach-omap2/common.c |3 arch/arm/mach-omap2/common.h |5 + arch/arm/mach-omap2/control.c |1 arch/arm/mach-omap2/devices.c |1 arch/arm/mach-omap2/io.c |3 arch/arm/mach-omap2/irq.c |5 - arch/arm/mach-omap2/omap-smp.c |4 arch/arm/mach-omap2/pm24xx.c |4 arch/arm/mach-omap2/prcm_mpu44xx.c |3 arch/arm/mach-omap2/prm44xx.c |3 arch/arm/mach-omap2/prminst44xx.c |3 arch/arm/mach-omap2/sdrc2xxx.c |5 - arch/arm/mach-omap2/sleep34xx.S|4 arch/arm/mach-omap2/sram242x.S |4 arch/arm/mach-omap2/sram243x.S |4 arch/arm/mach-omap2/sram34xx.S |5 - arch/arm/plat-omap/devices.c |4 arch/arm/plat-omap/dma.c |6 - arch/arm/plat-omap/dmtimer.c |1 arch/arm/plat-omap/include/plat/io.h | 226 arch/arm/plat-omap/include/plat/omap-iomap.h | 221 +++ arch/arm/plat-omap/ocpi.c |2 arch/arm/plat-omap/sram.c |2 arch/arm/plat-omap/usb.c |1 drivers/gpio/gpio-omap.c |7 + drivers/pcmcia/omap_cf.c |4 drivers/spi/spi-omap-uwire.c |4 drivers/usb/host/ohci-omap.c |6 - drivers/usb/otg/isp1301_omap.c |7 - drivers/video/omap/lcd_ams_delta.c |2 drivers/video/omap/lcd_inn1510.c |2 drivers/video/omap/lcd_osk.c |3 drivers/video/omap/lcdc.c |7 - drivers/video/omap/sossi.c |1 78 files changed, 449 insertions(+), 306 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/omap-iomap.h -- Signature -- To unsubscribe from this list: send the line
[PATCH 2/3] ARM: OMAP: Introduce omap-iomap.h and convert files depending on current io.h to use it
Introduce omap-iomap.h and convert files depending on current io.h to use it. This is needed to move most of io.h into omap-iomap.h in two smaller patches without breaking build and booting. While at it, clean-up the include ordering to separate asm, plat, mach and local includes as the ordering has gotten confusing after earlier search and replace changes to introduce the local common.h header. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap1/ams-delta-fiq-handler.S|1 + arch/arm/mach-omap1/ams-delta-fiq.c|3 +++ arch/arm/mach-omap1/board-ams-delta.c |7 +-- arch/arm/mach-omap1/board-fsample.c|7 +-- arch/arm/mach-omap1/board-h2.c |7 --- arch/arm/mach-omap1/board-h3.c |9 + arch/arm/mach-omap1/board-htcherald.c |5 +++-- arch/arm/mach-omap1/board-innovator.c |7 +-- arch/arm/mach-omap1/board-nokia770.c |7 +-- arch/arm/mach-omap1/board-osk.c|8 arch/arm/mach-omap1/board-palmte.c |5 - arch/arm/mach-omap1/board-palmtt.c | 10 ++ arch/arm/mach-omap1/board-palmz71.c| 10 ++ arch/arm/mach-omap1/board-perseus2.c |7 +-- arch/arm/mach-omap1/board-sx1.c|7 +-- arch/arm/mach-omap1/board-voiceblue.c |7 +-- arch/arm/mach-omap1/clock.c|1 + arch/arm/mach-omap1/clock_data.c |1 + arch/arm/mach-omap1/devices.c |8 +--- arch/arm/mach-omap1/dma.c |1 + arch/arm/mach-omap1/flash.c|1 + arch/arm/mach-omap1/fpga.c |4 +++- arch/arm/mach-omap1/id.c |2 ++ arch/arm/mach-omap1/include/mach/entry-macro.S |4 +++- arch/arm/mach-omap1/io.c |2 ++ arch/arm/mach-omap1/irq.c |5 - arch/arm/mach-omap1/lcd_dma.c |4 +++- arch/arm/mach-omap1/mcbsp.c|4 +++- arch/arm/mach-omap1/pm.c |6 -- arch/arm/mach-omap1/reset.c|4 +++- arch/arm/mach-omap1/sleep.S|5 + arch/arm/mach-omap1/sram.S |4 arch/arm/mach-omap1/time.c |4 +++- arch/arm/mach-omap1/timer32k.c |8 ++-- arch/arm/mach-omap1/usb.c |1 + arch/arm/mach-omap2/board-flash.c |1 + arch/arm/mach-omap2/clock2420_data.c |1 + arch/arm/mach-omap2/clock2430.c|1 + arch/arm/mach-omap2/clock2430_data.c |1 + arch/arm/mach-omap2/clock3xxx_data.c |1 + arch/arm/mach-omap2/clock44xx_data.c |2 ++ arch/arm/mach-omap2/cm2xxx_3xxx.c |3 ++- arch/arm/mach-omap2/cm44xx.c |3 ++- arch/arm/mach-omap2/cminst44xx.c |3 ++- arch/arm/mach-omap2/common.c |3 ++- arch/arm/mach-omap2/control.c |1 + arch/arm/mach-omap2/devices.c |1 + arch/arm/mach-omap2/io.c |3 ++- arch/arm/mach-omap2/irq.c |5 - arch/arm/mach-omap2/omap-smp.c |4 +++- arch/arm/mach-omap2/pm24xx.c |4 +++- arch/arm/mach-omap2/prcm_mpu44xx.c |3 ++- arch/arm/mach-omap2/prm44xx.c |3 ++- arch/arm/mach-omap2/prminst44xx.c |3 ++- arch/arm/mach-omap2/sdrc2xxx.c |5 +++-- arch/arm/mach-omap2/sleep34xx.S|4 arch/arm/mach-omap2/sram242x.S |4 arch/arm/mach-omap2/sram243x.S |4 arch/arm/mach-omap2/sram34xx.S |5 - arch/arm/plat-omap/devices.c |4 +++- arch/arm/plat-omap/dma.c |6 -- arch/arm/plat-omap/dmtimer.c |1 + arch/arm/plat-omap/include/plat/omap-iomap.h |0 arch/arm/plat-omap/ocpi.c |2 ++ arch/arm/plat-omap/sram.c |2 +- arch/arm/plat-omap/usb.c |1 + drivers/gpio/gpio-omap.c |7 +-- drivers/pcmcia/omap_cf.c |4 +++- drivers/spi/spi-omap-uwire.c |4 +++- drivers/usb/host/ohci-omap.c |6 -- drivers/usb/otg/isp1301_omap.c |7 --- drivers/video/omap/lcd_ams_delta.c |2 ++ drivers/video/omap/lcd_inn1510.c |2 ++ drivers/video/omap/lcd_osk.c |3 +++ drivers/video/omap/lcdc.c |7 --- drivers/video/omap/sossi.c
[PATCH 3/3] ARM: OMAP: Move most of io.h to omap-iomap.h
Move most of io.h to omap-iomap.h. This is needed for the ARM generic removal of io.h files. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/plat/io.h | 222 -- arch/arm/plat-omap/include/plat/omap-iomap.h | 221 ++ 2 files changed, 221 insertions(+), 222 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index f5b386b..6a3c700 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -48,226 +48,4 @@ #define __io(a)__typesafe_io(a) #define __mem_pci(a) (a) -/* - * - * I/O mapping - * - */ - -#ifdef __ASSEMBLER__ -#define IOMEM(x) (x) -#else -#define IOMEM(x) ((void __force __iomem *)(x)) -#endif - -#define OMAP1_IO_OFFSET0x0100 /* Virtual IO = 0xfefb */ -#define OMAP1_IO_ADDRESS(pa) IOMEM((pa) - OMAP1_IO_OFFSET) - -#define OMAP2_L3_IO_OFFSET 0x9000 -#define OMAP2_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L3_IO_OFFSET) /* L3 */ - - -#define OMAP2_L4_IO_OFFSET 0xb200 -#define OMAP2_L4_IO_ADDRESS(pa)IOMEM((pa) + OMAP2_L4_IO_OFFSET) /* L4 */ - -#define OMAP4_L3_IO_OFFSET 0xb400 -#define OMAP4_L3_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_IO_OFFSET) /* L3 */ - -#define AM33XX_L4_WK_IO_OFFSET 0xb500 -#define AM33XX_L4_WK_IO_ADDRESS(pa)IOMEM((pa) + AM33XX_L4_WK_IO_OFFSET) - -#define OMAP4_L3_PER_IO_OFFSET 0xb110 -#define OMAP4_L3_PER_IO_ADDRESS(pa)IOMEM((pa) + OMAP4_L3_PER_IO_OFFSET) - -#define OMAP4_GPMC_IO_OFFSET 0xa900 -#define OMAP4_GPMC_IO_ADDRESS(pa) IOMEM((pa) + OMAP4_GPMC_IO_OFFSET) - -#define OMAP2_EMU_IO_OFFSET0xaa80 /* Emulation */ -#define OMAP2_EMU_IO_ADDRESS(pa) IOMEM((pa) + OMAP2_EMU_IO_OFFSET) - -/* - * - * Omap1 specific IO mapping - * - */ - -#define OMAP1_IO_PHYS 0xFFFB -#define OMAP1_IO_SIZE 0x4 -#define OMAP1_IO_VIRT (OMAP1_IO_PHYS - OMAP1_IO_OFFSET) - -/* - * - * Omap2 specific IO mapping - * - */ - -/* We map both L3 and L4 on OMAP2 */ -#define L3_24XX_PHYS L3_24XX_BASE/* 0x6800 -- 0xf800*/ -#define L3_24XX_VIRT (L3_24XX_PHYS + OMAP2_L3_IO_OFFSET) -#define L3_24XX_SIZE SZ_1M /* 44kB of 128MB used, want 1MB sect */ -#define L4_24XX_PHYS L4_24XX_BASE/* 0x4800 -- 0xfa00 */ -#define L4_24XX_VIRT (L4_24XX_PHYS + OMAP2_L4_IO_OFFSET) -#define L4_24XX_SIZE SZ_1M /* 1MB of 128MB used, want 1MB sect */ - -#define L4_WK_243X_PHYSL4_WK_243X_BASE /* 0x4900 -- 0xfb00 */ -#define L4_WK_243X_VIRT(L4_WK_243X_PHYS + OMAP2_L4_IO_OFFSET) -#define L4_WK_243X_SIZESZ_1M -#define OMAP243X_GPMC_PHYS OMAP243X_GPMC_BASE -#define OMAP243X_GPMC_VIRT (OMAP243X_GPMC_PHYS + OMAP2_L3_IO_OFFSET) - /* 0x6e00 -- 0xfe00 */ -#define OMAP243X_GPMC_SIZE SZ_1M -#define OMAP243X_SDRC_PHYS OMAP243X_SDRC_BASE - /* 0x6D00 -- 0xfd00 */ -#define OMAP243X_SDRC_VIRT (OMAP243X_SDRC_PHYS + OMAP2_L3_IO_OFFSET) -#define OMAP243X_SDRC_SIZE SZ_1M -#define OMAP243X_SMS_PHYS OMAP243X_SMS_BASE - /* 0x6c00 -- 0xfc00 */ -#define OMAP243X_SMS_VIRT (OMAP243X_SMS_PHYS + OMAP2_L3_IO_OFFSET) -#define OMAP243X_SMS_SIZE SZ_1M - -/* 2420 IVA */ -#define DSP_MEM_2420_PHYS OMAP2420_DSP_MEM_BASE - /* 0x5800 -- 0xfc10 */ -#define DSP_MEM_2420_VIRT 0xfc10 -#define DSP_MEM_2420_SIZE 0x28000 -#define DSP_IPI_2420_PHYS OMAP2420_DSP_IPI_BASE - /* 0x5900 -- 0xfc128000 */ -#define DSP_IPI_2420_VIRT 0xfc128000 -#define DSP_IPI_2420_SIZE SZ_4K -#define DSP_MMU_2420_PHYS OMAP2420_DSP_MMU_BASE - /* 0x5a00 -- 0xfc129000 */ -#define DSP_MMU_2420_VIRT 0xfc129000 -#define DSP_MMU_2420_SIZE SZ_4K - -/* 2430 IVA2.1 - currently unmapped */ - -/* - * - * Omap3 specific IO mapping - * - */ - -/* We map both L3 and L4 on OMAP3 */ -#define L3_34XX_PHYS L3_34XX_BASE/*
Re: OMAP34xx
* Tony Lindgren t...@atomide.com [120213 12:46]:
Got the compiler build going further with the following fix to
crosstool-ng in case others are having similar issues. Will send
that separately to crosstool-ng mailing list.
Looks like that's already in works according to this:
http://sourceware.org/ml/crossgcc/2012-02/msg00048.html
Regards,
Tony
--- a/scripts/build/debug/200-duma.sh Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/200-duma.sh Mon Feb 13 12:36:06 2012 -0800
@@ -4,7 +4,7 @@
# Downloading an non-existing file from sourceforge will give you an
# HTML file containing an error message, instead of returning a 404.
# Sigh...
-CT_GetFile duma_${CT_DUMA_VERSION} .tar.gz
http://mesh.dl.sourceforge.net/sourceforge/duma/
+CT_GetFile duma_${CT_DUMA_VERSION} .tar.gz
http://dfn.dl.sourceforge.net/sourceforge/duma/
# Downloading from sourceforge may leave garbage, cleanup
CT_DoExecLog ALL rm -f ${CT_TARBALLS_DIR}/showfiles.php*
}
--- a/scripts/build/debug/300-gdb.sh Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/300-gdb.sh Mon Feb 13 12:36:06 2012 -0800
@@ -62,7 +62,7 @@
if [ ${do_expat} = y ]; then
CT_GetFile expat-${CT_DEBUG_GDB_EXPAT_VERSION} .tar.gz\
-
http://mesh.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
+
http://dfn.dl.sourceforge.net/sourceforge/expat/expat/${CT_DEBUG_GDB_EXPAT_VERSION}
fi
}
--- a/scripts/build/debug/500-strace.sh Thu Feb 02 22:43:18 2012 +0100
+++ b/scripts/build/debug/500-strace.sh Mon Feb 13 12:36:06 2012 -0800
@@ -1,7 +1,7 @@
# Build script for strace
do_debug_strace_get() {
-CT_GetFile strace-${CT_STRACE_VERSION}
http://mesh.dl.sourceforge.net/sourceforge/strace/
+CT_GetFile strace-${CT_STRACE_VERSION}
http://dfn.dl.sourceforge.net/sourceforge/strace/
# Downloading from sourceforge leaves garbage, cleanup
CT_DoExecLog ALL rm -f ${CT_TARBALLS_DIR}/showfiles.php*
}
--
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
--
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: [PATCH] modpost: Fix section warnings for ARM for many compilers
On Mon, 13 Feb 2012 22:51:18 +, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Feb 13, 2012 at 11:26:52PM +0100, Uwe Kleine-König wrote: On Mon, Feb 13, 2012 at 01:24:01PM -0800, Tony Lindgren wrote: Maybe: #ifndef R_ARM_CALL #warning you're elf.h include is outdated You are elf.h include is outdated does not make sense. Why are you calling Tony an elf.h include? Because he knew it would attract the attention of pedants to the patch? :) Just do the #ifndef, and skip the warning. There's not much the poor user receiving the warning can do about it. Acked-by: Rusty Russell ru...@rustcorp.com.au Thanks, Rusty. -- 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: [PATCH] staging: tidspbridge: enable watchdog by default
On Feb 11, 2012 3:03 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Feb 11, 2012 at 9:19 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: On Feb 10, 2012 12:44 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Feb 10, 2012 at 10:35 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Fri, Feb 10, 2012 at 09:42:32PM +0200, Felipe Contreras wrote: On Fri, Feb 10, 2012 at 8:00 PM, Dan Carpenter dan.carpen...@oracle.com wrote: On Fri, Feb 10, 2012 at 01:30:48AM +0200, Felipe Contreras wrote: It's not an oops, it's a warning, and again, it depends on the firmware being used. We don't have control over that, and we have no way to detect if this feature is there. It's up to the user. Perhaps just remove the warning message and handle the condition instead of printing a stack dump? The user should be triggering stack dumps. What on earth? The warning doesn't come from the driver. I'm not sure I understand. Are you saying that because it comes from the arch/ directory, it can't be fixed? I have good news for you my friend. :) It's all open source! \o/ The fact that you _can_ remove the warning doesn't mean you should. To me it sounds like a proper warning. Anyway, I saw in another email that Omar is working on a fix so probably we can just wait for his patch, yes? He only proposed a solution, I doubt he is working on. And to me, that sounded like a hack rather than a proper fix. I'm out on travel but will be able to look at it on Monday. Well, I think it is the right way, you look on the firmware if it has WDT you use it if it doesn't then you don't. Rather than guessing if you have the feature. It would be like reading a config option in the firmware. Yeah, but it's not really firmware, it's an operating system image. I can be running Linux there, and I might have implemented WDT. How is that code going to find that out? Tidspbridge loader doesn't support that use case, baseimage and let's say a dsp-linuximg won't have the same layout, hence it won't be able to parse and load the latter. When that case is applicable, we should first modify the loader code or prepare the baseimages to be common so we can get rid of specific loaders and just dump them into memory. WDT could be detected by prepending common symbols into the baseimages or just making the new images to treat all peripherals as resources, that is, the new baseimg should actually request the wdt3 as any other clock. Regards, Omar -- 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: [PATCH] staging: tidspbridge: enable watchdog by default
On Thu, Feb 9, 2012 at 9:18 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote: Hi, On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Again, I'm totally confused as to _WHY_ this needs to be y. What is causing this oops without it? If an oops is happening, then shouldn't this be a strict dependancy? Why allow it to be disabled at all if it can break your box if you don't enable it? It's not an oops, it's a warning, and again, it depends on the firmware being used. We don't have control over that, and we have no way to detect if this feature is there. It's up to the user. I have been thinking more into it, how about looking for a WDT symbol inside the baseimage to decide whether to turn ON/OFF WDT3, this would mean that the code is always compiled in, but the decision to turn it on/off is made at runtime. I totally don't understand, why not just silence the warning properly then? I fail to understand why this warning happens, why it depends on the firmware, and why you can't detect it at runtime to not do it. And how it all ties into a kconfig option... Just FTR, the warning comes from an interconnect driver that reports errors. This specific warning occurs because the dsp tries to access wdt3 registers without a clock, hence turning ON the wdt3 (or default y for wdt3 Kconfig) will make the warning to disappear when first loading a base image into the dsp, because now there will be a clock for the registers. It depends on the firmware because the accesses are made from the dsp itself. Regards, Omar -- 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: [PATCH] modpost: Fix section warnings for ARM for many compilers
* Rusty Russell ru...@rustcorp.com.au [120213 16:07]:
On Mon, 13 Feb 2012 22:51:18 +, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Feb 13, 2012 at 11:26:52PM +0100, Uwe Kleine-König wrote:
On Mon, Feb 13, 2012 at 01:24:01PM -0800, Tony Lindgren wrote:
Maybe:
#ifndef R_ARM_CALL
#warning you're elf.h include is outdated
You are elf.h include is outdated does not make sense.
Why are you calling Tony an elf.h include?
Because he knew it would attract the attention of pedants to the patch?
:)
I've been called worse than that :)
Just do the #ifndef, and skip the warning. There's not much the poor
user receiving the warning can do about it.
OK
Acked-by: Rusty Russell ru...@rustcorp.com.au
Assuming your ack applies for this patch below, let me know if that's
not the case.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 13 Feb 2012 12:30:09 -0800
Subject: [PATCH] modpost: Fix section warnings for ARM for many compilers
It turns out that many compilers don't show section warnings on ARM
currently because handling for ARM_CALL relocs are missing from
modpost.c.
Based on commit c2e26114 ([ARM] 3205/1: Handle new EABI relocations when
loading kernel modules) it seems that R_ARM_PC24, R_ARM_CALL and
R_ARM_JUMP24 can be handled the same way.
Note that at least Debian libc6-dev is missing defines for both
R_ARM_CALL and R_ARM_JUMP24 in /usr/include/elf.h. So for now
we need to define them in modpost.c if not defined.
Acked-by: Rusty Russell ru...@rustcorp.com.au
Cc: Ben Hutchings b...@decadent.org.uk
Cc: Anders Kaseorg ande...@ksplice.com
Cc: Greg KH gre...@linuxfoundation.org
Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1494,6 +1494,13 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr
*sechdr, Elf_Rela *r)
return 0;
}
+#ifndef R_ARM_CALL
+#define R_ARM_CALL 28
+#endif
+#ifndef R_ARM_JUMP24
+#define R_ARM_JUMP24 29
+#endif
+
static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
{
unsigned int r_typ = ELF_R_TYPE(r-r_info);
@@ -1505,6 +1512,8 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr
*sechdr, Elf_Rela *r)
(elf-symtab_start + ELF_R_SYM(r-r_info));
break;
case R_ARM_PC24:
+ case R_ARM_CALL:
+ case R_ARM_JUMP24:
/* From ARM ABI: ((S + A) | T) - P */
r-r_addend = (int)(long)(elf-hdr +
sechdr-sh_offset +
--
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: [PATCH 1/2] ARM: OMAP: Get rid of reset for system timer
On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [120202 05:33]: From: Rajendra Nayakrna...@ti.com hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code. If we want this queued as a fix, it should also describe what actually breaks? Timer? PM? It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4. So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet. -- 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: [PATCH 0/6] mmc: omap_hsmmc: Clean up use/abuse of pdev-id
On Friday 10 February 2012 06:57 PM, T Krishnamoorthy, Balaji wrote: On Tue, Feb 7, 2012 at 3:32 PM, S, Venkatramansvenk...@ti.com wrote: On Sat, Feb 4, 2012 at 8:21 PM, Rajendra Nayakrna...@ti.com wrote: This series mainly cleans up all instances of hardcoding's in the driver based on pdev-id. This is cleanup leading to the DT adaptation of omap_hsmmc driver. Patches are based on 3.3-rc2 and can be found here git://gitorious.org/omap-pm/linux.git omap_hsmmc_cleanup Tested the patches on my omap4 boards (panda and SDP) but haven't tested yet on omap3/2 since I did'nt have boards handy. So any testing on any omap3/2 boards is really appreciated. Tested this series on 2430SDP with FS on SD card Thanks, will repost adding Tested-by from you and Venkat, also getting rid of the one instance of host-id usage left in a debug print. -- 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: [PATCH 00/10] I2C updates
Hi, I am interested in testing these patches on AM335x. Do you have a tree with these patches applied so that I can pull. On Fri, Feb 10, 2012 at 19:29:55, Datta, Shubhrajyoti wrote: This patch series colates the various i2c updates into a series. Since it is collection of various patches the version info is not retained, however most of them undergone multiple versions. This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. Tested on omap4sdp and omap3sdp. Cc: Kevin Hilman khil...@ti.com Cc: Ben Dooks ben-li...@fluff.org Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (8): I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME OMAP : I2C : Remove reset at init OMAP: I2C: I2C register restore only if context is lost OMAP: I2C: Fix the interrupt clearing in OMAP4 OMAP: I2C: Fix the mismatch of pm_runtime enable and disable OMAP: I2C: Optimise the remove code OMAP: I2C: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition drivers/i2c/busses/i2c-omap.c | 173 - 1 files changed, 101 insertions(+), 72 deletions(-) Regards, Gururaja -- 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: [PATCH 1/2] ARM: OMAP: Get rid of reset for system timer
On Tue, Feb 14, 2012 at 10:44 AM, Rajendra Nayak rna...@ti.com wrote: On Saturday 11 February 2012 12:48 AM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [120202 05:33]: From: Rajendra Nayakrna...@ti.com hwmod setup already does a reset and sets the OCP sysconfig registers appropriately. Avoid doing a reset again and overriding the OCP sysconfig settings in the system timer init code. If we want this queued as a fix, it should also describe what actually breaks? Timer? PM? It only fixes the redundant reset and overriding the smartidle-wakeup OCP setting (done by hwmod) with the smartidle in the driver. Doing this doesn't really break anything as yet in mainline, but will cause timer wakeup issues once OFF mode is in place for OMAP4. On OMAP5 however this was causing more issues as the softreset bit position is different than on OMAP2/3/4. So it should be ok to queue this in for 3.4 considering neither OMAP4 OFF, not OMAP5 support is in mainline yet. I second Rajendra's comment. Regards Santosh -- 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: [PATCH 2/2] pinctrl: Add simple pinmux driver using device tree data
On Mon, Feb 13, 2012 at 11:11:13AM -0800, Tony Lindgren wrote:
...
Put it in pinctrl device node?
Then how do we name each pin?
And for IMX, currently we name all pins in driver.
I still can not find a good reason that i should name all pins in dt file.
But do you actually need the pin names in kernel? :)
Yes, i meant name pins in driver.
Yes, we indeed have such a case.
For IMX, some special pins mux still need a setting called 'select input'
which
is controlled in other registers.
But a rough idea in my mind that may choose different way to fix this issue.
It's a little like:
pinctrl_usdhc4: pinconfig-usdhc4 {
mux =
MX6Q_SD4_CMD 0 SELECT_INPUT
MX6Q_SD4_CLK 0 0
MX6Q_SD4_DAT0 1 0
MX6Q_SD4_DAT1 1 0
MX6Q_SD4_DAT2 1 SELECT_INPUT
MX6Q_SD4_DAT3 1 0
MX6Q_SD4_DAT4 1 0
MX6Q_SD4_DAT5 1 0
MX6Q_SD4_DAT6 1 0
MX6Q_SD4_DAT7 1 0;
}
This format would not make the dts writer to take too much care of
register address
and value. For this case, the #pinmux-cells would be 3;
It is a little different from OMAP.
If you don't want to keep the extra register entry around, then you
could have a custom .data entry in the pinctrl driver that contains
the mapping of these special registers.
Yes, that's what i think.
But we still need pass the value for thoes sepcial registers from dt.
For your proposal, I'm afraid it is a little too much depend on the SoC
register
layout. We need to find a flexible enough way to cover all possible
register layout
difference for all SoCs.
(Considering one register controls multi muxs?)
Most likely those special cases are best handled in hardware specific
drivers.
Yes, common driver needs provide a way to cover that.
Did i misunderstand?
I still can not understand why need this.
The pinctrl properly in device node can support multi pinmuxs .
serial@4802 {
pinctrl = pmx_uart3_x pmx_uart3_y;
It's good to me that the consensus we reached at Linaro Connect is much like
my proposal in above URL. :)
I meant like what you have in the second option here, the count is
used to parse each entry.
You're right, i misunderstood before.
Sorry for the noise.
Regards
Dong Aisheng
--
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
