Re: [RFC] OMAP3: CPUIDLE PM: Modifications and fixes
Hello Jouni, On Tue, 12 Aug 2008, Högander Jouni wrote: ext Paul Walmsley [EMAIL PROTECTED] writes: On Mon, 11 Aug 2008, Högander Jouni wrote: ext Paul Walmsley [EMAIL PROTECTED] writes: Could you explain a little further why PER would have a wakeup dependency on CORE? Is this something that we should only enable under certain conditions, e.g., latency requirements for a device in PER? This is done to make sure we don't loose any gpio interrupts: GPIO wakeup/interrupt doesn't work for GPIOs in PER domain if PER is not active. I'm probably misunderstanding something, but ... wouldn't it better to just keep PER powerdomain ON all the time when PER GPIOs are enabled for interrupts? It seems possible for PER to go to retention or OFF even with the CORE wkdep in place, which would result in a period of time where the interrupts would be missed, no? No, it won't, PER goes sleep state only if CORE goes too. There is a hardware sleepdep between PER and CORE, thanks to Rajendra for pointing this out some time ago. This way there are all the time some wakeup mechanism available for PER gpios (gpio/iopad). Leaving PER ON would increase consumption. Ah, I see. Do you think we should add a mechanism for the CORE-PER wkdep to be dynamically added and removed, based on whether GPIO2-6 balls are enabled in IO pad wakeup? Conceivably a board could just use GPIO1 (in WKUP), and PER would not need to be awakened along with CORE in those instances, correct? - Paul
Re: Git tree updated to v2.6.27-rc2, help needed
From: ext Tony Lindgren [EMAIL PROTECTED] Subject: Git tree updated to v2.6.27-rc2, help needed Date: Mon, 11 Aug 2008 18:26:21 +0300 Hi all, I've updated our git tree to v2.6.27-rc2, and looks like we still have a bunch of issues to solve: - DSP compile is broken as now device_create() is same as device_create_drvdata(). So device_create() expects some some drvdata to be set also in drivers/dsp/dspgateway/task.c and drivers/dsp/dspgateway/dsp_ctl_core.c. Hiroshi, care to take a look at the DSP issue? Got it. I will send the patch in another e-mail. Hiroshi DOYU -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
On Mon, 11 Aug 2008 18:26:21 +0300 ext Tony Lindgren [EMAIL PROTECTED] wrote: Hi all, I've updated our git tree to v2.6.27-rc2, and looks like we still have a bunch of issues to solve: - Booting fails early on 3430sdp for some reason - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - N800 boots up to UI with gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2 and with DEBUG_LL=y. Without DEBUG_LL it hangs somewhere before serial is initialized - With gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53) there is alignment exception in early booting independently of 718fc6cd4db902aa2242a736cc3feb8744a4c71a 5Kernel command line: root=1f03 rootfstype=jffs2 6Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz 1Unhandled fault: alignment exception (0x001) at 0xc02bf695 Internal error: : 1 [#1] Modules linked in: CPU: 0Not tainted (2.6.27-rc2-omap1 #9) PC is at omap2_clkdm_clk_enable+0x2c/0x74 LR is at omap2_clk_enable+0x54/0x9c pc : [c0034ed8]lr : [c0033738]psr: a1d3 sp : c0303e90 ip : c0303ea8 fp : c0303ea4 r10: 800252c0 r9 : 4107b362 r8 : 0013 r7 : c03261ac r6 : 0002 r5 : r4 : c02bf689 r3 : c02bf695 r2 : r1 : c03072c8 r0 : c02bf689 Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc0302260) Stack: (0xc0303e90 to 0xc0304000) 3e80: c03072c8 c0306d24 c0303ebc c0303ea8 3ea0: c0033738 c0034eb8 c0306d7c c0306d24 c0303ed4 c0303ec0 c003371c c00336f0 3ec0: c03071f4 c0306d24 c0303eec c0303ed8 c003371c c00336f0 c03073f0 c0306d24 3ee0: c0303f04 c0303ef0 c003371c c00336f0 c0307d90 c0306d24 c0303f1c c0303f08 3f00: c003371c c00336f0 c03099c0 c0306d24 c0303f34 c0303f20 c003371c c00336f0 3f20: 81d3 c0306d24 c0303f4c c0303f38 c00432e4 c00336f0 c03099c0 c0306d24 3f40: c0303f64 c0303f50 c00433c4 c00432b0 0292 c0306d24 c0303f94 c0303f68 3f60: c001144c c00433a4 0149 c0305cb8 c0303f94 c03255c0 c0026f0c 3f80: c0305cb8 800252f4 c0303fac c0303f98 c0010818 c0011288 c0026f10 c03255c0 3fa0: c0303fbc c0303fb0 c0011aec c00107fc c0303fcc c0303fc0 c000e438 c0011ae4 3fc0: c0303ff4 c0303fd0 c0008c14 c000e40c c00086bc c0026f10 3fe0: 00c5387d c0325f4c c0303ff8 80008034 c0008ad0 Backtrace: [c0034eac] (omap2_clkdm_clk_enable+0x0/0x74) from [c0033738] (omap2_clk_enable +0x54/0x9c) r5:c0306d24 r4:c03072c8 [c00336e4] (omap2_clk_enable +0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c0306d7c [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03071f4 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03073f0 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c0307d90 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03099c0 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c00432e4] (clk_enable +0x40/0x54) r5:c0306d24 r4:81d3 [c00432a4] (clk_enable+0x0/0x54) from [c00433c4] (clk_enable_init_clocks+0x2c/0x4c) r5:c0306d24 r4:c03099c0 [c0043398] (clk_enable_init_clocks+0x0/0x4c) from [c001144c] (omap2_clk_init+0x1d0/0x23c) r5:c0306d24 r4:0292 [c001127c] (omap2_clk_init+0x0/0x23c) from [c0010818] (omap2_init_common_hw+0x28/0x40) r8:800252f4 r7:c0305cb8 r6:c0026f0c r5:c03255c0 r4: [c00107f0] (omap2_init_common_hw+0x0/0x40) from [c0011aec] (nokia_n800_init_irq+0x14/0x5c) r5:c03255c0 r4:c0026f10 [c0011ad8] (nokia_n800_init_irq+0x0/0x5c) from [c000e438] (init_IRQ+0x38/0x48) [c000e400] (init_IRQ+0x0/0x48) from [c0008c14] (start_kernel+0x150/0x2b8) [c0008ac4] (start_kernel +0x0/0x2b8) from [80008034] (0x80008034) r5:c0325f4c r4:00c5387d Code: 03a05001 03e00015 089da830 e284300c (e1931f9f) 4---[ end trace 1b75b31a2719ed1c ]--- 0Kernel panic - not syncing: Attempted to kill the idle task! Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Build fix for n800_defconfig
Just updated from the latest header file.
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
drivers/media/radio/radio-tea5761.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/radio-tea5761.c
b/drivers/media/radio/radio-tea5761.c
index e8ccf29..1c6d8ab 100644
--- a/drivers/media/radio/radio-tea5761.c
+++ b/drivers/media/radio/radio-tea5761.c
@@ -1,7 +1,7 @@
/*
* drivers/media/radio/radio-tea5761.c
*
- * Copyright (C) 2005 Nokia Corporation
+ * Copyright (C) 2005-2008 Nokia Corporation
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -23,6 +23,7 @@
#include linux/i2c.h
#include linux/delay.h
#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
#define DRIVER_NAME tea5761
@@ -255,11 +256,12 @@ static int tea5761_do_ioctl(struct inode *inode, struct
file *file,
case VIDIOC_QUERYCAP:
dev_dbg(client-dev, VIDIOC_QUERYCAP\n);
memset(u-c, 0, sizeof(u-c));
- strlcpy(u-c.driver, dev-dev-driver-name,
+ strlcpy(u-c.driver,
+ dev-parent-driver-name,
sizeof(u-c.driver));
strlcpy(u-c.card, dev-name, sizeof(u-c.card));
snprintf(u-c.bus_info, sizeof(u-c.bus_info), I2C:%s,
-dev-dev-bus_id);
+dev-parent-bus_id);
u-c.version = TEA5761_VERSION;
u-c.capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
break;
@@ -406,9 +408,8 @@ static struct file_operations tea5761_fops = {
};
static struct video_device tea5761_video_device = {
- .owner = THIS_MODULE,
.name = TEA5761 FM-Radio,
- .type = VID_TYPE_TUNER,
+ .vfl_type = VID_TYPE_TUNER,
.fops = tea5761_fops,
.release = video_device_release
};
@@ -434,7 +435,7 @@ static int tea5761_i2c_driver_probe(struct i2c_client
*client,
tea-video_dev = video_dev;
*video_dev = tea5761_video_device;
- video_dev-dev = client-dev;
+ video_dev-parent = client-dev;
i2c_set_clientdata(client, video_dev);
/* initialize and power off the chip */
--
1.5.5.1.357.g1af8b
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Build fix for n800_defconfig
Just updated from the latest header file.
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
drivers/media/video/omap24xxcam.c | 67 +++-
1 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index 6793869..682d402 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -5,7 +5,7 @@
*
* Copyright (C) 2004 MontaVista Software, Inc.
* Copyright (C) 2004 Texas Instruments.
- * Copyright (C) 2007 Nokia Corporation.
+ * Copyright (C) 2007-2008 Nokia Corporation.
*
* Contact: Sakari Ailus [EMAIL PROTECTED]
*
@@ -997,8 +997,8 @@ static int vidioc_querycap(struct file *file, void *fh,
return 0;
}
-static int vidioc_enum_fmt_cap(struct file *file, void *fh,
- struct v4l2_fmtdesc *f)
+static int vidioc_enum_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_fmtdesc *f)
{
struct omap24xxcam_fh *ofh = fh;
struct omap24xxcam_device *cam = ofh-cam;
@@ -1009,8 +1009,8 @@ static int vidioc_enum_fmt_cap(struct file *file, void
*fh,
return rval;
}
-static int vidioc_g_fmt_cap(struct file *file, void *fh,
- struct v4l2_format *f)
+static int vidioc_g_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
{
struct omap24xxcam_fh *ofh = fh;
struct omap24xxcam_device *cam = ofh-cam;
@@ -1023,8 +1023,8 @@ static int vidioc_g_fmt_cap(struct file *file, void *fh,
return rval;
}
-static int vidioc_s_fmt_cap(struct file *file, void *fh,
- struct v4l2_format *f)
+static int vidioc_s_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
{
struct omap24xxcam_fh *ofh = fh;
struct omap24xxcam_device *cam = ofh-cam;
@@ -1048,13 +1048,13 @@ out:
}
memset(f, 0, sizeof(*f));
- vidioc_g_fmt_cap(file, fh, f);
+ vidioc_g_fmt_vid_cap(file, fh, f);
return rval;
}
-static int vidioc_try_fmt_cap(struct file *file, void *fh,
- struct v4l2_format *f)
+static int vidioc_try_fmt_vid_cap(struct file *file, void *fh,
+ struct v4l2_format *f)
{
struct omap24xxcam_fh *ofh = fh;
struct omap24xxcam_device *cam = ofh-cam;
@@ -1608,6 +1608,28 @@ static int omap24xxcam_resume(struct platform_device
*pdev)
}
#endif /* CONFIG_PM */
+static const struct v4l2_ioctl_ops omap24xxcam_ioctl_fops = {
+ .vidioc_querycap= vidioc_querycap,
+ .vidioc_enum_fmt_vid_cap= vidioc_enum_fmt_vid_cap,
+ .vidioc_g_fmt_vid_cap = vidioc_g_fmt_vid_cap,
+ .vidioc_s_fmt_vid_cap = vidioc_s_fmt_vid_cap,
+ .vidioc_try_fmt_vid_cap = vidioc_try_fmt_vid_cap,
+ .vidioc_reqbufs = vidioc_reqbufs,
+ .vidioc_querybuf= vidioc_querybuf,
+ .vidioc_qbuf= vidioc_qbuf,
+ .vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_streamon= vidioc_streamon,
+ .vidioc_streamoff = vidioc_streamoff,
+ .vidioc_enum_input = vidioc_enum_input,
+ .vidioc_g_input = vidioc_g_input,
+ .vidioc_s_input = vidioc_s_input,
+ .vidioc_queryctrl = vidioc_queryctrl,
+ .vidioc_g_ctrl = vidioc_g_ctrl,
+ .vidioc_s_ctrl = vidioc_s_ctrl,
+ .vidioc_g_parm = vidioc_g_parm,
+ .vidioc_s_parm = vidioc_s_parm,
+};
+
/*
*
* Camera device (i.e. /dev/video).
@@ -1641,33 +1663,14 @@ static int omap24xxcam_device_register(struct
v4l2_int_device *s)
}
vfd-release = video_device_release;
- vfd-dev = cam-dev;
+ vfd-parent = cam-dev;
strlcpy(vfd-name, CAM_NAME, sizeof(vfd-name));
- vfd-type= VID_TYPE_CAPTURE | VID_TYPE_CHROMAKEY;
+ vfd-vfl_type= VID_TYPE_CAPTURE | VID_TYPE_CHROMAKEY;
vfd-fops= omap24xxcam_fops;
vfd-priv= cam;
vfd-minor = -1;
-
- vfd-vidioc_querycap = vidioc_querycap;
- vfd-vidioc_enum_fmt_cap = vidioc_enum_fmt_cap;
- vfd-vidioc_g_fmt_cap= vidioc_g_fmt_cap;
- vfd-vidioc_s_fmt_cap= vidioc_s_fmt_cap;
- vfd-vidioc_try_fmt_cap = vidioc_try_fmt_cap;
- vfd-vidioc_reqbufs = vidioc_reqbufs;
- vfd-vidioc_querybuf = vidioc_querybuf;
- vfd-vidioc_qbuf = vidioc_qbuf;
- vfd-vidioc_dqbuf= vidioc_dqbuf;
- vfd-vidioc_streamon = vidioc_streamon;
- vfd-vidioc_streamoff= vidioc_streamoff;
- vfd-vidioc_enum_input = vidioc_enum_input;
- vfd-vidioc_g_input = vidioc_g_input;
- vfd-vidioc_s_input = vidioc_s_input;
- vfd-vidioc_queryctrl= vidioc_queryctrl;
-
Re: [PATCH] ARM TLB: add v7wbi_{possible,always}_flags to {possible,always}_tlb_flags
On Mon, 2008-08-11 at 14:03 -0600, Paul Walmsley wrote: Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry() (intended for Feroceon only) to execute on ARMv7, and the CPU hangs. This patch is required for OMAP3 boards to boot. Signed-off-by: Paul Walmsley [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Acked-by me as well. I posted it last month as well but I was waiting for the include stuff to settle down. http://article.gmane.org/gmane.linux.ports.arm.kernel/44729 -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM TLB: add v7wbi_{possible, always}_flags to {possible, always}_tlb_flags
On Mon, 2008-08-11 at 23:08 +0100, Russell King - ARM Linux wrote: On Mon, Aug 11, 2008 at 02:03:10PM -0600, Paul Walmsley wrote: Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry() (intended for Feroceon only) to execute on ARMv7, and the CPU hangs. And this most definitely is required. One wonders how any ARMv7 platform could boot without this. Please submit to the patch system, I don't think any further acks are required. It is a bug indeed but not visible until commit 99c6dc11 (Feroceon-specific TLB flushing which is undefined on ARMv7). -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2EVM: Add keypad support
TWL4030 keypad controller driver support for OMAP2EVM
Signed-off-by: Arun C [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap2evm.c | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap2evm.c
b/arch/arm/mach-omap2/board-omap2evm.c
index b6354e3..9eb93b6 100644
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -17,6 +17,7 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
+#include linux/input.h
#include asm/hardware.h
#include asm/mach-types.h
@@ -27,6 +28,7 @@
#include asm/arch/board.h
#include asm/arch/common.h
#include asm/arch/hsmmc.h
+#include asm/arch/keypad.h
static struct resource omap2evm_smc911x_resources[] = {
[0] = {
@@ -72,6 +74,41 @@ static struct omap_lcd_config omap2_evm_lcd_config
__initdata = {
.ctrl_name = internal,
};
+static int omap2evm_keymap[] = {
+ KEY(0, 0, KEY_LEFT),
+ KEY(0, 1, KEY_RIGHT),
+ KEY(0, 2, KEY_A),
+ KEY(0, 3, KEY_B),
+ KEY(1, 0, KEY_DOWN),
+ KEY(1, 1, KEY_UP),
+ KEY(1, 2, KEY_E),
+ KEY(1, 3, KEY_F),
+ KEY(2, 0, KEY_ENTER),
+ KEY(2, 1, KEY_I),
+ KEY(2, 2, KEY_J),
+ KEY(2, 3, KEY_K),
+ KEY(3, 0, KEY_M),
+ KEY(3, 1, KEY_N),
+ KEY(3, 2, KEY_O),
+ KEY(3, 3, KEY_P)
+};
+
+static struct omap_kp_platform_data omap2evm_kp_data = {
+ .rows = 4,
+ .cols = 4,
+ .keymap = omap2evm_keymap,
+ .keymapsize = ARRAY_SIZE(omap2evm_keymap),
+ .rep= 1,
+};
+
+static struct platform_device omap2evm_kp_device = {
+ .name = omap_twl4030keypad,
+ .id = -1,
+ .dev= {
+ .platform_data = omap2evm_kp_data,
+ },
+};
+
static void __init omap2_evm_init_irq(void)
{
omap2_init_common_hw(NULL);
@@ -111,6 +148,7 @@ static int __init omap2_evm_i2c_init(void)
static struct platform_device *omap2_evm_devices[] __initdata = {
omap2_evm_lcd_device,
omap2evm_smc911x_device,
+ omap2evm_kp_device,
};
static void __init omap2_evm_init(void)
--
1.5.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP2EVM: twl4030 keypad Kconfig dependency fix
OMAP2EVM keypad is controlled by twl4030 Signed-off-by: Arun C [EMAIL PROTECTED] --- drivers/input/keyboard/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index cf86a7b..e4d0436 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -261,7 +261,7 @@ config KEYBOARD_OMAP config KEYBOARD_TWL4030 tristate TI TWL4030 keypad support - depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP_3430SDP || MACH_OMAP3EVM) + depends on TWL4030_CORE (MACH_OMAP_2430SDP || MACH_OMAP2EVM || MACH_OMAP_3430SDP || MACH_OMAP3EVM) help Say Y here if you want to use the OMAP TWL4030 keypad. -- 1.5.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix isp1301_omap compile (Re: testers wanted: isp1301_omap conversion to new-style i2c driver)
f35ae6346850f6c192269b09088b20261760f0e0 Tony, actually ... there were some issues in the omap_udc code too. Yeah, blame it on me, looks like I missed that one somehow with the __REG removal. So did a lot of other folk! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Build fix for n800_defconfig
ext Hiroshi DOYU wrote: Just updated from the latest header file. Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED] --- drivers/media/video/omap24xxcam.c | 67 +++- 1 files changed, 35 insertions(+), 32 deletions(-) Looks good to me. Thanks. Regards, -- Sakari Ailus [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
USB-webcam support
Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? Regards, Arun C -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB-webcam support
Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? I don't see why not. Do you expect a problem with using it? You could use MUSB in host or OTG mode and connect the camera to the MUSB port. - Anand-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] DSPGW: Fix build error for device_create()
* Hiroshi DOYU [EMAIL PROTECTED] [080812 10:14]:
Ideally, the contents mamagement should be handled by drv_data instead
of homebrewed array.
Pushing today.
Tony
Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED]
---
drivers/dsp/dspgateway/dsp_ctl_core.c |5 ++---
drivers/dsp/dspgateway/task.c |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/dspgateway/dsp_ctl_core.c
b/drivers/dsp/dspgateway/dsp_ctl_core.c
index 3c13572..25954bb 100644
--- a/drivers/dsp/dspgateway/dsp_ctl_core.c
+++ b/drivers/dsp/dspgateway/dsp_ctl_core.c
@@ -110,9 +110,8 @@ int __init dsp_ctl_core_init(void)
dsp_ctl_class = class_create(THIS_MODULE, dspctl);
for (i = 0; i ARRAY_SIZE(dev_list); i++) {
device_create(dsp_ctl_class, NULL,
- MKDEV(OMAP_DSP_CTL_MAJOR,
- dev_list[i].minor),
- dev_list[i].devname);
+ MKDEV(OMAP_DSP_CTL_MAJOR, dev_list[i].minor),
+ NULL, dev_list[i].devname);
}
return 0;
diff --git a/drivers/dsp/dspgateway/task.c b/drivers/dsp/dspgateway/task.c
index 4d7dcdd..ab18934 100644
--- a/drivers/dsp/dspgateway/task.c
+++ b/drivers/dsp/dspgateway/task.c
@@ -1762,7 +1762,7 @@ static int taskdev_init(struct taskdev *dev, char
*name, unsigned char minor)
goto fail_create_proclist;
task_dev = device_create(dsp_task_class, NULL,
- MKDEV(OMAP_DSP_TASK_MAJOR, minor),
+ MKDEV(OMAP_DSP_TASK_MAJOR, minor), NULL,
dsptask%d, (int)minor);
if (unlikely(IS_ERR(task_dev))) {
--
1.5.5.1.357.g1af8b
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Build fix for n800_defconfig
* Sakari Ailus [EMAIL PROTECTED] [080812 13:19]: ext Hiroshi DOYU wrote: Just updated from the latest header file. Signed-off-by: Hiroshi DOYU [EMAIL PROTECTED] --- drivers/media/video/omap24xxcam.c | 67 +++- 1 files changed, 35 insertions(+), 32 deletions(-) Looks good to me. Thanks. Pushing today. Tony Regards, -- Sakari Ailus [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB-webcam support
Hi Arun, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of arun c Sent: Tuesday, August 12, 2008 4:02 PM To: linux-omap@vger.kernel.org Subject: USB-webcam support Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? Yes you can, I have tried Logitech LZ708BC on Beagle board and it works good at 160x120 resolution. You just need UVC driver, which I think is part of latest kernel. Regards, Khasim http://khasim.blogspot.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-webcam support
On Tue, Aug 12, 2008 at 4:20 PM, Gadiyar, Anand [EMAIL PROTECTED] wrote: Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? I don't see why not. Do you expect a problem with using it? You could use MUSB in host or OTG mode and connect the camera to the MUSB port. I have a Creative webcam and a fedora9 host machine. If I connect my webcam to my PC it happily gives me /dev/video0 to play with(I can grab photos, use xawtv). Can I expect the same with the OMAP3EVM? Regards, Arun C - Anand-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-webcam support
Op 12 aug 2008, om 12:50 heeft Gadiyar, Anand het volgende geschreven: Hi All, If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? I don't see why not. Do you expect a problem with using it? You could use MUSB in host or OTG mode and connect the camera to the MUSB port. Not quite, MUSB doesn't support the 'high bandwidth' flag, which most usb webcams seem to use (even the puny 12mbit ones). Tested on the MUSB port of my beagle and bf548. regards, Koen PGP.sig Description: This is a digitally signed message part
Re: Git tree updated to v2.6.27-rc2, help needed
* Jarkko Nikula [EMAIL PROTECTED] [080812 10:13]: On Mon, 11 Aug 2008 18:26:21 +0300 ext Tony Lindgren [EMAIL PROTECTED] wrote: Hi all, I've updated our git tree to v2.6.27-rc2, and looks like we still have a bunch of issues to solve: - Booting fails early on 3430sdp for some reason - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - N800 boots up to UI with gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2 and with DEBUG_LL=y. Without DEBUG_LL it hangs somewhere before serial is initialized - With gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53) there is alignment exception in early booting independently of 718fc6cd4db902aa2242a736cc3feb8744a4c71a Weird that this alignment exception only happens on 24xx, not on 34xx. Tony 5Kernel command line: root=1f03 rootfstype=jffs2 6Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz 1Unhandled fault: alignment exception (0x001) at 0xc02bf695 Internal error: : 1 [#1] Modules linked in: CPU: 0Not tainted (2.6.27-rc2-omap1 #9) PC is at omap2_clkdm_clk_enable+0x2c/0x74 LR is at omap2_clk_enable+0x54/0x9c pc : [c0034ed8]lr : [c0033738]psr: a1d3 sp : c0303e90 ip : c0303ea8 fp : c0303ea4 r10: 800252c0 r9 : 4107b362 r8 : 0013 r7 : c03261ac r6 : 0002 r5 : r4 : c02bf689 r3 : c02bf695 r2 : r1 : c03072c8 r0 : c02bf689 Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 00c5387f Table: 80004000 DAC: 0017 Process swapper (pid: 0, stack limit = 0xc0302260) Stack: (0xc0303e90 to 0xc0304000) 3e80: c03072c8 c0306d24 c0303ebc c0303ea8 3ea0: c0033738 c0034eb8 c0306d7c c0306d24 c0303ed4 c0303ec0 c003371c c00336f0 3ec0: c03071f4 c0306d24 c0303eec c0303ed8 c003371c c00336f0 c03073f0 c0306d24 3ee0: c0303f04 c0303ef0 c003371c c00336f0 c0307d90 c0306d24 c0303f1c c0303f08 3f00: c003371c c00336f0 c03099c0 c0306d24 c0303f34 c0303f20 c003371c c00336f0 3f20: 81d3 c0306d24 c0303f4c c0303f38 c00432e4 c00336f0 c03099c0 c0306d24 3f40: c0303f64 c0303f50 c00433c4 c00432b0 0292 c0306d24 c0303f94 c0303f68 3f60: c001144c c00433a4 0149 c0305cb8 c0303f94 c03255c0 c0026f0c 3f80: c0305cb8 800252f4 c0303fac c0303f98 c0010818 c0011288 c0026f10 c03255c0 3fa0: c0303fbc c0303fb0 c0011aec c00107fc c0303fcc c0303fc0 c000e438 c0011ae4 3fc0: c0303ff4 c0303fd0 c0008c14 c000e40c c00086bc c0026f10 3fe0: 00c5387d c0325f4c c0303ff8 80008034 c0008ad0 Backtrace: [c0034eac] (omap2_clkdm_clk_enable+0x0/0x74) from [c0033738] (omap2_clk_enable +0x54/0x9c) r5:c0306d24 r4:c03072c8 [c00336e4] (omap2_clk_enable +0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c0306d7c [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03071f4 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03073f0 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c0307d90 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03099c0 [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c00432e4] (clk_enable +0x40/0x54) r5:c0306d24 r4:81d3 [c00432a4] (clk_enable+0x0/0x54) from [c00433c4] (clk_enable_init_clocks+0x2c/0x4c) r5:c0306d24 r4:c03099c0 [c0043398] (clk_enable_init_clocks+0x0/0x4c) from [c001144c] (omap2_clk_init+0x1d0/0x23c) r5:c0306d24 r4:0292 [c001127c] (omap2_clk_init+0x0/0x23c) from [c0010818] (omap2_init_common_hw+0x28/0x40) r8:800252f4 r7:c0305cb8 r6:c0026f0c r5:c03255c0 r4: [c00107f0] (omap2_init_common_hw+0x0/0x40) from [c0011aec] (nokia_n800_init_irq+0x14/0x5c) r5:c03255c0 r4:c0026f10 [c0011ad8] (nokia_n800_init_irq+0x0/0x5c) from [c000e438] (init_IRQ+0x38/0x48) [c000e400] (init_IRQ+0x0/0x48) from [c0008c14] (start_kernel+0x150/0x2b8) [c0008ac4] (start_kernel +0x0/0x2b8) from [80008034] (0x80008034) r5:c0325f4c r4:00c5387d Code: 03a05001 03e00015 089da830 e284300c (e1931f9f) 4---[ end trace 1b75b31a2719ed1c ]--- 0Kernel panic - not syncing: Attempted to kill the idle task! Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
* Paul Walmsley [EMAIL PROTECTED] [080811 22:58]: On Mon, 11 Aug 2008, Tony Lindgren wrote: - Booting fails early on 3430sdp for some reason This affects all ARMv7 and is due to a bug in the TLB clearing code; patch coming shortly. - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? Haven't seen this here with CSL gcc 2007q3-51 on OMAP3. Seems to happen on 24xx only. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: off mode and smartreflex
Hi Richard, On pe, 2008-08-01 at 09:49 -0500, ext Woodruff, Richard wrote: Hi Peter, Using Rajendra's cpuidle and offmode patches + the patches I posted to configure triton2 and set the correct off mode polarity, I noticed the system does not go to off mode when smartreflex is enabled. At least sysoffmode is not deasserted and the VDD1 and VDD2 voltages do not drop to 0V. Should smartreflex be disabled by sw before the wfi is issued ? Any other idea on why this would happen ? SR does need to be disabled before an OPP change and re-enabled after the change when using the bypass method. Yes, I do think you also need to disable SR before idle. Also, this is in CDP code and functionally validated. I thought I'd fix this issue for both pm-idle and the up-coming cpu-idle by moving the smartreflex disable/enable calls to omap_sram_idle. But I could not do it, because this way the device hangs on both suspend and dynamic idle. I wonder why this is? The CDP code seems to disable smartreflex in the early stages of the function calling omap_sram_idle. In the suspend path the disable call is made just before local_fiq_disable. In pm-idle path the call seems to be before checking if some interrupt has occurred. So I gathered this might have something to do with interrupts. The thing that puzzles me is that with linux-omap, the suspend path does not have any local_fiq_disable calls. Nevertheless, if the smartreflex disable call is in omap_sram_idle, the suspend hangs. But, if it is in start of the preceding omap3_pm_suspend call, as it is now, suspending works fine. So this makes me think there could be some delay from when smartreflex is disabled to when the actual I2C commands stop to the voltage controller. Do you know why the smartreflex disable calls are positioned as they are in the CDP code? regards, Kalle Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: off mode and smartreflex
On ti, 2008-08-12 at 08:10 -0500, ext Woodruff, Richard wrote: I thought I'd fix this issue for both pm-idle and the up-coming cpu-idle by moving the smartreflex disable/enable calls to omap_sram_idle. But I could not do it, because this way the device hangs on both suspend and dynamic idle. I wonder why this is? The CDP code seems to disable smartreflex in the early stages of the function calling omap_sram_idle. In the suspend path the disable call is made just before local_fiq_disable. In pm-idle path the call seems to be before checking if some interrupt has occurred. So I gathered this might have something to do with interrupts. The thing that puzzles me is that with linux-omap, the suspend path does not have any local_fiq_disable calls. Nevertheless, if the smartreflex disable call is in omap_sram_idle, the suspend hangs. But, if it is in start of the preceding omap3_pm_suspend call, as it is now, suspending works fine. So this makes me think there could be some delay from when smartreflex is disabled to when the actual I2C commands stop to the voltage controller. Have you enabled SR really to do something? Yes, I'm using vdd1vdd2 autocompensation with the hardcoded testing values instead of efuse. My board seems quite stable using them. With out proper efuse values its job is to do OPP changes. Once you have proper efuses it can do safe auto-adjustment. Most early non-production devices won't have useable efuse values. I agree hardware I2C messages when it is in use might be a point of worry when investigating issues. Ok. The hang actually happens when coming out of suspend. The silicon errata states that if smartreflex is sending i2c commands while sleep command is issued, a warm reset will be generated. I don't know if warm resets are handled now, but this could be something causing the hang. Or it's something else, gotta do some debugging. Do you know why the smartreflex disable calls are positioned as they are in the CDP code? I don't recall there being a placement. I can ask others if there aware. Thanks! Regards, Kalle Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
* Tony Lindgren [EMAIL PROTECTED] [080812 14:42]:
* Jarkko Nikula [EMAIL PROTECTED] [080812 10:13]:
On Mon, 11 Aug 2008 18:26:21 +0300
ext Tony Lindgren [EMAIL PROTECTED] wrote:
Hi all,
I've updated our git tree to v2.6.27-rc2, and looks like we still
have a bunch of issues to solve:
- Booting fails early on 3430sdp for some reason
- Alignment error on omap2/3. This seems to happen also with
718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted?
- N800 boots up to UI with gcc version 3.4.4 (release) (CodeSourcery
ARM 2005q3-2 and with DEBUG_LL=y. Without DEBUG_LL it hangs somewhere
before serial is initialized
- With gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-53)
there is alignment exception in early booting independently of
718fc6cd4db902aa2242a736cc3feb8744a4c71a
Weird that this alignment exception only happens on 24xx, not on 34xx.
For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this.
Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned
does not help for me with gcc version 4.2.3 (Sourcery G++ Lite
2008q1-126).
Tony
5Kernel command line: root=1f03 rootfstype=jffs2
6Clocking rate (Crystal/DPLL/MPU): 19.2/658/329 MHz
1Unhandled fault: alignment exception (0x001) at 0xc02bf695
Internal error: : 1 [#1]
Modules linked in:
CPU: 0Not tainted (2.6.27-rc2-omap1 #9)
PC is at omap2_clkdm_clk_enable+0x2c/0x74
LR is at omap2_clk_enable+0x54/0x9c
pc : [c0034ed8]lr : [c0033738]psr: a1d3
sp : c0303e90 ip : c0303ea8 fp : c0303ea4
r10: 800252c0 r9 : 4107b362 r8 : 0013
r7 : c03261ac r6 : 0002 r5 : r4 : c02bf689
r3 : c02bf695 r2 : r1 : c03072c8 r0 : c02bf689
Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387f Table: 80004000 DAC: 0017
Process swapper (pid: 0, stack limit = 0xc0302260)
Stack: (0xc0303e90 to 0xc0304000)
3e80: c03072c8 c0306d24 c0303ebc
c0303ea8 3ea0: c0033738 c0034eb8 c0306d7c c0306d24 c0303ed4 c0303ec0
c003371c c00336f0 3ec0: c03071f4 c0306d24 c0303eec c0303ed8 c003371c
c00336f0 c03073f0 c0306d24 3ee0: c0303f04 c0303ef0 c003371c c00336f0
c0307d90 c0306d24 c0303f1c c0303f08 3f00: c003371c c00336f0 c03099c0
c0306d24 c0303f34 c0303f20 c003371c c00336f0 3f20: 81d3 c0306d24
c0303f4c c0303f38 c00432e4 c00336f0 c03099c0 c0306d24 3f40: c0303f64
c0303f50 c00433c4 c00432b0 0292 c0306d24 c0303f94 c0303f68 3f60:
c001144c c00433a4 0149 c0305cb8 c0303f94 c03255c0 c0026f0c
3f80: c0305cb8 800252f4 c0303fac c0303f98 c0010818 c0011288 c0026f10
c03255c0 3fa0: c0303fbc c0303fb0 c0011aec c00107fc c0303fcc c0303fc0
c000e438 c0011ae4 3fc0: c0303ff4 c0303fd0 c0008c14 c000e40c c00086bc
c0026f10 3fe0: 00c5387d c0325f4c c0303ff8
80008034 c0008ad0 Backtrace: [c0034eac]
(omap2_clkdm_clk_enable+0x0/0x74) from [c0033738] (omap2_clk_enable
+0x54/0x9c) r5:c0306d24 r4:c03072c8 [c00336e4] (omap2_clk_enable
+0x0/0x9c) from [c003371c] (omap2_clk_enable+0x38/0x9c) r5:c0306d24
r4:c0306d7c [c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c]
(omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03071f4
[c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c]
(omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03073f0
[c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c]
(omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c0307d90
[c00336e4] (omap2_clk_enable+0x0/0x9c) from [c003371c]
(omap2_clk_enable+0x38/0x9c) r5:c0306d24 r4:c03099c0
[c00336e4] (omap2_clk_enable+0x0/0x9c) from [c00432e4] (clk_enable
+0x40/0x54) r5:c0306d24 r4:81d3
[c00432a4] (clk_enable+0x0/0x54) from [c00433c4]
(clk_enable_init_clocks+0x2c/0x4c) r5:c0306d24 r4:c03099c0
[c0043398] (clk_enable_init_clocks+0x0/0x4c) from [c001144c]
(omap2_clk_init+0x1d0/0x23c) r5:c0306d24 r4:0292
[c001127c] (omap2_clk_init+0x0/0x23c) from [c0010818]
(omap2_init_common_hw+0x28/0x40) r8:800252f4 r7:c0305cb8 r6:c0026f0c
r5:c03255c0 r4: [c00107f0] (omap2_init_common_hw+0x0/0x40)
from [c0011aec] (nokia_n800_init_irq+0x14/0x5c) r5:c03255c0
r4:c0026f10 [c0011ad8] (nokia_n800_init_irq+0x0/0x5c) from
[c000e438] (init_IRQ+0x38/0x48) [c000e400] (init_IRQ+0x0/0x48) from
[c0008c14] (start_kernel+0x150/0x2b8) [c0008ac4] (start_kernel
+0x0/0x2b8) from [80008034] (0x80008034) r5:c0325f4c r4:00c5387d
Code: 03a05001 03e00015 089da830 e284300c (e1931f9f)
4---[ end trace 1b75b31a2719ed1c ]---
0Kernel panic - not syncing: Attempted to kill the idle task!
Jarkko
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at
RE: Git tree updated to v2.6.27-rc2, help needed
The omap3_evm_defconfig needs to be updated. Else, build fails with: LD init/built-in.o LD .tmp_vmlinux1 arm-none-linux-gnueabi-ld: no machine record defined arm-none-linux-gnueabi-ld: no machine record defined make: *** [.tmp_vmlinux1] Error 1 make oldconfig did not help either. I 'hacked' a defconfig with using omap_3430sdp_defconfig as reference for the build to be successful. Will need to review it later in the night before I send a patch... Best regards, Sanjeev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Lindgren Sent: Monday, August 11, 2008 8:56 PM To: linux-omap@vger.kernel.org; Sakari Ailus; Hiroshi DOYU; Eduardo Valentin Subject: Git tree updated to v2.6.27-rc2, help needed Hi all, I've updated our git tree to v2.6.27-rc2, and looks like we still have a bunch of issues to solve: - DSP compile is broken as now device_create() is same as device_create_drvdata(). So device_create() expects some some drvdata to be set also in drivers/dsp/dspgateway/task.c and drivers/dsp/dspgateway/dsp_ctl_core.c. Hiroshi, care to take a look at the DSP issue? - V4L drivers init needs to be fixed as the configuration is now passed in some other struct. This affects at least omap24xxcam.c and radio-tea5761.c. Sakari Eduardo, can you look at these issues? - Booting fails early on 3430sdp for some reason - Alignment error on omap2/3. This seems to happen also with 718fc6cd4db902aa2242a736cc3feb8744a4c71a reverted? - Pending patches to isp1301_omap.c need to be tested on H2 and H4 USB - Cpufreq is oopses on at least omap1 I'll continue looking at the 3430sdp boot issues on Tuesday and then update to current mainline with the header changes. Cheers, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git tree updated to v2.6.27-rc2, help needed
On Tue, Aug 12, 2008 at 05:31:20PM +0300, Tony Lindgren wrote: For me reverting 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 fixes this. Reverting 718fc6cd4db902aa2242a736cc3feb8744a4c71a like Felipe mentioned does not help for me with gcc version 4.2.3 (Sourcery G++ Lite 2008q1-126). But still quite weird that it only happens on 24xx. I gcc attributes to force alignment and make that union transparent, and nothing seems to help. Any thoughts from you guys ?? -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] OMAP2 SDRC: add timing data for Micron MT46H32M32LF-6
Many early EVMs used Samsung memory (mine for example). Are these
timings compatible or is a separate Samsung header required?
Steve
On Mon, Jul 7, 2008 at 7:54 PM, Paul Walmsley [EMAIL PROTECTED] wrote:
Add timing data for the Micron MT46H32M32LF-6 SDRAM chip, used on the
OMAP3 Beagle and EVM boards. Original timing data is from the Micron
datasheet PDF downloaded from:
http://download.micron.com/pdf/datasheets/dram/mobile/1gb_ddr_mobile_sdram_t48m.pdf
Thanks to Rajendra Nayak [EMAIL PROTECTED] for his help identifying
the chips used on Beagle OMAP3EVM.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/board-omap3beagle.c |4 +-
arch/arm/mach-omap2/board-omap3evm.c |4 +-
arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h | 55
+
include/asm-arm/arch-omap/sdrc.h |2 -
4 files changed, 62 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3523611..bf4b430 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -33,6 +33,8 @@
#include asm/arch/hsmmc.h
#include asm/arch/common.h
+#include sdram-micron-mt46h32m32lf-6.h
+
static struct omap_uart_config omap3_beagle_uart_config __initdata = {
.enabled_uarts = ((1 0) | (1 1) | (1 2)),
};
@@ -47,7 +49,7 @@ static int __init omap3_beagle_i2c_init(void)
static void __init omap3_beagle_init_irq(void)
{
- omap2_init_common_hw(NULL);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 1ba8a45..df81706 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -37,6 +37,8 @@
#include asm/arch/common.h
#include asm/arch/mcspi.h
+#include sdram-micron-mt46h32m32lf-6.h
+
static struct resource omap3evm_smc911x_resources[] = {
[0] = {
.start = OMAP3EVM_ETHR_START,
@@ -188,7 +190,7 @@ static struct platform_device omap3evm_kp_device = {
static void __init omap3_evm_init_irq(void)
{
- omap2_init_common_hw(NULL);
+ omap2_init_common_hw(mt46h32m32lf6_sdrc_params);
omap_init_irq();
omap_gpio_init();
omap3evm_init_smc911x();
diff --git a/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
new file mode 100644
index 000..f0ec104
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-micron-mt46h32m32lf-6.h
@@ -0,0 +1,55 @@
+/*
+ * SDRC register values for the Micron MT46H32M32LF-6
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H32M32LF
+#define ARCH_ARM_MACH_OMAP2_SDRAM_MICRON_MT46H32M32LF
+
+#include asm/arch/sdrc.h
+
+/* Micron MT46H32M32LF-6 */
+/* XXX Using ARE = 0x1 (no autorefresh burst) -- can this be changed? */
+static struct omap_sdrc_params mt46h32m32lf_sdrc_params[] = {
+ [0] = {
+ .rate= 165941176,
+ .actim_ctrla = 0x9a9db4c6,
+ .actim_ctrlb = 0x00011217,
+ .rfr_ctrl= 0x0004dc01,
+ .mr = 0x0032,
+ },
+ [1] = {
+ .rate= 1,
+ .actim_ctrla = 0x7a19b485,
+ .actim_ctrlb = 0x00011213,
+ .rfr_ctrl= 0x0003de01,
+ .mr = 0x0032,
+ },
+ [2] = {
+ .rate= 82970588,
+ .actim_ctrla = 0x51512283,
+ .actim_ctrlb = 0x0001120c,
+ .rfr_ctrl= 0x00025501,
+ .mr = 0x0032,
+ },
+ [3] = {
+ .rate= ,
+ .actim_ctrla = 0x410d2243,
+ .actim_ctrlb = 0x0001120a,
+ .rfr_ctrl= 0x0001d601,
+ .mr = 0x0032,
+ },
+ [4] = {
+ .rate= 0
+ },
+};
+
+#endif
diff --git a/include/asm-arm/arch-omap/sdrc.h
b/include/asm-arm/arch-omap/sdrc.h
index 00ba539..1d974a0 100644
--- a/include/asm-arm/arch-omap/sdrc.h
+++ b/include/asm-arm/arch-omap/sdrc.h
@@ -102,7 +102,7 @@ struct omap_sdrc_params {
u32 mr;
};
-void __init omap2_sdrc_init(void);
+void __init omap2_sdrc_init(struct omap_sdrc_params *);
struct omap_sdrc_params *omap2_sdrc_get_params(unsigned long r);
#ifdef
[PATCH 0/2] OMAP2/3: fix clock/clockdomain bugs
This series fixes two bugs that cause N800 to panic on boot: - a OMAP2xxx clock code bug, which caused an Unhandled fault: alignment exception (0x001) at 0xc02. panic; and - an OMAP2/3 clockdomain bug, which caused an Unable to handle kernel paging request at virtual address 5f75706d panic. These bugs were exposed by 0e5194e1a84c219bebbb78f305b7a8eabc4a3656 and 718fc6cd4db902aa2242a736cc3feb8744a4c71a. With the following patches applied on git head, N800 boots fine, but only if CONFIG_DEBUG_LL is enabled. If it is disabled, it hangs at some point in early boot. Don't know why. These patches also boot-tested cleanly on 2430SDP and 3430SDP, both with and without CONFIG_DEBUG_LL. textdata bss dec hex filename 3217805 149808 85008 3452621 34aecd vmlinux.n800.orig 3217837 149808 85008 3452653 34aeed vmlinux.n800 arch/arm/mach-omap2/clock24xx.c |2 ++ arch/arm/mach-omap2/clockdomain.c |6 ++ 2 files changed, 8 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2 clock: associate clocks with clockdomains at startup
The OMAP2 clock code was missing code to associate clocks with clockdomains
at registration time; fix this.
Resolves Unhandled fault: alignment exception (0x001) at 0xc02c1b4e (address
may vary) panic during clock framework init on OMAP2. The alignment error
was caused by an attempt to dereference a pointer to a string (1-byte aligned)
as if it were a pointer to a structure.
Thanks to Felipe Balbi [EMAIL PROTECTED] for originally reporting this
bug.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock24xx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock24xx.c b/arch/arm/mach-omap2/clock24xx.c
index 370f4f0..0d9d91f 100644
--- a/arch/arm/mach-omap2/clock24xx.c
+++ b/arch/arm/mach-omap2/clock24xx.c
@@ -567,11 +567,13 @@ int __init omap2_clk_init(void)
if ((*clkp)-flags CLOCK_IN_OMAP242X cpu_is_omap2420()) {
clk_register(*clkp);
+ omap2_init_clk_clkdm(*clkp);
continue;
}
if ((*clkp)-flags CLOCK_IN_OMAP243X cpu_is_omap2430()) {
clk_register(*clkp);
+ omap2_init_clk_clkdm(*clkp);
continue;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP2/3 clockdomains: autodeps should respect platform flags
Fix the clockdomain autodep code to respect omap_chip platform flags.
Resolves Unable to handle kernel paging request at virtual address
5f75706d panic during power management initialization on OMAP2.
Signed-off-by: Paul Walmsley [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clockdomain.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index caa7992..49741e8 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -96,6 +96,9 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
struct clkdm_pwrdm_autodep *autodep;
for (autodep = autodeps; autodep-pwrdm.ptr; autodep++) {
+ if (!omap_chip_is(autodep-omap_chip))
+ continue;
+
pr_debug(clockdomain: adding %s sleepdep/wkdep for
pwrdm %s\n, autodep-pwrdm.ptr-name,
clkdm-pwrdm.ptr-name);
@@ -118,6 +121,9 @@ static void _clkdm_del_autodeps(struct clockdomain *clkdm)
struct clkdm_pwrdm_autodep *autodep;
for (autodep = autodeps; autodep-pwrdm.ptr; autodep++) {
+ if (!omap_chip_is(autodep-omap_chip))
+ continue;
+
pr_debug(clockdomain: removing %s sleepdep/wkdep for
pwrdm %s\n, autodep-pwrdm.ptr-name,
clkdm-pwrdm.ptr-name);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] OMAP2 SDRC: add timing data for Micron MT46H32M32LF-6
Hello Steve, On Tue, 12 Aug 2008, Steve Sakoman wrote: Many early EVMs used Samsung memory (mine for example). Are these timings compatible or is a separate Samsung header required? Probably they will need fixing. Presumably we'll have to use least common denominator values between the two, unless there is some way to discriminate in software between the chips. BTW, if anyone would like to calculate their own timings/rates, I have a small utility here for doing so. The plan is to clean it up and post it for inclusion eventually, but I would be happy to send it to anyone who would like a copy in the interim, in the event that they are using some other type of RAM or different DPLL3 timings on their OMAP3 board. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-webcam support
If I have a USB camera with good Linux support, can I connect it to omap3evm(or any omap2) and make it functional? I'm told some folk have used ISO transfer support, but when I last did much work with the musb code, none of it was tested. Oh, one more point: it should work pretty well with EHCI. There are some glitches with the periodic scheduling (it's really messy even before you start thinking about how to code it), but folk have successfully used it with a variety of hardware. So if you can use EHCI on your EVM, that should be solvable. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP AIC23
Hi Chandra, i have a question, why a client is modifying mcbsp registers. There is a mcbsp config function (omap_mcbsp_config) exported which you can use to configure mcbsp registers. if its an absolute necessity you can use omap_mcbsp_read and omap_mcbsp_write function. which are defined in arch/arm/plat-omap/mcbsp.c. but you need to pass full register name, like OMAP_MCBSP_REG_SPCR1 instead of just SPCR1 ( 'SPCR1' undeclared error). Looking at the source file drivers/i2c/chips/tlv320aic23.c the function omap_mcbsp3_aic23_clock_init() is enabling the McBSP sample rate generator in order to generate the 12MHz system clock to the aic23. I believe that this needs to be done in order to configure the aic23. The good news is that there appears to be a simple fix. All we need to do is move the definitions of the macros OMAP_MCBSP_READ and OMAP_MCBSP_WRITE from mcbsp.c to the header include/asm-arm/arch-omap/mcbsp.h Doing this and making a couple other minor changes I am now able to build the alsa driver successfully for the omap5912 osk. I will submit a patch to the list. Let me know what you think. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [0/2]
This patch series fixes the omap5912 osk alsa driver. --- arch/arm/plat-omap/mcbsp.c|5 - include/asm-arm/arch-omap/mcbsp.h |8 sound/arm/omap/omap-alsa-dma.c|2 +- 3 files changed, 9 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [1/2]
Move OMAP_MCBSP_READ and OMAP_MCBSP_WRITE macro definitions from arch/arm/plat-omap/mcbsp.c to include/asm-arm/arch-omap/mcbsp.h. Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- arch/arm/plat-omap/mcbsp.c|5 - include/asm-arm/arch-omap/mcbsp.h |8 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 70944a5..214136e 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -46,11 +46,6 @@ int omap_mcbsp_read(u32 io_base, u16 reg) return __raw_readl(io_base + reg); } -#define OMAP_MCBSP_READ(base, reg) \ - omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg) -#define OMAP_MCBSP_WRITE(base, reg, val) \ - omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val) - #define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count) #define id_to_mcbsp_ptr(id)mcbsp_ptr[id]; diff --git a/include/asm-arm/arch-omap/mcbsp.h b/include/asm-arm/arch-omap/mcbsp.h index 8fa89c2..cf39ef1 100644 --- a/include/asm-arm/arch-omap/mcbsp.h +++ b/include/asm-arm/arch-omap/mcbsp.h @@ -50,6 +50,14 @@ #define OMAP34XX_MCBSP4_BASE 0x49026000 #define OMAP34XX_MCBSP5_BASE 0x48096000 +void omap_mcbsp_write(u32 io_base, u16 reg, u32 val); +int omap_mcbsp_read(u32 io_base, u16 reg); + +#define OMAP_MCBSP_READ(base, reg) \ + omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg) +#define OMAP_MCBSP_WRITE(base, reg, val) \ + omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val) + #if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX) || defined(CONFIG_ARCH_OMAP730) #define OMAP_MCBSP_REG_DRR20x00 -- 1.4.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP5912: Fix omap5912 osk alsa driver [2/2]
Corrected header file path in file sound/arm/omap/omap-alsa-dma.c. Signed-off-by: Jon Hunter [EMAIL PROTECTED] --- sound/arm/omap/omap-alsa-dma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/arm/omap/omap-alsa-dma.c b/sound/arm/omap/omap-alsa-dma.c index d263933..baafacf 100644 --- a/sound/arm/omap/omap-alsa-dma.c +++ b/sound/arm/omap/omap-alsa-dma.c @@ -64,9 +64,9 @@ #include linux/dma-mapping.h #include linux/io.h #include linux/uaccess.h +#include linux/semaphore.h #include asm/hardware.h -#include asm/semaphore.h #include asm/arch/dma.h #include asm/arch/mcbsp.h #include asm/arch/omap-alsa.h -- 1.4.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13][GIT 3/4+] Dspbridge latest patches
Hi, I would like to announce that the latest patches for dspbridge code are now uploaded, you can find them in Gforge OmapZoom site at: http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseViewrelease_id=119 Also, update your API and samples code when using the latest patches or when pulling from OmapZoom GIT, since the previous one will not longer work due to bool type changes in bridge sources, you can find these tarballs at: http://omapzoom.org/gf/project/omapbridge/frs/?action=FrsReleaseViewrelease_id=117 -omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git omapzoom suggestions
Hi Felipe Contreras -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Felipe Contreras Sent: Thursday, August 07, 2008 8:07 PM To: linux-omap@vger.kernel.org Subject: git omapzoom suggestions Hi, I'm trying to pull from git.omapzoom and nothing happens, it seems you are not running git-update-server-info (info/refs is outdated[1]). You need to chmod +x .git/hooks/post-update. This is updated now. Thanks for pointing out the miss. The clone is working fine now. Also, you don't have a .git/cloneurl file, so the URL is not displayed I will be doing this soon. by gitweb. It would also be good to support native git instead of http (much more efficient). We are actively working on getting the native git support up. Till then we will have to live with http. Thanks for the feedback. Best regards. [1] http://git.omapzoom.org/repo/omapkernel/info/refs -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/11] OMAP3 CPUidle patches - ver 2
Check wether serial can sleep is missing from
omap3_enter_idle and it should be removed from omap3_can_sleep:
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index a02da6d..16ff30b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -431,7 +431,7 @@ static int omap3_enter_idle(struct
cpuidle_device *dev,
current_cx_state = *cx;
- if (cx-type == OMAP3_STATE_C0) {
+ if (cx-type == OMAP3_STATE_C0 || !omap_serial_can_sleep()) {
/* Do nothing for C0, not even a wfi */
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..f9b3676 100644
@@ -391,8 +391,6 @@ int omap3_can_sleep(void)
return 0;
if (atomic_read(sleep_block) 0)
return 0;
- if (!omap_serial_can_sleep())
- return 0;
return 1;
}
Doing this would make serial console to work faster.
Yes, I removed these in my patches and put in the changes suggested by Richard
in 8250.c
I thought the final conclusion of the discussion was that it was too expensive
to the keep the
system in C0 all the time while UART inactivity runs, or did I miss something?
_omap_sram_idle should be non-static:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c index f68fa0a..133a666 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -60,7 +60,7 @@ u32 restore_pointer_address;
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
+void (*_omap_sram_idle)(u32 *addr, int save_state);
static void (*saved_idle)(void);
I thought this is already part of the patches. It is now non-static.
Serial and gpio clock disabling and gpio_prepare/resume can
be removed from omap3_pm_idle because they are already done
in omap_sram_idle. And if omap_serial_can_sleep is removed
from omap3_can_sleep it should be added to omap3_pm_idle.
Omap3_pm_idle can be also put behind #ifndef CONFIG_CPU_IDLE:
+#ifndef CONFIG_CPU_IDLE
static void omap3_pm_idle(void)
{
local_irq_disable();
@@ -454,33 +455,16 @@ static void omap3_pm_idle(void)
if (omap_irq_pending())
goto out;
- omap2_gpio_prepare_for_retention();
-
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(0, 0);
- omap_serial_enable_clocks(0, 1);
- omap_serial_enable_clocks(0, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_disable();
- }
+ if (!omap_serial_can_sleep())
+ goto out;
omap_sram_idle();
- if (clocks_off_while_idle) {
- omap_serial_enable_clocks(1, 0);
- omap_serial_enable_clocks(1, 1);
- omap_serial_enable_clocks(1, 2);
- /* XXX This is for gpio fclk hack. Will be removed as
-* gpio driver * handles fcks correctly */
- per_gpio_clk_enable();
- }
-
- omap2_gpio_resume_after_retention();
out:
local_fiq_enable();
local_irq_enable();
}
+#endif /* CONFIG_CPU_IDLE */
These are also done as part of the last patch in the series.
I would like to see also some reformatting. E.g. patch 11
contains lots of code which is not related to CORE context
save/restore. It might be also good idea to enable only
non-off mode C states and have a pwrdms_setup function which
is something like this:
static int __init pwrdms_setup(struct powerdomain *pwrdm) {
struct power_state *pwrst;
if (!pwrdm-pwrsts)
return 0;
pwrst = kmalloc(sizeof(struct power_state), GFP_KERNEL);
if (!pwrst)
return -ENOMEM;
pwrst-pwrdm = pwrdm;
pwrst-next_state = PWRDM_POWER_RET;
list_add(pwrst-node, pwrst_list);
if (pwrdm_has_hdwr_sar(pwrdm))
pwrdm_enable_hdwr_sar(pwrdm);
#ifdef CONFIG_CPU_IDLE
/* Let cpuidle do selection here */
if (!strcmp(pwrst-pwrdm-name, core_pwrdm) ||
!strcmp(pwrst-pwrdm-name, mpu_pwrdm) ||
!strcmp(pwrst-pwrdm-name, neon_pwrdm))
return set_pwrdm_state(pwrst-pwrdm, PWRDM_POWER_ON);
else
#endif
return set_pwrdm_state(pwrst-pwrdm,
pwrst-next_state); }
This way cpuidle code would be in a state that it could be
applied on linux-omap tree and it wouldn't break anything.
Then have e.g. separate patch for testing off state. This
patch could modify code to set next states to off and mark
off mode C states as a valid.
Yes, will do that. Maybe the couple of comments above are also due to
the last patch doing a lot more than it actually should.
Hi,
I am
