Re: [PATCHv4 3/4] OMAP3: Devkit8000: Check return value of gpio_request
Hello,
Am 19.01.2011 13:23, schrieb Sergei Shtylyov:
Hello.
On 19-01-2011 11:19, Thomas Weber wrote:
The return value of gpio_request is ignored.
This patch adds the check of the return value of gpio_request.
Signed-off-by: Thomas Weberwe...@corscience.de
---
arch/arm/mach-omap2/board-devkit8000.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 9fb416b..4ddd81c 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
[...]
@@ -244,13 +246,23 @@ static int devkit8000_twl_gpio_setup(struct
device *dev,
/* TWL4030_GPIO_MAX + 0 is LCD_PWREN (out, active high) */
devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
-gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
+ret = gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
+if (ret 0) {
+printk(KERN_ERR Failed to request GPIO for LCD_PWRN\n);
+return ret;
+}
+
/* Disable until needed */
gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
/* gpio + 7 is DVI_PD (out, active low) */
devkit8000_dvi_device.reset_gpio = gpio + 7;
-gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
+ret = gpio_request(devkit8000_dvi_device.reset_gpio, DVI
PowerDown);
+if (ret 0) {
+printk(KERN_ERR Failed to request GPIO for DVI PowerDown\n);
You forgot to call:
gpio_free(devkit8000_lcd_device.reset_gpio);
Couldn't I use lcd without dvi?
And shouldn't the gpio then be set to -EINVAL for the gpio_is_valid()
check in enable_lcd()/disable_lcd() and enable_dvi()/disable_dvi()?
Thomas
+return ret;
+}
+
/* Disable until needed */
gpio_direction_output(devkit8000_dvi_device.reset_gpio, 0);
WBR, Sergei
--
--
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 v4] ARM: Thumb-2: Symbol manipulation macros for function body copying
On Wed, Jan 19, 2011 at 10:29 PM, Kevin Hilman khil...@ti.com wrote: Dave Martin dave.mar...@linaro.org writes: In low-level board support code, there is sometimes a need to copy a function body to another location at run-time. A straightforward call to memcpy doesn't work in Thumb-2, because bit 0 of external Thumb function symbols is set to 1, indicating that the function is Thumb. Without corrective measures, this will cause an off-by-one copy, and the copy may be called using the wrong instruction set. This patch adds an fncpy() macro to help with such copies. Particular care is needed, because C doesn't guarantee any defined behaviour when casting a function pointer to any other type. This has been observed to lead to strange optimisation side-effects when doing the arithmetic which is required in order to copy/move function bodies correctly in Thumb-2. Thanks to Russell King and Nicolas Pitre for their input on this patch. Signed-off-by: Dave Martin dave.mar...@linaro.org Tested-by: Jean Pihet j-pi...@ti.com Tested-by: Kevin Hilman khil...@ti.com along with Jean's OMAP patch on: OMAP2420/n810: including basic suspend/resume test. OMAP16xx/OSK: boot test only. Kevin Thanks ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
On some architectures, secondary cores shares clock with primiary
core and hence scale together. Hence secondary core lpj calibration
is not necessary and can be skipped to save considerable time.
This can speed up the secondary cpu boot and hotplug cpu online
paths.
Discussion thread:
http://www.spinics.net/lists/arm-kernel/msg24.html
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Linus Walleij linus.wall...@stericsson.com
---
arch/arm/Kconfig|5 +
arch/arm/kernel/smp.c | 36
arch/arm/mach-omap2/Kconfig |1 +
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..8944639 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -823,6 +823,7 @@ config ARCH_U300
config ARCH_U8500
bool ST-Ericsson U8500 Series
select CPU_V7
+ select ARCH_HAS_COMMON_CORES_CLOCK
select ARM_AMBA
select GENERIC_CLOCKEVENTS
select CLKDEV_LOOKUP
@@ -1418,6 +1419,10 @@ config ARCH_SPARSEMEM_DEFAULT
config ARCH_SELECT_MEMORY_MODEL
def_bool ARCH_SPARSEMEM_ENABLE
+config ARCH_HAS_COMMON_CORES_CLOCK
+ bool
+ depends on SMP
+
config HIGHMEM
bool High Memory Support (EXPERIMENTAL)
depends on MMU EXPERIMENTAL
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4539ebc..8e72b11 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -270,6 +270,20 @@ static void __cpuinit smp_store_cpu_info(unsigned int
cpuid)
}
/*
+ * Skip the secondary calibration on architectures sharing clock
+ * with primary cpu. Archs can select ARCH_HAS_COMMON_CORES_CLOCK
+ * for this.
+ */
+static inline int skip_secondary_calibrate(void)
+{
+#ifdef CONFIG_ARCH_HAS_COMMON_CORES_CLOCK
+ return true;
+#else
+ return false;
+#endif
+}
+
+/*
* This is the secondary CPU boot entry. We're using this CPUs
* idle thread stack, but a set of temporary page tables.
*/
@@ -312,7 +326,8 @@ asmlinkage void __cpuinit secondary_start_kernel(void)
*/
percpu_timer_setup();
- calibrate_delay();
+ if (!skip_secondary_calibrate())
+ calibrate_delay();
smp_store_cpu_info(cpu);
@@ -332,14 +347,19 @@ void __init smp_cpus_done(unsigned int max_cpus)
int cpu;
unsigned long bogosum = 0;
- for_each_online_cpu(cpu)
- bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+ if (!skip_secondary_calibrate()) {
+ for_each_online_cpu(cpu)
+ bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
- printk(KERN_INFO SMP: Total of %d processors activated
- (%lu.%02lu BogoMIPS).\n,
- num_online_cpus(),
- bogosum / (50/HZ),
- (bogosum / (5000/HZ)) % 100);
+ printk(KERN_INFO SMP: Total of %d processors activated
+ (%lu.%02lu BogoMIPS).\n,
+ num_online_cpus(),
+ bogosum / (50/HZ),
+ (bogosum / (5000/HZ)) % 100);
+ } else {
+ printk(KERN_INFO SMP: Total of %d processors activated.\n,
+ num_online_cpus());
+ }
}
void __init smp_prepare_boot_cpu(void)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..e6ad15d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -43,6 +43,7 @@ config ARCH_OMAP4
default y
depends on ARCH_OMAP2PLUS
select CPU_V7
+ select ARCH_HAS_COMMON_CORES_CLOCK
select ARM_GIC
select PL310_ERRATA_588369
select ARM_ERRATA_720789
--
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
Re: [PATCH] ARM: oprofile: Always allow backtraces
On 20.01.11 04:42:24, Will Deacon wrote:
Hi Ari,
Always allow backtrace when using oprofile on ARM, even if a PMU
isn't present.
Restores functionality originally introduced in
1b7b56982fdcd9d85effd76f3928cf5d6eb26155 by Richard Purdie.
Well spotted, I'd forgotten we still want this for timer mode.
Comments inline.
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..a23e5ae 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -46,6 +46,7 @@ char *op_name_from_perf_id(void)
return NULL;
}
}
+#endif
static int report_trace(struct stackframe *frame, void *d)
{
@@ -109,6 +110,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
tail = user_backtrace(tail);
}
+#ifdef CONFIG_HW_PERF_EVENTS
Can you reorder the backtrace stuff so that we don't need the extra
#endif/#ifdef please?
I would like to go even further, see the diff below.
-Robert
---
arch/arm/oprofile/common.c | 45 ---
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..916aa2e 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -47,18 +47,6 @@ char *op_name_from_perf_id(void)
}
}
-static int report_trace(struct stackframe *frame, void *d)
-{
- unsigned int *depth = d;
-
- if (*depth) {
- oprofile_add_trace(frame-pc);
- (*depth)--;
- }
-
- return *depth == 0;
-}
-
/*
* The registers we're interested in are at the end of the variable
* length saved register structure. The fp points at the end of this
@@ -91,6 +79,30 @@ static struct frame_tail* user_backtrace(struct frame_tail
*tail)
return buftail[0].fp-1;
}
+#else
+
+static int oprofile_arch_init(struct oprofile_operations *ops)
+{
+ pr_info(oprofile: hardware counters not available\n);
+ return -ENODEV;
+}
+
+static void oprofile_arch_exit(void) { }
+
+#endif /* CONFIG_HW_PERF_EVENTS */
+
+static int report_trace(struct stackframe *frame, void *d)
+{
+ unsigned int *depth = d;
+
+ if (*depth) {
+ oprofile_add_trace(frame-pc);
+ (*depth)--;
+ }
+
+ return *depth == 0;
+}
+
static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
{
struct frame_tail *tail = ((struct frame_tail *) regs-ARM_fp) - 1;
@@ -111,6 +123,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
+ /* provide backtrace support also in timer mode: */
ops-backtrace = arm_backtrace;
return oprofile_perf_init(ops);
@@ -120,11 +133,3 @@ void __exit oprofile_arch_exit(void)
{
oprofile_perf_exit();
}
-#else
-int __init oprofile_arch_init(struct oprofile_operations *ops)
-{
- pr_info(oprofile: hardware counters not available\n);
- return -ENODEV;
-}
-void __exit oprofile_arch_exit(void) {}
-#endif /* CONFIG_HW_PERF_EVENTS */
--
1.7.3.4
--
Advanced Micro Devices, Inc.
Operating System Research Center
--
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: OMAP DSS Enable clocks in dss_setup_partial_planes
Hi, I am not sure if this is needed. All calls within configure_dispc() ensure that clocks are enabled before a register write. The functions which read/write to registers and don't enable/disable clocks have names which start with a _(for most cases). Regards, Archit linux-omap-ow...@vger.kernel.org wrote: From 086e3454c8f154cd90a4669899f2179f16ef32cd Mon Sep 17 00:00:00 2001 From: Ben Tucker btuc...@mpc-data.co.uk Date: Thu, 13 Jan 2011 12:56:45 + Subject: [PATCH] OMAP DSS Enable clocks in dss_setup_partial_planes Enable the interface clocks while calling configure_dispc(). --- drivers/video/omap2/dss/manager.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/dss/manager.c b/drivers/video/omap2/dss/manager.c index 545e9b9..cb90dac 100644 --- a/drivers/video/omap2/dss/manager.c +++ b/drivers/video/omap2/dss/manager.c @@ -1106,7 +1106,9 @@ void dss_setup_partial_planes(struct omap_dss_device *dssdev, mc-w = w; mc-h = h; + dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1); configure_dispc(); + dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1); mc-do_manual_update = false; -- 1.7.3.2-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap3: nand: bch ecc support added
bch error correction (t=4 and t=8) for 512 bytes support added.
Tested in omap-3630 es-1.1 silicon.
Need to select the bch-ecc from board file. E.g.
arch/arm/mach-omap2/board-flash.c: board_nand_init()
board_nand_data.ecc_opt = OMAP_ECC_BCH4_CODE_HW
This patch has dependency on -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42658.html
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 126 ---
arch/arm/plat-omap/include/plat/gpmc.h |6 +-
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/omap2.c | 119 --
drivers/mtd/nand/omap_bch_decoder.c| 393
5 files changed, 583 insertions(+), 62 deletions(-)
create mode 100644 drivers/mtd/nand/omap_bch_decoder.c
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 29c9732..91cfdca 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -48,6 +48,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -94,7 +95,6 @@ static struct resourcegpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -832,52 +832,77 @@ void omap3_gpmc_restore_context(void)
/**
* gpmc_enable_hwecc - enable hardware ecc functionality
+ * @ecc_type: ecc type e.g. Hamming, BCH
* @cs: chip select number
* @mode: read/write mode
* @dev_width: device bus width(1 for x16, 0 for x8)
* @ecc_size: bytes for which ECC will be generated
*/
-int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
+int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
+ int dev_width, int ecc_size)
{
- unsigned int val;
-
- /* check if ecc module is in used */
- if (gpmc_ecc_used != -EINVAL)
- return -EINVAL;
-
- gpmc_ecc_used = cs;
-
- /* clear ecc and enable bits */
- val = ((0x00018) | 0x0001);
- gpmc_write_reg(GPMC_ECC_CONTROL, val);
-
- /* program ecc and result sizes */
- val = ecc_size 1) - 1) 22) | (0x000F));
- gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+ unsigned int bch_mod = 0, bch_wrapmode = 0, eccsize1 = 0, eccsize0 = 0;
+ unsigned int ecc_conf_val = 0, ecc_size_conf_val = 0;
switch (mode) {
case GPMC_ECC_READ:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0xD; eccsize0 = 0x48;
+ bch_mod = 0;
+ bch_wrapmode = 0x09;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x1A; eccsize0 = 0x18;
+ bch_mod = 1;
+ bch_wrapmode = 0x04;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
case GPMC_ECC_READSYN:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
break;
+
case GPMC_ECC_WRITE:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 0;
+ bch_wrapmode = 0x06;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 1;
+ bch_wrapmode = 0x06;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
default:
printk(KERN_INFO Error: Unrecognized Mode[%d]!\n, mode);
break;
}
- /* (ECC 16 or 8 bit col) | ( CS ) | ECC Enable */
- val = (dev_width 7) | (cs 1) | (0x1);
- gpmc_write_reg(GPMC_ECC_CONFIG, val);
+ /* clear ecc and enable bits */
+ if ((ecc_type == OMAP_ECC_BCH4_CODE_HW) ||
+ (ecc_type == OMAP_ECC_BCH8_CODE_HW)) {
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x0001);
+ ecc_size_conf_val = (eccsize1 22) | (eccsize0 12);
+ ecc_conf_val = ((0x01 16) | (bch_mod 12)
+ | (bch_wrapmode 8) | (dev_width 7)
+ | (0x03 4) | (cs 1) | (0x1));
+ } else {
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x0101);
+ ecc_size_conf_val = (eccsize1 22) | 0x000F;
+ ecc_conf_val = (dev_width 7) | (cs 1) | (0x1);
+ }
+
+
Re: [PATCH] ARM: oprofile: Always allow backtraces
On 20.01.11 10:52:39, Robert Richter wrote:
I would like to go even further, see the diff below.
-Robert
---
arch/arm/oprofile/common.c | 45 ---
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..916aa2e 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -47,18 +47,6 @@ char *op_name_from_perf_id(void)
}
}
-static int report_trace(struct stackframe *frame, void *d)
-{
- unsigned int *depth = d;
-
- if (*depth) {
- oprofile_add_trace(frame-pc);
- (*depth)--;
- }
-
- return *depth == 0;
-}
-
/*
* The registers we're interested in are at the end of the variable
* length saved register structure. The fp points at the end of this
@@ -91,6 +79,30 @@ static struct frame_tail* user_backtrace(struct frame_tail
*tail)
return buftail[0].fp-1;
}
+#else
+
+static int oprofile_arch_init(struct oprofile_operations *ops)
Of course it should compile, but in this sense...
-Robert
+{
+ pr_info(oprofile: hardware counters not available\n);
+ return -ENODEV;
+}
+
+static void oprofile_arch_exit(void) { }
+
+#endif /* CONFIG_HW_PERF_EVENTS */
+
+static int report_trace(struct stackframe *frame, void *d)
+{
+ unsigned int *depth = d;
+
+ if (*depth) {
+ oprofile_add_trace(frame-pc);
+ (*depth)--;
+ }
+
+ return *depth == 0;
+}
+
static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
{
struct frame_tail *tail = ((struct frame_tail *) regs-ARM_fp) - 1;
@@ -111,6 +123,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
+ /* provide backtrace support also in timer mode: */
ops-backtrace = arm_backtrace;
return oprofile_perf_init(ops);
@@ -120,11 +133,3 @@ void __exit oprofile_arch_exit(void)
{
oprofile_perf_exit();
}
-#else
-int __init oprofile_arch_init(struct oprofile_operations *ops)
-{
- pr_info(oprofile: hardware counters not available\n);
- return -ENODEV;
-}
-void __exit oprofile_arch_exit(void) {}
-#endif /* CONFIG_HW_PERF_EVENTS */
--
Advanced Micro Devices, Inc.
Operating System Research Center
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: oprofile: Always allow backtraces
On 20.01.11 05:17:16, Ari Kauppi wrote:
@@ -91,6 +79,30 @@ static struct frame_tail* user_backtrace(struct
frame_tail *tail)
return buftail[0].fp-1;
}
+#else
+
+static int oprofile_arch_init(struct oprofile_operations *ops)
+{
+ pr_info(oprofile: hardware counters not available\n);
+ return -ENODEV;
+}
+
+static void oprofile_arch_exit(void) { }
I guess you mean oprofile_perf_init and oprofile_perf_exit?
Yes, did not compile test it as my arm cross compile chain was broken.
Maybe we move it to include/linux/oprofile.h.
I also observed some mismatches while using CONFIG_HW_PERF_EVENTS and
CONFIG_PERF_EVENTS, esp. with include/linux/oprofile.h. /arch/sh is
also affected. We need to review this too.
Also the user_backtrace and frame_tail need to be moved out from the
#ifdef.
Yes, thanks.
-Robert
--
Advanced Micro Devices, Inc.
Operating System Research Center
--
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] omap3: Add basic support for 720MHz part
-Original Message-
From: Varadarajan, Charulatha
Sent: Tuesday, January 18, 2011 2:44 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
Couple of minor comments.
[snip]...[snip]
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
#define FEAT_NEON 0
#define FEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
Do not use multiline comment style for single line comments
[sp] Was only following the multi-line comment stye few lines
above...
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#define OMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+ * Does it support 720MHz?
+ */
Ditto
[sp] Same here.
But since the code is quite evident, I will remove the comment
altogether.
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
No need of { } as there is only one line statement inside the
if condition.
[sp] missed this.
~sanjeev
[snip]...[snip]--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: oprofile: Always allow backtraces
On Thu, 20 Jan 2011, Robert Richter wrote:
Hi,
On 20.01.11 04:42:24, Will Deacon wrote:
Hi Ari,
Always allow backtrace when using oprofile on ARM, even if a PMU
isn't present.
Restores functionality originally introduced in
1b7b56982fdcd9d85effd76f3928cf5d6eb26155 by Richard Purdie.
Well spotted, I'd forgotten we still want this for timer mode.
Comments inline.
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..a23e5ae 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -46,6 +46,7 @@ char *op_name_from_perf_id(void)
return NULL;
}
}
+#endif
static int report_trace(struct stackframe *frame, void *d)
{
@@ -109,6 +110,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
tail = user_backtrace(tail);
}
+#ifdef CONFIG_HW_PERF_EVENTS
Can you reorder the backtrace stuff so that we don't need the extra
#endif/#ifdef please?
I would like to go even further, see the diff below.
Thanks for comments, I can prepare a new patch. I think your patch below
has two typos but the idea was clear, please see comments below.
-Robert
---
arch/arm/oprofile/common.c | 45 ---
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..916aa2e 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -47,18 +47,6 @@ char *op_name_from_perf_id(void)
}
}
-static int report_trace(struct stackframe *frame, void *d)
-{
- unsigned int *depth = d;
-
- if (*depth) {
- oprofile_add_trace(frame-pc);
- (*depth)--;
- }
-
- return *depth == 0;
-}
-
/*
* The registers we're interested in are at the end of the variable
* length saved register structure. The fp points at the end of this
@@ -91,6 +79,30 @@ static struct frame_tail* user_backtrace(struct frame_tail
*tail)
return buftail[0].fp-1;
}
+#else
+
+static int oprofile_arch_init(struct oprofile_operations *ops)
+{
+ pr_info(oprofile: hardware counters not available\n);
+ return -ENODEV;
+}
+
+static void oprofile_arch_exit(void) { }
I guess you mean oprofile_perf_init and oprofile_perf_exit?
Also the user_backtrace and frame_tail need to be moved out from the
#ifdef.
+
+#endif /* CONFIG_HW_PERF_EVENTS */
+
+static int report_trace(struct stackframe *frame, void *d)
+{
+ unsigned int *depth = d;
+
+ if (*depth) {
+ oprofile_add_trace(frame-pc);
+ (*depth)--;
+ }
+
+ return *depth == 0;
+}
+
static void arm_backtrace(struct pt_regs * const regs, unsigned int depth)
{
struct frame_tail *tail = ((struct frame_tail *) regs-ARM_fp) - 1;
@@ -111,6 +123,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
+ /* provide backtrace support also in timer mode: */
ops-backtrace = arm_backtrace;
return oprofile_perf_init(ops);
@@ -120,11 +133,3 @@ void __exit oprofile_arch_exit(void)
{
oprofile_perf_exit();
}
-#else
-int __init oprofile_arch_init(struct oprofile_operations *ops)
-{
- pr_info(oprofile: hardware counters not available\n);
- return -ENODEV;
-}
-void __exit oprofile_arch_exit(void) {}
-#endif /* CONFIG_HW_PERF_EVENTS */
--
Ari
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DMA: clear interrupt status correctly
On 20/01/11 00:44, Tony Lindgren wrote: * Tony Lindgrent...@atomide.com [110119 14:23]: * Adrian Hunteradrian.hun...@nokia.com [110119 02:23]: From fffa19df17d73c1ed2e8c65c0b6604ee1dddff84 Mon Sep 17 00:00:00 2001 From: Adrian Hunteradrian.hun...@nokia.com Date: Wed, 24 Nov 2010 13:23:21 +0200 Subject: [PATCH] OMAP: DMA: clear interrupt status correctly When clearing the DMA channel, clear all status bits. When handling a DMA interrupt, clear only the interrupt status bits that have been read and are passed to the channel's interrupt handler, not every status bit. Signed-off-by: Adrian Hunteradrian.hun...@nokia.com Thanks, will queue as a fix. This did not apply for some reason, I've applied it manually. Please check that I got it right in omap-fixes branch soonish. Let me know if it needs updating. Looks fine Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Add basic support for 720MHz part
On Thu, Jan 20, 2011 at 16:28, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Varadarajan, Charulatha Sent: Tuesday, January 18, 2011 2:44 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap3: Add basic support for 720MHz part Also do not miss the version number while posting patches. -- 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] omap2: fix DPLL_FREQSEL calculation
Hi, On Thu, Jan 20, 2011 at 11:42:24AM +0100, John Ogness wrote: This patch fixes the calculation of the internal frequency. The value of n is one less than the actual divider. 0 is a valid value. An example where the internal frequency is calculated correctly can be found here: clkt_dpll.c:_dpll_test_fint() This patch is against linux-next-20110120. Signed-off-by: John Ogness john.ogn...@linutronix.de scripts/get_maintainer.pl would've helped you getting a better Cc list. I'm adding linux-omap and lakml --- arch/arm/mach-omap2/dpll3xxx.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/arm/mach-omap2/dpll3xxx.c 2011-01-20 11:20:41.706860086 +0100 +++ b/arch/arm/mach-omap2/dpll3xxx.c 2011-01-20 11:21:27.966860086 +0100 @@ -93,7 +93,7 @@ static u16 _omap3_dpll_compute_freqsel(s unsigned long fint; u16 f = 0; - fint = clk-dpll_data-clk_ref-rate / n; + fint = clk-dpll_data-clk_ref-rate / (n + 1); pr_debug(clock: fint is %lu\n, fint); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: Add basic support for 720MHz part
On Thu, Jan 20, 2011 at 04:28:11PM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Varadarajan, Charulatha
Sent: Tuesday, January 18, 2011 2:44 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: Add basic support for 720MHz part
Couple of minor comments.
[snip]...[snip]
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,13 @@
#define FEAT_NEON 0
#define FEAT_NEON_NONE 1
+/*
+ * Product ID register
+ */
Do not use multiline comment style for single line comments
[sp] Was only following the multi-line comment stye few lines
above...
+#define OMAP3_PRODID 0x020C
+
+#define OMAP3_SKUID_MASK 0x0f
+#define OMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..53fbe01 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -195,6 +195,15 @@ static void __init omap3_check_features(void)
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
*/
+
+ /*
+ * Does it support 720MHz?
+ */
Ditto
[sp] Same here.
But since the code is quite evident, I will remove the comment
altogether.
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+
+ if (status OMAP3_SKUID_720MHZ) {
+ omap3_features |= OMAP3_HAS_720MHZ;
+ }
No need of { } as there is only one line statement inside the
if condition.
[sp] missed this.
Looks fine. Feel free to add after the above changes:
Reviewed-by: G, Manjunath Kondaiah manj...@ti.com
-Manjunath
--
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
[PATCHv4] omap3: Add basic support for 720MHz part
This patch adds support for new speed enhanced parts with ARM
and IVA running at 720MHz and 520MHz respectively. These parts
can be probed at run-time by reading PRODID.SKUID[3:0] at
0x4830A20C [1].
This patch specifically does following:
* Detect devices capable of 720MHz.
* Add new OPP
* Ensure that OPP is conditionally enabled.
* Check for presence of IVA before attempting to enable
the corresponding OPP.
[1] http://focus.ti.com/lit/ug/spruff1d/spruff1d.pdf
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Since v3:
1) Minor changes to comments and braces.
Since v2:
1) pr_xxx() - dev_xxx() functions - suggested by
Manjunath (manj...@ti.com)
2) Add check for presense of IVA - earlier planned to
be in a separate patch; but we multiple discussions
on optimizations.
3) Do look-up for hwmod corresponding for iva only if
iva is present. Should save multiple strcmp()s in
_lookup().
Since v1:
1) Using opp_enable() to enable the OPP after the OPP
table has been initialized.
2) Starting at 3 levels of indent, the statements had
be broken into multiple lines for most of the code.
So, opted to create a new static that enables the
OPPs corresponding to 720MHz.
3) I have only build tested this patch - will be able
to confirm working tomorrow. With any further change,
if needed. (However, functionally nothing has changed.)
arch/arm/mach-omap2/control.h |6 +++
arch/arm/mach-omap2/id.c |5 +++
arch/arm/mach-omap2/opp3xxx_data.c| 63 -
arch/arm/plat-omap/include/plat/cpu.h |2 +
4 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f0629ae..c338466 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -365,6 +365,12 @@
#defineFEAT_NEON 0
#defineFEAT_NEON_NONE 1
+/* Product ID register */
+#define OMAP3_PRODID 0x020C
+
+/* Mask to extract SKU ID from Product ID */
+#define OMAP3_SKUID_MASK 0x0f
+#defineOMAP3_SKUID_720MHZ 0x08
#ifndef __ASSEMBLY__
#ifdef CONFIG_ARCH_OMAP2PLUS
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 5f9086c..8c4500f 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -191,6 +191,10 @@ static void __init omap3_check_features(void)
if (!cpu_is_omap3505() !cpu_is_omap3517())
omap3_features |= OMAP3_HAS_IO_WAKEUP;
+ status = (OMAP3_SKUID_MASK read_tap_reg(OMAP3_PRODID));
+ if (status OMAP3_SKUID_720MHZ)
+ omap3_features |= OMAP3_HAS_720MHZ;
+
/*
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
@@ -445,6 +449,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(neon);
OMAP3_SHOW_FEATURE(isp);
OMAP3_SHOW_FEATURE(192mhz_clk);
+ OMAP3_SHOW_FEATURE(720mhz);
printk()\n);
}
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c
b/arch/arm/mach-omap2/opp3xxx_data.c
index 0486fce..cba17f7 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -17,8 +17,10 @@
* GNU General Public License for more details.
*/
#include linux/module.h
+#include linux/opp.h
#include plat/cpu.h
+#include plat/omap_device.h
#include omap_opp_data.h
@@ -33,6 +35,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(mpu, true, 55000, 127),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, 135),
+ /* MPU OPP6 */
+ OPP_INITIALIZER(mpu, false, 72000, 135),
/*
* L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -58,6 +62,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[]
= {
OPP_INITIALIZER(iva, true, 4, 127),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, 135),
+ /* DSP OPP6 */
+ OPP_INITIALIZER(iva, false, 52000, 135),
};
static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
@@ -85,6 +91,57 @@ static struct omap_opp_def __initdata
omap36xx_opp_def_list[] = {
OPP_INITIALIZER(iva, false, 8, 1375000),
};
+
+/**
+ * omap3_opp_enable_720Mhz() - Enable the OPP corresponding to 720MHz
+ *
+ * This function would be executed only if the silicon is capable of
+ * running at the 720MHz.
+ */
+static int __init omap3_opp_enable_720Mhz(void)
+{
+ int r = -ENODEV;
+ struct omap_hwmod *oh_mpu = omap_hwmod_lookup(mpu);
+ struct omap_hwmod *oh_iva;
+ struct platform_device *pdev;
+
+ if (!oh_mpu || !oh_mpu-od) {
+ goto err;
+ } else {
+ pdev = oh_mpu-od-pdev;
+
+ r = opp_enable(pdev-dev, 72000);
+ if (r 0) {
+
RE: [PATCH] omap3: Add basic support for 720MHz part
-Original Message- From: G, Manjunath Kondaiah [mailto:manj...@ti.com] Sent: Thursday, January 20, 2011 4:51 PM To: Premi, Sanjeev Cc: Varadarajan, Charulatha; linux-omap@vger.kernel.org Subject: Re: [PATCH] omap3: Add basic support for 720MHz part [snip] Looks fine. Feel free to add after the above changes: Reviewed-by: G, Manjunath Kondaiah manj...@ti.com Sorry, noticed this mail after sending the patch from linux box :( -Manjunath -- 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: [PATCHv2] OMAP: Enable Magic SysRq on serial console ttyOx
On Wed, Jan 19, 2011 at 07:28:20PM +0530, Govindraj wrote:
On Wed, Jan 19, 2011 at 7:01 PM, Thomas Weber we...@corscience.de wrote:
Am 19.01.2011 14:00, schrieb G, Manjunath Kondaiah:
On Wed, Jan 19, 2011 at 03:01:39PM +0530, Govindraj wrote:
On Wed, Jan 19, 2011 at 2:11 PM, Thomas Weber we...@corscience.de wrote:
Magic SysRq key is not working for OMAP on new serial
console ttyOx because SUPPORT_SYSRQ is not defined
for omap-serial.
This patch defines SUPPORT_SYSRQ in omap-serial and
enables handling of Magic SysRq character.
Signed-off-by: Thomas Weber we...@corscience.de
Looks fine to me.
Acked-by: Govindraj.R govindraj.r...@ti.com
I tried to use SysRq key on minicom after applying this patch, it looks
like it is not triggering sysrq event.
Am I missing anything?
-Manjunath
--
Hello Manjunath,
Do you have CONFIG_MAGIC_SYSRQ enabled?
Magic SysRq key in Kernel Hacking
I tested it on Devkit8000 (beagle board clone).
re-setting lsr_break_flag to 0 in receive chars is causing issues
in getting sysrq key break sequence on omap-serial.c
Manju,
can you try this change on your environment.
With below change works for me on 3430SDP/4430SDP.
key sequence I checked.
[alt + b + t] = shows trace of tasks running.
[alt + b + b] = system reboot.
With below patch, it works fine on TeraTerm. However, I am not able to
perform the same on minicom.
Tested-by: Manjunath G Kondaiah manj...@ti.com
-Manjunath
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 1201eff..6df623e 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -20,6 +20,10 @@
* this driver as required for the omap-platform.
*/
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include linux/module.h
#include linux/init.h
#include linux/console.h
@@ -190,7 +194,6 @@ static inline void receive_chars(struct
uart_omap_port *up, int *status)
if (up-port.line == up-port.cons-index) {
/* Recover the break flag from console xmit */
lsr |= up-lsr_break_flag;
- up-lsr_break_flag = 0;
}
#endif
if (lsr UART_LSR_BI)
--
Thanks,
Govindraj.R
--
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: [PATCHv2] OMAP: Enable Magic SysRq on serial console ttyOx
Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Signed-off-by: Thomas Weber we...@corscience.de Looks fine to me. Acked-by: Govindraj.R govindraj.r...@ti.com I tried to use SysRq key on minicom after applying this patch, it looks like it is not triggering sysrq event. Am I missing anything? -Manjunath -- Hello Manjunath, Do you have CONFIG_MAGIC_SYSRQ enabled? Magic SysRq key in Kernel Hacking I tested it on Devkit8000 (beagle board clone). re-setting lsr_break_flag to 0 in receive chars is causing issues in getting sysrq key break sequence on omap-serial.c Manju, can you try this change on your environment. With below change works for me on 3430SDP/4430SDP. key sequence I checked. [alt + b + t] = shows trace of tasks running. [alt + b + b] = system reboot. With below patch, it works fine on TeraTerm. However, I am not able to perform the same on minicom. Tested-by: Manjunath G Kondaiah manj...@ti.com -Manjunath Not sure what you guys are trying out, but I am able to use sysrq just fine in minicom (using only Thomas' original patch) - you need to send a break sequence, and the way to do this in minicom is to do Ctrl-A followed by F. Works for me, without the resetting lsr_break_flag to 0 part. @Govind, What are the issues you see in getting sysrq key break sequence without your change? And how is your change fixing this? - Anand -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: oprofile: Always allow backtraces
Hello. On 19-01-2011 23:54, Ari Kauppi wrote: Always allow backtrace when using oprofile on ARM, even if a PMU isn't present. Restores functionality originally introduced in 1b7b56982fdcd9d85effd76f3928cf5d6eb26155 by Richard Purdie. You're lacking the commit summary specified in parens which Linus asked to add. Signed-off-by: Ari Kauppikau...@papupata.org Cc: Richard Purdierpur...@rpsys.net Cc: Will Deaconwill.dea...@arm.com Cc: Matt Flemingm...@console-pimps.org WBR, Sergei -- 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] OMAP3: PM: Adding T2 enabling of smartreflex
On Wed, Jan 19, 2011 at 5:54 PM, Nishanth Menon n...@ti.com wrote: Gulati, Shweta wrote, on 01/19/2011 02:10 PM: I cant see how disable_sr is usable, further as discussed in http://marc.info/?l=linux-omapm=129424774929498w=2 http://marc.info/?l=linux-omapm=129424774929498w=2 we decided to introduce api *if needed*. does any one need it? There might be some OMAP3xxx chips where for DVFS VMODE or VSEL method is used, for those boards this disable API could be called from Board File, to make sure the sequence of execution of late_init_call of twl_init from omap2_common_pm_late_init does not hamper clearing of this bit I would add a global variable to keep track if Resetting is required or not, will submit V2 with changes. Apologies, but a Dumb question: late_initcall(omap2_common_pm_late_init) board files(arch/arm/include/asm/mach/arch.h machine_desc) tend to have the following hooks: void (*fixup)(struct machine_desc *, struct tag *, char **, struct meminfo *); void (*reserve)(void);/* reserve mem blocks */ void (*map_io)(void);/* IO mapping function */ void (*init_early)(void); void (*init_irq)(void); struct sys_timer *timer; /* system tick timer */ void (*init_machine (void); void (*handle_irq)(struct pt_regs *); So if i wanted to disable the SR setting, where should I do it? -- Regards, Nishanth Menon Nishanth, I think i could not make my point clear in my previous reply. There are two APIs added 'omap3_twl_disable_sr' and 'omap3_twl_enable_sr'. omap3_twl_enable_sr sets SR bit in TWL4030 registers to make sure VPforceupdate method of voltage scaling works properly but there could be some OMAP3xxx chips where VMODE or VSEL method of voltage scaling is used (though today these voltage scaling methods are not recommended by HW folks). For the boards where Vpforceupdate method is used this 'omap3_twl_disable_sr' would not be called. For possible case of platforms where VMODE or VSEL methods are used the API 'omap3_twl_disable_sr' will reset this bit. The API 'omap3_twl_disable_sr' can be called from board file, to make sure the resetting of this bit is not overwritten in late_init call of omap3_twl_init(where 'omap3_twl_enable_sr' is called) I suggested adding a global flag which will keep track whether this bit is cleared from board file or not. Would make these changes in V2. Regards, Shweta PS: could you please fix your mailer when replying on l-o for netetiquette reasons? -- Thanks, Regards, Shweta -- 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] OMAP: use fncpy to copy the PM code functions to SRAM
On Wed, Jan 19, 2011 at 11:10 PM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@ti.com [110119 13:37]: Kevin Hilman khil...@ti.com writes: jean.pi...@newoldbits.com writes: From: Jean Pihet j-pi...@ti.com The new fncpy API is better suited for copying some code to SRAM at runtime. This patch changes the ad-hoc code to the more generic fncpy API. Tested OK on OMAP3 in low power modes (RET/OFF) using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL. Compile tested on OMAP1/2 using omap1_defconfig. Signed-off-by: Jean Pihet j-pi...@ti.com Acked-by: Kevin Hilman khil...@ti.com Boot tested on OMAP1 OMAP2 as well. Note that neither OMAP1 or OMAP2 has had working suspend/resume for a long time now, so I did not test suspend/resume. For OMAP2: Tested-by: Kevin Hilman khil...@ti.com to test a little more on OMAP2, I just removed the WFI from the low-level code and tested suspend that way. That's enough to be sure the copied code is copied and executed. Worked fine on OMAP2420/n810. For OMAP1, this didn't work and would require more serious hacking on the OMAP1 suspend path, which I currently have no plans to do. Boots fine on osk5912 and n800 too: Tested-by: Tony Lindgren t...@atomide.com Thanks for testing! Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: omap-mcbsp: Fix building after replacement
Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in
commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95.
omap: Start using CONFIG_SOC_OMAP
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.
Search and replace the following:
ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430
Signed-off-by: Thomas Weber we...@corscience.de
---
sound/soc/omap/omap-mcbsp.c |1 +
sound/soc/omap/omap-mcbsp.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 3cc293b..ede6afd 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -113,6 +113,7 @@ static const int omap44xx_dma_reqs[][2] = {
static const int omap44xx_dma_reqs[][2] = {};
#endif
+#if defined(CONFIG_SOC_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index b7b0ce1..37dc721 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -54,6 +54,7 @@ enum omap_mcbsp_div {
#undef NUM_LINKS
#define NUM_LINKS 4
#endif
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_OMAP2430)
#undef NUM_LINKS
#define NUM_LINKS 5
#endif
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap2: fix DPLL_FREQSEL calculation
On 2011-01-20, Felipe Balbi ba...@ti.com wrote:
scripts/get_maintainer.pl would've helped you getting a better Cc
list. I'm adding linux-omap and lakml
Thanks.
After investigating the issue further it seems that I had it
backwards. The value of n is the value to divide by, not the value
that goes in the register. This means that it is _dpll_test_fint()
that is doing it incorrectly. Here is a new version of the patch to
fix the right function.
This patch fixes the calculation of the internal frequency. The value
of n is the actual divider to use.
This patch is against linux-next-20110120.
Signed-off-by: John Ogness john.ogn...@linutronix.de
---
arch/arm/mach-omap2/clkt_dpll.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 337392c..acb7ae5 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -77,7 +77,7 @@ static int _dpll_test_fint(struct clk *clk, u8 n)
dd = clk-dpll_data;
/* DPLL divider must result in a valid jitter correction val */
- fint = clk-parent-rate / (n + 1);
+ fint = clk-parent-rate / n;
if (fint DPLL_FINT_BAND1_MIN) {
pr_debug(rejecting n=%d due to Fint failure,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap-mcbsp: Fix building after replacement
On Thu, Jan 20, 2011 at 7:42 PM, Thomas Weber we...@corscience.de wrote:
Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in
commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95.
omap: Start using CONFIG_SOC_OMAP
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.
Search and replace the following:
ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430
I was just about to post a patch for this, but you beat me
to it!
Signed-off-by: Thomas Weber we...@corscience.de
Acked-by: Sourav Poddar sourav.pod...@ti.com
---
sound/soc/omap/omap-mcbsp.c | 1 +
sound/soc/omap/omap-mcbsp.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 3cc293b..ede6afd 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -113,6 +113,7 @@ static const int omap44xx_dma_reqs[][2] = {
static const int omap44xx_dma_reqs[][2] = {};
#endif
+#if defined(CONFIG_SOC_OMAP2420)
static const unsigned long omap2420_mcbsp_port[][2] = {
{ OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index b7b0ce1..37dc721 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -54,6 +54,7 @@ enum omap_mcbsp_div {
#undef NUM_LINKS
#define NUM_LINKS 4
#endif
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_OMAP2430)
#undef NUM_LINKS
#define NUM_LINKS 5
#endif
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
On 01/20/2011 03:42 AM, Santosh Shilimkar wrote: On some architectures, secondary cores shares clock with primiary core and hence scale together. Hence secondary core lpj calibration is not necessary and can be skipped to save considerable time. This can speed up the secondary cpu boot and hotplug cpu online paths. Discussion thread: http://www.spinics.net/lists/arm-kernel/msg24.html There's already one way to do this with pre-calculated lpj. Also, this isn't multi-platform friendly. You could accomplish the same thing using the clock api to get the core frequency of each core and only calculate lpj if the frequency is different. Rob -- 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] omap3: nand: bch ecc support added
Hi Ghorai,
I am the initial author of this patch. And I guess this patch still
uses most of my work.
Thanks and Regards,
Vimal
On Thu, Jan 20, 2011 at 3:48 PM, Sukumar Ghorai s-gho...@ti.com wrote:
bch error correction (t=4 and t=8) for 512 bytes support added.
Tested in omap-3630 es-1.1 silicon.
Need to select the bch-ecc from board file. E.g.
arch/arm/mach-omap2/board-flash.c: board_nand_init()
board_nand_data.ecc_opt = OMAP_ECC_BCH4_CODE_HW
This patch has dependency on -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42658.html
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 126 ---
arch/arm/plat-omap/include/plat/gpmc.h | 6 +-
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/omap2.c | 119 --
drivers/mtd/nand/omap_bch_decoder.c | 393
5 files changed, 583 insertions(+), 62 deletions(-)
create mode 100644 drivers/mtd/nand/omap_bch_decoder.c
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 29c9732..91cfdca 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -48,6 +48,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT 0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET 0x60
#define GPMC_CS_SIZE 0x30
@@ -94,7 +95,6 @@ static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are initialized
*/
-static int gpmc_ecc_used = -EINVAL; /* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -832,52 +832,77 @@ void omap3_gpmc_restore_context(void)
/**
* gpmc_enable_hwecc - enable hardware ecc functionality
+ * @ecc_type: ecc type e.g. Hamming, BCH
* @cs: chip select number
* @mode: read/write mode
* @dev_width: device bus width(1 for x16, 0 for x8)
* @ecc_size: bytes for which ECC will be generated
*/
-int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
+int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
+ int dev_width, int ecc_size)
{
- unsigned int val;
-
- /* check if ecc module is in used */
- if (gpmc_ecc_used != -EINVAL)
- return -EINVAL;
-
- gpmc_ecc_used = cs;
-
- /* clear ecc and enable bits */
- val = ((0x00018) | 0x0001);
- gpmc_write_reg(GPMC_ECC_CONTROL, val);
-
- /* program ecc and result sizes */
- val = ecc_size 1) - 1) 22) | (0x000F));
- gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+ unsigned int bch_mod = 0, bch_wrapmode = 0, eccsize1 = 0, eccsize0 =
0;
+ unsigned int ecc_conf_val = 0, ecc_size_conf_val = 0;
switch (mode) {
case GPMC_ECC_READ:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0xD; eccsize0 = 0x48;
+ bch_mod = 0;
+ bch_wrapmode = 0x09;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x1A; eccsize0 = 0x18;
+ bch_mod = 1;
+ bch_wrapmode = 0x04;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
case GPMC_ECC_READSYN:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
break;
+
case GPMC_ECC_WRITE:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 0;
+ bch_wrapmode = 0x06;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 1;
+ bch_wrapmode = 0x06;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
default:
printk(KERN_INFO Error: Unrecognized Mode[%d]!\n, mode);
break;
}
- /* (ECC 16 or 8 bit col) | ( CS ) | ECC Enable */
- val = (dev_width 7) | (cs 1) | (0x1);
- gpmc_write_reg(GPMC_ECC_CONFIG, val);
+ /* clear ecc and enable bits */
+ if ((ecc_type == OMAP_ECC_BCH4_CODE_HW) ||
+ (ecc_type == OMAP_ECC_BCH8_CODE_HW)) {
+ gpmc_write_reg(GPMC_ECC_CONTROL, 0x0001);
+ ecc_size_conf_val = (eccsize1 22) | (eccsize0 12);
+ ecc_conf_val = ((0x01 16) | (bch_mod 12)
+ | (bch_wrapmode 8) | (dev_width 7)
+
[QUERY] [AUDIO][OMAP3 EVM] arecord not working on OMAP3 EVM
Hi all While testing audio capture (using arecord e,g.),I'm getting only noise in the (zeroed out) output buffers on the OMAP3 EVM. I have enabled AUXL and AUXR mic inputs through alsamixer, which according to the schematics are connected to the Audio In connector on the board, even though the TWL4030 reg list does not allow me any ways ( or so I think) to specify mic-bias for these aux inputs. With AUXL and AUXR muted - I get only silence, which seems to make sense. Is there any basic startup setting I'm missing, maybe specific to OMAP3 EVM? Has anyone seen anything like this before, and could provide pointers? I'm running a kernel based on 2.6.37-rc7 and audio playback is working fine for me. Thanks in advance Abhilash -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
-Original Message- From: Rob Herring [mailto:robherri...@gmail.com] Sent: Thursday, January 20, 2011 8:44 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux- o...@vger.kernel.org; Linus Walleij Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot On 01/20/2011 03:42 AM, Santosh Shilimkar wrote: On some architectures, secondary cores shares clock with primiary core and hence scale together. Hence secondary core lpj calibration is not necessary and can be skipped to save considerable time. This can speed up the secondary cpu boot and hotplug cpu online paths. Discussion thread: http://www.spinics.net/lists/arm-kernel/msg24.html There's already one way to do this with pre-calculated lpj. How about the hot-plug path? This is not for just boot. Also, this isn't multi-platform friendly. You could accomplish the same thing using the clock api to get the core frequency of each core and only calculate lpj if the frequency is different. May be but what's wrong with the obvious approach which is completely non-intrusive. Why is not multi-platform friendly ? Archs can choose not to select this option. 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
[PATCHv5] OMAP3: Devkit8000: Change lcd power pin
This patch fixes a wrongly used lcd enable pin.
The Devkit8000 uses twl4030_ledA configured as output gpio only for
the lcd enable line. twl4030_gpio.1 is used through the generic
gpio functions while ledA is used via low level twl4030 calls.
This patch removes the low level calls and use the generic gpio functions
for initialization and use of ledA. This patch also fixes a bug where the
lcd would not power down when blanking.
Further this patch fixes an indentation issue. The comment line uses
eight whitespace and is replaced with a hard tab.
gpio_request + gpio_direction_output are replaced with gpio_request_one.
The return value of gpio_request_one is used to set the value of the
gpio to -EINVAL when unsuccessful, so that gpio_is_valid can detect the
unsuccessful request. But already successful requested gpios are not freed.
Reported-by: Daniel Morsing daniel.mors...@gmail.com
Signed-off-by: Thomas Weber we...@corscience.de
---
Changes from v4:
Merge of two patches
Use of gpio_request_one instead of gpio_request + gpio_direction_output
Changes from v3:
Use return value of gpio_request
Changes from v2:
Fix indention = indentation
Better comment for removing low level functions used for twl4030 gpio
Changes from v1:
Pull the indentation fix into this patch
Change the pin for lcd pwren
arch/arm/mach-omap2/board-devkit8000.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index a5eb955..e4c12fe 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -115,9 +115,6 @@ static struct omap2_hsmmc_info mmc[] = {
static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
{
- twl_i2c_write_u8(TWL4030_MODULE_GPIO, 0x80, REG_GPIODATADIR1);
- twl_i2c_write_u8(TWL4030_MODULE_LED, 0x0, 0x0);
-
if (gpio_is_valid(dssdev-reset_gpio))
gpio_set_value_cansleep(dssdev-reset_gpio, 1);
return 0;
@@ -247,6 +244,8 @@ static struct gpio_led gpio_leds[];
static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int ret;
+
omap_mux_init_gpio(29, OMAP_PIN_INPUT);
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
@@ -255,17 +254,23 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
-/* gpio + 1 is LCD_PWREN (out, active high) */
- devkit8000_lcd_device.reset_gpio = gpio + 1;
- gpio_request(devkit8000_lcd_device.reset_gpio, LCD_PWREN);
- /* Disable until needed */
- gpio_direction_output(devkit8000_lcd_device.reset_gpio, 0);
+ /* TWL4030_GPIO_MAX + 0 is LCD_PWREN (out, active high) */
+ devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
+ ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
+ GPIOF_DIR_OUT | GPIOF_INIT_LOW, LCD_PWREN);
+ if (ret 0) {
+ devkit8000_lcd_device.reset_gpio = -EINVAL;
+ printk(KERN_ERR Failed to request GPIO for LCD_PWRN\n);
+ }
/* gpio + 7 is DVI_PD (out, active low) */
devkit8000_dvi_device.reset_gpio = gpio + 7;
- gpio_request(devkit8000_dvi_device.reset_gpio, DVI PowerDown);
- /* Disable until needed */
- gpio_direction_output(devkit8000_dvi_device.reset_gpio, 0);
+ ret = gpio_request_one(devkit8000_dvi_device.reset_gpio,
+ GPIOF_DIR_OUT | GPIOF_INIT_LOW, DVI PowerDown);
+ if (ret 0) {
+ devkit8000_dvi_device.reset_gpio = -EINVAL;
+ printk(KERN_ERR Failed to request GPIO for DVI PowerDown\n);
+ }
return 0;
}
--
1.7.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
2011/1/20 Rob Herring robherri...@gmail.com:
On 01/20/2011 03:42 AM, Santosh Shilimkar wrote:
On some architectures, secondary cores shares clock with primiary
core and hence scale together. Hence secondary core lpj calibration
is not necessary and can be skipped to save considerable time.
This can speed up the secondary cpu boot and hotplug cpu online
paths.
Discussion thread:
http://www.spinics.net/lists/arm-kernel/msg24.html
There's already one way to do this with pre-calculated lpj.
Also, this isn't multi-platform friendly.
It can be made to be, then -
skip all Kconfig business (more elegant like this anyway):
static inline int skip_secondary_calibrate(void)
{
return machine_is_u8500() ||
machine_is_svp8500v1() ||
machine_is_svp8500v2() ||
machine_is_svp5500() ||
machine_is_b5500() ||
machine_is_s5500() ||
machine_is_omap4_panda();
}
Hm if this multi-platform stuff is desirable we probably need
a runtime arch_is_omap4(), arch_is_u8500() etc so this machine
list doesn't grow ridiculously long, but ftm this will work.
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
2.6.38-rc1-git1 musb undefined references
Cross compiling for Beagleboard on Ubuntu 11.04 x86_64. # make-kpkg --revision=0 --append-to-version=-custom --arch=armel --cross-compile=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- kernel-image --initrd == making target debian/stamp/build/kernel [new prereqs: vars]== This is kernel package version 12.036+nmu1. restore_upstream_debianization test ! -f scripts/package/builddeb.kpkg-dist || mv -f scripts/package/builddeb.kpkg-dist scripts/package/builddeb test ! -f scripts/package/Makefile.kpkg-dist || mv -f scripts/package/Makefile.kpkg-dist scripts/package/Makefile /usr/bin/make EXTRAVERSION=-rc1-git1-custom ARCH=arm \ CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- zImage make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' scripts/kconfig/conf --silentoldconfig Kconfig make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' CHK include/linux/version.h CHK include/generated/utsrelease.h make[2]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h LD fs/built-in.o LD lib/zlib_deflate/built-in.o LD lib/built-in.o LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 3 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `musb_free': clkdev.c:(.text+0xf3d08): undefined reference to `dma_controller_destroy' drivers/built-in.o: In function `musb_probe': clkdev.c:(.init.text+0x64a8): undefined reference to `dma_controller_create' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make: *** [debian/stamp/build/kernel] Error 2 root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep OMAP2PLUS .config CONFIG_ARCH_OMAP2PLUS=y CONFIG_ARCH_OMAP2PLUS_TYPICAL=y # CONFIG_USB_MUSB_OMAP2PLUS is not set root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep MUSB .config CONFIG_USB_MUSB_HDRC=y # CONFIG_USB_MUSB_TUSB6010 is not set # CONFIG_USB_MUSB_OMAP2PLUS is not set CONFIG_USB_MUSB_AM35X=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_PERIPHERAL is not set CONFIG_USB_MUSB_OTG=y CONFIG_USB_GADGET_MUSB_HDRC=y CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set # CONFIG_USB_MUSB_DEBUG is not set Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot
On 01/20/2011 09:36 AM, Santosh Shilimkar wrote: -Original Message- From: Rob Herring [mailto:robherri...@gmail.com] Sent: Thursday, January 20, 2011 8:44 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux- o...@vger.kernel.org; Linus Walleij Subject: Re: [PATCH] ARM: smp: Introduce ARCH_HAS_COMMON_CORES_CLOCK to speed-up boot On 01/20/2011 03:42 AM, Santosh Shilimkar wrote: On some architectures, secondary cores shares clock with primiary core and hence scale together. Hence secondary core lpj calibration is not necessary and can be skipped to save considerable time. This can speed up the secondary cpu boot and hotplug cpu online paths. Discussion thread: http://www.spinics.net/lists/arm-kernel/msg24.html There's already one way to do this with pre-calculated lpj. How about the hot-plug path? This is not for just boot. The path is the same for hotplug and secondary boot, so yes for both. Plus you get the added benefit of speeding up the primary core boot as well. Also, this isn't multi-platform friendly. You could accomplish the same thing using the clock api to get the core frequency of each core and only calculate lpj if the frequency is different. May be but what's wrong with the obvious approach which is completely non-intrusive. Why is not multi-platform friendly ? Archs can choose not to select this option. I meant you can't have single kernel binary with a platform with single core freq and a platform with independent core freq. Looking at this some more, the only reason to call calibrate_delay is to get a more accurate value. If you have different frequencies per core, you've got bigger problems as loops_per_jiffy value is not per core. So your kconfig option name is misleading. Something like ARCH_WANT_UDELAY_RECALC would be more accurate. To get a more accurate calculation, calibrate_delay only needs to be called by 1 secondary core. Perhaps it could be called from somewhere that is not in the boot/hotplug path or only done once. Rob 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
Merging xloader, bootloader and boot environment variables partitions into a single partition on NAND
Hi, I was wondering what the merits and demerits are of having a single integrated xloader+bootloader+boot environment variables in a single partition in NAND, as opposed to having multiple partitions that hold xloader, bootloader and the uboot environment in separate partitions? Elvis Dowson -- 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
NAND flash update via serial debug console
Hi, Is it possible to flash NAND via the serial debug console for OMAP35xx devices? Elvis Dowson -- 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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
* Felipe Balbi ba...@ti.com [110119 20:07]: On Wed, Jan 19, 2011 at 03:04:13PM -0500, Ben Gamari wrote: On Wed, 19 Jan 2011 05:45:28 +0200, Felipe Balbi ba...@ti.com wrote: The point is, being able to disable features I don't want on my kernel image, is completely valid, if there's a compile breakage, then fix the breakage but don't prevent the board from compiling. I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another I never mentioned defconfigs here. means of selecting the basic drivers necessary to get a fully functional board? Perhaps a CONFIG_MACH_OMAP3_BEAGLE_CORE option selecting the necessary driver for a fully functional board would be a solution. I I'll leave this for Tony to decide, but I don't like your proposal. remember this being discussed several months ago (when Linus started pulling defconfigs out of the tree), but I don't recall there being any replacement proposals. It should be possible to build a functional kernel from the mainline without iterating over all available configuration options. So you're saying that when you're building a kernel for you laptop/desktop you don't have to get a menuconfig and choose the drivers you want to compile ? I dare to doubt that. What we want to do in the long run is build a minimal kernel and make everything else loaded as modules from initramfs. In order to do that we need to cut down all the dependencies between core omap code and the drivers. So I'd stay away from selecting things for boards where possible. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] omap4: Add board_data and initialise the serial pads
Hi, * sricharan r.sricha...@ti.com [110118 07:11]: Pass the board specific serial pad mux data to the platform level init code. Signed-off-by: sricharan r.sricha...@ti.com --- This is a test patch and not intended for a specific use case. 1) The support to add the pad data to the device hwmod entry and to use it to dynamically configure the pads based on the state of the hwmod is already present. 2) But using that for pads that requires only initialisation and not dynamic remux, brings in a overhead to iterate over all the hwmod signals of the device for every device enable/idle transitions. The right fix for this problem is to change the mux code to keep a separate list for dynamic pads and static pads. That way all the static pads can be skipped, and the dynamic list is empty in most cases. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] omap4: hsmmc: Adding ADMA support
* Kishore Kadiyala kishore.kadiy...@ti.com [110118 09:19]: This patch series adds support for ADMA on MMC1 MMC2 controllers on OMAP4. There is no performance improvement observed using ADMA over SDMA. Advantage using ADMA could be reducing contention over SDMA. Also the series includes some cleanup. To me it seems that the only sane way to deal with multiple different DMA enginges is to implement them all with drivers/dma/dmaengine.c. Otherwise we'll end up with multiple custom ADMA implementations in each driver. We need to also make SDMA use the dmaengine code. If the current dmaengine code does not support this, we need to improve it to deal with cases like these. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap-mcbsp: Fix building after replacement
* Poddar, Sourav sourav.pod...@ti.com [110120 07:08]: On Thu, Jan 20, 2011 at 7:42 PM, Thomas Weber we...@corscience.de wrote: Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95. omap: Start using CONFIG_SOC_OMAP We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest are nowadays just subcategories of these. Search and replace the following: ARCH_OMAP2420 SOC_OMAP2420 ARCH_OMAP2430 SOC_OMAP2430 ARCH_OMAP3430 SOC_OMAP3430 I was just about to post a patch for this, but you beat me to it! Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Sourav Poddar sourav.pod...@ti.com Thanks, merging this into the original. Also adding applying into linux-omap master. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAND flash update via serial debug console
On 01/20/2011 10:21 AM, Elvis Dowson wrote: Hi, Is it possible to flash NAND via the serial debug console for OMAP35xx devices? If you have U-Boot running, you can download whatever you need via Y-Modem (loady command) and then update the NAND as needed. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] oprofile: ARM backtraces and few minors
This patchset re-enables ARM backtraces with non-PMU capable CPUs.
In V2 I have tried to address the comments received for the V1
patches. arch/sh/oprofile/common.c is untouched but should work
as earlier.
Compile tested with arm/omap2plus_defconfig (with and without
CONFIG_HW_PERF_EVENTS).
Ari Kauppi (3):
oprofile: Use CONFIG_HW_PERF_EVENTS for oprofile_perf_init and
friends
oprofile: Provide stubs for oprofile_perf_{init,exit}
ARM: oprofile: Always allow backtraces
arch/arm/oprofile/common.c | 12 ++--
include/linux/oprofile.h | 13 +++--
2 files changed, 13 insertions(+), 12 deletions(-)
--
1.7.4.rc2.3.g60a2e
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] oprofile: Use CONFIG_HW_PERF_EVENTS for oprofile_perf_init and friends
The implementations are flagged in Makefile with CONFIG_HW_PERF_EVENTS instead of CONFIG_PERF_EVENTS. Signed-off-by: Ari Kauppi kau...@papupata.org --- include/linux/oprofile.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h index 32fb812..54c8382 100644 --- a/include/linux/oprofile.h +++ b/include/linux/oprofile.h @@ -186,10 +186,10 @@ int oprofile_add_data(struct op_entry *entry, unsigned long val); int oprofile_add_data64(struct op_entry *entry, u64 val); int oprofile_write_commit(struct op_entry *entry); -#ifdef CONFIG_PERF_EVENTS +#ifdef CONFIG_HW_PERF_EVENTS int __init oprofile_perf_init(struct oprofile_operations *ops); void oprofile_perf_exit(void); char *op_name_from_perf_id(void); -#endif /* CONFIG_PERF_EVENTS */ +#endif /* CONFIG_HW_PERF_EVENTS */ #endif /* OPROFILE_H */ -- 1.7.4.rc2.3.g60a2e -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] oprofile: Provide stubs for oprofile_perf_{init,exit}
If CONFIG_HW_PERF_EVENTS is not defined, provide stubs for
oprofile_perf_init and oprofile_perf_exit. Allows cleaning of
architecture specific implementations.
Signed-off-by: Ari Kauppi kau...@papupata.org
---
include/linux/oprofile.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/linux/oprofile.h b/include/linux/oprofile.h
index 54c8382..1ca6411 100644
--- a/include/linux/oprofile.h
+++ b/include/linux/oprofile.h
@@ -16,6 +16,8 @@
#include linux/types.h
#include linux/spinlock.h
#include linux/init.h
+#include linux/errno.h
+#include linux/printk.h
#include asm/atomic.h
/* Each escaped entry is prefixed by ESCAPE_CODE
@@ -190,6 +192,13 @@ int oprofile_write_commit(struct op_entry *entry);
int __init oprofile_perf_init(struct oprofile_operations *ops);
void oprofile_perf_exit(void);
char *op_name_from_perf_id(void);
+#else
+static inline int __init oprofile_perf_init(struct oprofile_operations *ops)
+{
+ pr_info(oprofile: hardware counters not available\n);
+ return -ENODEV;
+}
+static inline void oprofile_perf_exit(void) { }
#endif /* CONFIG_HW_PERF_EVENTS */
#endif /* OPROFILE_H */
--
1.7.4.rc2.3.g60a2e
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] ARM: oprofile: Always allow backtraces
Always allow backtrace when using oprofile on ARM, even if a PMU
isn't present. Implemented by removing code and using stubs
provided by linux/oprofile.h.
Restores functionality originally introduced in commit
1b7b56982fdcd9d85effd76f3928cf5d6eb26155 (oprofile: Always allow
backtraces on ARM) by Richard Purdie.
Signed-off-by: Ari Kauppi kau...@papupata.org
---
arch/arm/oprofile/common.c | 12 ++--
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 8aa9744..2b66391 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -10,8 +10,6 @@
*/
#include linux/cpumask.h
-#include linux/err.h
-#include linux/errno.h
#include linux/init.h
#include linux/mutex.h
#include linux/oprofile.h
@@ -46,6 +44,7 @@ char *op_name_from_perf_id(void)
return NULL;
}
}
+#endif
static int report_trace(struct stackframe *frame, void *d)
{
@@ -111,6 +110,7 @@ static void arm_backtrace(struct pt_regs * const regs,
unsigned int depth)
int __init oprofile_arch_init(struct oprofile_operations *ops)
{
+ /* provide backtrace support also in timer mode: */
ops-backtrace = arm_backtrace;
return oprofile_perf_init(ops);
@@ -120,11 +120,3 @@ void __exit oprofile_arch_exit(void)
{
oprofile_perf_exit();
}
-#else
-int __init oprofile_arch_init(struct oprofile_operations *ops)
-{
- pr_info(oprofile: hardware counters not available\n);
- return -ENODEV;
-}
-void __exit oprofile_arch_exit(void) {}
-#endif /* CONFIG_HW_PERF_EVENTS */
--
1.7.4.rc2.3.g60a2e
--
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
[Query] mm: !*pte hit in mm/memory.c:remap_pte_range
Hi,
WARNING: Linux MM newbie here. Please bare with me a bit.
While debugging a new v4l2 driver that makes use of the OMAP4 Tiler allocators
in mmap calls, I found out that
remap_pfn_range was getting completely stalled.
And while debugging further, i realized that the point of stall was in
mm/memory.c, function:
static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
unsigned long addr, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
pte_t *pte;
spinlock_t *ptl;
pte = pte_alloc_map_lock(mm, pmd, addr, ptl);
if (!pte)
return -ENOMEM;
arch_enter_lazy_mmu_mode();
do {
BUG_ON(!pte_none(*pte)); ---*** HERE
set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
pfn++;
} while (pte++, addr += PAGE_SIZE, addr != end);
arch_leave_lazy_mmu_mode();
pte_unmap_unlock(pte - 1, ptl);
return 0;
}
This is in 2.6.35.6 kernel + TI Android kernel changes. [1]
How should i interpret this? Does this mean something specific?
Any pointers will be appreciated.
Regards,
Sergio
---
[1]
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-android-omap-2.6.35--
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
Fail to suspend to ram: Class driver suspend failed for cpu0
Hello, I have a beagle board with OMAP3530. I ported linux-omap-pm2.6.32 to this board. When I want to let it suspend to ram, it fails and I get the message Class driver suspend failed for cpu0. Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? Thanks. -- Luke -- 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] omap2-beagle: Depend upon CONFIG_GPIO_TWL4030
--text follows this line-- On Thu, 20 Jan 2011 06:08:25 +0200, Felipe Balbi ba...@ti.com wrote: On Wed, Jan 19, 2011 at 03:04:13PM -0500, Ben Gamari wrote: I understand. That being said, Linus has made it well known that defconfigs will not be an option going forward. Have we found another I never mentioned defconfigs here. Certainly, I was trying to point out that there is no good way to package a configuration for a given board, which definitely increases the learning curve for a board integrator. means of selecting the basic drivers necessary to get a fully functional board? Perhaps a CONFIG_MACH_OMAP3_BEAGLE_CORE option selecting the necessary driver for a fully functional board would be a solution. I I'll leave this for Tony to decide, but I don't like your proposal. Fair enough. So you're saying that when you're building a kernel for you laptop/desktop you don't have to get a menuconfig and choose the drivers you want to compile ? I dare to doubt that. On the whole x86 hardware is far more uniform than ARM hardware. There is a good reason why there used to be so many defconfigs for ARM in the tree. Cheers, - Ben -- 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 RFC] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Laurent,
On Wed, Jan 19, 2011 at 12:38:09AM +0100, Laurent Pinchart wrote:
Hi Martin,
Thanks for the patch.
On Tuesday 18 January 2011 23:32:16 Martin Hostettler wrote:
Adds board support for an MT9M032 based camera to omap3evm.
Sigend-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-omap3evm-camera.c | 177
2 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
Is there a special reason to add camera support to a separate file ?
No it's just that the other code i looked at did it in the same way. I don't
really know what's the best way to handle this board code...
Of course not all OMAP3 EVM systems will use an MT9M032 sensor, so some kind
of modularity (and if possible runtime configuration) will be needed.
My 0th version did have a Kconfig option, but i got advise (off-list) that i
should be doing it unconditionally and leave the design for compile or runtime
selection to the developer who adds code for another option.
[snip]
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
index 000..ea82a49
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,177 @@
[snip]
+/*
+ * Copyright (C) 2010-2011 Lund Engineering
+ * Contact: Gil Lund gwl...@lundeng.com
+ * Author: Martin Hostettler mar...@neutronstar.dyndns.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/i2c.h
+#include linux/init.h
+#include linux/platform_device.h
+
+#include asm/gpio.h
+#include plat/mux.h
+#include mux.h
+
+#include ../../../drivers/media/video/isp/isp.h
+#include ../../../drivers/media/video/mt9m032.h
mt9m032.h should be moved to include/media (the same is true for isp.h as
well, I'll probably split it and move the part required by board files to
include/media/omap3isp.h).
Ok, sounds sensible.
+#include devices.h
+
+#define EVM_TWL_GPIO_BASE OMAP_MAX_GPIO_LINES
+#define GPIO98_VID_DEC_RES 98
+#define nCAM_VD_SEL157
+
+#define MT9M032_I2C_BUS_NUM2
+
+
+enum omap3evmdc_mux {
+ MUX_TVP5146,
+ MUX_CAMERA_SENSOR,
+ MUX_EXP_CAMERA_SENSOR,
+};
+
+/**
+ * omap3evm_set_mux - Sets mux to enable signal routing to
+ * different peripherals present on new EVM
board + * @mux_id: enum, mux id to enable
+ *
+ * Returns 0 for success or a negative error code
+ */
+static int omap3evm_set_mux(enum omap3evmdc_mux mux_id)
+{
+ /* Set GPIO6 = 1 */
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 6, 1);
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+
+ switch (mux_id) {
+ case MUX_TVP5146:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 1);
+ break;
+
+ case MUX_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 0);
+ gpio_set_value(nCAM_VD_SEL, 0);
+ break;
+
+ case MUX_EXP_CAMERA_SENSOR:
+ gpio_set_value_cansleep(EVM_TWL_GPIO_BASE + 2, 1);
+ break;
+
+ default:
+ pr_err(omap3evm-camera: Invalid mux id #%d\n, mux_id);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int __init camera_init(void)
+{
+ omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
+ if (gpio_request(nCAM_VD_SEL, nCAM_VD_SEL) 0) {
+ pr_err(omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n,
+ nCAM_VD_SEL);
+ goto err;
You can return -EINVAL directly here. This removes the need for the 'err'
label.
I like to have all error handling work the same way. So one return for error
and one return for success. At least if it's as trivial as here.
+ }
+ if (gpio_direction_output(nCAM_VD_SEL, 1) 0) {
+ pr_err(omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
direction\n, +nCAM_VD_SEL);
+ goto err_vdsel;
+ }
+
+ if (gpio_request(EVM_TWL_GPIO_BASE + 2, T2_GPIO2) 0) {
+ pr_err(omap3evm-camera:
Re: Fail to suspend to ram: Class driver suspend failed for cpu0
Luke Gong lukejg...@gmail.com writes: I have a beagle board with OMAP3530. I ported linux-omap-pm2.6.32 to this board. When I want to let it suspend to ram, This is an old kernel. Any reason you're not using a newer kernel? it fails and I get the message Class driver suspend failed for cpu0 This is the CPUfreq driver failing to suspend, probably because there is no CPUfreq driver implemented in your kernel. Try disabling CPU_FREQ in your kernel config. Kevin . Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? 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: Fail to suspend to ram: Class driver suspend failed for cpu0
Thanks, Kevin. On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman khil...@ti.com wrote: Luke Gong lukejg...@gmail.com writes: I have a beagle board with OMAP3530. I ported linux-omap-pm2.6.32 to this board. When I want to let it suspend to ram, This is an old kernel. Any reason you're not using a newer kernel? I have Angstrom7 with kernel 2.6.32 running on this board. So I selected this old version to test. I might try the latest one. it fails and I get the message Class driver suspend failed for cpu0 This is the CPUfreq driver failing to suspend, probably because there is no CPUfreq driver implemented in your kernel. Try disabling CPU_FREQ in your kernel config. It seems can suspend to ram after disabling CPU_FREQ. Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) * Once I hit the keyboard, I get: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (cam_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend Restarting tasks ... done. root@beagleboard:~# *** I am just curious why the powerdomain didn't enter target state 1. Another issue is about CPU frequency scaling. Using the original Angstrom7, I can scale CPU frequency. But with the linux-omap-pm kernel, I cannot do it even though I enable this feature in the config file. Is there any solution to support both cpu frequency scaling and suspend to ram? Thanks again for your help. Kevin . Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? Thanks. -- Luke -- 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] omap2: fix DPLL_FREQSEL calculation
On Thu, Jan 20, 2011 at 03:29:50PM +0100, John Ogness wrote: On 2011-01-20, Felipe Balbi ba...@ti.com wrote: scripts/get_maintainer.pl would've helped you getting a better Cc list. I'm adding linux-omap and lakml Thanks. After investigating the issue further it seems that I had it backwards. The value of n is the value to divide by, not the value that goes in the register. This means that it is _dpll_test_fint() that is doing it incorrectly. Here is a new version of the patch to fix the right function. you might want to look at Documentation/SubmittingPatches before sending these patches. If anyone applies this patch of yours the commitlog will have all the comments you've made above. Generally, patches are standalone emails, without a discussion on them, if you want to add comments which aren't supposed to go into commit log, then do so after the tear line (---) and before the diff --git line; that way, git will know it must drop that part of the comments. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.38-rc1-git1 musb undefined references
Hi, (please, keep also linux-usb@vger on the Cc list on any patch regarding drivers/usb) On Thu, Jan 20, 2011 at 04:22:01PM +, Sid Boyce wrote: Cross compiling for Beagleboard on Ubuntu 11.04 x86_64. # make-kpkg --revision=0 --append-to-version=-custom --arch=armel --cross-compile=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- kernel-image --initrd == making target debian/stamp/build/kernel [new prereqs: vars]== This is kernel package version 12.036+nmu1. restore_upstream_debianization test ! -f scripts/package/builddeb.kpkg-dist || mv -f scripts/package/builddeb.kpkg-dist scripts/package/builddeb test ! -f scripts/package/Makefile.kpkg-dist || mv -f scripts/package/Makefile.kpkg-dist scripts/package/Makefile /usr/bin/make EXTRAVERSION=-rc1-git1-custom ARCH=arm \ CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- zImage make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' scripts/kconfig/conf --silentoldconfig Kconfig make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' CHK include/linux/version.h CHK include/generated/utsrelease.h make[2]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h LD fs/built-in.o LD lib/zlib_deflate/built-in.o LD lib/built-in.o LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 3 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `musb_free': clkdev.c:(.text+0xf3d08): undefined reference to `dma_controller_destroy' drivers/built-in.o: In function `musb_probe': clkdev.c:(.init.text+0x64a8): undefined reference to `dma_controller_create' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make: *** [debian/stamp/build/kernel] Error 2 root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# I just compiled 2.6.38-rc1 and it doesn't fail for me. root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep OMAP2PLUS .config CONFIG_ARCH_OMAP2PLUS=y CONFIG_ARCH_OMAP2PLUS_TYPICAL=y # CONFIG_USB_MUSB_OMAP2PLUS is not set root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep MUSB .config CONFIG_USB_MUSB_HDRC=y # CONFIG_USB_MUSB_TUSB6010 is not set # CONFIG_USB_MUSB_OMAP2PLUS is not set CONFIG_USB_MUSB_AM35X=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_PERIPHERAL is not set CONFIG_USB_MUSB_OTG=y CONFIG_USB_GADGET_MUSB_HDRC=y CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set # CONFIG_USB_MUSB_DEBUG is not set There's a bug on your .config, did you edit by hand ? AM35X doesn't have DMA support as of today, that's why we have: config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X did you disable PIO only ? I know that's a bit fuzzy still, a few patches will be needed to clean up the entire MUSB Kconfig, I apologize for that. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: nand: bch ecc support added
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Thursday, January 20, 2011 8:47 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org; Kamat, Nishant
Subject: Re: [PATCH] omap3: nand: bch ecc support added
Hi Ghorai,
I am the initial author of this patch. And I guess this patch still
uses most of my work.
[Ghorai] I know you are working on it,
But I think your code was in a shape for -
1. not for up-streamble shape
2. non functional,
So can you check this version matching with your original code?
In that case I can add your Signed-off.
Thanks and Regards,
Vimal
On Thu, Jan 20, 2011 at 3:48 PM, Sukumar Ghorai s-gho...@ti.com wrote:
bch error correction (t=4 and t=8) for 512 bytes support added.
Tested in omap-3630 es-1.1 silicon.
Need to select the bch-ecc from board file. E.g.
arch/arm/mach-omap2/board-flash.c: board_nand_init()
board_nand_data.ecc_opt = OMAP_ECC_BCH4_CODE_HW
This patch has dependency on -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42658.html
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 126 ---
arch/arm/plat-omap/include/plat/gpmc.h |6 +-
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/omap2.c | 119 --
drivers/mtd/nand/omap_bch_decoder.c| 393
5 files changed, 583 insertions(+), 62 deletions(-)
create mode 100644 drivers/mtd/nand/omap_bch_decoder.c
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 29c9732..91cfdca 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -48,6 +48,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -94,7 +95,6 @@ static struct resourcegpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are
initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -832,52 +832,77 @@ void omap3_gpmc_restore_context(void)
/**
* gpmc_enable_hwecc - enable hardware ecc functionality
+ * @ecc_type: ecc type e.g. Hamming, BCH
* @cs: chip select number
* @mode: read/write mode
* @dev_width: device bus width(1 for x16, 0 for x8)
* @ecc_size: bytes for which ECC will be generated
*/
-int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
+int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
+ int dev_width, int ecc_size)
{
- unsigned int val;
-
- /* check if ecc module is in used */
- if (gpmc_ecc_used != -EINVAL)
- return -EINVAL;
-
- gpmc_ecc_used = cs;
-
- /* clear ecc and enable bits */
- val = ((0x00018) | 0x0001);
- gpmc_write_reg(GPMC_ECC_CONTROL, val);
-
- /* program ecc and result sizes */
- val = ecc_size 1) - 1) 22) | (0x000F));
- gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+ unsigned int bch_mod = 0, bch_wrapmode = 0, eccsize1 = 0,
eccsize0 = 0;
+ unsigned int ecc_conf_val = 0, ecc_size_conf_val = 0;
switch (mode) {
case GPMC_ECC_READ:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0xD; eccsize0 = 0x48;
+ bch_mod = 0;
+ bch_wrapmode = 0x09;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x1A; eccsize0 = 0x18;
+ bch_mod = 1;
+ bch_wrapmode = 0x04;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
case GPMC_ECC_READSYN:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
break;
+
case GPMC_ECC_WRITE:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 0;
+ bch_wrapmode = 0x06;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 1;
+ bch_wrapmode = 0x06;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
default:
RE: Fail to suspend to ram: Class driver suspend failed for cpu0
Luke, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Luke Gong Sent: Friday, January 21, 2011 5:03 AM To: Kevin Hilman Cc: linux-omap@vger.kernel.org Subject: Re: Fail to suspend to ram: Class driver suspend failed for cpu0 Thanks, Kevin. On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman khil...@ti.com wrote: Luke Gong lukejg...@gmail.com writes: I have a beagle board with OMAP3530. I ported linux-omap- pm2.6.32 to this board. When I want to let it suspend to ram, This is an old kernel. Any reason you're not using a newer kernel? I have Angstrom7 with kernel 2.6.32 running on this board. So I selected this old version to test. I might try the latest one. it fails and I get the message Class driver suspend failed for cpu0 This is the CPUfreq driver failing to suspend, probably because there is no CPUfreq driver implemented in your kernel. Try disabling CPU_FREQ in your kernel config. It seems can suspend to ram after disabling CPU_FREQ. Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) ** *** Once I hit the keyboard, I get: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (cam_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend Restarting tasks ... done. root@beagleboard:~# *** I am just curious why the powerdomain didn't enter target state 1. It looks like your camera module is not idling upon suspend preventing per and core to idle. Pls check whether camera driver has implemented suspend/resume hooks properly. OR you can disable camera module and try. Another issue is about CPU frequency scaling. Using the original Angstrom7, I can scale CPU frequency. But with the linux-omap-pm kernel, I cannot do it even though I enable this feature in the config file. Is there any solution to support both cpu frequency scaling and suspend to ram? In current linux-omap-pm branch, DVFS feature is not supported and this work is under progress. Previously DVFS feature was supported in pm branch using SRF and it has been removed sometime back. If you really want cpufreq support, you can pick DVFS patches under review available at: https://patchwork.kernel.org/patch/290542/ It's also available in the dvfs tree hosted@ http://dev.omapzoom.org/?p=thara/omap-dvfs.git;a=shortlog;h=refs/heads/pm- dvfs Vishwa Thanks again for your help. Kevin . Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? Thanks. -- Luke -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/18] OMAP2,3: hwmod DSS Adaptation
Hi Sumit, Sumit Semwal sumit.sem...@ti.com writes: [...] Testing: - The patches are tested on 2420-n800, 2430sdp, 3630zoom, 3430sdp. Complete bootup with penguins on panel is done on 3430sdp. For the rest of the mentioned platforms, kernel is built with OMAP2_DSS and bootup is tested so that base address and clk_get calls are successful. I think this series needs more validation on the other platforms. Getting a visible framebuffer w/tux on all tested platforms seems like a minimal requirement. I gave a test of this on 3530/Beagle with CONFIG_PANEL_GENERIC_DPI=y and driving a DVI monitor, using the following kernel cmdline # cat /proc/cmdline console=ttyO2,115200n8 mpurate=600 vram=12M omapfb.mode=dvi:1024x768MR-16@60 omapfb.debug=y omapdss.def_disp=dvi root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Without your series, I see penguin logo and get a console login on the screen with this boot log (from dmesg |grep -i omapfb): [2.651885] OMAPFB: omapfb_init [2.652160] OMAPFB: omapfb_probe [2.657653] OMAPFB: create 3 framebuffers [2.657714] OMAPFB: fb_infos allocated [2.657714] OMAPFB: allocating 1572864 bytes for fb 0 [2.668212] OMAPFB: allocated VRAM paddr 8f40, vaddr d0a0 [2.668243] OMAPFB: region0 phys 8f40 virt d0a0 size=1572864 [2.668243] OMAPFB: region1 phys virt (null) size=0 [2.668273] OMAPFB: region2 phys virt (null) size=0 [2.668273] OMAPFB: fbmems allocated [2.668518] OMAPFB: check_fb_var 0 [2.668548] OMAPFB: max frame size 1572864, line size 2048 [2.668548] OMAPFB: xres = 1024, yres = 768, vxres = 1024, vyres = 768 [2.668579] OMAPFB: set_fb_fix [2.669036] OMAPFB: fb_infos initialized [2.673522] OMAPFB: set_par(0) [2.673614] OMAPFB: set_fb_fix [2.673614] OMAPFB: apply_changes, fb 0, ovl 0 [2.673645] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [2.673645] OMAPFB: paddr 8f40, vaddr d0a0 [2.674346] OMAPFB: pan_display(0) [2.674346] OMAPFB: setcmap [2.674377] OMAPFB: setcmap [2.683746] OMAPFB: pan_display(0) [2.683776] OMAPFB: setcmap [2.692108] OMAPFB: setcmap [2.701599] OMAPFB: framebuffers registered [2.701629] OMAPFB: apply_changes, fb 0, ovl 0 [2.701660] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 [2.701690] OMAPFB: paddr 8f40, vaddr d0a0 [2.701721] OMAPFB: apply_changes, fb 1, ovl 1 [2.701751] OMAPFB: apply_changes, fb 2, ovl 2 [2.701751] OMAPFB: create_framebuffers done [2.702331] OMAPFB: mgr-apply'ed [2.704803] OMAPFB: create sysfs for fbs [2.704833] OMAPFB: create sysfs for fbs With your series applied (no other changes), I don't see anything on the screen because omapfb_probe() fails: [2.519653] OMAPFB: omapfb_init [2.519958] OMAPFB: omapfb_probe [2.520019] omapfb omapfb: no driver for display [2.525115] OMAPFB: free_resources [2.525146] OMAPFB: free all fbmem [2.525177] omapfb omapfb: failed to setup omapfb which indicates that omap_dss_get_device() is failing in omapfb_probe(). 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: Fail to suspend to ram: Class driver suspend failed for cpu0
Luke Gong lukejg...@gmail.com writes: Thanks, Kevin. On Thu, Jan 20, 2011 at 5:54 PM, Kevin Hilman khil...@ti.com wrote: Luke Gong lukejg...@gmail.com writes: I have a beagle board with OMAP3530. I ported linux-omap-pm2.6.32 to this board. When I want to let it suspend to ram, This is an old kernel. Any reason you're not using a newer kernel? I have Angstrom7 with kernel 2.6.32 running on this board. So I selected this old version to test. I might try the latest one. You'll have to get support from the folks making the Angstrom kernel as I don't keep track of the kernel baseline they use or the local patches they apply, so can't help you. If you can reproduce on current linux-omap, I'll be glad to help. Kevin it fails and I get the message Class driver suspend failed for cpu0 This is the CPUfreq driver failing to suspend, probably because there is no CPUfreq driver implemented in your kernel. Try disabling CPU_FREQ in your kernel config. It seems can suspend to ram after disabling CPU_FREQ. Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) * Once I hit the keyboard, I get: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (cam_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend Restarting tasks ... done. root@beagleboard:~# *** I am just curious why the powerdomain didn't enter target state 1. Another issue is about CPU frequency scaling. Using the original Angstrom7, I can scale CPU frequency. But with the linux-omap-pm kernel, I cannot do it even though I enable this feature in the config file. Is there any solution to support both cpu frequency scaling and suspend to ram? Thanks again for your help. Kevin . Here is the log: root@beagleboard:~# echo mem /sys/power/state PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Suspending console(s) (use no_console_suspend to debug) omapfb omapfb: timeout waiting for FRAME DONE Class driver suspend failed for cpu0 Restarting tasks ... done. * Is there any idea to fix this problem? 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: 2.6.38-rc1-git1 musb undefined references
On 21/01/11 03:22, Felipe Balbi wrote: Hi, (please, keep also linux-usb@vger on the Cc list on any patch regarding drivers/usb) On Thu, Jan 20, 2011 at 04:22:01PM +, Sid Boyce wrote: Cross compiling for Beagleboard on Ubuntu 11.04 x86_64. # make-kpkg --revision=0 --append-to-version=-custom --arch=armel --cross-compile=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- kernel-image --initrd == making target debian/stamp/build/kernel [new prereqs: vars]== This is kernel package version 12.036+nmu1. restore_upstream_debianization test ! -f scripts/package/builddeb.kpkg-dist || mv -f scripts/package/builddeb.kpkg-dist scripts/package/builddeb test ! -f scripts/package/Makefile.kpkg-dist || mv -f scripts/package/Makefile.kpkg-dist scripts/package/Makefile /usr/bin/make EXTRAVERSION=-rc1-git1-custom ARCH=arm \ CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- zImage make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' scripts/kconfig/conf --silentoldconfig Kconfig make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make[1]: Entering directory `/usr/src/XXX/linux-2.6.38-rc1-git1' CHK include/linux/version.h CHK include/generated/utsrelease.h make[2]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h LD fs/built-in.o LD lib/zlib_deflate/built-in.o LD lib/built-in.o LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 3 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `musb_free': clkdev.c:(.text+0xf3d08): undefined reference to `dma_controller_destroy' drivers/built-in.o: In function `musb_probe': clkdev.c:(.init.text+0x64a8): undefined reference to `dma_controller_create' make[1]: *** [.tmp_vmlinux1] Error 1 make[1]: Leaving directory `/usr/src/XXX/linux-2.6.38-rc1-git1' make: *** [debian/stamp/build/kernel] Error 2 root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# I just compiled 2.6.38-rc1 and it doesn't fail for me. root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep OMAP2PLUS .config CONFIG_ARCH_OMAP2PLUS=y CONFIG_ARCH_OMAP2PLUS_TYPICAL=y # CONFIG_USB_MUSB_OMAP2PLUS is not set root@sdrbox:/usr/src/XXX/linux-2.6.38-rc1-git1# grep MUSB .config CONFIG_USB_MUSB_HDRC=y # CONFIG_USB_MUSB_TUSB6010 is not set # CONFIG_USB_MUSB_OMAP2PLUS is not set CONFIG_USB_MUSB_AM35X=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_PERIPHERAL is not set CONFIG_USB_MUSB_OTG=y CONFIG_USB_GADGET_MUSB_HDRC=y CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set # CONFIG_USB_MUSB_DEBUG is not set There's a bug on your .config, did you edit by hand ? AM35X doesn't have DMA support as of today, that's why we have: config MUSB_PIO_ONLY bool 'Disable DMA (always use PIO)' depends on USB_MUSB_HDRC default USB_MUSB_TUSB6010 || USB_MUSB_DA8XX || USB_MUSB_AM35X did you disable PIO only ? I know that's a bit fuzzy still, a few patches will be needed to clean up the entire MUSB Kconfig, I apologize for that. I copied the .config from the Beagleboard and did ARCH=arm make oldconfig. Thanks, I shall do make omap2plus_defconfig. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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: Merging xloader, bootloader and boot environment variables partitions into a single partition on NAND
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Elvis Dowson Sent: Thursday, January 20, 2011 10:51 PM To: linux-omap Mailing List Subject: Merging xloader, bootloader and boot environment variables partitions into a single partition on NAND Hi, I was wondering what the merits and demerits are of having a single integrated xloader+bootloader+boot environment variables in a single partition in NAND, as opposed to having multiple partitions that hold xloader, bootloader and the uboot environment in separate partitions? [Ghorai] This the way we represent or arrange the nand/flash. Current design helps to update x-loader, u-boot, saveen or kernel in different partition(s) from user-space without remember the offset. Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap-mcbsp: Fix building after replacement
On Thu, Jan 20, 2011 at 23:49, Tony Lindgren t...@atomide.com wrote: * Poddar, Sourav sourav.pod...@ti.com [110120 07:08]: On Thu, Jan 20, 2011 at 7:42 PM, Thomas Weber we...@corscience.de wrote: Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95. omap: Start using CONFIG_SOC_OMAP We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest are nowadays just subcategories of these. Search and replace the following: ARCH_OMAP2420 SOC_OMAP2420 ARCH_OMAP2430 SOC_OMAP2430 ARCH_OMAP3430 SOC_OMAP3430 I was just about to post a patch for this, but you beat me to it! Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Sourav Poddar sourav.pod...@ti.com Thanks, merging this into the original. Also adding applying into linux-omap master. Aren't we breaking multi-omap build with this? -V Charulatha -- 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: [PATCHv2] OMAP: Enable Magic SysRq on serial console ttyOx
On Thu, Jan 20, 2011 at 5:49 PM, Anand Gadiyar gadi...@ti.com wrote: Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Signed-off-by: Thomas Weber we...@corscience.de Looks fine to me. Acked-by: Govindraj.R govindraj.r...@ti.com I tried to use SysRq key on minicom after applying this patch, it looks like it is not triggering sysrq event. Am I missing anything? -Manjunath -- Hello Manjunath, Do you have CONFIG_MAGIC_SYSRQ enabled? Magic SysRq key in Kernel Hacking I tested it on Devkit8000 (beagle board clone). re-setting lsr_break_flag to 0 in receive chars is causing issues in getting sysrq key break sequence on omap-serial.c Manju, can you try this change on your environment. With below change works for me on 3430SDP/4430SDP. key sequence I checked. [alt + b + t] = shows trace of tasks running. [alt + b + b] = system reboot. With below patch, it works fine on TeraTerm. However, I am not able to perform the same on minicom. Tested-by: Manjunath G Kondaiah manj...@ti.com -Manjunath Not sure what you guys are trying out, but I am able to use sysrq just fine in minicom (using only Thomas' original patch) - you need to send a break sequence, and the way to do this in minicom is to do Ctrl-A followed by F. Works for me, without the resetting lsr_break_flag to 0 part. @Govind, What are the issues you see in getting sysrq key break sequence without your change? And how is your change fixing this? Actually I was using teraterm on windows platform. using keyboard to send a break char [alt + b] sometimes i observed that first break char was getting lost and subsequent break chars where getting recognized. However using send break option from terterm menu seems to work most of times. my change can be dropped. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap-mcbsp: Fix building after replacement
On Fri, 21 Jan 2011 11:55:55 +0530 Varadarajan, Charulatha ch...@ti.com wrote: I was just about to post a patch for this, but you beat me to it! Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Sourav Poddar sourav.pod...@ti.com Thanks, merging this into the original. Also adding applying into linux-omap master. Aren't we breaking multi-omap build with this? Don't point it out immediately but these patches looks like yet another reason why there's a need to get rid of these ifdefs and cpu_is_omapxxx tests from the drivers. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap-mcbsp: Fix building after replacement
On Fri, Jan 21, 2011 at 12:58, Jarkko Nikula jhnik...@gmail.com wrote: On Fri, 21 Jan 2011 11:55:55 +0530 Varadarajan, Charulatha ch...@ti.com wrote: I was just about to post a patch for this, but you beat me to it! Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Sourav Poddar sourav.pod...@ti.com Thanks, merging this into the original. Also adding applying into linux-omap master. Aren't we breaking multi-omap build with this? Don't point it out immediately but these patches looks like yet another reason why there's a need to get rid of these ifdefs and cpu_is_omapxxx tests from the drivers. Yes. I agree. -- Jarkko -- 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] omap3: nand: bch ecc support added
On Fri, Jan 21, 2011 at 9:37 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Thursday, January 20, 2011 8:47 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; Kamat, Nishant Subject: Re: [PATCH] omap3: nand: bch ecc support added Hi Ghorai, I am the initial author of this patch. And I guess this patch still uses most of my work. [Ghorai] I know you are working on it, But I think your code was in a shape for - 1. not for up-streamble shape That's because I never posted it for up-stream. 2. non functional, No, it was a working (at least for 8-bit correction) patch on that kernel version (I do not remember the correct version now, may be .29-.30) It did not work for 4-bit, because of known reason. And I guess while posting this patch you should also have mentioned/documented about that. No? So can you check this version matching with your original code? In that case I can add your Signed-off. Yes, you should. I can see this version has got many changes, but original idea is same. And not all code is changed. Does it? Regards, Vimal -- 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: [PATCHv2] OMAP: Enable Magic SysRq on serial console ttyOx
On Fri, Jan 21, 2011 at 12:54:29PM +0530, Govindraj wrote: On Thu, Jan 20, 2011 at 5:49 PM, Anand Gadiyar gadi...@ti.com wrote: Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Signed-off-by: Thomas Weber we...@corscience.de Looks fine to me. Acked-by: Govindraj.R govindraj.r...@ti.com I tried to use SysRq key on minicom after applying this patch, it looks like it is not triggering sysrq event. Am I missing anything? -Manjunath -- Hello Manjunath, Do you have CONFIG_MAGIC_SYSRQ enabled? Magic SysRq key in Kernel Hacking I tested it on Devkit8000 (beagle board clone). re-setting lsr_break_flag to 0 in receive chars is causing issues in getting sysrq key break sequence on omap-serial.c Manju, can you try this change on your environment. With below change works for me on 3430SDP/4430SDP. key sequence I checked. [alt + b + t] = shows trace of tasks running. [alt + b + b] = system reboot. With below patch, it works fine on TeraTerm. However, I am not able to perform the same on minicom. Tested-by: Manjunath G Kondaiah manj...@ti.com -Manjunath Not sure what you guys are trying out, but I am able to use sysrq just fine in minicom (using only Thomas' original patch) - you need to send a break sequence, and the way to do this in minicom is to do Ctrl-A followed by F. Works for me, without the resetting lsr_break_flag to 0 part. @Govind, What are the issues you see in getting sysrq key break sequence without your change? And how is your change fixing this? Actually I was using teraterm on windows platform. using keyboard to send a break char [alt + b] sometimes i observed that first break char was getting lost and subsequent break chars where getting recognized. However using send break option from terterm menu seems to work most of times. my change can be dropped. If it is fixing the issue of losing first break character, what is wrong in having this patch? Do you see any other issues because of this change? -Manjunath -- 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: [QUERY] [AUDIO][OMAP3 EVM] arecord not working on OMAP3 EVM
On 01/20/11 17:26, ext Koyamangalath, Abhilash wrote: Hi all While testing audio capture (using arecord e,g.),I'm getting only noise in the (zeroed out) output buffers on the OMAP3 EVM. I have enabled AUXL and AUXR mic inputs through alsamixer, which according to the schematics are connected to the Audio In connector on the board, even though the TWL4030 reg list does not allow me any ways ( or so I think) to specify mic-bias for these aux inputs. Well, it is auxiliary input (line in). You do not need bias for it. I do not have access to OMAP3 EVM documentation, but Beagle also have AUXL/R as input. I guess you need to use correct cable, and correct source for the input (stereo jack I suppose). With AUXL and AUXR muted - I get only silence, which seems to make sense. Is there any basic startup setting I'm missing, maybe specific to OMAP3 EVM? Beagle? Has anyone seen anything like this before, and could provide pointers? My bet goes for the wrong cable/accessory pair. -- Péter -- 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
