Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
On Fri, 1 Apr 2011, Rajendra Nayak wrote:
On 4/1/2011 8:21 PM, Rajendra Nayak wrote:
In omap_hwmod.c:_enable(), what do you think about:
1. saving the current idle mode of the clockdomain,
2. forcing the clockdomain to software-supervised wakeup.
3. enabling clocks and waiting for the module as we currently do, then
4. switching the clockdomain's idle mode back to its original state?
Seems like that would be a reasonable approach for the short term, at
least for drivers that have been converted to PM runtime.
Ok, I'll try and get some RFC patches in these lines soon.
I tried some of what you were suggesting here and it seems to
work well, like you said, for the drivers which are converted
to PM runtime.
Now the issue seems to be, how do we handle the ones which
are *still* using clock framework to enable main clocks and
are yet to be converted to PM runtime.
One such, MMC, is showing me issues on OMAP4 even at boot
and causes a crash.
Its a different thing that some of these drivers which use
direct clock calls are working by fluke on OMAP4 since the
clock framework does not even wait for the modules to become
accessible after the clock enable.
I know the right way seems to be to get all these drivers
converted to PM runtime, but that might take sometime.
One way I am able to get this working (atleast MMC)
is by preventing the clock domain belonging to MMC module
from being programmed into HW_SUP mode.
What programs the OMAP4 clockdomains into hwsup mode in the first place?
There's no clkdms_setup() as there is in mach-omap2/pm34xx.c. I guess
maybe this code in mach-omap2/pm.c might do it as a side effect:
switch (sleep_switch) {
case FORCEWAKEUP_SWITCH:
if (pwrdm-pwrdm_clkdms[0]-flags CLKDM_CAN_ENABLE_AUTO)
clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
else
clkdm_sleep(pwrdm-pwrdm_clkdms[0]);
break;
If I'm reading this code correctly, it will always force clockdomains that
support hwsup mode into hwsup mode, even if they've been previously
programmed to swsup mode. That's not right. This function should leave
the clockdomain's autoidle setting where it was when the function was
entered. So this needs to be fixed also.
Acceptable hack in the interim while we wait for the MMC driver to be
using PM runtime?
Ideally this should be overridden in the code, not the data, since this
hack is needed due to a software problem, not a hardware problem. The
clockdomains data should just be a statement of what the hardware
supports.
But given the above bug and the lack of some clkdms_setup() function for
OMAP4, I guess the clockdomains data is the least bad choice for right
now, provided that the patch also:
1. puts a big comment in that data warning about the problem and
explaining why
2. puts a pr_warn() in mach-omap2/pm44xx.c:omap4_pm_init() saying:
WARNING: OMAP4 power savings limited since MMC driver not converted to
PM runtime
- Paul
--
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: OMAP4 DSS clock setup
Hi Paul, Benoit,
On Fri, 2011-04-01 at 20:12 -0600, Paul Walmsley wrote:
Based on the E-mail thread so far, I'd say that changing the clock aliases
is the way to go for right now. The clock aliases are not hardware data;
they just control how the clock hardware is mapped to the drivers.
I'd very much prefer this option. Below is a patch for this.
If Benoit doesn't complain too much about this, I'd like to get this
merged as soon as possible, as OMAP4 DSS is currently crashing in the
mainline kernel.
I can either handle it myself if I get your acks, or you can send a pull
request for this if you have some other patches going in also.
Of course, at some point soon, those clock aliases are going to go away.
But hopefully you all will have converted the driver over to PM runtime at
that point.
Once that happens, there's another problem: omap_hwmod_enable() is defined
that the hardware registers should be accessible by the MPU after it
completes. So by that definition, the hwmod code should be
enabling/disabling that dss_clk clock too when it enables/idles/shuts down
the hwmod. Probably we'd need to mark that struct omap_hwmod_opt_clk with
some flag. Then we'd need some kind of way for the DSS to tell the hwmod
code whether it is or isn't reliant on the PRCM-provided functional clock
for its internal functional clock. Maybe something like
omap_hwmod_{release,require}_system_fclk()?
Hmm, right. I guess no other HW module has clock setups like this?
Currently DSS can use clk_enable/disable() for the system fclk when its
using DSI PLL for the fclk. So omap_hwmod_{release,require}_system_fclk
sounds like a simple solution to this.
Not directly related, but something I've been wondering about is how to
abstract the DSI/HDMI PLLs in DSS. What do you think, would it be
possible/worth it to create struct clks for the clocks coming out of
those PLLs? These would, of course, be DSS internal clks. I'm not very
familiar with the clock framework, so I don't really have any idea what
this would require and what would be the pros and cons.
---
From fceb48b2e22217dccc85b33362b6a17e5a00 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Mon, 4 Apr 2011 09:26:19 +0300
Subject: [PATCH] OMAP4: clock data: Change DSS clock aliases
DSS driver has used fck and ick clocks on OMAP2/3 to get DSS HW up and
running, and also to get the pixel clock's source clock rate from the
fck.
On OMAP4 the clock data is set up in a different way, as there's no ick,
dss_fck points to a fake clock which just affects DSS's MODULEMODE, and
dss_dss_clk if the DSS_FCK.
From DSS driver's point of view the dss_fck sounds like an ick, and
dss_dss_clk is the fck. While this is not entirely correct from HW point
of view, especially for the ick, configuring the clock aliases that way
makes DSS just work with OMAP4's clock setup.
In the (hopefully near) future DSS driver will be reworked to use
pm_runtime support which should clean up the clock code.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 276992d..8c96567 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3116,14 +3116,9 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
CLK(omapdss_dss, sys_clk, dss_sys_clk,
CK_443X),
CLK(omapdss_dss, tv_clk, dss_tv_clk,
CK_443X),
- CLK(omapdss_dss, dss_clk, dss_dss_clk,
CK_443X),
CLK(omapdss_dss, video_clk,dss_48mhz_clk,
CK_443X),
- CLK(omapdss_dss, fck, dss_fck,
CK_443X),
- /*
-* On OMAP4, DSS ick is a dummy clock; this is needed for compatibility
-* with OMAP2/3.
-*/
- CLK(omapdss_dss, ick, dummy_ck,
CK_443X),
+ CLK(omapdss_dss, fck, dss_dss_clk,
CK_443X),
+ CLK(omapdss_dss, ick, dss_fck,
CK_443X),
CLK(NULL, efuse_ctrl_cust_fck, efuse_ctrl_cust_fck,
CK_443X),
CLK(NULL, emif1_fck,emif1_fck,
CK_443X),
CLK(NULL, emif2_fck,emif2_fck,
CK_443X),
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC, GIC based smp_cross_call cleanup suggestion
On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote: On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote: On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote: If you plan to commit this change then I can move these to other OMAP4 header file. Can you send me a patch to do that please? Here it is.. Generated against latest mainline. Also attached just in case for any mailer issues. Looks good, please send to the patch system. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC, GIC based smp_cross_call cleanup suggestion
On 4/4/2011 1:55 PM, Russell King - ARM Linux wrote: On Mon, Apr 04, 2011 at 01:50:35PM +0530, Santosh Shilimkar wrote: On 4/3/2011 7:18 PM, Russell King - ARM Linux wrote: On Sun, Apr 03, 2011 at 04:23:41PM +0530, Santosh Shilimkar wrote: If you plan to commit this change then I can move these to other OMAP4 header file. Can you send me a patch to do that please? Here it is.. Generated against latest mainline. Also attached just in case for any mailer issues. Looks good, please send to the patch system. patch 6860/1 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] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
On Mon, Apr 04, 2011 at 02:34:56PM +0530, Santosh Shilimkar wrote:
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..7857146 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR Could not detect SRAM size\n);
+ pr_err(Could not detect SRAM size\n);
omap_sram_size = 0x4000;
}
}
@@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n,
+ pr_info(SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n,
__pfn_to_phys(omap_sram_io_desc[0].pfn),
omap_sram_io_desc[0].virtual,
omap_sram_io_desc[0].length);
This is wrong.
I guess this is a consequence of using phys_addr_t rather than explicitly
'unsigned long' for physical addresses, which ends up as u32, which in
turn is 'unsigned int' not 'unsigned long'.
In any case, these warnings are telling us what needs to be fixed for
large physical addresses. The way that we've sorted this in the generic
ARM code is to use 0x%08llx, and casting the physical address to
'unsigned long long'. That gives consistent arguments without printing
excessive zeros at the start of an address.
--
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] OMAP4: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'
On 4/4/2011 2:42 PM, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 02:34:56PM +0530, Santosh Shilimkar wrote:
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..7857146 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR Could not detect SRAM size\n);
+ pr_err(Could not detect SRAM size\n);
omap_sram_size = 0x4000;
}
}
@@ -221,7 +221,7 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n,
+ pr_info(SRAM: Mapped pa 0x%08x to va 0x%08lx size: 0x%lx\n,
__pfn_to_phys(omap_sram_io_desc[0].pfn),
omap_sram_io_desc[0].virtual,
omap_sram_io_desc[0].length);
This is wrong.
I guess this is a consequence of using phys_addr_t rather than explicitly
'unsigned long' for physical addresses, which ends up as u32, which in
turn is 'unsigned int' not 'unsigned long'.
In any case, these warnings are telling us what needs to be fixed for
large physical addresses. The way that we've sorted this in the generic
ARM code is to use 0x%08llx, and casting the physical address to
'unsigned long long'. That gives consistent arguments without printing
excessive zeros at the start of an address.
Thanks for pointing out this. I see Will's commit on this
one 29a38193
Here is the updated patch as you suggested.
From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type
'long unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* ) to pr_*().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/sram.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -166,7 +166,7 @@ static void __init omap_detect_sram(void)
else if (cpu_is_omap1611())
omap_sram_size = SZ_256K;
else {
- printk(KERN_ERR Could not detect SRAM size\n);
+ pr_err(Could not detect SRAM size\n);
omap_sram_size = 0x4000;
}
}
@@ -221,10 +221,10 @@ static void __init omap_map_sram(void)
omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE);
iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc));
- printk(KERN_INFO SRAM: Mapped pa 0x%08lx to va 0x%08lx size: 0x%lx\n,
- __pfn_to_phys(omap_sram_io_desc[0].pfn),
- omap_sram_io_desc[0].virtual,
- omap_sram_io_desc[0].length);
+ pr_info(SRAM: Mapped pa 0x%08llx to va 0x%08lx size: 0x%lx\n,
+ (long long) __pfn_to_phys(omap_sram_io_desc[0].pfn),
+ omap_sram_io_desc[0].virtual,
+ omap_sram_io_desc[0].length);
/*
* Normally devicemaps_init() would flush caches and tlb after
@@ -252,7 +252,7 @@ static void __init omap_map_sram(void)
void *omap_sram_push_address(unsigned long size)
{
if (size (omap_sram_ceil - (omap_sram_base + SRAM_BOOTLOADER_SZ))) {
- printk(KERN_ERR Not enough space in SRAM\n);
+ pr_err(Not enough space in SRAM\n);
return NULL;
}
--
1.6.0.4
From 4d8d4e5c99c1477a8cb04b525ff5a2d93bbdacfd Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 4 Apr 2011 14:20:08 +0530
Subject: [PATCH] OMAP: SRAM: Fix warning: format '%08lx' expects type 'long
unsigned int'
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
While at this, convert SRAM printk(* ) to pr_*().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/plat-omap/sram.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index a3f50b3..6af3d0b
[PATCH] OMAP2+: Fix 9 section mismatch(es) warnings from mach-omap2/built-in.o
The serial*_data should have been marked as __initdata as per
it's usage in the board files. Fix the same to remove the
section mismatch warnings caused by it.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|6 +++---
arch/arm/mach-omap2/board-4430sdp.c|6 +++---
arch/arm/mach-omap2/board-omap4panda.c |6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 9afd087..a0f85a8 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -719,19 +719,19 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..c98e955 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -736,19 +736,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index f3a7b10..eeb22cd 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -551,19 +551,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
--
1.6.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
[regression] 2.6.39-rc1 - Beagleboard usbnet broken
Running 2.6.38 on my beagleboard, I can boot using nfs:- regulator_init_complete: VDVI: incomplete constraints, leaving on regulator_init_complete: VDAC: incomplete constraints, leaving on usb 1-2: new high speed USB device using ehci-omap and address 2 mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 1234 usb 1-2: New USB device found, idVendor=0424, idProduct=9514 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 mmcblk0: mmc0:1234 SA04G 3.67 GiB hub 1-2:1.0: USB hub found mmcblk0: p1 hub 1-2:1.0: 5 ports detected usb 1-2.1: new high speed USB device using ehci-omap and address 3 usb 1-2.1: New USB device found, idVendor=0424, idProduct=ec00 usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 smsc95xx v1.0.4 smsc95xx 1-2.1:1.0: usb0: register 'smsc95xx' at usb-ehci-omap.0-2.1, smsc95xx USB 2.0 Ethernet, 9e:79:dd:1e:2e:5c Sending DHCP requests . usb0: link up, 100Mbps, full-duplex, lpa 0x45E1 ., OK IP-Config: Got DHCP answer from 10.0.0.1, my address is 10.0.0.113 IP-Config: Complete: device=usb0, addr=10.0.0.113, mask=255.255.0.0, gw=10.0.0.1, host=10.0.0.113, domain=, nis-domain=(none), bootserver=10.0.0.1, rootserver=10.0.0.100, rootpath= VFS: Mounted root (nfs filesystem) on device 0:10. etc I have just tried out 2.6.39-rc1, and the usbnet is no longer detected:- regulator_init_complete: VDVI: incomplete constraints, leaving on regulator_init_complete: VDAC: incomplete constraints, leaving on mmc0: host does not support reading read-only switch. assuming write-enable. mmc0: new high speed SDHC card at address 1234 mmcblk0: mmc0:1234 SA04G 3.67 GiB mmcblk0: p1 VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device nfs or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: b300 3858432 mmcblk0 driver: mmcblk b301 72261 mmcblk0p1 ----0mmcblk0p1 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) I have tried a git bisect, but it seems to blame the wrong thing:- 087809fce28f50098d9c3ef1a6865c722f23afd2 is the first bad commit commit 087809fce28f50098d9c3ef1a6865c722f23afd2 Author: Jamie Iles ja...@jamieiles.com Date: Fri Jan 21 14:11:52 2011 + dmaengine/dw_dmac: don't scan descriptors if no xfers in progress Some hardware (picoChip picoXCell in particular) sometimes has the block transfer complete bit being set for a channel after the whole transfer has completed. If we don't have any transfers in the active list then don't bother to scan the descriptors. This often happens in normal operation and doesn't require the channel to be reset. v2: cleanup whitespace Signed-off-by: Jamie Iles jamie.i...@picochip.com Signed-off-by: Dan Williams dan.j.willi...@intel.com :04 04 d0dac7f65b52fb1849f77056740d84d06530629f 211910a820dad07f0439410cc849c34909a62c2f M drivers I have attached my .config. Can anyone help ? Cheers Mark # # Automatically generated make config: don't edit # Linux/arm 2.6.38 Kernel Configuration # Mon Apr 4 10:12:26 2011 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_SCHED_CLOCK=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_USES_GETTIMEOFFSET is not set CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_HAVE_IRQ_WORK=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_LZO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y # CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set CONFIG_HAVE_SPARSE_IRQ=y # CONFIG_GENERIC_PENDING_IRQ is not set # CONFIG_AUTO_IRQ_AFFINITY is not set # CONFIG_IRQ_PER_CPU is not set # CONFIG_SPARSE_IRQ is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set #
Re: [GIT PULL] omap changes for v2.6.39 merge window
Le 01/04/2011 17:30, Detlef Vollmann : On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. And if they add support for a new SOC, they just copy an existing one, change some GPIOs, and submit it as new files (sorry, I'm over- simplifying here). And if you happen to wire your board a bit differently than they do, you have to patch theur generic file (in addidtion to add your own board file). And though I only know the mach-at91 closely, I'm pretty sure quite a number of other mach-* are not better. So this is actually why the ARM tree has such a bad reputation: lot's of code repetition, and still more of that. Yes, certainly time has come for a change. Note however that AT91 community is making great effort to: - publish and maintain every single chip/board support since more than 5 years (and far before for first venerable at91rm9200) : if you recall well, it was before most of code that appeared in arch/arm/mach-* directories ;-) - integrate ideas and patches from contributors for simplifying and reducing board duplication - try to conform to new infrastructures that are appearing on ARM Linux for better convergence of code: gpiolib, leds, buttons, clocks (work in progress)... We know that work has to be done and we will for sure follow this effort of consolidation. And remember: contributions welcomed ;-). Best regards, -- Nicolas Ferre -- 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 changes for v2.6.39 merge window
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote: On Sunday 03 April 2011, Russell King - ARM Linux wrote: Then there's those which change the cs-read function pointer at runtime, ... and those which share that pointer with their sched_clock() implementation. Abstracting sched_clock() to be run-time selected is something that needs to be taken care of. Maybe we could have a generic sched_clock implementation that is written on top of clocksource instead of jiffies, and always select that on architectures that have a decent clocksource. On Cortex-A15 with the virtualisation extensions and architected timers the clocksource is implemented using a physical counter (as we want wall-clock timing). But for sched_clock() we may want to use a virtual counter (which is basically an offset from the physical one, set by the hypervisor during guest OS switching). Marc already posted some patches for this. -- Catalin -- 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 changes for v2.6.39 merge window
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read function pointer at runtime,
...
and those which share that pointer with their sched_clock()
implementation.
Abstracting sched_clock() to be run-time selected is something that
needs to be taken care of. Maybe we could have a generic sched_clock
implementation that is written on top of clocksource instead of jiffies,
and always select that on architectures that have a decent clocksource.
On Cortex-A15 with the virtualisation extensions and architected timers
the clocksource is implemented using a physical counter (as we want
wall-clock timing). But for sched_clock() we may want to use a virtual
counter (which is basically an offset from the physical one, set by the
hypervisor during guest OS switching). Marc already posted some patches
for this.
I had a quick look at the two patches, but I was far from impressed
due to the apparant complexity I saw.
There's no point in trying to consolidate stuff if it results in a net
increase in the amount of code to be maintained as that just increases
the burden, churn and maintainence headache.
Is there an easier way to consolidate it across all platforms? I think
so:
static DEFINE_CLOCK_DATA(cd);
static u32 sched_clock_mask;
static u32 (*read_sched_clock)(void);
unsigned long long notrace sched_clock(void)
{
if (read_sched_clock) {
u32 cyc = read_sched_clock();
return cyc_to_sched_clock(cd, cyc, sched_clock_mask);
} else {
/* jiffies based code */
}
}
static void notrace update_sched_clock(void)
{
u32 cyc = read_sched_clock();
update_sched_clock(cd, cyc, sched_clock_mask);
}
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
BUG_ON(bits 32);
read_sched_clock = read;
sched_clock_mask = (1 bits) - 1;
init_sched_clock(cd, update_sched_clock, bits, rate);
}
and then get rid of the per-platform implementations entirely - all
that platforms then have to provide is a read function and a call to
setup_sched_clock().
Whether its worth it or not is questionable - the above is more lines
of code than many of the existing implementations, and we're not going
to shrink the existing implementations by much (maybe one to three
lines.) The only thing we gain is the ability to select an implementation
at runtime.
--
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 changes for v2.6.39 merge window
On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote:
On Mon, Apr 04, 2011 at 12:03:42PM +0100, Catalin Marinas wrote:
On Mon, 2011-04-04 at 01:59 +0100, Arnd Bergmann wrote:
On Sunday 03 April 2011, Russell King - ARM Linux wrote:
Then there's those which change the cs-read function pointer at
runtime,
...
and those which share that pointer with their sched_clock()
implementation.
Abstracting sched_clock() to be run-time selected is something that
needs to be taken care of. Maybe we could have a generic sched_clock
implementation that is written on top of clocksource instead of jiffies,
and always select that on architectures that have a decent clocksource.
On Cortex-A15 with the virtualisation extensions and architected timers
the clocksource is implemented using a physical counter (as we want
wall-clock timing). But for sched_clock() we may want to use a virtual
counter (which is basically an offset from the physical one, set by the
hypervisor during guest OS switching). Marc already posted some patches
for this.
I had a quick look at the two patches, but I was far from impressed
due to the apparant complexity I saw.
There's no point in trying to consolidate stuff if it results in a net
increase in the amount of code to be maintained as that just increases
the burden, churn and maintainence headache.
Is there an easier way to consolidate it across all platforms? I think
so:
static DEFINE_CLOCK_DATA(cd);
static u32 sched_clock_mask;
static u32 (*read_sched_clock)(void);
unsigned long long notrace sched_clock(void)
{
if (read_sched_clock) {
u32 cyc = read_sched_clock();
return cyc_to_sched_clock(cd, cyc, sched_clock_mask);
} else {
/* jiffies based code */
}
}
static void notrace update_sched_clock(void)
{
u32 cyc = read_sched_clock();
update_sched_clock(cd, cyc, sched_clock_mask);
}
void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
{
BUG_ON(bits 32);
read_sched_clock = read;
sched_clock_mask = (1 bits) - 1;
init_sched_clock(cd, update_sched_clock, bits, rate);
}
and then get rid of the per-platform implementations entirely - all
that platforms then have to provide is a read function and a call to
setup_sched_clock().
The complexity mostly comes the fact that I tried to avoid having more
runtime complexity on platforms that didn't need to select their
sched_clock() implementation at runtime (no indirection while calling
sched_clock()).
If this can be relaxed, then your implementation is definitely better.
Whether its worth it or not is questionable - the above is more lines
of code than many of the existing implementations, and we're not going
to shrink the existing implementations by much (maybe one to three
lines.) The only thing we gain is the ability to select an implementation
at runtime.
I believe this last point to be rather important if we plan to have this
mythical single kernel covering several architectures. It's also nice
for the A15 to be able to use some default sched_clock() implementation
as a fallback if the generic timers are not available for some reason.
M.
--
Reality is an implementation detail.
--
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 changes for v2.6.39 merge window
On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: Whether its worth it or not is questionable - the above is more lines of code than many of the existing implementations, and we're not going to shrink the existing implementations by much (maybe one to three lines.) The only thing we gain is the ability to select an implementation at runtime. I believe this last point to be rather important if we plan to have this mythical single kernel covering several architectures. It's also nice for the A15 to be able to use some default sched_clock() implementation as a fallback if the generic timers are not available for some reason. If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. I do hope they're not missing functionality like the GIC is - otherwise they're just going to make the situation worse than it already is. -- 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 changes for v2.6.39 merge window
On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: On Mon, Apr 04, 2011 at 02:24:17PM +0100, Marc Zyngier wrote: On Mon, 2011-04-04 at 12:21 +0100, Russell King - ARM Linux wrote: Whether its worth it or not is questionable - the above is more lines of code than many of the existing implementations, and we're not going to shrink the existing implementations by much (maybe one to three lines.) The only thing we gain is the ability to select an implementation at runtime. I believe this last point to be rather important if we plan to have this mythical single kernel covering several architectures. It's also nice for the A15 to be able to use some default sched_clock() implementation as a fallback if the generic timers are not available for some reason. If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of better). Overall, it seems like we need some degree of flexibility to have several sched_clock() implementations within a single image, whether it is to support multiple platforms, or to allow a single architecture to pick the best alternative given a set of initial conditions. M. -- Reality is an implementation detail. -- 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/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use
Hi David, On Wednesday 30 March 2011 17:50:17 David Cohen wrote: On Wed, Mar 30, 2011 at 4:56 PM, Laurent Pinchart wrote: On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote: Laurent Pinchart wrote: On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote: Laurent Pinchart wrote: On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote: On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote: Hi, This patchset is aimed to fix a problem in arch_iommu implementation references. When an actual arch_iommu implementation is not loaded while iommu_get() is being called results to a kernel oops, as well as removing an arch_iommu implementation which is in use. How about fixing the dependency instead? Right now iommu2 depends on iommu because of the calls to install_iommu_arch/uninstall_iommu_arch... we should change that dependency to iommu depend on iommu2. Something like iommu (plat) querying iommu2 (mach) for devices to install. The reason why iommu depends on iommu2 and not the other way around is because several mach-specific iommu implementations should be able to coexist in the same kernel. The right one should be loaded at runtime. I think that Sakari's patches correcty fix the problems he noticed. However, they won't fix one basic issue, which is that the iommu2 module won't be automatically pulled in when the omap3isp module is loaded. The omap3isp driver will then fail to probe the device. That's better than crashing though. One option would be to specify the name of the module in the platform data and request_module() that in omap_iommu_probe(). This would solve the issue, not sure how pretty is this though. Do we need that ? My understanding is that a machine will need a single mach- specific iommu implementation only. Drivers shouldn't need to care about that. Well, no more than that there would have to be a driver for the IOMMU for that very hardware. The iommu implementation should be automatically selected based on the machine time. Machine type? I agree, but where is the selection made? The selection can be made by board code, or by the iommu implementations themselves if they're compiled in. I prefer the first option. The second one will make the current implementation be even more OMAP-only. We have basically 3 layers: IOVMM, IOMMU_GENERIC and IOMMU_SPECIFIC. The middle one should be generic and don't care about machine types. The later one can be handled by board code as it's machine specific and, for most of the cases, I see no reason to let any other implementation besides the machine type's to be loaded. But the generic layer should not depend on any specific one. If somebody decides to load the specific layer after the generic one, it cannot be a problem. Let me try to summarize the issue and the requirements. IOMMU support on OMAP platforms uses an OMAP-specific implementation, divided into 3 layers: - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual address space management - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU hardware, and deals with TLB and page tables - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko) handles the IOMMU implementation variants between various OMAP platforms Drivers depend on iovmm and iommu. They must not depend on iommu2.ko. The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+. An OMAP1 implementation is being worked on, and other implementations might be needed for OMAP4 and/or OMAP5. Building a kernel image that will run on all OMAP platforms isn't possible at the moment but is being worked on. Such a kernel image will need to include all the platform-specific IOMMU layers, and the correct layer will need to be selected at runtime. If a driver tries to request and use an IOMMU before the platform-specific IOMMU layer is initialized, the request will fail. We thus need to ensure that the correct platform-specific IOMMU layer is initialized before IOMMU users are initialized. I can see several ways to fix the problem. - Turn the iommu and iommu2 options from tristate to bool. The downside is that the kernel image will get slightly bigger. - Merge the iommu and iommu2 modules together. This will temporarily fix the problem, but a proper solution will still be needed for the OMAP1 (and maybe OMAP5) IOMMU layers. - Auto-load the correct platform-specific IOMMU module based on modaliases created from the platform name. The platform-specific modules will need to check at runtime whether they support the current platform to avoid conflicts when several of those modules will be compiled in. The second solution is the simplest, but it's a workaround. On the other hand, it's hard to design a proper solution before we know the requirements of the other OMAP platforms that have an IOMMU incompatible
Re: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Ming, On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: Hi Avik, 2011/4/1 Avik Silavik...@linux.vnet.ibm.com: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); Can you please tell me where should I insert the above code to enable l3 clocks to drive CTI? Regards, Avik No such issue on mainline since this clocks are enabled automatically. thanks, -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi, 2011/4/4 Avik Sil avik...@linux.vnet.ibm.com: Hi Ming, On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: Hi Avik, 2011/4/1 Avik Silavik...@linux.vnet.ibm.com: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); Can you please tell me where should I insert the above code to enable l3 clocks to drive CTI? It should be inserted before calling omap4_configure_pmu_irq. thanks, -- Ming Lei -- 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
rtc-twl: catch22 in 2.6.37 and 2.6.38 when clock was never set
Hello, it just happened here that the rechargeable backup battery for the RTC on a TPS65950 run out off power, because of some days while the device wasn't powered. Afterwards I couldn't read or set the clock with hwclock using a kernel 2.6.37.n or 2.6.38.n. I don't have a fix, but I think I've analyzed the problem and can offer a (bad) workaround. What happens is the following: When trying to read or set the clock with hwclock, the driver (rtc-twl) starts an alarm, but the irq for the alarm will never get called. The result is that a select in hwclock times out (for both operations, read or set). Because I had this clock running before, I've got the idea to try one of those old OMAP-kernels (2.6.32-angstrom) using the same userland. And with that kernel I could set the clock. Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read an set are working. So it looks like there is a catch22 in kernels =2.6.37 (I haven't tested .33-.36): When the clock was never set, the alarm(-irq) doesn't work, so hwclock doesn't work, so one can't set the clock. Regards, Alexander Holler -- 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: Question regarding suspend/resume
On 04/01/2011 01:05 AM, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Friday, April 01, 2011 2:18 AM To: Peter Barada Cc: Linux OMAP list Subject: Re: Question regarding suspend/resume Hi Peter, Peter Barada peter.bar...@gmail.com writes: [...] Thanks for helping me to understand things. The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] with their u-boot [2] and x-loader[3], modified to run on Logic's DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). I'm afraid somone who supports that older TI kernel will have to help you out. [Hiremath, Vaibhav] Peter, I have validated the release kernel (along with x-loader/uboot) on OMAP3EVM, and it does work without any issues. I have personally validated this with latest Arago repos, probably you may want to share the changes you have made in x-loader/uboot/kernel to port PSP2.6.32 to LogicPD hardware. [Barada, Peter] Viabhav, I've also validated that the x-loader/u-boot/kernel built from the OMAPPSP_03.00.01.06 tags suspends on the DM3730EVM hardware. I'llp ut together a set of patches to those and send you a pointer where to find them. What I'm trying now is to cut board-omap3evm.c down to just the serial/mmc to see if the DM3730EVM shows the same effect; it could be that u-boot has put some of the hardware into a state that the kernel handles in the suspend path but my minimal kernel doesn't. At least that would tell me I'm on the right path. Thanks, Vaibhav If you can reproduce on a current kernel, I'd be glad to help but I'm currently not able (well, not willing is more accurate) to try and figure out what's going on based on an older kernel with who knows how many out-of-tree patches/hacks piled on. What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Sorry I can't be of more help, Kevin -- 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 -- Peter Barada peter.bar...@logicpd.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: Question regarding suspend/resume
On 03/31/2011 04:48 PM, Kevin Hilman wrote: Hi Peter, Peter Barada peter.bar...@gmail.com writes: [...] Thanks for helping me to understand things. The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] with their u-boot [2] and x-loader[3], modified to run on Logic's DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). I'm afraid somone who supports that older TI kernel will have to help you out. If you can reproduce on a current kernel, I'd be glad to help but I'm currently not able (well, not willing is more accurate) to try and figure out what's going on based on an older kernel with who knows how many out-of-tree patches/hacks piled on. I've tried with a newer kernel and see different results: http://dchs.spinics.net/lists/linux-omap/msg49235.html What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) How can I determine if an IP block is not idled? Any suggestion where to add code into the suspend patch to do such a check? As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Hmm, where in the current kernel is this done, device driver probe functions or common platform init code? Sorry I can't be of more help, Kevin -- 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 -- Peter Barada peter.bar...@logicpd.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: Question regarding suspend/resume
Peter Barada peter.bar...@logicpd.com writes: [...] What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) How can I determine if an IP block is not idled? Any suggestion where to add code into the suspend patch to do such a check? Unfortunatly, there is no easy way for OMAP3-based platforms. There are unfortunately several things that can be (mis)configured such that an IP block will not properly idle.This is one of the reasons that omap_hwmod was introduced. It gives a uniform way for IP blocks to be enabled, idled and shutdown so they are in an a known state. As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Hmm, where in the current kernel is this done, device driver probe functions or common platform init code? As part of the initializion of omap_hwmod for a given IP block, the module is reset. Kevin -- 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: Question regarding suspend/resume
-Original Message- From: Peter Barada [mailto:peter.bar...@logicpd.com] Sent: Monday, April 04, 2011 8:01 PM To: Hiremath, Vaibhav Cc: Hilman, Kevin; Peter Barada; Linux OMAP list Subject: Re: Question regarding suspend/resume On 04/01/2011 01:05 AM, Hiremath, Vaibhav wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hilman, Kevin Sent: Friday, April 01, 2011 2:18 AM To: Peter Barada Cc: Linux OMAP list Subject: Re: Question regarding suspend/resume Hi Peter, Peter Barada peter.bar...@gmail.com writes: [...] Thanks for helping me to understand things. The kernel I'm using is TI's OMAPPSP_03.00.01.06 2.6.32 kernel [1] with their u-boot [2] and x-loader[3], modified to run on Logic's DM3730 board(s) (as we use the Micron mt29c4g48mazapakq-5 POP). I'm afraid somone who supports that older TI kernel will have to help you out. [Hiremath, Vaibhav] Peter, I have validated the release kernel (along with x-loader/uboot) on OMAP3EVM, and it does work without any issues. I have personally validated this with latest Arago repos, probably you may want to share the changes you have made in x-loader/uboot/kernel to port PSP2.6.32 to LogicPD hardware. [Barada, Peter] Viabhav, I've also validated that the x-loader/u- boot/kernel built from the OMAPPSP_03.00.01.06 tags suspends on the DM3730EVM hardware. I'llp ut together a set of patches to those and send you a pointer where to find them. What I'm trying now is to cut board- omap3evm.c down to just the serial/mmc to see if the DM3730EVM shows the same effect; [Hiremath, Vaibhav] Does this mean, the issue is only seen on your custom board and not on DM3730EVM? Thanks, Vaibhav it could be that u-boot has put some of the hardware into a state that the kernel handles in the suspend path but my minimal kernel doesn't. At least that would tell me I'm on the right path. Thanks, Vaibhav If you can reproduce on a current kernel, I'd be glad to help but I'm currently not able (well, not willing is more accurate) to try and figure out what's going on based on an older kernel with who knows how many out-of-tree patches/hacks piled on. What I can say based on the register dump you shared is that there is no obvious driver issue going on where a clock was left on by a driver. More than likely what is going on is that the booloader is using a device (e.g. USB, MMC) but is leaving it in a state such that that IP block cannot idle, so the CORE powerdomain then does not fully idle. In older kernels like this one, the linux drivers did not fully reset the hardware so bootloaders could cause problems like this (the u-boot on beagle has had several problems like this.) As a first whack at things, I would focus on USB OTG and MMC, as I've seen problem with both on other platforms, like Beagle. You need to ensure that both the these modules are fully reset either by the bootloader when it's done using them, or by the kernel in the early boot process. Current kernels now do the latter. Sorry I can't be of more help, Kevin -- 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 -- Peter Barada peter.bar...@logicpd.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 v2] ARM: GIC: Convert GIC library to use the IO relaxed operations
On Fri, 2011-04-01 at 10:32 +0100, Santosh Shilimkar wrote: The GIC register accesses today make use of readl()/writel() which prove to be very expensive when used along with mandatory barriers. This mandatory barriers also introduces an un-necessary and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC IO accesses from CPU are direct and doesn't go through L2X0 write buffer. Also since a DSB does not guarantee that the device state has been changed, a read back from the device is introduced wherever necessary. ... @@ -98,7 +98,8 @@ static void gic_mask_irq(struct irq_data *d) u32 mask = 1 (d-irq % 32); spin_lock(irq_controller_lock); - writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); + readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) / 32) * 4); if (gic_arch_extn.irq_mask) gic_arch_extn.irq_mask(d); spin_unlock(irq_controller_lock); Talking to the hardware people, a readl back would guarantee that the GIC state has changed but you can still get spurious interrupts because of the signal propagation from the GIC to the CPU. That's difficult to reliably sort out in software as we don't know the hardware delays, so we'll have to cope with spurious interrupts (unlikely though). A better sequence would be something like below (but still no guarantees): STR [Device] LDR [Device] DSB ISB (the ISB is needed in case some instructions already in the pipeline sampled the state of the interrupt signal) But I'm more in favour of not even bothering with an additional readl_relaxed, we simply cope with a very rare spurious interrupt. In a virtualised environment accesses to the GIC distributor are trapped making things slower. -- Catalin -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
On Monday 04 April 2011 07:53 PM, Ming Lei wrote: Hi, 2011/4/4 Avik Silavik...@linux.vnet.ibm.com: Hi Ming, On Saturday 02 April 2011 10:57 AM, Ming Lei wrote: Hi Avik, 2011/4/1 Avik Silavik...@linux.vnet.ibm.com: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL)0x300) != 0x300); Can you please tell me where should I insert the above code to enable l3 clocks to drive CTI? It should be inserted before calling omap4_configure_pmu_irq. After inserting the above code, I got build error saying undeclared identifiers. After searching, I found the above identifiers are defined with 'OMAP4430_' prefix in arch/arm/mach-omap2/cm2_44xx.h (OMAP4430_CM_L3INSTR_L3_3_CLKCTRL and OMAP4430_CM_L3INSTR_L3_INSTR_CLKCTRL) and arch/arm/mach-omap2/prm44xx.h (OMAP4430_CM_EMU_CLKSTCTRL): #define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720) [...] Should I use those identifier instead? I gave a try with those identifiers and it built the image successfully although with some warnings - passing argument 2 of 'omap_writel' makes integer from pointer without a cast. And the kernel ended up with oops: [1.082122] Unable to handle kernel paging request at virtual address ae008e20 [1.089630] pgd = c0004000 [1.092498] [ae008e20] *pgd= [1.096252] Internal error: Oops: 805 [#1] SMP [1.100891] last sysfs file: [1.104034] Modules linked in: [1.107269] CPU: 0Not tainted (2.6.38.2+ #13) [1.112274] PC is at omap_writel+0x4/0xc [1.116394] LR is at omap2_init_devices+0x108/0x42c [1.121490] pc : [c006f174]lr : [c0011274]psr: 6013 [1.121490] sp : da845f98 ip : 271beb3a fp : [1.133453] r10: r9 : r8 : c001116c [1.138916] r7 : r6 : c0789738 r5 : 0002 r4 : c078acd0 [1.145690] r3 : da848000 r2 : 271beb3a r1 : ae008e20 r0 : 0001 [1.152496] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [1.160064] Control: 10c53c7f Table: 8000404a DAC: 0015 [1.166046] Process swapper (pid: 1, stack limit = 0xda8442f8) [1.172119] Stack: (0xda845f98 to 0xda846000) [1.176696] 5f80: c07ed3a0 c003b82c [1.185180] 5fa0: c0789738 c00535a4 271beb3a c07bddf4 019a c0789738 c07843d4 [1.193664] 5fc0: c003b2bc c003b82c c0789738 c07843d4 0004 c000874c [1.202148] 5fe0: c0008588 c00600b0 0013 c00600b0 38c64703 060aa000 [1.210632] [c006f174] (omap_writel+0x4/0xc) from [c0011274] (omap2_init_devices+0x108/0x42c) [1.219848] [c0011274] (omap2_init_devices+0x108/0x42c) from [c00535a4] (do_one_initcall+0x34/0x18c) [1.229675] [c00535a4] (do_one_initcall+0x34/0x18c) from [c000874c] (kernel_init+0x1c4/0x250) [1.238891] [c000874c] (kernel_init+0x1c4/0x250) from [c00600b0] (kernel_thread_exit+0x0/0x8) [1.248107] Code: e28114b2 e1c100b0 e12fff1e e28114b2 (e581) [1.254455] ---[ end trace da227214a82491b7 ]--- [1.259338] Kernel panic - not syncing: Attempted to kill init! [1.265533] [c00673ac] (unwind_backtrace+0x0/0xfc) from [c057d2f0] (panic+0xb8/0x1dc) [1.274047] [c057d2f0] (panic+0xb8/0x1dc) from [c00a75fc] (do_exit+0x6e4/0x74c) [1.282012] [c00a75fc] (do_exit+0x6e4/0x74c) from [c0063458] (die+0x1e0/0x1f8) [1.289916] [c0063458] (die+0x1e0/0x1f8) from [c006b884] (__do_kernel_fault+0x74/0x84) [1.298492] [c006b884] (__do_kernel_fault+0x74/0x84) from [c05831c8] (do_page_fault+0xa8/0x338) [1.307891] [c05831c8] (do_page_fault+0xa8/0x338) from [c00534e0] (do_DataAbort+0x38/0x98) [1.316833] [c00534e0] (do_DataAbort+0x38/0x98) from [c05811ec] (__dabt_svc+0x4c/0x60) [1.325408] Exception stack(0xda845f50 to 0xda845f98) [1.330718] 5f40: 0001 ae008e20 271beb3a da848000 [1.339202] 5f60: c078acd0 0002 c0789738 c001116c [1.347686] 5f80: 271beb3a da845f98 c0011274 c006f174 6013 [1.354583] [c05811ec] (__dabt_svc+0x4c/0x60) from [c006f174] (omap_writel+0x4/0xc) [1.362915] [c006f174] (omap_writel+0x4/0xc) from [c0011274] (omap2_init_devices+0x108/0x42c) [1.372131] [c0011274] (omap2_init_devices+0x108/0x42c) from [c00535a4] (do_one_initcall+0x34/0x18c) [1.381958] [c00535a4] (do_one_initcall+0x34/0x18c) from [c000874c] (kernel_init+0x1c4/0x250) [
Re: [GIT PULL] omap changes for v2.6.39 merge window
2011/4/4 Marc Zyngier marc.zyng...@arm.com: On Mon, 2011-04-04 at 14:31 +0100, Russell King - ARM Linux wrote: If ARM are going to architect a set of timers into the hardware, let's make sure that all such hardware has them so we can dig ourselves out of this crappy mess that we find ourselves in today. As far as I know, A15 always has a set of generic timers. It may be that they are not available (frequency not programmed into the CNTFREQ register), or that someone decided to use a better alternative (for some particular interpretation of better). I guess this thing is inside that A15 core? First, what happens the day any vendors start making SoCs on this is they turn the A15 core off whenever it is not used, loosing all state including this timer, I believe. This forces them all to add some totally different clocksource, event and wakeup in some always-on voltage domain and rate that higher than the A15 timer(s). They will then implement sched_clock() and clocksource on that instead and only use A15 for localtimers. (Leading to the proliferation of board/SoC timer hacks discussed so much recently...) The only way to reuse that poor thing in practice is if you engineer a separate power domain with stuff that is supposed to be always-on in the A15 macro (including these timers) so vendors must implement this so as not to loose its state. Is this the case? Else, in effect it will only be used as clocksource and sched_clock() with these Versatile boards where the power is always on anyway. Second, have you taken into account the effect of changing the frequency of the A15 core, which is something every vendor also does, as you know Colin Cross already has a patch pending for that on the TWD localtimer which has not yet reached the kernel. (Or is A15 fixed frequency? Forgive my ignorance...) (And third it will also eventually need to hook into the timer-based delay framework that I think Nokia is working on to be really useful, else all delays become unpredictable.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [regression] 2.6.39-rc1 - Beagleboard usbnet broken
On Mon, Apr 4, 2011 at 2:22 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote: Running 2.6.38 on my beagleboard, I can boot using nfs:- [snip] I have just tried out 2.6.39-rc1, and the usbnet is no longer detected:- Yea, I hit something similar, where on the beagleboard I only see the root hubs, and not any of the devices (no usb, no keyboard, etc). I bisected it down to: commit 9e64bb1e9f0613093b3e34ac5402fcfef0dcc35a Author: Keshava Munegowda keshava_mgo...@ti.com Date: Tue Mar 1 20:08:19 2011 +0530 arm: omap: usb: Invoke usbhs core device initialization thanks -john -- 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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi, 2011/4/5 Avik Sil avik...@linux.vnet.ibm.com: #define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720) [...] Should I use those identifier instead? Yes, seems right, but you need to use the ioremap addresses of the identifiers. Are there other definitions for the identifiers you have used? As I said before, these are not needed for mainline, so I didn't try these. thanks, -- Ming Lei -- 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
