RE: [PATCH 08/10] OMAP: split plat-omap/common.c
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c; 3. and the remainder of the OMAP-wide common code, which includes the deprecated ATAGs code and a deprecated video RAM reservation function. The primary motivation for doing this is to move the OMAP2+-specific parts into an OMAP2+-specific file, so that build breakage related to the System Control Module code can be resolved. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/common.c | 138 ++ arch/arm/plat-omap/32ksynctimer.c | 184 +++ arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/common.c | 291 - arch/arm/plat-omap/devices.c |1 arch/arm/plat-omap/sram.c |3 7 files changed, 325 insertions(+), 297 deletions(-) create mode 100644 arch/arm/mach-omap2/common.c create mode 100644 arch/arm/plat-omap/32ksynctimer.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 9edacb0..d543533 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -3,7 +3,8 @@ # # Common support -obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o +obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \ + common.o omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.o hwmod-common = omap_hwmod.o \ diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c new file mode 100644 index 000..4e0469d --- /dev/null +++ b/arch/arm/mach-omap2/common.c @@ -0,0 +1,138 @@ +/* + * linux/arch/arm/mach-omap2/common.c + * + * Code common to all OMAP2+ machines. + * + * Copyright (C) 2009 Texas Instruments + * Copyright (C) 2010 Nokia Corporation + * Tony Lindgren t...@atomide.com + * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com + * Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include linux/kernel.h +#include linux/init.h +#include linux/clk.h +#include linux/io.h + +#include plat/common.h +#include plat/board.h +#include plat/control.h +#include plat/mux.h + +#include plat/clock.h + +#include sdrc.h + +/* Global address base setup code */ + +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) + +static void __init __omap2_set_globals(struct omap_globals *omap2_globals) +{ + omap2_set_globals_tap(omap2_globals); + omap2_set_globals_sdrc(omap2_globals); + omap2_set_globals_control(omap2_globals); + omap2_set_globals_prcm(omap2_globals); + omap2_set_globals_uart(omap2_globals); +} + +#endif + +#if defined(CONFIG_ARCH_OMAP2420) + +static struct omap_globals omap242x_globals = { + .class = OMAP242X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x48014000), + .sdrc = OMAP2420_SDRC_BASE, + .sms= OMAP2420_SMS_BASE, + .ctrl = OMAP242X_CTRL_BASE, + .prm= OMAP2420_PRM_BASE, + .cm = OMAP2420_CM_BASE, + .uart1_phys = OMAP2_UART1_BASE, + .uart2_phys = OMAP2_UART2_BASE, + .uart3_phys = OMAP2_UART3_BASE, +}; + +void __init omap2_set_globals_242x(void) +{ + __omap2_set_globals(omap242x_globals); +} +#endif + +#if defined(CONFIG_ARCH_OMAP2430) + +static struct omap_globals omap243x_globals = { + .class = OMAP243X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), + .sdrc = OMAP243X_SDRC_BASE, + .sms= OMAP243X_SMS_BASE, + .ctrl = OMAP243X_CTRL_BASE, + .prm= OMAP2430_PRM_BASE, + .cm = OMAP2430_CM_BASE, + .uart1_phys = OMAP2_UART1_BASE, + .uart2_phys = OMAP2_UART2_BASE, + .uart3_phys = OMAP2_UART3_BASE, +}; + +void __init omap2_set_globals_243x(void) +{ + __omap2_set_globals(omap243x_globals); +} +#endif + +#if defined(CONFIG_ARCH_OMAP3) Do you really need these #ifdefs? It would be better to avoid these #ifdefs and use cpu_is* checks. Same comment holds good across this patch. + +static struct omap_globals omap3_globals = { + .class = OMAP343X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x4830A000), + .sdrc = OMAP343X_SDRC_BASE, + .sms= OMAP343X_SMS_BASE, +
RE: Issue : jffs2 and ecc layout
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar Sent: Tuesday, September 28, 2010 6:17 PM To: linux-...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: Issue : jffs2 and ecc layout Hi, I was using the following ecc layout which is not working to mount the jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is not working with latest 2.6 kernel. Observation is that - no read request issued to the driver (say omap2.c). # mount -t jffs2 /dev/mtdblock4 /mnt/nand [ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0 bytes, error -22 mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error # dmesg 3[ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0 bytes, error -22 Code: 178 static struct nand_ecclayout hw_x16_romcode_oob_64 = { 179 .eccbytes = 12, 180 .eccpos = { 181 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 182 }, 183 .oobfree = { 184 {.offset = 14, 185 .length = 50} 186 } 187 }; 1188 info-nand.ecc.layout = hw_x16_romcode_oob_64; [Ghorai] Does anyone using similar layout for Jffs2? i.e. ECC store at beginning of the spare area? Regards, Ghorai -- 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] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Fri, 2010-09-24 at 23:45 +0200, Loïc Minier wrote: Fix missing cs arg to gpmc_prefetch_reset() when CONFIG_MTD_NAND_OMAP_PREFETCH_DMA=y which caused a build failure since 948d38e799f0ab87cf8ed9113fcdaaee61acf321: drivers/mtd/nand/omap2.c: In function 'omap_nand_dma_transfer': drivers/mtd/nand/omap2.c:416: error: too few arguments to function 'gpmc_prefetch_reset' Signed-off-by: Loïc Minier loic.min...@linaro.org --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) FYI, a similar patch is already in Linus' tree, so I'm dropping it from my tree: commit f12f662f29d5801e598c6bb4a71e54b2de218f72 Author: Daniel J Blueman daniel.blue...@gmail.com Date: Wed Sep 29 21:01:55 2010 +0100 fix OMAP2 MTD build failure Fix build failure from recent interface change and merge. Tested on OMAP3430. Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com Signed-off-by: Linus Torvalds torva...@linux-foundation.org -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
On Monday 04 October 2010 10:36:16 ext G, Manjunath Kondaiah wrote: are going to have: DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to For OMAP2, you should use DMA_ERRATA_IFRAME_BUFFERING since it is different type of issue. Thanks! I'll do that. -Manjunath -- 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
RE: NOTE: hwmod changes merged to linux-omap master for testing
Hi Tony, With latest merges on master branch with commit ID: 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. Looks like multiple warning dumps and finally it crashes after Freeing init memory with both NFS and ramdisk file systems. The complete bootlogs are available at: NFS bootlog: http://pastebin.com/nrWQ5FGG Ramdisk bootlog: http://pastebin.com/1F75d2Ew -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, October 02, 2010 6:18 AM To: linux-omap@vger.kernel.org Subject: NOTE: hwmod changes merged to linux-omap master for testing Hi all, So I've finally merged Kevin's hwmod branch into the linux-omap master so we can give it some testing to see if we can merge it to the mainline. Might take few minutes to hit the mirrors. Please note that for omap2plus machines you need to change: - u-boot bootargs for kernel cmdline needs to change with setenv - if you use hardcoded CONFIG_CMDLINE, change it in your .config - /etc/inittab in your omap root file system if using serial console This is because otherwise the serial-omap would be conflicting with the 8250 driver. This should not affect omap1 machines. Please give it a try and report any issues on this list! Now all the machines except ams_delta_defconfig should build. That one is still missing some camera driver changes to build. 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3 PM: sleep code clean up
On 10 Oct 04, Sripathy, Vishwanath wrote: Kevin, [snip] But this also makes me wonder, if we're going to clean this up, the bulk of it could be re-written in C, with some inline asm helpers as needed. Probably yes. But as this code is specific to OMAP3, do you think it's worth spending time on rewriting the entire code in C? It might be a significant effort and it will not be reusable for other ARM SOCs. The C code will be more maintainable and offer more opportunities to refactor across OMAP flavours - perhaps OMAP4 as well. I'm also interested in code reuse across other SoCs. We've got to be able to shut down the ARM core using common code instead of each SoC copying buggy code from each other. Could you list reasons why you don't think the code is re-usable? Regards, Amit -- 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: Fix compilation warnings
On Friday 01 October 2010 09:30 PM, Kevin Hilman wrote: pramod.gu...@ti.com writes: From: Pramod Guravpramod.gu...@ti.com patch is missing - more descriptive subject - more descriptive changelog (preferably incluing compilation error) - signoff (should've been noticed when running checkpatch) And after the '---', which tree this applies to since it does not apply to current l-o master. In fact, it appears that all these issues have already been fixed in l-o master. I was working out of l-o pm branch. Sorry for the confusion! Kevin --- arch/arm/mach-omap2/board-omap4panda.c |2 -- arch/arm/mach-omap2/mux.c |2 +- arch/arm/plat-omap/gpio.c |4 ++-- 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index c03d1d5..96f5bbb 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -274,8 +274,6 @@ static int __init omap4_panda_i2c_init(void) } static void __init omap4_panda_init(void) { - int status; - omap4_panda_i2c_init(); omap_serial_init(); omap4_twl6030_hsmmc_init(mmc); diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index ab403b2..6c2f8f0 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -87,7 +87,7 @@ static char *omap_mux_options; int __init omap_mux_init_gpio(int gpio, int val) { struct omap_mux_entry *e; - struct omap_mux *gpio_mux; + struct omap_mux *gpio_mux = NULL; u16 old_mode; u16 mux_mode; int found = 0; diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c index f6c03a7..22f175f 100644 --- a/arch/arm/plat-omap/gpio.c +++ b/arch/arm/plat-omap/gpio.c @@ -2223,7 +2223,7 @@ void omap2_gpio_prepare_for_idle(int power_state) for (i = min; i gpio_bank_count; i++) { struct gpio_bank *bank =gpio_bank[i]; - u32 l1, l2; + u32 l1 = 0, l2 = 0; int j; for (j = 0; j hweight_long(bank-dbck_enable_mask); j++) @@ -2291,7 +2291,7 @@ void omap2_gpio_resume_after_idle(void) min = 1; for (i = min; i gpio_bank_count; i++) { struct gpio_bank *bank =gpio_bank[i]; - u32 l, gen, gen0, gen1; + u32 l = 0, gen, gen0, gen1; int j; for (j = 0; j hweight_long(bank-dbck_enable_mask); j++) -- 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: multiple linux-next OMAP3 build errors
Hi, On Fri, 2010-10-01 at 17:57 +0200, ext Grazvydas Ignotas wrote: hi, I've been building linux-next for a while now and keep getting these build errors, just posting them here in case not all are known. Not familiar enough with that code to send patches unfortunately. CC drivers/video/omap2/vram.o drivers/video/omap2/vram.c: In function 'omap_vram_reserve_sdram_memblock': drivers/video/omap2/vram.c:568: error: implicit declaration of function 'memblock_region_is_memory' Benjamin, your patch memblock/arm: Use memblock_region_is_memory() for omap fb in linux-next seems to be broken. I believe the called function should be memblock_is_region_memory, not memblock_region_is_memory? Tomi -- 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] usb: musb: fix build break due to partial rename
On Fri, Oct 01, 2010 at 03:34:24PM -0500, Gadiyar, Anand wrote: Patch usb gadget: don't save bind callback in struct usb_gadget_driver in Greg's USB queue missed one conversion of usb_gadget_register_driver to usb_gadget_probe_driver, causing a build break when MUSB is built in gadget mode. Fix this. Reported-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Uwe Kleine-Koenigu.kleine-koe...@pengutronix.de Cc: Michal Nazarewicz m.nazarew...@samsung.com Cc: Felipe Balbi ba...@ti.com wow, good catch :-) Acked-by: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@suse.de --- Greg, Since Uwe's original patch isn't yet in mainline, maybe you could fold this patch into the original. Fine by me to fold on original patch. -- 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 08/10] OMAP: split plat-omap/common.c
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Monday, October 04, 2010 2:39 PM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c Hi Paul, On 10/1/2010 11:35 PM, Paul Walmsley wrote: Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c; 3. and the remainder of the OMAP-wide common code, which includes the deprecated ATAGs code and a deprecated video RAM reservation function. The primary motivation for doing this is to move the OMAP2+-specific parts into an OMAP2+-specific file, so that build breakage related to the System Control Module code can be resolved. Signed-off-by: Paul Walmsleyp...@pwsan.com --- ... diff --git a/arch/arm/plat-omap/32ksynctimer.c b/arch/arm/plat- omap/32ksynctimer.c new file mode 100644 index 000..b7f458c --- /dev/null +++ b/arch/arm/plat-omap/32ksynctimer.c @@ -0,0 +1,184 @@ +/* + * linux/arch/arm/plat-omap/clocksource.c What name do you want to use? 32ksynctimer.c or clocksource.c? If this file is dedicated for the 32k sync timer, maybe we should now use the new OMAP4 name: counter_32k. Noboby knows what the sync stand for, and at the end this is just a 32k counter. Hence the new name :-) One of the points to be kept in mind while naming is that we are able to relate our driver easily to the hardware device. In this regard the TRM terms this module as 32-kHz Synchronized Timer. Therefore we should be careful in our naming. With regard to the meaning of the word here is the extract from the TRM. OMAP4430 ES2.0 TRM ... The sync logic ensures the read transaction correctness by synchronizing the counter register read access on 32KSYNCNT_ICLK because the 32KSYNCNT_ICLK clock signal is completely asynchronous with S32KSYNCNT_FCLK. ... Benoit + * + * OMAP clocksource-related code + * + * Copyright (C) 2009 Texas Instruments + * Copyright (C) 2010 Nokia Corporation + * Tony Lindgrent...@atomide.com + * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com + * Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#includelinux/kernel.h +#includelinux/init.h +#includelinux/clk.h +#includelinux/io.h + +#includeplat/common.h +#includeplat/board.h + +#includeplat/clock.h + + +/* + * 32KHz clocksource ... always available, on pretty most chips except + * OMAP 730 and 1510. Other timers could be used as clocksources, with + * higher resolution in free-running counter modes (e.g. 12 MHz xtal), + * but systems won't necessarily want to spend resources that way. + */ + +#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410 + +#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) + +#includelinux/clocksource.h + +/* + * offset_32k holds the init time counter value. It is then subtracted + * from every counter read to achieve a counter that counts time from the + * kernel boot (needed for sched_clock()). + */ +static u32 offset_32k __read_mostly; + +#ifdef CONFIG_ARCH_OMAP16XX +static cycle_t omap16xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k; +} +#else +#define omap16xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2420 +static cycle_t omap2420_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2420_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2430 +static cycle_t omap2430_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2430_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP3 +static cycle_t omap34xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap34xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP4 +static cycle_t omap44xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap44xx_32k_read NULL +#endif + +/* + * Kernel assumes that sched_clock can be called early but may not have + * things ready yet. + */ +static cycle_t omap_32k_read_dummy(struct clocksource *cs) +{ + return 0; +} + +static struct clocksource clocksource_32k = { + .name =
[PATCH v4 3/4] OMAP2: DMA: Use errata flag for disabling buffering
Convert the errata handling of buffering disable on OMAP2 platforms. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- arch/arm/plat-omap/dma.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ae0ff64..c116c41 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -147,6 +147,7 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = { }; /* Errata handling */ +#define DMA_ERRATA_IFRAME_BUFFERING(1 0) static u16 dma_errata; #define IS_DMA_ERRATA(id) (dma_errata (id)) @@ -1003,8 +1004,7 @@ void omap_start_dma(int lch) * Errata: On ES2.0 BUFFERING disable must be set. * This will always fail on ES1.0 */ - if (cpu_is_omap2420() || - (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) + if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING)) l |= OMAP_DMA_CCR_BUFFERING_DISABLE; l |= OMAP_DMA_CCR_EN; @@ -2048,6 +2048,9 @@ void omap_dma_global_context_restore(void) static void dma_errata_configure(void) { + if (cpu_is_omap2420() || + (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) + dma_errata |= DMA_ERRATA_IFRAME_BUFFERING; } static int __init omap_init_dma(void) -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/10] OMAP: split plat-omap/common.c
Paul, snip +static int __init omap_init_clocksource_32k(void) +{ + static char err[] __initdata = KERN_ERR + %s: can't register clocksource!\n; + + if (cpu_is_omap16xx() || cpu_class_is_omap2()) { + struct clk *sync_32k_ick; + + if (cpu_is_omap16xx()) Avoid cpu_is* checks in plat-omap. OK, I'll bite. Why? I think this is being looked for all the new code introduced in plat-omap layer for the following reasons: Adding cpu-is-* checks makes code unmaintainable going fwd. plat-omap layer needs to handle common code for all omap platforms. This was raised for GPIO driver because of which, there was a requirement to clean-up the gpio driver. Is this stand changed? Are cpu_is* checks allowed in plat-omap? + clocksource_32k.read = omap16xx_32k_read; + else if (cpu_is_omap2420()) + clocksource_32k.read = omap2420_32k_read; + else if (cpu_is_omap2430()) + clocksource_32k.read = omap2430_32k_read; + else if (cpu_is_omap34xx()) + clocksource_32k.read = omap34xx_32k_read; + else if (cpu_is_omap44xx()) + clocksource_32k.read = omap44xx_32k_read; + else + return -ENODEV; + + sync_32k_ick = clk_get(NULL, omap_32ksync_ick); + if (sync_32k_ick) + clk_enable(sync_32k_ick); + + clocksource_32k.mult = clocksource_hz2mult(32768, + clocksource_32k.shift); + + offset_32k = clocksource_32k.read(clocksource_32k); + + if (clocksource_register(clocksource_32k)) + printk(err, clocksource_32k.name); + } + return 0; +} +arch_initcall(omap_init_clocksource_32k); + -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
[PATCH v4 0/4] OMAP2/3: DMA: FIFO drain errata fixes
Hello, Changes since v3: - use flags for errata handling - OMAP2 buffering disable converted to use flags - OMAP3 i541 is using the dma_errata flag - Spelling fix in OMAP3 drain timeout message Changes since v2: - remove multiple assignment Changes since v1: - Errata ID added to the comment (i541) Intro mail from v1: The following series fixes the sDMA FIFO drain issue present for OMAP2 and OMAP3, and covered by an errata. For OMAP2 the omap_start_dma had a comment about this errata, but the workaround configured wrong bit (CCR_EN instead of the correct BUFFERING_DISABLE bit). The first patch from Jarkko Nikula jhnik...@gmail.com fixes this. For OMAP3 the suggestion is to set sDMA to NoStandby before disabling the channel, and wait for the drain to finish, than configure sDMA to SmartStandby again. The second patch implements this workaround for OMAP3. The FIFO drain problem can be reproduced on both OMAP2 and OMAP3 while using audio (capture case): Either introduce load to the CPU: nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat /dev/null \ dd if=/dev/urandom of=/dev/null or suspending the arecord, and resuming it: arecord -D hw:0 -M -B 1 -F 5000 -f dat /dev/null CTRL+Z; fg; CTRL+Z; fg; ... On OMAP2 we can not recover from this problem. The board has to be rebooted, while OMAP3 can be recovered by reseting the sDMA channel, or introducing unrelated sDMA activity (which takes sDMA out from Standby - but this is not working all the time). --- Peter Ujfalusi (3): OMAP: DMA: Introduce errata handling variable, and macro OMAP2: DMA: Use errata flag for disabling buffering OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish ext Jarkko Nikula (1): omap: dma: Fix buffering disable bit setting for omap24xx arch/arm/plat-omap/dma.c | 60 ++-- arch/arm/plat-omap/include/plat/dma.h |4 ++ 2 files changed, 60 insertions(+), 4 deletions(-) -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
Peter, -Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Monday, October 04, 2010 12:46 PM To: G, Manjunath Kondaiah Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; Liam Girdwood Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote: No errata numbers numbers used with TI errata documents till omap2430. Errata numbers avaialable from omap3430 onwards. For OMAP3 the errata number is i541, but I do not know the iXYZ number for OMAP2 class. Being said that no errata numbers for omap2 class, it's ok to use omap3 errata numbers for common errata(like your patch 2/2) Thanks, we are going to use the same errata ID for OMAP2, and OMAP3, but going to use different workaround for them: OMAP2: disable buffering This issue seems to be completly different from omap3 i541. This is required to flush out fifo contents properly where as with i541, it requires DMA controller to be put in no mstandby mode before stoping DMA transfer. OMAP3: implement the workaround as it is in the errata So, as Tony suggested, I'll add the errata handling, and we If you are introducing errata handling, are you taking care of existing errata in DMA driver also? If not, it is better to go ahead current implementation. DMA hwmod patches will introduce errata handling and these changes can be rebased once it is available in mainline. are going to have: DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to For OMAP2, you should use DMA_ERRATA_IFRAME_BUFFERING since it is different type of issue. -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: [PATCH v4 0/4] OMAP2/3: DMA: FIFO drain errata fixes
On Monday 04 October 2010 11:29:16 ext Peter Ujfalusi wrote: Hello, Will resend, since I'll wait for comments on v4 series, and I'll send the v5 later today after the comments to reduce the noise. -- 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
Re: [PATCH 02/14] omap: Map only available sram memory
This hangs OMAP3 pandora: [ 0.00] Linux version 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-20 [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.00] Machine: Pandora Handheld Console [ 0.00] Ignoring unrecognised tag 0x54410008 [ 0.00] bootconsole [earlycon0] enabled [ 0.00] Reserving 6422528 bytes SDRAM for VRAM [ 0.00] Memory policy: ECC disabled, Data cache writeback [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 (stuck here) reverting this fixes the problem. Hmm, boots fine here with overo. Any idea what in this patch breaks pandora? The change in this patch is not board dependent really. Have tested this on 3430SDP. Pandora is OMAP3 based, right ? OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and it has the same problem. Maybe it's because of older Cortex A8 used there, or I'm missing some errata workaround in defconfig. BTW, hacking the size to 1M on top of your patch fixes the problem too: base = omap_sram_start; base = ROUND_DOWN(base, PAGE_SIZE); omap_sram_io_desc[0].pfn = __phys_to_pfn(base); - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE); + omap_sram_io_desc[0].length = 0x10; iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); -- 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: NOTE: hwmod changes merged to linux-omap master for testing
On Mon, Oct 4, 2010 at 2:20 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Can you post complete boot log? so far, it failed on one blaze and one 3430sdp both of them are having es2.0 Sure: wizery.com/ohad/blaze-linux-omap.txt.gz Summary of my setup: - Blaze ES2.0 - linux-omap-2.6 master branch (commit 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing) - omap2plus_defconfig - kernel boots (with 2-3 warnings) -- 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: Dropping omap3430 ES1.0 support in mainline
On 10/2/2010 12:28 AM, Anand Gadiyar wrote: Paul Walmsley wrote: On Sat, 2 Oct 2010, Anand Gadiyar wrote: Okay, so we're aligned that you guys don't have an ES1 board to test, and TI doesn't have any either. :) I'd still like to know if anyone in the wild still cares about the board. (I see Tony already said No thanks, but I'd like to know anyway). Why would we want to remove support for a board that should work fine with linux-omap and isn't causing any problems with existing code? I'm not sure it works fine, and if there are no users that care about the board, then it would be nice to drop the support. If the board works fine today, that's good, but has anyone tested the current kernel on that board? (we're struggling to keep linux-omap working on boards available now, why support something that nobody cares about. It's not like I'm asking 3430 support to be dropped) - the ES1 chip has never been available to the outside world beyond sampling quantities - no new developments are likely to happen on that board - nobody's likely to have one of these around and care to boot it up - there are plenty of replacements like the beagles which are lower cost, easier to obtain, and can beat an ES1 in speed I'm okay having support for the board if someone's actually using it. It's not such a big deal. It was just a thought - it came up because Manju was looking at old errata docs, and came across something that was specific to an ES1, but we realized there was no way to test it. If this is the SDMA bug we are talking about, it was unfortunately already there in OMAP2420. For some reason I didn't find it in 2430 errata, but since it was still there in 3430 ES1, we can assume that 2430 also has the issue. That being said, ES1 devices for both OMAP3 and OMAP4 were supposed to be engineering samples. There is no product out there with OMAP3 ES1, and same thing is happening with 4430 ES1. So, it makes sense to keep supporting them during the transition, but as soon as everybody is upgraded to the next production version, what the point to keep maintaining these buggy devices? Hopefully the auto-destroy mode after 2 years seems to work fine :-) Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3 PM: sleep code clean up
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Amit Kucheria Sent: Monday, October 04, 2010 2:27 PM To: Sripathy, Vishwanath Cc: Kevin Hilman; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up On 10 Oct 04, Sripathy, Vishwanath wrote: Kevin, [snip] But this also makes me wonder, if we're going to clean this up, the bulk of it could be re-written in C, with some inline asm helpers as needed. Probably yes. But as this code is specific to OMAP3, do you think it's worth spending time on rewriting the entire code in C? It might be a significant effort and it will not be reusable for other ARM SOCs. The C code will be more maintainable and offer more opportunities to refactor across OMAP flavours - perhaps OMAP4 as well. I'm also interested in code reuse across other SoCs. We've got to be able to shut down the ARM core using common code instead of each SoC copying buggy code from each other. Could you list reasons why you don't think the code is re-usable? Trust zone implementation and it's varients -- 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] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Mon, 2010-10-04 at 10:52 +0200, Loïc Minier wrote: On Mon, Oct 04, 2010, Artem Bityutskiy wrote: FYI, a similar patch is already in Linus' tree, so I'm dropping it from my tree Ok, thanks; is there something I should have done to get this patch into Linus tree? No, you did everything right. I guess that guy was just faster than you. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx
From: ext Jarkko Nikula jhnik...@gmail.com An errata workaround for omap24xx is not setting the buffering disable bit 25 what is the purpose but channel enable bit 7 instead. Background for this fix is the DMA stalling issue with ASoC omap-mcbsp driver. Peter Ujfalusi peter.ujfal...@nokia.com has found an issue in recording that the DMA stall could happen if there were a buffer overrun detected by ALSA and the DMA was stopped and restarted due that. This problem is known to occur on both OMAP2420 and OMAP3. It can recover on OMAP3 after dma free, dma request and reconfiguration cycle. However, on OMAP2420 it seems that only way to recover is a reset. Problem was not visible before the commit c12abc0. That commit changed that the McBSP transmitter/receiver is released from reset only when needed. That is, only enabled McBSP transmitter without transmission was able to prevent this DMA stall problem in receiving side and underlying problem did not show up until now. McBSP transmitter itself seems to no be reason since DMA stall does not recover by enabling the transmission after stall. Debugging showed that there were a DMA write active during DMA stop time and it never completed even when restarting the DMA. Experimenting showed that the DMA buffering disable bit could be used to avoid stalling when using source synchronized transfers. However that could have performance hit and OMAP3 TRM states that buffering disable is not allowed for destination synchronized transfers so subsequent patch will implement a method to complete DMA writes when stopping. This patch is based on assumtion that complete lock-up on OMAP2420 is different but related problem. I don't have access to OMAP2420 errata but I believe this old workaround here is put for a reason but unfortunately a wrong bit was typed and problem showed up only now. v2: Issue is applicaple only to OMAP2420 and ES1.0 of OMAP2430. Thanks to G, Manjunath Kondaiah manj...@ti.com for noticing. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- arch/arm/plat-omap/dma.c |5 +++-- arch/arm/plat-omap/include/plat/dma.h |1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ec7eddf..6914ccf 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -999,8 +999,9 @@ void omap_start_dma(int lch) * Errata: On ES2.0 BUFFERING disable must be set. * This will always fail on ES1.0 */ - if (cpu_is_omap24xx()) - l |= OMAP_DMA_CCR_EN; + if (cpu_is_omap2420() || + (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) + l |= OMAP_DMA_CCR_BUFFERING_DISABLE; l |= OMAP_DMA_CCR_EN; dma_write(l, CCR(lch)); diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h index af3a039..776ba44 100644 --- a/arch/arm/plat-omap/include/plat/dma.h +++ b/arch/arm/plat-omap/include/plat/dma.h @@ -335,6 +335,7 @@ #define OMAP2_DMA_MISALIGNED_ERR_IRQ (1 11) #define OMAP_DMA_CCR_EN(1 7) +#define OMAP_DMA_CCR_BUFFERING_DISABLE (1 25) #define OMAP_DMA_DATA_TYPE_S8 0x00 #define OMAP_DMA_DATA_TYPE_S16 0x01 -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] OMAP: DMA: Introduce errata handling variable, and macro
Use flags for errata handling. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- arch/arm/plat-omap/dma.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index 6914ccf..ae0ff64 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -146,6 +146,10 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = { INT_1610_DMA_CH14, INT_1610_DMA_CH15, INT_DMA_LCD }; +/* Errata handling */ +static u16 dma_errata; +#define IS_DMA_ERRATA(id) (dma_errata (id)) + static inline void disable_lnk(int lch); static void omap_disable_channel_irq(int lch); static inline void omap_enable_channel_irq(int lch); @@ -2042,6 +2046,10 @@ void omap_dma_global_context_restore(void) /**/ +static void dma_errata_configure(void) +{ +} + static int __init omap_init_dma(void) { unsigned long base; @@ -2064,6 +2072,8 @@ static int __init omap_init_dma(void) return -ENODEV; } + dma_errata_configure(); + omap_dma_base = ioremap(base, SZ_4K); BUG_ON(!omap_dma_base); -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] OMAP3 PM: sleep code clean up
Kevin, -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 25, 2010 1:35 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH 2/2] OMAP3 PM: sleep code clean up Vishwanath BS vishwanath...@ti.com writes: This patch has done some clean up of omap3 sleep code. Basically all possible hardcodings are removed and code is Reorganized into more logical buckets for better readability and instrumentation. Tested on ZOOM3. Again, please describe more about how it was tested. idle? suspend? retention? off? This has been tested for both RET and OFF mode in Idle and suspend path. Will update the change log for the same. Also please fix long-line checkpatch warnings. OK. While breaking this up in to subroutines, why not just call them all from the C-code instead of assembly? I thought about that. But unfortunately, while saving CPU registers (in save_context_wfi), LR also gets saved. So if I call wfi routine (omap34xx_do_wfi ) from C code itself, then LR would have pointed to omap34xx_do_wfi while saving the registers which is not correct. But this also makes me wonder, if we're going to clean this up, the bulk of it could be re-written in C, with some inline asm helpers as needed. Probably yes. But as this code is specific to OMAP3, do you think it's worth spending time on rewriting the entire code in C? It might be a significant effort and it will not be reusable for other ARM SOCs. Vishwa Kevin Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Kevin Hillman khil...@deeprootsystems.com Cc: Linaro linaro-...@lists.linaro.org --- arch/arm/mach-omap2/sleep34xx.S | 377 ++--- arch/arm/plat-omap/include/plat/control.h |2 + 2 files changed, 189 insertions(+), 190 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach- omap2/sleep34xx.S index ba53191..734f82a --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,17 +33,20 @@ #include prm.h #include sdrc.h -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR \ + (SDRC_SCRATCHPAD_SEM_OFFS) #define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \ - OMAP3430_PM_PREPWSTST) -#define PM_PREPWSTST_CORE_P0x48306AE8 + OMAP3430_PM_PREPWSTST) +#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD + \ + OMAP3430_PM_PREPWSTST #define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \ OMAP3430_PM_PREPWSTST) #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) -#define SRAM_BASE_P0x4020 -#define CONTROL_STAT 0x480022F0 +#define SRAM_BASE_P0x4020 +#define CONTROL_STAT OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is * available */ #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ @@ -184,29 +187,16 @@ api_params: ENTRY(save_secure_ram_context_sz) .word . - save_secure_ram_context -/* - * Forces OMAP into idle state - * - * omap34xx_suspend() - This bit of code just executes the WFI - * for normal idles. - * - * Note: This code get's copied to internal SRAM at boot. When the OMAP - * wakes up it continues execution at the point it went to sleep. - */ -ENTRY(omap34xx_cpu_suspend) +/* Function to execute WFI. When the MPU wakes up from retention + * or inactive mode, it continues execution just after wfi */ fix multi-line comment style +ENTRY(omap34xx_do_wfi) stmfd sp!, {r0-r12, lr} @ save registers on stack -loop: - /*b loop*/ @Enable to debug by stepping through code - /* r0 contains restore pointer in sdram */ - /* r1 contains information about saving context */ + ldr r4, sdrc_power @ read the SDRC_POWER register ldr r5, [r4]@ read the contents of SDRC_POWER orr r5, r5, #0x40 @ enable self refresh on idle req str r5, [r4]@ write back to SDRC_POWER register - cmp r1, #0x0 - /* If context save is required, do that and execute wfi */ - bne save_context_wfi /* Data memory barrier and Data sync barrier */ mov r1, #0 mcr p15, 0, r1, c7, c10, 4 @@ -225,8 +215,182 @@ loop: nop nop bl
Re: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset()
On Mon, Oct 04, 2010, Artem Bityutskiy wrote: FYI, a similar patch is already in Linus' tree, so I'm dropping it from my tree Ok, thanks; is there something I should have done to get this patch into Linus tree? -- Loïc Minier -- 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: NOTE: hwmod changes merged to linux-omap master for testing
On Mon, Oct 4, 2010 at 9:49 AM, G, Manjunath Kondaiah manj...@ti.com wrote: Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. FWIW, for me it worked just fine with blaze -- 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: beagle hangs in uart3 disabling clocks
Hi Sanjeev, I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: [snip]..[snip] Texas Instruments X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle Board + LPDDR/NAND DRAM: 128 MB NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... I am seeing the same issue with console on UART3 on zoom3 board. The bootloaders are older. Can you please share a link to latest bootloader which will have zoom3 support. I am using L25_INC3.x android kernel. The board hangs as soon as it boots the kernel. Enabling the logs shows us that the hang occurs when UART3 clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has anyone observed this issue on any of omap boards? ~sanjeev -- 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: NOTE: hwmod changes merged to linux-omap master for testing
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Monday, October 04, 2010 6:03 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: NOTE: hwmod changes merged to linux-omap master for testing On Mon, Oct 4, 2010 at 2:20 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Can you post complete boot log? so far, it failed on one blaze and one 3430sdp both of them are having es2.0 Sure: wizery.com/ohad/blaze-linux-omap.txt.gz Here is difference: you are booting with nosmp.. console=ttyO2,115200n8 root=/dev/nfs rw rootdelay=1 mem=4...@0x8000 mem=5...@0xa000 noinitrd vram=12M omapfb.vram=0:5M,1:5M nosmp nfsroot=192.168.1.4:/home/ohad/embedded/myfs_blaze,nolock,devfs=mount ip=192.168.1.160 Remove nosmp from your bootargs and try. -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: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area
Hi, I have no access to my @nokia.com e-mail at this moment, so I'm replying using my personal one. On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, Fernando wrote: On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo, Fernando wrote: [snip] arch/arm/plat-omap/iovmm.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 24ca9c4..fc6b109 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -289,19 +289,19 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, prev_end = 0; list_for_each_entry(tmp, obj-mmap, list) { - if (prev_end = start) + if (prev_end start) break; if (start + bytes = tmp-da_start) goto found; if (flags IOVMF_DA_ANON) - start = roundup(tmp-da_end + 1, alignement); + start = roundup(tmp-da_end, alignement); There's a lack of comment here, but the purpose of tmp-da_end + 1 is to create a gap between iovm areas to force to trigger iommu faults when some access exceeds a valid area. Without this gap, such situation may produce data corruption which is much more difficult to track. That only works when you are accessing sequencially beyond the End of the vm_area. However if you are accessing a random address Which is in the mmu tables you still can corrupt memory which does Not belong to you. That looks not very effective then why waste Memory? The main intention is to detect sequential access beyond the end of the vm area and it is effective for that purpose. i.e., OMAP3 ISP has a hw issue which makes its H3A submodule, responsible to produce statistics data for the captured image, to write more data than it should. The workaround described in the errata wasn't enough to avoid error conditions, so a different approach was implemented. This gap did help me to make sure the new workaround is valid and no data corruption was occurring anymore. Anyway, I can't see why memory is being wasted. I was taking about vitual memory waste (maybe not so important). Is ok for me then keep the gap. Do other changes look good to You? Do you mean in this patch? All changes make sense only if you're removing the gap, except for the fix below. The thing is, the dspbridge needs to map some register in order to DSP can read and configure some of them. We need to map some pages with fix addresses and to do that I use iommu_kmap. So when some of that pages are contiguous I get his error: %s: no space to fit %08x(%x) flags: %08x\n Which is not true. The page to page perfectly fix, but the check with 1 byte more avoid that it could be mapped and I am getting the error. I am not agree with the gap, but I am ok when it is not fixed address as below code if (flags IOVMF_DA_ANON) start = roundup(tmp-da_end + 1, alignement); But it is breaking the tidspbridge when the gap is used for fixed addresses. It should not fail when we want to map a page what is freed just because of the gap. Please let me know what you thing. I got your point. I agree the gap shouldn't be forced for fixed da. IMO you can apply this change when !(flags IOVMF_DA_ANON). Regards, David Thanks, Fernando. [snip] prev_end = tmp-da_end; } - if ((start prev_end) (ULONG_MAX - start = bytes)) + if ((start = prev_end) (ULONG_MAX - start + 1 = bytes)) This fix is partially valid. The correct change must be only: - if ((start prev_end) (ULONG_MAX - start = bytes)) + if ((start prev_end) (ULONG_MAX - start + 1 = bytes)) Otherwise you wouldn't guarantee the gap for fixed da. Br, David -- 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 02/14] omap: Map only available sram memory
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Monday, October 04, 2010 3:08 PM To: Grazvydas Ignotas Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Russell King - ARM Linux Subject: RE: [PATCH 02/14] omap: Map only available sram memory -Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Monday, October 04, 2010 2:34 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Russell King - ARM Linux Subject: Re: [PATCH 02/14] omap: Map only available sram memory This hangs OMAP3 pandora: [ 0.00] Linux version 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-20 [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.00] Machine: Pandora Handheld Console [ 0.00] Ignoring unrecognised tag 0x54410008 [ 0.00] bootconsole [earlycon0] enabled [ 0.00] Reserving 6422528 bytes SDRAM for VRAM [ 0.00] Memory policy: ECC disabled, Data cache writeback [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 (stuck here) reverting this fixes the problem. Hmm, boots fine here with overo. Any idea what in this patch breaks pandora? The change in this patch is not board dependent really. Have tested this on 3430SDP. Pandora is OMAP3 based, right ? OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and it has the same problem. Maybe it's because of older Cortex A8 used there, or I'm missing some errata workaround in defconfig. BTW, hacking the size to 1M on top of your patch fixes the problem too: base = omap_sram_start; base = ROUND_DOWN(base, PAGE_SIZE); omap_sram_io_desc[0].pfn = __phys_to_pfn(base); - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE); + omap_sram_io_desc[0].length = 0x10; This is the exact reason this patch is created :) So that you map only available memory instead of 1 MB iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); Just booted latest mainline where this patch is already merged and my OMAP3630 boots fine ## Booting image at 8030 ... Image Name: Linux-2.6.36-rc6-00086-gd4e8aa3 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3242124 Bytes = 3.1 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Linux version 2.6.36-rc6-00086-gd4e8aa3 (a0393...@a0393909-desktop) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 Mon Oct 4 18:27:30 IST 2010 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [0.00] Machine: OMAP Zoom3 board [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] SRAM: Mapped pa 0x40208000 to va 0xfe408000 size: 0x8000 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [0.00] Kernel command line: root=/dev/ram0 rw mem=128M console=ttyS0,115200n8 noinitrd root=/dev/nfs rw nfsroot=172.24.190.46:/ubuntu/nfs-share/omap3_next/,nolock,tcp,rsize=4096,wsize=4096 ip=dhcp earlyprintk [0.00] PID hash table entries: 512 (order: -1, 2048 bytes) [0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [0.00] Memory: 128MB = 128MB total [0.00] Memory: 116148k/116148k available, 14924k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB) [0.00] vmalloc : 0xc880 - 0xf800 ( 760 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0047000 ( 252 kB) [0.00] .text : 0xc0047000 - 0xc05e9000 (5768 kB) [0.00] .data : 0xc0612000 - 0xc07e2900 (1859 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] Verbose stalled-CPUs detection is disabled. [
RE: NOTE: hwmod changes merged to linux-omap master for testing
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Monday, October 04, 2010 5:44 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: NOTE: hwmod changes merged to linux-omap master for testing On Mon, Oct 4, 2010 at 2:13 PM, G, Manjunath Kondaiah manj...@ti.com wrote: ES2.0 or ES1.0? 2.0 Can you post complete boot log? so far, it failed on one blaze and one 3430sdp both of them are having es2.0 -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: NOTE: hwmod changes merged to linux-omap master for testing
-Original Message- From: Govindraj [mailto:govindraj...@gmail.com] Sent: Monday, October 04, 2010 2:50 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: NOTE: hwmod changes merged to linux-omap master for testing On Mon, Oct 4, 2010 at 1:19 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Hi Tony, With latest merges on master branch with commit ID: 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. Looks like multiple warning dumps and finally it crashes after Freeing init memory with both NFS and ramdisk file systems. This issue though seems to exist much before hwmod merge, I tried below commit on master Mainline line kernel(2.6.36-rc6) merged only with 'omap_for_2.6.37' of git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base will work fine on omap4. -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: [PATCH v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi Sent: Monday, October 04, 2010 1:48 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Jarkko Nikula; linux-arm-ker...@lists.infradead.org Subject: [PATCH v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx From: ext Jarkko Nikula jhnik...@gmail.com An errata workaround for omap24xx is not setting the buffering disable bit 25 what is the purpose but channel enable bit 7 instead. ... diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ec7eddf..6914ccf 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -999,8 +999,9 @@ void omap_start_dma(int lch) * Errata: On ES2.0 BUFFERING disable must be set. * This will always fail on ES1.0 */ Sorry, I didn't catch this with earlier patch. Looks like wrong comment. only on 2430ES1.0 and for all omap2420, buffer disable should be set. I feel below description will be useful to the reader: Errata: Inter Frame DMA buffering issue(All OMAP2420 and OMAP2430ES1.0): DMA will wrongly buffer elements if packing and bursting is enabled. This might result in data gets stalled in FIFO at the end of the block. Workaround: DMA channels must have BUFFERING_DISABLED bit set to guarantee no data will stay in the DMA FIFO in case inter frame buffering occurs. -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: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Monday, October 04, 2010 4:13 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org; Jarkko Nikula; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish On Monday 04 October 2010 12:17:41 ext G, Manjunath Kondaiah wrote: ... + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */ This logic is required for multiple erratas. As Tony requested, I have added a variable for flags to handle the different erratas. I even added a macro to check that the errata applies, so one can use: if (IS_DMA_ERRATA(DMA_ERRATA_X)) Can we have seperate function for handling this logic. More details at: https://patchwork.kernel.org/patch/126271/ I see. That patch is for hwmod converted dma code, right? We need this fix without the hwmod to applied, and than backport it to earlier kernel releases. As I mentioned in other mail, if you are introducing this feature, it is better to convert existing erratas also to use this feature. The upcoming hwmod conversion will take care of the cleanup. If this is the case, not sure about intention of having dma_errata only for these two erratas since all the erratas are not handled. All the erratas will get cleaned up and errata handling feature will be introduced along with dma hwmod changes. If feel v3 version is better so that I can use these changes along dma hwmod. It is upto Tony to decide. We _need_ these two small fixes ASAP, since it is fixing serious problem in audio (and the same issue might bite other areas as well). It is not the intention of this series to clean up the arc/arm/plat-omap/dma.c. Tony, How about having v3 series + review comments fixed(except comments related errata handling). Errata handling will be done as part dma hwmod. I am waiting for these patches so that I can rebase these patches in DMA hwmod. -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
[PATCH] omap: devices: Avoid merge conflict between ASoC and OMAP hwmod changes
Upcoming ASoC multi-component and OMAP hwmod changes will conflict in arch/arm/mach-omap2/devices.c. Avoid this by moving a little bit include statement introduced by ASoC Multi-Component Support patch. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- This is intended to be merged with ASoC: multi-component - ASoC Multi-Component Support patch via ASoC tree. --- arch/arm/mach-omap2/devices.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 08e1ad5..512ae46 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -25,10 +25,10 @@ #include plat/control.h #include plat/tc.h #include plat/board.h +#include plat/mcbsp.h #include mach/gpio.h #include plat/mmc.h #include plat/dma.h -#include plat/mcbsp.h #include mux.h -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: multiple linux-next OMAP3 build errors
On Mon, Oct 4, 2010 at 11:59 AM, Tomi Valkeinen tomi.valkei...@nokia.com wrote: Hi, On Fri, 2010-10-01 at 17:57 +0200, ext Grazvydas Ignotas wrote: hi, I've been building linux-next for a while now and keep getting these build errors, just posting them here in case not all are known. Not familiar enough with that code to send patches unfortunately. CC drivers/video/omap2/vram.o drivers/video/omap2/vram.c: In function 'omap_vram_reserve_sdram_memblock': drivers/video/omap2/vram.c:568: error: implicit declaration of function 'memblock_region_is_memory' Benjamin, your patch memblock/arm: Use memblock_region_is_memory() for omap fb in linux-next seems to be broken. I believe the called function should be memblock_is_region_memory, not memblock_region_is_memory? I've posted this patch [1] for this. Could one of you please pick up, or fold into the original patch if it hasn't yet reached mainline? - Anand [1] https://patchwork.kernel.org/patch/224902/ -- 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 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
On Monday 04 October 2010 12:17:41 ext G, Manjunath Kondaiah wrote: ... + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */ This logic is required for multiple erratas. As Tony requested, I have added a variable for flags to handle the different erratas. I even added a macro to check that the errata applies, so one can use: if (IS_DMA_ERRATA(DMA_ERRATA_X)) Can we have seperate function for handling this logic. More details at: https://patchwork.kernel.org/patch/126271/ I see. That patch is for hwmod converted dma code, right? We need this fix without the hwmod to applied, and than backport it to earlier kernel releases. As I mentioned in other mail, if you are introducing this feature, it is better to convert existing erratas also to use this feature. The upcoming hwmod conversion will take care of the cleanup. We _need_ these two small fixes ASAP, since it is fixing serious problem in audio (and the same issue might bite other areas as well). It is not the intention of this series to clean up the arc/arm/plat-omap/dma.c. I have added the dma_errata variable, since Tony asked for it, but even that addition is a bigger change than what I was planning to do here. -- 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
[PATCH 4/5] arm/omap: remove duplicated include
Remove duplicated include. Signed-off-by: Nicolas Kaiser ni...@nikai.net --- arch/arm/mach-omap2/board-cm-t35.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index e10bc10..3308119 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -237,8 +237,6 @@ static inline void cm_t35_init_nand(void) {} defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) #include linux/spi/ads7846.h -#include plat/mcspi.h - static struct omap2_mcspi_device_config ads7846_mcspi_config = { .turbo_mode = 0, .single_channel = 1,/* 0: slave, 1: master */ -- 1.7.2.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
Re: NOTE: hwmod changes merged to linux-omap master for testing
On Mon, Oct 4, 2010 at 2:13 PM, G, Manjunath Kondaiah manj...@ti.com wrote: ES2.0 or ES1.0? 2.0 -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: beagle hangs in uart3 disabling clocks
2010/10/4 Premi, Sanjeev pr...@ti.com: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ming Lei Sent: Sunday, October 03, 2010 2:34 PM To: Kevin Hilman; linux-omap@vger.kernel.org Subject: beagle hangs in uart3 disabling clocks Hi, I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: [snip]..[snip] Texas Instruments X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle Board + LPDDR/NAND DRAM: 128 MB NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... No difference even update x-load and u-boot with those in the link below: http://code.google.com/p/beagleboard/wiki/BeagleboardRevC3Validation thanks, -- Lei Ming -- 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: Dropping omap3430 ES1.0 support in mainline
On Fri, Oct 01, 2010 at 04:58:32PM -0500, Tony Lindgren wrote: * Anand Gadiyar gadi...@ti.com [101001 14:38]: Tony, all, The OMAP3430 ES1.0 was pretty much a test chip, with the only known board being the 3430ES1.0 SDP. There are only a small number of these boards outside TI and within TI, they've likely never been used in over 2 years. It's unlikely that these boards still work on mainline, and likely have been broken in linux-omap since the very beginning. Between ES1.0 and ES2.0 we've had several major changes in the clock nodes, and IPs. However we're still keeping code/data on these in the kernel today. Since all later OMAP3 chips have been very similar to ES2.0, it probably makes sense to drop support for the ES1.0. This would result in a small but probably significant reduction in the current code. If you're okay with dropping this support, we can slowly start working on this. What do you think? No thanks! yeah, I don't like the idea of simply dropping support either and would be very happy if I had an old h2 board to fix up the omap_udc.c code which is horrible :-p -- 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 v4 3/4] OMAP2: DMA: Use errata flag for disabling buffering
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi Sent: Monday, October 04, 2010 1:48 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Jarkko Nikula; linux-arm-ker...@lists.infradead.org Subject: [PATCH v4 3/4] OMAP2: DMA: Use errata flag for disabling buffering ... /* Errata handling */ +#define DMA_ERRATA_IFRAME_BUFFERING (1 0) static u16 dma_errata; #define IS_DMA_ERRATA(id)(dma_errata (id)) These macros should move to header file since these macros will be used in mach-omap2/dma.c and plat-omap/dma.c with upcoming dma hwmod series. -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: [PATCH 08/10] OMAP: split plat-omap/common.c
-Original Message- From: Balbi, Felipe Sent: Monday, October 04, 2010 12:31 PM To: Balbi, Felipe Cc: Shilimkar, Santosh; Paul Walmsley; linux-omap@vger.kernel.org; linux- arm-ker...@lists.infradead.org Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c On Mon, Oct 04, 2010 at 01:56:24AM -0500, Balbi, Felipe wrote: On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote: Felipe, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; I remember you have converted the 32k sync time code to a platform driver. That was also addressing the multi-omap build and was removing all the compile time switches. Do you plan to rebase it and post it again ? I still have that sitting on my gitorious tree. The patch is attached to this mail. I compile tested (only) for omap3_defconfig, it probably needs to start using pm_runtime functions at some point and probably move to drivers/clocksource instead of arch/arm/plat-omap. patch is also available at [1] [1] git://gitorious.org/usb/usb.git clksource I made a few changes to make checkpatch.pl --strict happy. Attached Good !! This patch addresses splitting as well as multi-omap builds and probably also a better candidate in case we need to convert sync timer to hwmod driver. Paul, what's your take? Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/10] OMAP: split plat-omap/common.c
On Mon, 4 Oct 2010, Varadarajan, Charulatha wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: ... +#if defined(CONFIG_ARCH_OMAP2430) + +static struct omap_globals omap243x_globals = { + .class = OMAP243X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), + .sdrc = OMAP243X_SDRC_BASE, + .sms= OMAP243X_SMS_BASE, + .ctrl = OMAP243X_CTRL_BASE, + .prm= OMAP2430_PRM_BASE, + .cm = OMAP2430_CM_BASE, + .uart1_phys = OMAP2_UART1_BASE, + .uart2_phys = OMAP2_UART2_BASE, + .uart3_phys = OMAP2_UART3_BASE, +}; + +void __init omap2_set_globals_243x(void) +{ + __omap2_set_globals(omap243x_globals); +} +#endif + +#if defined(CONFIG_ARCH_OMAP3) Do you really need these #ifdefs? It would be better to avoid these #ifdefs and use cpu_is* checks. Same comment holds good across this patch. If you think you can do it better, please create a patch for the 2.6.38 time frame. I personally am not interested in changing any of this code (which was not added by this patch; the patch just splits the existing code) for the .37 merge window. +static int __init omap_init_clocksource_32k(void) +{ + static char err[] __initdata = KERN_ERR + %s: can't register clocksource!\n; + + if (cpu_is_omap16xx() || cpu_class_is_omap2()) { + struct clk *sync_32k_ick; + + if (cpu_is_omap16xx()) Avoid cpu_is* checks in plat-omap. OK, I'll bite. Why? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] OMAP: split plat-omap/common.c
On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote: Felipe, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; I remember you have converted the 32k sync time code to a platform driver. That was also addressing the multi-omap build and was removing all the compile time switches. Do you plan to rebase it and post it again ? I still have that sitting on my gitorious tree. The patch is attached to this mail. I compile tested (only) for omap3_defconfig, it probably needs to start using pm_runtime functions at some point and probably move to drivers/clocksource instead of arch/arm/plat-omap. patch is also available at [1] [1] git://gitorious.org/usb/usb.git clksource 8--- cut here - From 9aad17796072a2ee88aa11c0431fa99e8e9609f0 Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Tue, 23 Mar 2010 12:54:14 +0200 Subject: [PATCH] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver Organization: Texas Instruments\n Convert the omap32k clocksource driver into a platform_driver and while at that, also remove the ifdeferry around the code. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap1/devices.c| 24 arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c| 35 + arch/arm/plat-omap/Makefile |4 +- arch/arm/plat-omap/common.c | 158 - arch/arm/plat-omap/counter-32k.c | 251 ++ 8 files changed, 315 insertions(+), 163 deletions(-) create mode 100644 arch/arm/plat-omap/counter-32k.c diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c index aa07256..b276b4b 100644 --- a/arch/arm/mach-omap1/devices.c +++ b/arch/arm/mach-omap1/devices.c @@ -28,6 +28,29 @@ /*-*/ +#define OMAP16XX_TIMER_32K_BASE 0xfffbc400 + +static struct resource omap_32k_resources[] = { + { + .start = OMAP16XX_TIMER_32K_BASE, + .end= SZ_4K, + .flags = IORESOURCE_MEM, + }, +}; + +static struct platform_device omap_32k_device = { + .name = omap-counter-32k, + .id = -1, + .num_resources = ARRAY_SIZE(omap_32k_resources), + .resource = omap_32k_resources, +}; + +static void omap_init_32k(void) +{ + if (cpu_is_omap16xx()) + (void) platform_device_register(omap_32k_device); +}; + #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE) #define OMAP_RTC_BASE 0xfffb4800 @@ -223,6 +246,7 @@ static int __init omap1_init_devices(void) * in alphabetical order so they're easier to sort through. */ + omap_init_32k(); omap_init_mbox(); omap_init_rtc(); omap_init_spi100k(); diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c index 37d65d6..781bfeb 100644 --- a/arch/arm/mach-omap2/clock2420_data.c +++ b/arch/arm/mach-omap2/clock2420_data.c @@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = { CLK(NULL, gpios_fck, gpios_fck, CK_242X), CLK(omap_wdt, ick,mpu_wdt_ick, CK_242X), CLK(omap_wdt, fck,mpu_wdt_fck, CK_242X), - CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X), + CLK(omap-counter-32k, ick,sync_32k_ick, CK_242X), CLK(NULL, wdt1_ick, wdt1_ick, CK_242X), CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X), CLK(omap24xxcam, fck, cam_fck, CK_242X), diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c index b33118f..e997692 100644 --- a/arch/arm/mach-omap2/clock2430_data.c +++ b/arch/arm/mach-omap2/clock2430_data.c @@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = { CLK(NULL, gpios_fck, gpios_fck, CK_243X), CLK(omap_wdt, ick,mpu_wdt_ick, CK_243X), CLK(omap_wdt, fck,mpu_wdt_fck, CK_243X), - CLK(NULL, sync_32k_ick, sync_32k_ick, CK_243X), + CLK(omap-counter-32k, ick,sync_32k_ick, CK_243X), CLK(NULL, wdt1_ick, wdt1_ick, CK_243X), CLK(NULL,
Re: [PATCH] usb: musb: fix build break due to partial rename
On Sat, Oct 02, 2010 at 02:04:24AM +0530, Anand Gadiyar wrote: Patch usb gadget: don't save bind callback in struct usb_gadget_driver in Greg's USB queue missed one conversion of usb_gadget_register_driver to usb_gadget_probe_driver, causing a build break when MUSB is built in gadget mode. Fix this. Reported-by: Grazvydas Ignotas nota...@gmail.com Signed-off-by: Anand Gadiyar gadi...@ti.com Cc: Uwe Kleine-Koenigu.kleine-koe...@pengutronix.de Cc: Michal Nazarewicz m.nazarew...@samsung.com Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@suse.de Acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de --- Greg, Since Uwe's original patch isn't yet in mainline, maybe you could fold this patch into the original. drivers/usb/musb/musb_gadget.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6/drivers/usb/musb/musb_gadget.c === --- linux-2.6.orig/drivers/usb/musb/musb_gadget.c +++ linux-2.6/drivers/usb/musb/musb_gadget.c @@ -1786,7 +1786,7 @@ int usb_gadget_probe_driver(struct usb_g return retval; } -EXPORT_SYMBOL(usb_gadget_register_driver); +EXPORT_SYMBOL(usb_gadget_probe_driver); static void stop_activity(struct musb *musb, struct usb_gadget_driver *driver) { -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe
Dmitry, As agreed, can you push this patch? https://patchwork.kernel.org/patch/197442/ -Manjunath -Original Message- From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] Sent: Tuesday, September 21, 2010 9:57 PM To: G, Manjunath Kondaiah Cc: Ameya Palande; linux-omap@vger.kernel.org; linux-in...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Tony Lindgren Subject: Re: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe Hi, On Tue, Sep 21, 2010 at 07:11:01PM +0530, G, Manjunath Kondaiah wrote: Hi, -Original Message- From: Ameya Palande [mailto:ameya.pala...@nokia.com] Sent: Tuesday, September 21, 2010 7:04 PM To: G, Manjunath Kondaiah Cc: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org; Dmitry Torokhov; linux-arm-ker...@lists.infradead.org; Tony Lindgren Subject: Re: [PATCH v2] OMAP3: Keypad: Fix failure exit path in probe Hi Manjunath, On Tue, 2010-09-21 at 13:49 +0200, ext G, Manjunath Kondaiah wrote: The failure exit paths seems to be wrong in probe function. This patch corrects exit failure paths for error handling cases. And also adds memory leak... https://patchwork.kernel.org/patch/160551/ Any comments on this? Looks fine. Sorry, I didn't look at the change. This version seems to be better. I do not understand why we need to separate memory allocations. It looks like the minimal patch should be like one below. Thanks. -- Dmitry Input: twl4030_keypad - fix error handling path From: Dmitry Torokhov dmitry.torok...@gmail.com We should not try to call free_irq() when request_irq() failed. Reported-by: G, Manjunath Kondaiah manj...@ti.com Signed-off-by: Dmitry Torokhov d...@mail.ru --- drivers/input/keyboard/twl4030_keypad.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/input/keyboard/twl4030_keypad.c b/drivers/input/keyboard/twl4030_keypad.c index fb16b5e..09bef79 100644 --- a/drivers/input/keyboard/twl4030_keypad.c +++ b/drivers/input/keyboard/twl4030_keypad.c @@ -406,23 +406,22 @@ static int __devinit twl4030_kp_probe(struct platform_device *pdev) if (error) { dev_info(kp-dbg_dev, request_irq failed for irq no=%d\n, kp-irq); - goto err3; + goto err2; } /* Enable KP and TO interrupts now. */ reg = (u8) ~(KEYP_IMR1_KP | KEYP_IMR1_TO); if (twl4030_kpwrite_u8(kp, reg, KEYP_IMR1)) { error = -EIO; - goto err4; + goto err3; } platform_set_drvdata(pdev, kp); return 0; -err4: +err3: /* mask all events - we don't care about the result */ (void) twl4030_kpwrite_u8(kp, 0xff, KEYP_IMR1); -err3: free_irq(kp-irq, NULL); err2: input_unregister_device(input); -- 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: [PATCHv3 3/17] dmtimer: add omap2420 hwmod database
Hi Paul, On 10/2/2010 12:25 AM, Paul Walmsley wrote: On Thu, 30 Sep 2010, Cousson, Benoit wrote: On 9/21/2010 10:51 AM, DebBarma, Tarun Kanti wrote: #include omap_hwmod_common_data.h #include prm-regbits-24xx.h @@ -121,6 +123,614 @@ static struct omap_hwmod omap2420_l4_wkup_hwmod = { .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420), .flags = HWMOD_NO_IDLEST, }; +/* Timer Common */ +static char *timer_clk_src_names[] = { + sys_ck, + func_32k_ck, + alt_ck, + NULL, +}; I have an issue with that, because this is a pure duplication of the clock_sel information already contained in the clock data: static const struct clksel omap24xx_gpt_clksel[] = { { .parent =func_32k_ck, .rates = gpt_32k_rates }, { .parent =sys_ck, .rates = gpt_sys_rates }, { .parent =alt_ck, .rates = gpt_alt_rates }, { .parent = NULL }, }; And duplicating the same information somewhere else is most of the time a bad idea. Yep, there's no way that info should be in the hwmod data, in the current setup. It belongs in the clkdev tables. Example below. That being said... I don't really know how to handle that properly :-) We have to find a better way to select the proper source clock in a soc independent way. Maybe Paul will have some idea? Here's how it's done: http://marc.info/?l=linux-omapm=128596931017785w=2 and http://marc.info/?l=linux-omapm=128596931417805w=2 The famous clock alias... I don't know why but I always forgot that solution each time I have such concern:-( This is indeed the very clean and cool way to do that clock selection. We can even remove this #define to identified them and use the clock string name directly. Thanks Paul, Benoit -- 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: NOTE: hwmod changes merged to linux-omap master for testing
On Mon, Oct 4, 2010 at 1:19 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Hi Tony, With latest merges on master branch with commit ID: 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. Looks like multiple warning dumps and finally it crashes after Freeing init memory with both NFS and ramdisk file systems. This issue though seems to exist much before hwmod merge, I tried below commit on master commit 2365f1f7e5544b531ccd3e07fd06bb12bf7a62a7 Merge: acc012f 391bcdd Author: Tony Lindgren t...@atomide.com Date: Wed Sep 29 11:19:10 2010 -0700 Issue still reproducible. I used 4430SDP with es2.0 Not sure what is happening though. http://pastebin.com/LZKaAztT --- Regards, Govindraj.R The complete bootlogs are available at: NFS bootlog: http://pastebin.com/nrWQ5FGG Ramdisk bootlog: http://pastebin.com/1F75d2Ew -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, October 02, 2010 6:18 AM To: linux-omap@vger.kernel.org Subject: NOTE: hwmod changes merged to linux-omap master for testing Hi all, So I've finally merged Kevin's hwmod branch into the linux-omap master so we can give it some testing to see if we can merge it to the mainline. Might take few minutes to hit the mirrors. Please note that for omap2plus machines you need to change: - u-boot bootargs for kernel cmdline needs to change with setenv - if you use hardcoded CONFIG_CMDLINE, change it in your .config - /etc/inittab in your omap root file system if using serial console This is because otherwise the serial-omap would be conflicting with the 8250 driver. This should not affect omap1 machines. Please give it a try and report any issues on this list! Now all the machines except ams_delta_defconfig should build. That one is still missing some camera driver changes to build. 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 -- 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 v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi Sent: Monday, October 04, 2010 1:48 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Jarkko Nikula; linux-arm-ker...@lists.infradead.org Subject: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish ... + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */ This logic is required for multiple erratas. Can we have seperate function for handling this logic. More details at: https://patchwork.kernel.org/patch/126271/ ... --- a/arch/arm/plat-omap/include/plat/dma.h +++ b/arch/arm/plat-omap/include/plat/dma.h @@ -335,6 +335,9 @@ #define OMAP2_DMA_MISALIGNED_ERR_IRQ (1 11) #define OMAP_DMA_CCR_EN (1 7) +#define OMAP_DMA_CCR_RD_ACTIVE (1 9) +#define OMAP_DMA_CCR_WR_ACTIVE (1 10) +#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC(1 24) #define OMAP_DMA_CCR_BUFFERING_DISABLE (1 25) As I mentioned in other mail, if you are introducing this feature, it is better to convert existing erratas also to use this feature. -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: [PATCH 08/10] OMAP: split plat-omap/common.c
On Mon, Oct 04, 2010 at 01:56:24AM -0500, Balbi, Felipe wrote: On Mon, Oct 04, 2010 at 12:34:48AM -0500, Shilimkar, Santosh wrote: Felipe, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; I remember you have converted the 32k sync time code to a platform driver. That was also addressing the multi-omap build and was removing all the compile time switches. Do you plan to rebase it and post it again ? I still have that sitting on my gitorious tree. The patch is attached to this mail. I compile tested (only) for omap3_defconfig, it probably needs to start using pm_runtime functions at some point and probably move to drivers/clocksource instead of arch/arm/plat-omap. patch is also available at [1] [1] git://gitorious.org/usb/usb.git clksource I made a few changes to make checkpatch.pl --strict happy. Attached -- balbi From 42dddbbd0738b36106e8aa9851ab16851642bdd0 Mon Sep 17 00:00:00 2001 From: Felipe Balbi ba...@ti.com Date: Tue, 23 Mar 2010 12:54:14 +0200 Subject: [PATCH] arm: omap1/2/3/4: convert 32k-sync driver to a platform_driver Organization: Texas Instruments\n Convert the omap32k clocksource driver into a platform_driver and while at that, also remove the ifdeferry around the code. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap1/devices.c| 24 arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/devices.c| 35 + arch/arm/plat-omap/Makefile |4 +- arch/arm/plat-omap/common.c | 158 - arch/arm/plat-omap/counter-32k.c | 253 ++ 8 files changed, 317 insertions(+), 163 deletions(-) create mode 100644 arch/arm/plat-omap/counter-32k.c diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c index aa07256..62170fd 100644 --- a/arch/arm/mach-omap1/devices.c +++ b/arch/arm/mach-omap1/devices.c @@ -28,6 +28,29 @@ /*-*/ +#define OMAP16XX_TIMER_32K_BASE 0xfffbc400 + +static struct resource omap_32k_resources[] = { + { + .start = OMAP16XX_TIMER_32K_BASE, + .end = SZ_4K, + .flags = IORESOURCE_MEM, + }, +}; + +static struct platform_device omap_32k_device = { + .name = omap-counter-32k, + .id = -1, + .num_resources = ARRAY_SIZE(omap_32k_resources), + .resource = omap_32k_resources, +}; + +static void omap_init_32k(void) +{ + if (cpu_is_omap16xx()) + (void) platform_device_register(omap_32k_device); +}; + #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE) #define OMAP_RTC_BASE 0xfffb4800 @@ -223,6 +246,7 @@ static int __init omap1_init_devices(void) * in alphabetical order so they're easier to sort through. */ + omap_init_32k(); omap_init_mbox(); omap_init_rtc(); omap_init_spi100k(); diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c index 37d65d6..781bfeb 100644 --- a/arch/arm/mach-omap2/clock2420_data.c +++ b/arch/arm/mach-omap2/clock2420_data.c @@ -1806,7 +1806,7 @@ static struct omap_clk omap2420_clks[] = { CLK(NULL, gpios_fck, gpios_fck, CK_242X), CLK(omap_wdt, ick, mpu_wdt_ick, CK_242X), CLK(omap_wdt, fck, mpu_wdt_fck, CK_242X), - CLK(NULL, sync_32k_ick, sync_32k_ick, CK_242X), + CLK(omap-counter-32k, ick, sync_32k_ick, CK_242X), CLK(NULL, wdt1_ick, wdt1_ick, CK_242X), CLK(NULL, omapctrl_ick, omapctrl_ick, CK_242X), CLK(omap24xxcam, fck, cam_fck, CK_242X), diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c index b33118f..e997692 100644 --- a/arch/arm/mach-omap2/clock2430_data.c +++ b/arch/arm/mach-omap2/clock2430_data.c @@ -1900,7 +1900,7 @@ static struct omap_clk omap2430_clks[] = { CLK(NULL, gpios_fck, gpios_fck, CK_243X), CLK(omap_wdt, ick, mpu_wdt_ick, CK_243X), CLK(omap_wdt, fck, mpu_wdt_fck, CK_243X), - CLK(NULL, sync_32k_ick, sync_32k_ick, CK_243X), + CLK(omap-counter-32k, ick, sync_32k_ick, CK_243X), CLK(NULL, wdt1_ick, wdt1_ick, CK_243X), CLK(NULL, omapctrl_ick, omapctrl_ick, CK_243X), CLK(NULL, icr_ick, icr_ick, CK_243X), diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index dfdce2d..257a8fe 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -3343,7 +3343,7 @@ static struct omap_clk omap3xxx_clks[] = { CLK(omap_wdt, ick, wdt2_ick, CK_3XXX), CLK(NULL, wdt1_ick, wdt1_ick, CK_3XXX), CLK(NULL, gpio1_ick, gpio1_ick, CK_3XXX), -
Re: [PATCH v4 0/4] OMAP2/3: DMA: FIFO drain errata fixes
Hello, Will resend, since On Monday 04 October 2010 11:18:10 ext Peter Ujfalusi wrote: ... ext Jarkko Nikula (1): omap: dma: Fix buffering disable bit setting for omap24xx Our mail server changed Jarkko's name. Sorry. -- 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
Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
On Monday 04 October 2010 09:23:18 ext G, Manjunath Kondaiah wrote: No errata numbers numbers used with TI errata documents till omap2430. Errata numbers avaialable from omap3430 onwards. For OMAP3 the errata number is i541, but I do not know the iXYZ number for OMAP2 class. Being said that no errata numbers for omap2 class, it's ok to use omap3 errata numbers for common errata(like your patch 2/2) Thanks, we are going to use the same errata ID for OMAP2, and OMAP3, but going to use different workaround for them: OMAP2: disable buffering OMAP3: implement the workaround as it is in the errata So, as Tony suggested, I'll add the errata handling, and we are going to have: DMA_ERRATA_i541_OMAP2, and DMA_ERRATA_i541_OMAP3 to differentiate the different workarounds. We can than experiment, and we might use the OMAP3 workaround for OMAP2 as well. I'll send the v4 series shortly (after testing). -- 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
Re: beagle hangs in uart3 disabling clocks
I tried now on zoom3 with uart3[ttyO2] as console It boots up fine for me Logs: http://pastebin.com/sXR5nYcD I am using omap2plus_defconfig and lo-master commit 0882b1455797b0a104978000a622c3f2412e7cf5 Author: Tony Lindgren t...@atomide.com Date: Fri Oct 1 17:23:48 2010 -0700 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing --- Regards, Govindraj.R On Mon, Oct 4, 2010 at 5:47 PM, Pramod pramod.gu...@ti.com wrote: Hi Sanjeev, I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: [snip]..[snip] Texas Instruments X-Loader 1.41 Starting OS Bootloader... U-Boot 1.3.3 (Jul 10 2008 - 16:33:09) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle Board + LPDDR/NAND DRAM: 128 MB NAND: Lei, Couldn't help noticing the version information for x-loader and u-boot. Both seem to be quite old... Could you try update both? May be, there is a dependency... I am seeing the same issue with console on UART3 on zoom3 board. The bootloaders are older. Can you please share a link to latest bootloader which will have zoom3 support. I am using L25_INC3.x android kernel. The board hangs as soon as it boots the kernel. Enabling the logs shows us that the hang occurs when UART3 clocks are being disabled in omap_hwmod.c as mentioned by Lei Ming. Has anyone observed this issue on any of omap boards? ~sanjeev -- 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin, -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Saturday, September 25, 2010 1:28 AM To: Sripathy, Vishwanath Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr Vishwanath BS vishwanath...@ti.com writes: There is no need to keep omap3 sleep code in SRAM. This code can be run very well on DDR. /me remains skeptical This would help us to instrument CPUIdle latencies. Indeed, but... I'm afraid we will need a much more descriptive changelog here, describing in detail why this will still work, and what about the previous motiviations for running SRAM has changed such that this will work out of SRAM. Running the code from SRAM for CPUIdle was more of legacy from OMAP2 and there was no technical reason why it cannot be run from DDR. Also note that, once MPU enters off mode, wake up code used to run from DDR earlier (w/o these changes) as well. I will put more details in the change log. Tested on ZOOM3. Tested in what way? This path is used for both idle and suspend, and needs to be validated for retention and off mode. I have tested for both retention and off mode in both CPU idle and suspend path. I will update the changelog in next version. Vishwa Kevin Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Kevin Hillman khil...@deeprootsystems.com Cc: Linaro linaro-...@lists.linaro.org --- arch/arm/mach-omap2/pm34xx.c |9 + 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 85ef245..ed9d12c 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -79,8 +79,6 @@ struct power_state { static LIST_HEAD(pwrst_list); -static void (*_omap_sram_idle)(u32 *addr, int save_state); - static int (*_omap_save_secure_sram)(u32 *addr); static struct powerdomain *mpu_pwrdm, *neon_pwrdm; @@ -360,9 +358,6 @@ void omap_sram_idle(void) int core_prev_state, per_prev_state; u32 sdrc_pwr = 0; - if (!_omap_sram_idle) - return; - pwrdm_clear_all_prev_pwrst(mpu_pwrdm); pwrdm_clear_all_prev_pwrst(neon_pwrdm); pwrdm_clear_all_prev_pwrst(core_pwrdm); @@ -438,7 +433,7 @@ void omap_sram_idle(void) * get saved. The restore path then reads from this * location and restores them back. */ - _omap_sram_idle(omap3_arm_context, save_state); + omap34xx_cpu_suspend(omap3_arm_context, save_state); cpu_init(); if (is_suspending()) @@ -995,8 +990,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm, void *unused) void omap_push_sram_idle(void) { - _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend, - omap34xx_cpu_suspend_sz); if (omap_type() != OMAP2_DEVICE_TYPE_GP) _omap_save_secure_sram = omap_sram_push(save_secure_ram_context, save_secure_ram_context_sz); -- 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 02/14] omap: Map only available sram memory
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Monday, October 04, 2010 2:34 PM To: Shilimkar, Santosh Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org; Russell King - ARM Linux Subject: Re: [PATCH 02/14] omap: Map only available sram memory This hangs OMAP3 pandora: [ 0.00] Linux version 2.6.36-rc6-next-20101001-2-ge76bb53-dirty (no...@pixelinis) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-20 [ 0.00] CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f [ 0.00] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.00] Machine: Pandora Handheld Console [ 0.00] Ignoring unrecognised tag 0x54410008 [ 0.00] bootconsole [earlycon0] enabled [ 0.00] Reserving 6422528 bytes SDRAM for VRAM [ 0.00] Memory policy: ECC disabled, Data cache writeback [ 0.00] OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) [ 0.00] SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 (stuck here) reverting this fixes the problem. Hmm, boots fine here with overo. Any idea what in this patch breaks pandora? The change in this patch is not board dependent really. Have tested this on 3430SDP. Pandora is OMAP3 based, right ? OMAP3530 ES2.1, also tried on friend's beagleboard b5 (also ES2.1) and it has the same problem. Maybe it's because of older Cortex A8 used there, or I'm missing some errata workaround in defconfig. BTW, hacking the size to 1M on top of your patch fixes the problem too: base = omap_sram_start; base = ROUND_DOWN(base, PAGE_SIZE); omap_sram_io_desc[0].pfn = __phys_to_pfn(base); - omap_sram_io_desc[0].length = ROUND_DOWN(omap_sram_size, PAGE_SIZE); + omap_sram_io_desc[0].length = 0x10; This is the exact reason this patch is created :) So that you map only available memory instead of 1 MB iotable_init(omap_sram_io_desc, ARRAY_SIZE(omap_sram_io_desc)); -- 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 08/10] OMAP: split plat-omap/common.c
Hi Paul, On 10/1/2010 11:35 PM, Paul Walmsley wrote: Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c; 3. and the remainder of the OMAP-wide common code, which includes the deprecated ATAGs code and a deprecated video RAM reservation function. The primary motivation for doing this is to move the OMAP2+-specific parts into an OMAP2+-specific file, so that build breakage related to the System Control Module code can be resolved. Signed-off-by: Paul Walmsleyp...@pwsan.com --- ... diff --git a/arch/arm/plat-omap/32ksynctimer.c b/arch/arm/plat-omap/32ksynctimer.c new file mode 100644 index 000..b7f458c --- /dev/null +++ b/arch/arm/plat-omap/32ksynctimer.c @@ -0,0 +1,184 @@ +/* + * linux/arch/arm/plat-omap/clocksource.c What name do you want to use? 32ksynctimer.c or clocksource.c? If this file is dedicated for the 32k sync timer, maybe we should now use the new OMAP4 name: counter_32k. Noboby knows what the sync stand for, and at the end this is just a 32k counter. Hence the new name :-) Benoit + * + * OMAP clocksource-related code + * + * Copyright (C) 2009 Texas Instruments + * Copyright (C) 2010 Nokia Corporation + * Tony Lindgrent...@atomide.com + * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com + * Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#includelinux/kernel.h +#includelinux/init.h +#includelinux/clk.h +#includelinux/io.h + +#includeplat/common.h +#includeplat/board.h + +#includeplat/clock.h + + +/* + * 32KHz clocksource ... always available, on pretty most chips except + * OMAP 730 and 1510. Other timers could be used as clocksources, with + * higher resolution in free-running counter modes (e.g. 12 MHz xtal), + * but systems won't necessarily want to spend resources that way. + */ + +#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410 + +#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) + +#includelinux/clocksource.h + +/* + * offset_32k holds the init time counter value. It is then subtracted + * from every counter read to achieve a counter that counts time from the + * kernel boot (needed for sched_clock()). + */ +static u32 offset_32k __read_mostly; + +#ifdef CONFIG_ARCH_OMAP16XX +static cycle_t omap16xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k; +} +#else +#define omap16xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2420 +static cycle_t omap2420_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2420_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2430 +static cycle_t omap2430_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2430_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP3 +static cycle_t omap34xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap34xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP4 +static cycle_t omap44xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap44xx_32k_read NULL +#endif + +/* + * Kernel assumes that sched_clock can be called early but may not have + * things ready yet. + */ +static cycle_t omap_32k_read_dummy(struct clocksource *cs) +{ + return 0; +} + +static struct clocksource clocksource_32k = { + .name = 32k_counter, + .rating = 250, + .read = omap_32k_read_dummy, + .mask = CLOCKSOURCE_MASK(32), + .shift = 10, + .flags = CLOCK_SOURCE_IS_CONTINUOUS, +}; + +/* + * Returns current time from boot in nsecs. It's OK for this to wrap + * around for now, as it's just a relative time stamp. + */ +unsigned long long sched_clock(void) +{ + return clocksource_cyc2ns(clocksource_32k.read(clocksource_32k), + clocksource_32k.mult, clocksource_32k.shift); +} + +/** + * read_persistent_clock - Return time from a persistent clock. + * + * Reads the time from a source which isn't disabled during PM, the + * 32k sync timer. Convert the cycles elapsed since last read into + * nsecs and adds to a monotonically increasing timespec. + */ +static struct timespec persistent_ts; +static cycles_t cycles, last_cycles; +void read_persistent_clock(struct timespec *ts) +{ + unsigned long long nsecs; + cycles_t delta; + struct timespec *tsp =persistent_ts; + + last_cycles = cycles; + cycles =
Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote: 2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is not used with TI internal trees. We experimented that also on 2420 and it seemed to help but since the lockup was unrecovable I went thinking if 2420 has also another issue what original workaround was trying to fix and buffering disable was needed there. I don't have any data for 2420. Based on your observation, it is better to disable buffering for 2420. Does the same errata number applies to OMAP2 and OMAP3 as well? For OMAP3 the errata number is i541, but I do not know the iXYZ number for OMAP2 class. Thanks, 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
RE: [PATCH 01/10] OMAP2+: Kconfig: disallow builds for boards that don't use the currently-selected SoC
On Mon, 4 Oct 2010, Varadarajan, Charulatha wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:05 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Cc: Tony Lindgren Subject: [PATCH 01/10] OMAP2+: Kconfig: disallow builds for boards that don't use the currently-selected SoC ... +++ b/arch/arm/mach-omap2/board-generic.c @@ -48,10 +48,22 @@ static void __init omap_generic_init(void) static void __init omap_generic_map_io(void) { - omap2_set_globals_242x(); /* should be 242x, 243x, or 343x */ - omap242x_map_common_io(); + if (cpu_is_omap242x()) { + omap2_set_globals_242x(); + omap242x_map_common_io(); + } else if (cpu_is_omap242x()) { Is this intended for 242x() or 243x()? + omap2_set_globals_243x(); + omap243x_map_common_io(); That's for 243x(). Thanks, updated that in the branch that's posted on git.pwsan.com. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
-Original Message- From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Monday, October 04, 2010 11:13 AM To: G, Manjunath Kondaiah Cc: Peter Ujfalusi; Tony Lindgren; linux-omap@vger.kernel.org; Liam Girdwood Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx On Sat, 2 Oct 2010 10:12:50 +0530 G, Manjunath Kondaiah manj...@ti.com wrote: --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch) * This will always fail on ES1.0 */ if (cpu_is_omap24xx()) - l |= OMAP_DMA_CCR_EN; + l |= OMAP_DMA_CCR_BUFFERING_DISABLE; This issue is applicable only for 2430ES1.0(not sure about 2420) and it got fixed with later ES versions. cpu check should be replaced with: if (cpu_is_omap2420() || (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) Ok, thanks for your info, I'll change this. How about later versions of 2430? Fixed in later versions ES2.0 and ES2.1 Should they use the workaround in Patch 2/2? 2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is not used with TI internal trees. We experimented that also on 2420 and it seemed to help but since the lockup was unrecovable I went thinking if 2420 has also another issue what original workaround was trying to fix and buffering disable was needed there. I don't have any data for 2420. Based on your observation, it is better to disable buffering for 2420. -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: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
-Original Message- From: Peter Ujfalusi [mailto:peter.ujfal...@nokia.com] Sent: Monday, October 04, 2010 11:45 AM To: G, Manjunath Kondaiah Cc: Jarkko Nikula; Tony Lindgren; linux-omap@vger.kernel.org; Liam Girdwood Subject: Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx On Monday 04 October 2010 08:55:46 ext G, Manjunath Kondaiah wrote: 2/2 is applicable for all omap2plus except omap4. So far 2/2 workaround is not used with TI internal trees. We experimented that also on 2420 and it seemed to help but since the lockup was unrecovable I went thinking if 2420 has also another issue what original workaround was trying to fix and buffering disable was needed there. I don't have any data for 2420. Based on your observation, it is better to disable buffering for 2420. Does the same errata number applies to OMAP2 and OMAP3 as well? No errata numbers numbers used with TI errata documents till omap2430. Errata numbers avaialable from omap3430 onwards. For OMAP3 the errata number is i541, but I do not know the iXYZ number for OMAP2 class. Being said that no errata numbers for omap2 class, it's ok to use omap3 errata numbers for common errata(like your patch 2/2) -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: [PATCH 08/10] OMAP: split plat-omap/common.c
Hi Tarun, On 10/4/2010 11:35 AM, DebBarma, Tarun Kanti wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cousson, Benoit Sent: Monday, October 04, 2010 2:39 PM To: Paul Walmsley Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 08/10] OMAP: split plat-omap/common.c Hi Paul, On 10/1/2010 11:35 PM, Paul Walmsley wrote: Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c; 3. and the remainder of the OMAP-wide common code, which includes the deprecated ATAGs code and a deprecated video RAM reservation function. The primary motivation for doing this is to move the OMAP2+-specific parts into an OMAP2+-specific file, so that build breakage related to the System Control Module code can be resolved. Signed-off-by: Paul Walmsleyp...@pwsan.com --- ... diff --git a/arch/arm/plat-omap/32ksynctimer.c b/arch/arm/plat- omap/32ksynctimer.c new file mode 100644 index 000..b7f458c --- /dev/null +++ b/arch/arm/plat-omap/32ksynctimer.c @@ -0,0 +1,184 @@ +/* + * linux/arch/arm/plat-omap/clocksource.c What name do you want to use? 32ksynctimer.c or clocksource.c? If this file is dedicated for the 32k sync timer, maybe we should now use the new OMAP4 name: counter_32k. Noboby knows what the sync stand for, and at the end this is just a 32k counter. Hence the new name :-) One of the points to be kept in mind while naming is that we are able to relate our driver easily to the hardware device. In this regard the TRM terms this module as 32-kHz Synchronized Timer. Therefore we should be careful in our naming. With regard to the meaning of the word here is the extract from the TRM. The TRM will have to be fixed anyway to stick to the new convention. We are just anticipating in order to avoid changing that again for the next revision. OMAP4430 ES2.0 TRM ... The sync logic ensures the read transaction correctness by synchronizing the counter register read access on 32KSYNCNT_ICLK because the 32KSYNCNT_ICLK clock signal is completely asynchronous with S32KSYNCNT_FCLK. Thanks, but if this is where the sync came from, then this is the case for all modules with a very slow functional clock or even as soon as the fclk is not derived from its iclk. This is not a functionality, it is just how it should be implemented. Regards, Benoit ... Benoit + * + * OMAP clocksource-related code + * + * Copyright (C) 2009 Texas Instruments + * Copyright (C) 2010 Nokia Corporation + * Tony Lindgrent...@atomide.com + * Added OMAP4 support - Santosh Shilimkarsantosh.shilim...@ti.com + * Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#includelinux/kernel.h +#includelinux/init.h +#includelinux/clk.h +#includelinux/io.h + +#includeplat/common.h +#includeplat/board.h + +#includeplat/clock.h + + +/* + * 32KHz clocksource ... always available, on pretty most chips except + * OMAP 730 and 1510. Other timers could be used as clocksources, with + * higher resolution in free-running counter modes (e.g. 12 MHz xtal), + * but systems won't necessarily want to spend resources that way. + */ + +#define OMAP16XX_TIMER_32K_SYNCHRONIZED0xfffbc410 + +#if !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) + +#includelinux/clocksource.h + +/* + * offset_32k holds the init time counter value. It is then subtracted + * from every counter read to achieve a counter that counts time from the + * kernel boot (needed for sched_clock()). + */ +static u32 offset_32k __read_mostly; + +#ifdef CONFIG_ARCH_OMAP16XX +static cycle_t omap16xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k; +} +#else +#define omap16xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2420 +static cycle_t omap2420_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2420_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2420_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP2430 +static cycle_t omap2430_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP2430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap2430_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP3 +static cycle_t omap34xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP3430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap34xx_32k_read NULL +#endif + +#ifdef CONFIG_ARCH_OMAP4 +static cycle_t omap44xx_32k_read(struct clocksource *cs) +{ + return omap_readl(OMAP4430_32KSYNCT_BASE + 0x10) - offset_32k; +} +#else +#define omap44xx_32k_read NULL +#endif + +/* + *
[PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
Implement the suggested workaround for OMAP3 regarding to sDMA draining issue, when the channel is disabled on the fly. This errata affects the following configuration: sDMA transfer is source synchronized Buffering is enabled SmartStandby is selected. The issue can be easily reproduced by creating overrun situation while recording audio. Either introduce load to the CPU: nice -19 arecord -D hw:0 -M -B 1 -F 5000 -f dat /dev/null \ dd if=/dev/urandom of=/dev/null or suspending the arecord, and resuming it: arecord -D hw:0 -M -B 1 -F 5000 -f dat /dev/null CTRL+Z; fg; CTRL+Z; fg; ... In case of overrun audio stops DMA, and restarts it (without reseting the sDMA channel). When we hit this errata in stop case (sDMA drain did not complete), at the coming start the sDMA will not going to be operational (it is still draining). This leads to DMA stall condition. On OMAP3 we can recover with sDMA channel reset, it has been observed that by introducing unrelated sDMA activity might also help (reading from MMC for example). The same errata exists for OMAP2, where the suggestion is to disable the buffering to avoid this type of error. On OMAP3 the suggestion is to set sDMA to NoStandby before disabling the channel, and wait for the drain to finish, than configure sDMA to SmartStandby again. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Jarkko Nikula jhnik...@gmail.com Acked-by : Santosh Shilimkar santosh.shilim...@ti.com Acked-by : G, Manjunath Kondaiah manj...@ti.com --- arch/arm/plat-omap/dma.c | 42 +++- arch/arm/plat-omap/include/plat/dma.h |3 ++ 2 files changed, 43 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index c116c41..a102cf5 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -30,6 +30,7 @@ #include linux/irq.h #include linux/io.h #include linux/slab.h +#include linux/delay.h #include asm/system.h #include mach/hardware.h @@ -148,6 +149,8 @@ static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = { /* Errata handling */ #define DMA_ERRATA_IFRAME_BUFFERING(1 0) +/* OMAP3 Errata i541: sDMA FIFO draining does not finish */ +#define DMA_ERRATA_i541(1 1) static u16 dma_errata; #define IS_DMA_ERRATA(id) (dma_errata (id)) @@ -1023,8 +1026,40 @@ void omap_stop_dma(int lch) dma_write(0, CICR(lch)); l = dma_read(CCR(lch)); - l = ~OMAP_DMA_CCR_EN; - dma_write(l, CCR(lch)); + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */ + if (IS_DMA_ERRATA(DMA_ERRATA_i541) + (l OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) { + int i = 0; + u32 sys_cf; + + /* Configure No-Standby */ + l = dma_read(OCP_SYSCONFIG); + sys_cf = l; + l = ~DMA_SYSCONFIG_MIDLEMODE_MASK; + l |= DMA_SYSCONFIG_MIDLEMODE(DMA_IDLEMODE_NO_IDLE); + dma_write(l , OCP_SYSCONFIG); + + l = dma_read(CCR(lch)); + l = ~OMAP_DMA_CCR_EN; + dma_write(l, CCR(lch)); + + /* Wait for sDMA FIFO drain */ + l = dma_read(CCR(lch)); + while (i 100 (l (OMAP_DMA_CCR_RD_ACTIVE | + OMAP_DMA_CCR_WR_ACTIVE))) { + udelay(5); + i++; + l = dma_read(CCR(lch)); + } + if (i = 100) + printk(KERN_ERR DMA drain did not complete on + lch %d\n, lch); + /* Restore OCP_SYSCONFIG */ + dma_write(sys_cf, OCP_SYSCONFIG); + } else { + l = ~OMAP_DMA_CCR_EN; + dma_write(l, CCR(lch)); + } if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1) { int next_lch, cur_lch = lch; @@ -2051,6 +2086,9 @@ static void dma_errata_configure(void) if (cpu_is_omap2420() || (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) dma_errata |= DMA_ERRATA_IFRAME_BUFFERING; + + if (cpu_is_omap34xx()) + dma_errata |= DMA_ERRATA_i541; } static int __init omap_init_dma(void) diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h index 776ba44..cf66f85 100644 --- a/arch/arm/plat-omap/include/plat/dma.h +++ b/arch/arm/plat-omap/include/plat/dma.h @@ -335,6 +335,9 @@ #define OMAP2_DMA_MISALIGNED_ERR_IRQ (1 11) #define OMAP_DMA_CCR_EN(1 7) +#define OMAP_DMA_CCR_RD_ACTIVE (1 9) +#define OMAP_DMA_CCR_WR_ACTIVE (1 10) +#define OMAP_DMA_CCR_SEL_SRC_DST_SYNC (1 24) #define OMAP_DMA_CCR_BUFFERING_DISABLE (1 25) #define OMAP_DMA_DATA_TYPE_S8 0x00 -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in
RE: [PATCH 08/10] OMAP: split plat-omap/common.c
Felipe, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Saturday, October 02, 2010 3:06 AM To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: [PATCH 08/10] OMAP: split plat-omap/common.c Split plat-omap/common.c into three pieces: 1. the 32KiHz sync timer and clocksource code, which now lives in plat-omap/32ksynctimer.c; I remember you have converted the 32k sync time code to a platform driver. That was also addressing the multi-omap build and was removing all the compile time switches. Do you plan to rebase it and post it again ? 2. the OMAP2+ common code, which has been moved to mach-omap2/common.c; 3. and the remainder of the OMAP-wide common code, which includes the deprecated ATAGs code and a deprecated video RAM reservation function. The primary motivation for doing this is to move the OMAP2+-specific parts into an OMAP2+-specific file, so that build breakage related to the System Control Module code can be resolved. Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile |3 arch/arm/mach-omap2/common.c | 138 ++ arch/arm/plat-omap/32ksynctimer.c | 184 +++ arch/arm/plat-omap/Makefile |2 arch/arm/plat-omap/common.c | 291 - arch/arm/plat-omap/devices.c |1 arch/arm/plat-omap/sram.c |3 7 files changed, 325 insertions(+), 297 deletions(-) create mode 100644 arch/arm/mach-omap2/common.c create mode 100644 arch/arm/plat-omap/32ksynctimer.c diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 9edacb0..d543533 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -3,7 +3,8 @@ # # Common support -obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o +obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o \ + common.o omap-2-3-common = irq.o sdrc.o prm2xxx_3xxx.o hwmod-common = omap_hwmod.o \ diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c new file mode 100644 index 000..4e0469d --- /dev/null +++ b/arch/arm/mach-omap2/common.c @@ -0,0 +1,138 @@ +/* + * linux/arch/arm/mach-omap2/common.c + * + * Code common to all OMAP2+ machines. + * + * Copyright (C) 2009 Texas Instruments + * Copyright (C) 2010 Nokia Corporation + * Tony Lindgren t...@atomide.com + * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com + * Paul Walmsley + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include linux/kernel.h +#include linux/init.h +#include linux/clk.h +#include linux/io.h + +#include plat/common.h +#include plat/board.h +#include plat/control.h +#include plat/mux.h + +#include plat/clock.h + +#include sdrc.h + +/* Global address base setup code */ + +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) + +static void __init __omap2_set_globals(struct omap_globals *omap2_globals) +{ + omap2_set_globals_tap(omap2_globals); + omap2_set_globals_sdrc(omap2_globals); + omap2_set_globals_control(omap2_globals); + omap2_set_globals_prcm(omap2_globals); + omap2_set_globals_uart(omap2_globals); +} + +#endif + +#if defined(CONFIG_ARCH_OMAP2420) + +static struct omap_globals omap242x_globals = { + .class = OMAP242X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x48014000), + .sdrc = OMAP2420_SDRC_BASE, + .sms= OMAP2420_SMS_BASE, + .ctrl = OMAP242X_CTRL_BASE, + .prm= OMAP2420_PRM_BASE, + .cm = OMAP2420_CM_BASE, + .uart1_phys = OMAP2_UART1_BASE, + .uart2_phys = OMAP2_UART2_BASE, + .uart3_phys = OMAP2_UART3_BASE, +}; + +void __init omap2_set_globals_242x(void) +{ + __omap2_set_globals(omap242x_globals); +} +#endif + +#if defined(CONFIG_ARCH_OMAP2430) + +static struct omap_globals omap243x_globals = { + .class = OMAP243X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), + .sdrc = OMAP243X_SDRC_BASE, + .sms= OMAP243X_SMS_BASE, + .ctrl = OMAP243X_CTRL_BASE, + .prm= OMAP2430_PRM_BASE, + .cm = OMAP2430_CM_BASE, + .uart1_phys = OMAP2_UART1_BASE, + .uart2_phys = OMAP2_UART2_BASE, + .uart3_phys = OMAP2_UART3_BASE, +}; + +void __init omap2_set_globals_243x(void) +{ + __omap2_set_globals(omap243x_globals); +} +#endif + +#if defined(CONFIG_ARCH_OMAP3) + +static struct omap_globals omap3_globals = { + .class = OMAP343X_CLASS, + .tap= OMAP2_L4_IO_ADDRESS(0x4830A000), + .sdrc =
Re: [PATCH v3 1/2] omap: dma: Fix buffering disable bit setting for omap24xx
On Sat, 2 Oct 2010 10:12:50 +0530 G, Manjunath Kondaiah manj...@ti.com wrote: --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -1000,7 +1000,7 @@ void omap_start_dma(int lch) * This will always fail on ES1.0 */ if (cpu_is_omap24xx()) - l |= OMAP_DMA_CCR_EN; + l |= OMAP_DMA_CCR_BUFFERING_DISABLE; This issue is applicable only for 2430ES1.0(not sure about 2420) and it got fixed with later ES versions. cpu check should be replaced with: if (cpu_is_omap2420() || (cpu_is_omap2430() (omap_type() == OMAP2430_REV_ES1_0))) Ok, thanks for your info, I'll change this. How about later versions of 2430? Should they use the workaround in Patch 2/2? We experimented that also on 2420 and it seemed to help but since the lockup was unrecovable I went thinking if 2420 has also another issue what original workaround was trying to fix and buffering disable was needed there. -- 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: [PATCHv3 17/17] dmtimer: remove OCP config code from plat-omap
On 9/21/2010 10:56 AM, DebBarma, Tarun Kanti wrote: This patch removes the ocp config code from omap-plat because they are supposed to be taken care of by the hwmod framework. Specifically, following changes are incorporated: (1) setting of smart-idle and wakeup-enable is already taken care in existing code and so they are simply removed from plat-omap (2) clockactivity configuration is not present in the present hwmod database. Therefore this filed is initialized to '1' in Typo. respective database. Could you explain why, the default setting is not working for the timers? Signed-off-by: Tarun Kanti DebBarmatarun.ka...@ti.com Signed-off-by: Partha Basakp-bas...@ti.com Cc: Cousson, Benoitb-cous...@ti.com Cc: Paul Walmsleyp...@pwsan.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Tony Lindgrent...@atomide.com --- arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 + arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + arch/arm/plat-omap/dmtimer.c | 11 --- 5 files changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c index fc761a5..25111bf 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c @@ -168,6 +168,7 @@ static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = { SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE), .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .clockact = 1, /* preserve fclk on idle */ In theory, this field is useless unless you add a flag: SYSC_HAS_CLOCKACTIVITY. So how is it working in your case? .sysc_fields=omap_hwmod_sysc_type1, }; diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c index 2ac463f..93d5c3d 100644 --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c @@ -174,6 +174,7 @@ static struct omap_hwmod_class_sysconfig omap2430_timer_sysc = { SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE), .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .clockact = 1, /* preserve fclk on idle */ .sysc_fields=omap_hwmod_sysc_type1, }; diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index 1ce40e0..c64c95b 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -147,6 +147,7 @@ static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = { SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET | SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE), .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .clockact = 1, /* preserve fclk on idle */ .sysc_fields=omap_hwmod_sysc_type1, }; diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 9edc518..a816d30 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -538,6 +538,7 @@ static struct omap_hwmod_class_sysconfig omap44xx_timer_1ms_sysc = { SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE | SYSS_MISSING), .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART), + .clockact = 1, /* preserve fclk on idle */ .sysc_fields=omap_hwmod_sysc_type1, }; diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7d57605..6211501 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -157,17 +157,6 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer) } omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ); - l = omap_dm_timer_read_reg(timer, OMAP_TIMER_OCP_CFG_REG); - l |= 0x02 3; /* Set to smart-idle mode */ - l |= 0x2 8; /* Set clock activity to perserve f-clock on idle */ It used to be 0x2 and now you put 1: .clockact = 1, /* preserve fclk on idle */ I do not understand how that patch can work??? Benoit - - /* -* Enable wake-up on OMAP2 CPUs. -*/ - if (cpu_class_is_omap2()) - l |= 1 2; - omap_dm_timer_write_reg(timer, OMAP_TIMER_OCP_CFG_REG, l); - /* Match hardware reset default of posted mode */ omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, OMAP_TIMER_CTRL_POSTED); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3 v5] musb: add musb support for AM35x
On Fri, Oct 01, 2010 at 01:48:57AM -0500, Balbi, Felipe wrote: On Fri, Oct 01, 2010 at 01:33:49AM -0500, Gupta, Ajay Kumar wrote: Hi, [...] I couldn't fetch your gitorious tree so I just applied 14 patch set Manually on my branch. Anyways I will look into it and send the refreshed patch shortly. gitorious must be trying to make me look bad :-p Works like a charm here. Will try on a different laptop fine on another laptop too. Maybe you need to check your .git/config the correct address is git://gitorious.org/usb/usb.git I am using same address (http one) but fetch always fails while getting Index pack, 484a70e99b430800a9d93198bae32df155aecfc9 try to get it via git instead of http. seems like our servers converted TABs into spaces. Would you send (privately, even) a tarball with all the patches ?? -- 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 v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx
On Mon, 4 Oct 2010 14:44:28 +0530 G, Manjunath Kondaiah manj...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Peter Ujfalusi Sent: Monday, October 04, 2010 1:48 PM To: Tony Lindgren Cc: linux-omap@vger.kernel.org; Jarkko Nikula; linux-arm-ker...@lists.infradead.org Subject: [PATCH v4 1/4] omap: dma: Fix buffering disable bit setting for omap24xx From: ext Jarkko Nikula jhnik...@gmail.com An errata workaround for omap24xx is not setting the buffering disable bit 25 what is the purpose but channel enable bit 7 instead. ... diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c index ec7eddf..6914ccf 100644 --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -999,8 +999,9 @@ void omap_start_dma(int lch) * Errata: On ES2.0 BUFFERING disable must be set. * This will always fail on ES1.0 */ Sorry, I didn't catch this with earlier patch. Looks like wrong comment. only on 2430ES1.0 and for all omap2420, buffer disable should be set. I feel below description will be useful to the reader: Errata: Inter Frame DMA buffering issue(All OMAP2420 and OMAP2430ES1.0): DMA will wrongly buffer elements if packing and bursting is enabled. This might result in data gets stalled in FIFO at the end of the block. Workaround: DMA channels must have BUFFERING_DISABLED bit set to guarantee no data will stay in the DMA FIFO in case inter frame buffering occurs. Ok, no problem. I'll add this to the next version. This is good to get documented. -- 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
[PATCH] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
This patch adds comments on precatution to be taken if Global SW reset is used as the means to trigger sysem reset. Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prcm.c | 26 ++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index c201374..fdc860e --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -157,6 +157,32 @@ void omap_prcm_arch_reset(char mode, const char *cmd) else WARN_ON(1); + /* As per Errata i520, In some cases, user +* will not be able to access DDR memory after warm-reset. +* This situation occurs while the warm-reset happens during a read +* access to DDR memory. In that particular condition, DDR memory +* does not respond to a corrupted read command due to the warm +* reset occurence but SDRC is waiting for read completion. +* SDRC is not sensitive to the warm reset, but the interconect is +* reset on the fly, thus causing a misalignment between SDRC logic, +* interconect logic and DDR memory state. +* WORKAROUND: +* Steps to perform before a Warm reset is trigged: +* 1. enable self-refresh on idle request +* 2. put SDRC in idle +* 3. wait until SDRC goes to idle +* 4. generate SW reset (Global SW reset) + +* Steps to be performed after warm reset occurs (in bootloader): +* if HW warm reset is the source, apply below steps before any +* accesses to SDRAM: +* 1. Reset SMS and SDRC and wait till reset is complete +* 2. Re-initialize SMS, SDRC and memory + +* NOTE: Above work around is required only if arch reset is implemented +* using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need +* the WA since it resets SDRC as well as part of cold reset. */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs, OMAP2_RM_RSTCTRL); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: devices: Avoid merge conflict between ASoC and OMAP hwmod changes
On Mon, Oct 04, 2010 at 03:04:53PM +0300, Jarkko Nikula wrote: Upcoming ASoC multi-component and OMAP hwmod changes will conflict in arch/arm/mach-omap2/devices.c. Avoid this by moving a little bit include statement introduced by ASoC Multi-Component Support patch. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NOTE: hwmod changes merged to linux-omap master for testing
G, Manjunath Kondaiah manj...@ti.com writes: Hi Tony, With latest merges on master branch with commit ID: 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. Looks like multiple warning dumps and finally it crashes after Freeing init memory with both NFS and ramdisk file systems. The complete bootlogs are available at: NFS bootlog: http://pastebin.com/nrWQ5FGG In the future, it helps greatly if you state what defconfig you're using, and specifically what you've changed from the default defconfig. Looking at this log, you've enabled CPUidle in your config, which is not (yet) supported for OMAP4 in mainline. Kevin Ramdisk bootlog: http://pastebin.com/1F75d2Ew -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Saturday, October 02, 2010 6:18 AM To: linux-omap@vger.kernel.org Subject: NOTE: hwmod changes merged to linux-omap master for testing Hi all, So I've finally merged Kevin's hwmod branch into the linux-omap master so we can give it some testing to see if we can merge it to the mainline. Might take few minutes to hit the mirrors. Please note that for omap2plus machines you need to change: - u-boot bootargs for kernel cmdline needs to change with setenv - if you use hardcoded CONFIG_CMDLINE, change it in your .config - /etc/inittab in your omap root file system if using serial console This is because otherwise the serial-omap would be conflicting with the 8250 driver. This should not affect omap1 machines. Please give it a try and report any issues on this list! Now all the machines except ams_delta_defconfig should build. That one is still missing some camera driver changes to build. 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 -- 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: beagle hangs in uart3 disabling clocks
2010/10/4 Govindraj govindraj...@gmail.com: I tried now on zoom3 with uart3[ttyO2] as console It boots up fine for me Logs: http://pastebin.com/sXR5nYcD I am using omap2plus_defconfig and lo-master commit 0882b1455797b0a104978000a622c3f2412e7cf5 Author: Tony Lindgren t...@atomide.com Date: Fri Oct 1 17:23:48 2010 -0700 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could you try the pm branch of the tree? thanks, -- Lei Ming -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH [0/4] perf: clean-up of power events API
Here is a re-spin of the patches after discussion. It includes: - clean-up of the API, - a deprecation process for backward compatibility, - support for x86 and OMAP processors, - support for the following tracepoints: cpuidle, cpufreq, system suspend, clocks power domains ToDO: - documentation of the new API (once the code is agreed on), - cpu idle latency tracing not included [PATCH 1/4] perf: cleanup power events API [PATCH 2/4] perf: add OMAP support for the new power events [PATCH 3/4] perf: add calls to suspend trace point [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] perf: cleanup power events API
From: Thomas Renninger tr...@suse.de New power trace events: power:processor_idle power:processor_frequency power:machine_suspend C-state/idle accounting events: power:power_start power:power_end are replaced with: power:processor_idle and power:power_frequency is replaced with: power:processor_frequency power:machine_suspend is newly introduced, a first implementation comes from the ARM side, but it's easy to add these events in X86 as well if needed. the type= field got removed from both, it was never used and the type is differed by the event type itself. perf timechart userspace tool gets adjusted in a separate patch. Signed-off-by: Thomas Renninger tr...@suse.de CC: Jean Pihet jean.pi...@newoldbits.com CC: Arjan van de Ven ar...@linux.intel.com CC: Peter Zijlstra pet...@infradead.org CC: Ingo Molnar mi...@elte.hu CC: linux-perf-us...@vger.kernel.org CC: linux-trace-us...@vger.kernel.org CC: linux...@lists.linux-foundation.org CC: Kevin Hilman khil...@deeprootsystems.com CC: Steven Rostedt rost...@goodmis.org CC: Frank Eigler f...@redhat.com CC: Rafael Wysocki r...@sisk.pl --- arch/x86/kernel/process.c|8 ++--- arch/x86/kernel/process_32.c |2 +- arch/x86/kernel/process_64.c |2 +- drivers/cpufreq/cpufreq.c|2 +- drivers/cpuidle/cpuidle.c|2 +- drivers/idle/intel_idle.c|6 ++-- include/trace/events/power.h | 69 ++ kernel/trace/power-traces.c |3 +- 8 files changed, 47 insertions(+), 47 deletions(-) diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index e8a5ad1..284df73 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -372,7 +372,7 @@ static inline int hlt_use_halt(void) void default_idle(void) { if (hlt_use_halt()) { - trace_power_start(POWER_CSTATE, 1, smp_processor_id()); + trace_processor_idle(1, smp_processor_id()); current_thread_info()-status = ~TS_POLLING; /* * TS_POLLING-cleared state must be visible before we @@ -442,7 +442,7 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait); */ void mwait_idle_with_hints(unsigned long ax, unsigned long cx) { - trace_power_start(POWER_CSTATE, (ax4)+1, smp_processor_id()); + trace_processor_idle((ax4)+1, smp_processor_id()); if (!need_resched()) { if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR)) clflush((void *)current_thread_info()-flags); @@ -458,7 +458,7 @@ void mwait_idle_with_hints(unsigned long ax, unsigned long cx) static void mwait_idle(void) { if (!need_resched()) { - trace_power_start(POWER_CSTATE, 1, smp_processor_id()); + trace_processor_idle(1, smp_processor_id()); if (cpu_has(current_cpu_data, X86_FEATURE_CLFLUSH_MONITOR)) clflush((void *)current_thread_info()-flags); @@ -479,11 +479,9 @@ static void mwait_idle(void) */ static void poll_idle(void) { - trace_power_start(POWER_CSTATE, 0, smp_processor_id()); local_irq_enable(); while (!need_resched()) cpu_relax(); - trace_power_end(0); } /* diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 96586c3..8dee35c 100644 --- a/arch/x86/kernel/process_32.c +++ b/arch/x86/kernel/process_32.c @@ -114,7 +114,7 @@ void cpu_idle(void) pm_idle(); start_critical_timings(); - trace_power_end(smp_processor_id()); + trace_processor_idle(0, smp_processor_id()); } tick_nohz_restart_sched_tick(); preempt_enable_no_resched(); diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index b3d7a3a..d30069a 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -141,7 +141,7 @@ void cpu_idle(void) pm_idle(); start_critical_timings(); - trace_power_end(smp_processor_id()); + trace_processor_idle(0, smp_processor_id()); /* In many cases the interrupt that ended idle has already called exit_idle. But some idle diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 199dcb9..8c0dbe6 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -354,7 +354,7 @@ void cpufreq_notify_transition(struct cpufreq_freqs *freqs, unsigned int state) adjust_jiffies(CPUFREQ_POSTCHANGE, freqs); dprintk(FREQ: %lu - CPU: %lu, (unsigned long)freqs-new, (unsigned long)freqs-cpu); - trace_power_frequency(POWER_PSTATE, freqs-new, freqs-cpu); + trace_processor_frequency(freqs-new, freqs-cpu);
[PATCH 2/4] perf: add OMAP support for the new power events
The patch adds the new power management trace points for the OMAP architecture. The trace points are for cpuidle, cpufreq (DVFS), the clocks changes (enable, disable, set_rate) and the power domains transitions. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c |3 +++ arch/arm/mach-omap2/pm34xx.c |5 + arch/arm/mach-omap2/powerdomain.c |3 +++ arch/arm/plat-omap/clock.c| 13 ++--- arch/arm/plat-omap/cpu-omap.c |2 ++ 5 files changed, 23 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 3d3d035..96a6f38 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -24,6 +24,7 @@ #include linux/sched.h #include linux/cpuidle.h +#include trace/events/power.h #include plat/prcm.h #include plat/irqs.h @@ -130,6 +131,8 @@ static int omap3_enter_idle(struct cpuidle_device *dev, local_irq_disable(); local_fiq_disable(); + trace_processor_idle(cx-type, smp_processor_id()); + pwrdm_set_next_pwrst(mpu_pd, mpu_state); pwrdm_set_next_pwrst(core_pd, core_state); diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7b03426..4b5383f 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -28,6 +28,7 @@ #include linux/clk.h #include linux/delay.h #include linux/slab.h +#include trace/events/power.h #include plat/sram.h #include plat/clockdomain.h @@ -557,6 +558,8 @@ static void omap3_pm_idle(void) if (omap_irq_pending() || need_resched()) goto out; + trace_processor_idle(1, smp_processor_id()); + omap_sram_idle(); out: @@ -623,6 +626,8 @@ restore: printk(KERN_INFO Powerdomain (%s) didn't enter target state %d\n, pwrst-pwrdm-name, pwrst-next_state); + trace_power_domain_missed(pwrst-pwrdm-name, + state, smp_processor_id()); ret = -1; } set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state); diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 6527ec3..73cbe9a 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -23,6 +23,7 @@ #include linux/errno.h #include linux/err.h #include linux/io.h +#include trace/events/power.h #include asm/atomic.h @@ -440,6 +441,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst) pr_debug(powerdomain: setting next powerstate for %s to %0x\n, pwrdm-name, pwrst); + trace_power_domain_target(pwrdm-name, pwrst, smp_processor_id()); + prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK, (pwrst OMAP_POWERSTATE_SHIFT), pwrdm-prcm_offs, pwrstctrl_reg_offs); diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c index 7190cbd..d6518f5 100644 --- a/arch/arm/plat-omap/clock.c +++ b/arch/arm/plat-omap/clock.c @@ -21,6 +21,7 @@ #include linux/cpufreq.h #include linux/debugfs.h #include linux/io.h +#include trace/events/power.h #include plat/clock.h @@ -43,8 +44,10 @@ int clk_enable(struct clk *clk) return -EINVAL; spin_lock_irqsave(clockfw_lock, flags); - if (arch_clock-clk_enable) + if (arch_clock-clk_enable) { + trace_clock_enable(clk-name, 1, smp_processor_id()); ret = arch_clock-clk_enable(clk); + } spin_unlock_irqrestore(clockfw_lock, flags); return ret; @@ -66,8 +69,10 @@ void clk_disable(struct clk *clk) goto out; } - if (arch_clock-clk_disable) + if (arch_clock-clk_disable) { + trace_clock_disable(clk-name, 0, smp_processor_id()); arch_clock-clk_disable(clk); + } out: spin_unlock_irqrestore(clockfw_lock, flags); @@ -120,8 +125,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate) return ret; spin_lock_irqsave(clockfw_lock, flags); - if (arch_clock-clk_set_rate) + if (arch_clock-clk_set_rate) { + trace_clock_set_rate(clk-name, rate, smp_processor_id()); ret = arch_clock-clk_set_rate(clk, rate); + } if (ret == 0) { if (clk-recalc) clk-rate = clk-recalc(clk); diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 6d3d333..19d5a6c 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -21,6 +21,7 @@ #include linux/err.h #include linux/clk.h #include linux/io.h +#include trace/events/power.h #include mach/hardware.h #include plat/clock.h @@ -95,6 +96,7 @@ static int omap_target(struct cpufreq_policy *policy,
[PATCH 3/4] perf: add calls to suspend trace point
Uses the machine_suspend trace point, from the generic kernel suspend_enter function. Signed-off-by: Jean Pihet j-pi...@ti.com CC: Thomas Renninger tr...@suse.de --- kernel/power/suspend.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c index 7335952..10cad5c 100644 --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -22,6 +22,7 @@ #include linux/mm.h #include linux/slab.h #include linux/suspend.h +#include trace/events/power.h #include power.h @@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state) error = sysdev_suspend(PMSG_SUSPEND); if (!error) { if (!suspend_test(TEST_CORE) pm_check_wakeup_events()) { + trace_machine_suspend(state); error = suspend_ops-enter(state); + trace_machine_suspend(0); events_check_enabled = false; } sysdev_resume(); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space
Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING option in order to provide backward compatibility with the user space tracing tools. To be removed as soon as the tools are in sync with the new API. Note: only the old events are mapped to. Signed-off-by: Jean Pihet j-pi...@ti.com CC: Thomas Renninger tr...@suse.de --- include/trace/events/power.h | 98 ++ kernel/trace/Kconfig |4 ++ kernel/trace/power-traces.c |4 ++ 3 files changed, 106 insertions(+), 0 deletions(-) diff --git a/include/trace/events/power.h b/include/trace/events/power.h index 00bf175..dd00512 100644 --- a/include/trace/events/power.h +++ b/include/trace/events/power.h @@ -7,6 +7,103 @@ #include linux/ktime.h #include linux/tracepoint.h + +#ifdef CONFIG_DEPRECATED_POWER_EVENT_TRACING +/* + * Keep the old power API for user space tools backward compatibility. + * To be removed as soon as the tools are in sync with the new API. + * + * Note: only the old events are mapped to. + * + * The mapping is as follows: + * - trace_processor_idle(state != 0, cpu_id) = + * trace_power_start(POWER_CSTATE, state, cpu_id) + * - trace_processor_idle(state == 0, cpu_id) = + * trace_power_end(cpu_id) + * - trace_processor_frequency(frequency, cpu_id) = + * trace_power_frequency(POWER_PSTATE, frequency, cpu_id) + * + */ + +/* Define old API events */ +#ifndef _TRACE_POWER_OLD_API_ +#define _TRACE_POWER_OLD_API_ +enum { + POWER_NONE = 0, + POWER_CSTATE = 1, + POWER_PSTATE = 2, +}; +#endif /* _TRACE_POWER_OLD_API_ */ + +DECLARE_EVENT_CLASS(power, + + TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id), + + TP_ARGS(type, state, cpu_id), + + TP_STRUCT__entry( + __field(u64,type) + __field(u64,state ) + __field(u64,cpu_id ) + ), + + TP_fast_assign( + __entry-type = type; + __entry-state = state; + __entry-cpu_id = cpu_id; + ), + + TP_printk(type=%lu state=%lu cpu_id=%lu, (unsigned long)__entry-type, + (unsigned long)__entry-state, (unsigned long)__entry-cpu_id) +); + +DEFINE_EVENT(power, power_start, + + TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id), + + TP_ARGS(type, state, cpu_id) +); + +DEFINE_EVENT(power, power_frequency, + + TP_PROTO(unsigned int type, unsigned int state, unsigned int cpu_id), + + TP_ARGS(type, state, cpu_id) +); + +TRACE_EVENT(power_end, + + TP_PROTO(unsigned int cpu_id), + + TP_ARGS(cpu_id), + + TP_STRUCT__entry( + __field(u64,cpu_id ) + ), + + TP_fast_assign( + __entry-cpu_id = cpu_id; + ), + + TP_printk(cpu_id=%lu, (unsigned long)__entry-cpu_id) +); + +/* Map new events trace points calls to old ones */ +#define trace_processor_idle(state, cpu_id)\ + do {\ + if (state != 0) \ + trace_power_start(POWER_CSTATE, state, cpu_id); \ + else\ + trace_power_end(cpu_id);\ + } while (0) + +#define trace_processor_frequency(frequency, cpu_id) \ + do {\ + trace_power_frequency(POWER_PSTATE, frequency, cpu_id); \ + } while (0) + +#else /* CONFIG_DEPRECATED_POWER_EVENT_TRACING */ + /* * The processor events class is used for cpuidle (processor_idle) and * for cpufreq (processor_frequency) @@ -44,6 +141,7 @@ DEFINE_EVENT(processor, processor_frequency, TP_ARGS(frequency, cpu_id) ); +#endif /* CONFIG_DEPRECATED_POWER_EVENT_TRACING */ /* * The machine_suspend event is used for system suspend (machine_suspend) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 538501c..dab2bc1 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -64,6 +64,10 @@ config EVENT_TRACING select CONTEXT_SWITCH_TRACER bool +config DEPRECATED_POWER_EVENT_TRACING + bool Use the deprecated power trace API + default n + config CONTEXT_SWITCH_TRACER bool diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c index abe..3a95670 100644 --- a/kernel/trace/power-traces.c +++ b/kernel/trace/power-traces.c @@ -13,4 +13,8 @@ #define CREATE_TRACE_POINTS #include trace/events/power.h +#ifdef CONFIG_DEPRECATED_POWER_EVENT_TRACING +EXPORT_TRACEPOINT_SYMBOL_GPL(power_start); +#else EXPORT_TRACEPOINT_SYMBOL_GPL(processor_idle); +#endif -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in
Re: beagle hangs in uart3 disabling clocks
Ming Lei tom.leim...@gmail.com writes: I just tested pm branch of tony's linux-omap-2.6 tree, and found my beagle will hang in uart3 disabling clocks, follows the log info: It greatly helps when you also state what defconfig you're using, and what you've changed from the default defconfig. ... more below... Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.36-rc6+ (t...@tom-lei) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #320 PREEM PT Sun Oct 3 16:46:04 CST 2010 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 Beagle Board bootconsole [earlycon0] enabled Memory policy: ECC disabled, Data cache writeback OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x1 On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c04a1a00, node_mem_map c06b8000 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone: 32512 pages, LIFO batch:7 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootdelay=1 earlyprintk initcall_de bug=1 loglevel=8 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 123068k/123068k available, 8004k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xffc0 - 0xffe0 ( 2 MB) vmalloc : 0xc880 - 0xf800 ( 760 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc0034000 ( 176 kB) .text : 0xc0034000 - 0xc046c000 (4320 kB) .data : 0xc046c000 - 0xc04a2000 ( 216 kB) Preemptable hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:402 omap_hwmod: l3_main: registering You've manually done a '#define DEBUG' in omap_hwmod.c. This does not work well with UART hwmods, especially when using a UART console and using DEBUG_LL + earlyprintk. [...] omap_hwmod: uart2: idling omap_hwmod: uart2: disabling clocks omap_device: omap-hsuart: activating omap_hwmod: uart2: enabling omap_hwmod: uart2: enabling clocks omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec omap_device: omap-hsuart: deactivating omap_hwmod: uart2: idling omap_hwmod: uart2: disabling clocks omap_device: omap-hsuart: pm_lat 0: deactivate: elapsed time 0 nsec omap_device: omap-hsuart: activating omap_hwmod: uart2: enabling omap_hwmod: uart2: enabling clocks omap_device: omap-hsuart: pm_lat 0: activate: elapsed time 0 nsec omap_device: omap-hsuart: building with 1 hwmods omap_device: omap-hsuart: counted 4 total resources across 1 hwmods omap_device: omap-hsuart: registering Registering platform device 'omap-hsuart.2'. Parent at omap device: 'omap-hsuart.2': device_add bus: 'platform': add device omap-hsuart.2 PM: Adding info for platform:omap-hsuart.2 omap_hwmod: uart3: idling omap_hwmod: uart3: disabling clocks Remember UART3 is your serial console. Basically, what is happening is that the hwmod is trying to print debug messages for all hwmod changes. As soon as UART3 is disabled, the printing will fail since that is your console, so as soon as uart3 clocks are disabled, there is a fault when the polling-mode serial driver (used for earlyprintk) tries to access the UART, and you hang. 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
tidspbridge broken?
Hi, I was trying the iommu patches but I noticed the tidspbridge driver doesn't work at all, I found two critical issues: First, the platform device is missing, so there's no way the driver can work. It seems to have been dropped from the migration to staging which happened some time ago... I would have expected somebody to notice a thing like this. I already have patches that fix this. And second, since 2.6.35, ioremap() doesn't work on RAM, so this driver cannot work anymore unless 309caa9 is reverted. I am reserving the memory with memblock, but it still fails the ioremap(), and __va() doesn't seem to work (don't know why). Has anyone tried the driver on 2.6.36-rcX? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/11] staging tidspbridge: iommu migration
Hi, On Fri, Oct 1, 2010 at 5:12 AM, Fernando Guzman Lugo x0095...@ti.com wrote: This set of patches remove the dspbridge custom mmu implementation and use iommu module instead. I suppose the driver wouldn't work in the middle of this patch series. I wanted to try this patches and experiment to see if I could come with a version that doesn't break in the middle, but it turns out the driver doesn't work at all on 2.6.36, I just sent an email with the details. Have you tried with the mainline? Or am I missing something? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] SoC Camera: add driver for OMAP1 camera interface
Sunday 03 October 2010 04:42:53 Guennadi Liakhovetski napisał(a): On Sat, 2 Oct 2010, Janusz Krzysztofik wrote: Saturday 02 October 2010 08:07:28 Guennadi Liakhovetski napisał(a): Same with this one - let's take it as is and address a couple of clean-ups later. Guennadi, Thanks for taking them both. BTW, what are your intentions about the last patch from my series still left not commented, SoC Camera: add support for g_parm / s_parm operations, http://www.spinics.net/lists/linux-media/msg22887.html ? Yes, taking that one too, thanks. I see it right, that I have to apply 3 of your patches: omap1 camera driver, ov6650 and default .[gs]_fmt for soc_camera, the rest will go via the OMAP / ARM tree, right? Right. Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area
-Original Message- From: David Cohen [mailto:daco...@gmail.com] Sent: Monday, October 04, 2010 7:11 AM To: Guzman Lugo, Fernando Cc: David Cohen; Doyu Hiroshi (Nokia-MS/Espoo); Contreras Felipe (Nokia-MS/Helsinki); Palande Ameya (Nokia-MS/Helsinki); linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area Hi, I have no access to my @nokia.com e-mail at this moment, so I'm replying using my personal one. On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, Fernando wrote: On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo, Fernando wrote: [snip] arch/arm/plat-omap/iovmm.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 24ca9c4..fc6b109 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -289,19 +289,19 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, prev_end = 0; list_for_each_entry(tmp, obj-mmap, list) { - if (prev_end = start) + if (prev_end start) break; if (start + bytes = tmp-da_start) goto found; if (flags IOVMF_DA_ANON) - start = roundup(tmp-da_end + 1, alignement); + start = roundup(tmp-da_end, alignement); There's a lack of comment here, but the purpose of tmp-da_end + 1 is to create a gap between iovm areas to force to trigger iommu faults when some access exceeds a valid area. Without this gap, such situation may produce data corruption which is much more difficult to track. That only works when you are accessing sequencially beyond the End of the vm_area. However if you are accessing a random address Which is in the mmu tables you still can corrupt memory which does Not belong to you. That looks not very effective then why waste Memory? The main intention is to detect sequential access beyond the end of the vm area and it is effective for that purpose. i.e., OMAP3 ISP has a hw issue which makes its H3A submodule, responsible to produce statistics data for the captured image, to write more data than it should. The workaround described in the errata wasn't enough to avoid error conditions, so a different approach was implemented. This gap did help me to make sure the new workaround is valid and no data corruption was occurring anymore. Anyway, I can't see why memory is being wasted. I was taking about vitual memory waste (maybe not so important). Is ok for me then keep the gap. Do other changes look good to You? Do you mean in this patch? All changes make sense only if you're removing the gap, except for the fix below. The thing is, the dspbridge needs to map some register in order to DSP can read and configure some of them. We need to map some pages with fix addresses and to do that I use iommu_kmap. So when some of that pages are contiguous I get his error: %s: no space to fit %08x(%x) flags: %08x\n Which is not true. The page to page perfectly fix, but the check with 1 byte more avoid that it could be mapped and I am getting the error. I am not agree with the gap, but I am ok when it is not fixed address as below code if (flags IOVMF_DA_ANON) start = roundup(tmp-da_end + 1, alignement); But it is breaking the tidspbridge when the gap is used for fixed addresses. It should not fail when we want to map a page what is freed just because of the gap. Please let me know what you thing. I got your point. I agree the gap shouldn't be forced for fixed da. IMO you can apply this change when !(flags IOVMF_DA_ANON). As for not fixed address it always travers the list from the Beginning. The only change need to revert in my patch is when We roundup. That means keeping: if (flags IOVMF_DA_ANON) start = roundup(tmp-da_end + 1, alignement); Is enough to create the gap for not fixed address. I will Update the patch and send them again. Thanks, Fernando. Regards, David Thanks, Fernando. [snip] prev_end = tmp-da_end; } - if ((start prev_end) (ULONG_MAX - start = bytes)) + if ((start = prev_end) (ULONG_MAX - start + 1 = bytes)) This fix is partially valid. The correct change must be only: - if ((start prev_end)
Re: [PATCH] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Vishwanath BS vishwanath...@ti.com writes: This patch adds comments on precatution to be taken if Global SW reset is used as the means to trigger sysem reset. Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Paul Walmsley p...@pwsan.com Please fix multi-line comment style. Search for 'multi-line' in Documentation/CodingStyle Kevin --- arch/arm/mach-omap2/prcm.c | 26 ++ 1 files changed, 26 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index c201374..fdc860e --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -157,6 +157,32 @@ void omap_prcm_arch_reset(char mode, const char *cmd) else WARN_ON(1); + /* As per Errata i520, In some cases, user + * will not be able to access DDR memory after warm-reset. + * This situation occurs while the warm-reset happens during a read + * access to DDR memory. In that particular condition, DDR memory + * does not respond to a corrupted read command due to the warm + * reset occurence but SDRC is waiting for read completion. + * SDRC is not sensitive to the warm reset, but the interconect is + * reset on the fly, thus causing a misalignment between SDRC logic, + * interconect logic and DDR memory state. + * WORKAROUND: + * Steps to perform before a Warm reset is trigged: + * 1. enable self-refresh on idle request + * 2. put SDRC in idle + * 3. wait until SDRC goes to idle + * 4. generate SW reset (Global SW reset) + + * Steps to be performed after warm reset occurs (in bootloader): + * if HW warm reset is the source, apply below steps before any + * accesses to SDRAM: + * 1. Reset SMS and SDRC and wait till reset is complete + * 2. Re-initialize SMS, SDRC and memory + + * NOTE: Above work around is required only if arch reset is implemented + * using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need + * the WA since it resets SDRC as well as part of cold reset. */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs, OMAP2_RM_RSTCTRL); -- 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] video/omap: remove duplicated include
Remove duplicated include. Signed-off-by: Nicolas Kaiser ni...@nikai.net --- drivers/video/omap/lcd_omap3beagle.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/video/omap/lcd_omap3beagle.c b/drivers/video/omap/lcd_omap3beagle.c index ca75cc2..ac715f9 100644 --- a/drivers/video/omap/lcd_omap3beagle.c +++ b/drivers/video/omap/lcd_omap3beagle.c @@ -26,7 +26,6 @@ #include linux/i2c/twl.h #include plat/mux.h -#include plat/mux.h #include asm/mach-types.h #include omapfb.h -- 1.7.2.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
Re: beagle hangs in uart3 disabling clocks
Ming Lei tom.leim...@gmail.com writes: 2010/10/4 Govindraj govindraj...@gmail.com: I tried now on zoom3 with uart3[ttyO2] as console It boots up fine for me Logs: http://pastebin.com/sXR5nYcD I am using omap2plus_defconfig and lo-master commit 0882b1455797b0a104978000a622c3f2412e7cf5 Author: Tony Lindgren t...@atomide.com Date: Fri Oct 1 17:23:48 2010 -0700 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Seems you are trying the master branch of Tony's linux-omap-2.6 tree, could you try the pm branch of the tree? Why? What do you need from the PM branch that is not in l-o master? The PM branch is *experimental*, and is under significant change while parts that are not yet ready for mainline are being reworked and in some cases completely re-written. IOW, the PM branch is unstable and should not be trusted. (I can say that, I am the maintainer.) ;) 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: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area
On Mon, Oct 04, 2010 at 05:37:04PM +0200, ext Guzman Lugo, Fernando wrote: -Original Message- From: David Cohen [mailto:daco...@gmail.com] Sent: Monday, October 04, 2010 7:11 AM To: Guzman Lugo, Fernando Cc: David Cohen; Doyu Hiroshi (Nokia-MS/Espoo); Contreras Felipe (Nokia-MS/Helsinki); Palande Ameya (Nokia-MS/Helsinki); linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-omap@vger.kernel.org Subject: Re: [PATCH 2/4] iovmm: fix roundup for next area and end check for the last area Hi, I have no access to my @nokia.com e-mail at this moment, so I'm replying using my personal one. On Mon, Oct 4, 2010 at 6:17 AM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Fri, Oct 01, 2010 at 09:21:36PM +0200, ext Guzman Lugo, Fernando wrote: On Fri, Oct 01, 2010 at 06:10:30PM +0200, ext Guzman Lugo, Fernando wrote: [snip] arch/arm/plat-omap/iovmm.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 24ca9c4..fc6b109 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -289,19 +289,19 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, prev_end = 0; list_for_each_entry(tmp, obj-mmap, list) { - if (prev_end = start) + if (prev_end start) break; if (start + bytes = tmp-da_start) goto found; if (flags IOVMF_DA_ANON) - start = roundup(tmp-da_end + 1, alignement); + start = roundup(tmp-da_end, alignement); There's a lack of comment here, but the purpose of tmp-da_end + 1 is to create a gap between iovm areas to force to trigger iommu faults when some access exceeds a valid area. Without this gap, such situation may produce data corruption which is much more difficult to track. That only works when you are accessing sequencially beyond the End of the vm_area. However if you are accessing a random address Which is in the mmu tables you still can corrupt memory which does Not belong to you. That looks not very effective then why waste Memory? The main intention is to detect sequential access beyond the end of the vm area and it is effective for that purpose. i.e., OMAP3 ISP has a hw issue which makes its H3A submodule, responsible to produce statistics data for the captured image, to write more data than it should. The workaround described in the errata wasn't enough to avoid error conditions, so a different approach was implemented. This gap did help me to make sure the new workaround is valid and no data corruption was occurring anymore. Anyway, I can't see why memory is being wasted. I was taking about vitual memory waste (maybe not so important). Is ok for me then keep the gap. Do other changes look good to You? Do you mean in this patch? All changes make sense only if you're removing the gap, except for the fix below. The thing is, the dspbridge needs to map some register in order to DSP can read and configure some of them. We need to map some pages with fix addresses and to do that I use iommu_kmap. So when some of that pages are contiguous I get his error: %s: no space to fit %08x(%x) flags: %08x\n Which is not true. The page to page perfectly fix, but the check with 1 byte more avoid that it could be mapped and I am getting the error. I am not agree with the gap, but I am ok when it is not fixed address as below code if (flags IOVMF_DA_ANON) start = roundup(tmp-da_end + 1, alignement); But it is breaking the tidspbridge when the gap is used for fixed addresses. It should not fail when we want to map a page what is freed just because of the gap. Please let me know what you thing. I got your point. I agree the gap shouldn't be forced for fixed da. IMO you can apply this change when !(flags IOVMF_DA_ANON). As for not fixed address it always travers the list from the Beginning. The only change need to revert in my patch is when We roundup. That means keeping: if (flags IOVMF_DA_ANON) start = roundup(tmp-da_end + 1, alignement); Is enough to create the gap for not fixed address. I will Update the patch and send them again. Sounds fine for me. Please, update the patch and I'll ack it. Br, David Thanks, Fernando. Regards, David Thanks, Fernando. [snip]
RE: tidspbridge broken?
Hi, Felipe Contreras wrote: Hi, I was trying the iommu patches but I noticed the tidspbridge driver doesn't work at all, I found two critical issues: First, the platform device is missing, so there's no way the driver can work. It seems to have been dropped from the migration to staging which happened some time ago... I would have expected somebody to notice a thing like this. I already have patches that fix this. Yes this is missing from beginning, I seeked advice on whether to send a patch for this or not, and since it would be touching mach dependent files it would be out of the scope of staging tree, however if needed: http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c This was meant to placed under dspbridge wiki, I still have to do that one. And second, since 2.6.35, ioremap() doesn't work on RAM, so this driver cannot work anymore unless 309caa9 is reverted. I am reserving the memory with memblock, but it still fails the ioremap(), and __va() doesn't seem to work (don't know why). Yes that's true, so far the only solution I have seen is to move the allocation on memory outside kernel control, I believe framebuffer has the same problem, but I haven't contacted them to see if we can align on a common solution. Has anyone tried the driver on 2.6.36-rcX? Yes I have, I was rebasing your mailbox hwmod patches but seems something has changed since they don't work, I was trying to write my own version. After that, I was planning the migration from bridge tasklet to a process context, and see how it works, since the spin_lock method used in the mailbox driver also causes an invalid locking condition. Regards, Omar-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
This patch adds comments on precatution to be taken if Global Warm reset is used as the means to trigger sysem reset. Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prcm.c | 28 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index c201374..6494a88 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -157,6 +157,34 @@ void omap_prcm_arch_reset(char mode, const char *cmd) else WARN_ON(1); + /* +* As per Errata i520, In some cases, user will not be able to +* access DDR memory after warm-reset. +* This situation occurs while the warm-reset happens during a read +* access to DDR memory. In that particular condition, DDR memory +* does not respond to a corrupted read command due to the warm +* reset occurence but SDRC is waiting for read completion. +* SDRC is not sensitive to the warm reset, but the interconect is +* reset on the fly, thus causing a misalignment between SDRC logic, +* interconect logic and DDR memory state. +* WORKAROUND: +* Steps to perform before a Warm reset is trigged: +* 1. enable self-refresh on idle request +* 2. put SDRC in idle +* 3. wait until SDRC goes to idle +* 4. generate SW reset (Global SW reset) + +* Steps to be performed after warm reset occurs (in bootloader): +* if HW warm reset is the source, apply below steps before any +* accesses to SDRAM: +* 1. Reset SMS and SDRC and wait till reset is complete +* 2. Re-initialize SMS, SDRC and memory + +* NOTE: Above work around is required only if arch reset is implemented +* using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need +* the WA since it resets SDRC as well as part of cold reset. +*/ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs, OMAP2_RM_RSTCTRL); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] omap: dsp: make the driver actually work
Hi, It seems the platform device was dropped from the migration of tidspbridge into staging, plus the sdram meblock (previously bootmem) required for it work are gone. Withouth these patches the driver loads, but doesn't do anything. A second issue with ioremap() still remains, but that can be solved by reverting 309caa9. I think these might be worth to get into 2.6.36, if not, I have versions with more changes; cleanups and so on. Tested on a Nokia N900. Felipe Contreras (2): omap: add dsp platform device staging: tidspbridge: use omap_dsp_platform_data arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/dsp.c | 85 arch/arm/plat-omap/common.c|2 + arch/arm/plat-omap/devices.c | 30 +++ arch/arm/plat-omap/include/plat/dsp.h | 31 +++ drivers/staging/tidspbridge/core/tiomap3430.c | 14 ++-- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 14 ++-- drivers/staging/tidspbridge/core/tiomap_io.c |4 +- .../tidspbridge/include/dspbridge/host_os.h| 19 - drivers/staging/tidspbridge/rmgr/drv_interface.c | 10 ++- 10 files changed, 177 insertions(+), 36 deletions(-) create mode 100644 arch/arm/mach-omap2/dsp.c create mode 100644 arch/arm/plat-omap/include/plat/dsp.h -- 1.7.3.1.2.g7fe2b -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap: add dsp platform device
Otherwise tidspbridge cannot work. It looks like this was dropped in the conversion to staging. I took the liberty of doing some cleaning up. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- arch/arm/mach-omap2/Makefile |4 ++ arch/arm/mach-omap2/dsp.c | 85 + arch/arm/plat-omap/common.c |2 + arch/arm/plat-omap/devices.c | 30 arch/arm/plat-omap/include/plat/dsp.h | 31 5 files changed, 152 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/dsp.c create mode 100644 arch/arm/plat-omap/include/plat/dsp.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 88d3a1e..58288a4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -102,6 +102,10 @@ obj-y += $(iommu-m) $(iommu-y) i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o obj-y += $(i2c-omap-m) $(i2c-omap-y) +ifneq ($(CONFIG_TIDSPBRIDGE),) +obj-y += dsp.o +endif + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o diff --git a/arch/arm/mach-omap2/dsp.c b/arch/arm/mach-omap2/dsp.c new file mode 100644 index 000..6feeeae --- /dev/null +++ b/arch/arm/mach-omap2/dsp.c @@ -0,0 +1,85 @@ +/* + * TI's OMAP DSP platform device registration + * + * Copyright (C) 2005-2006 Texas Instruments, Inc. + * Copyright (C) 2009 Nokia Corporation + * + * Written by Hiroshi DOYU hiroshi.d...@nokia.com + * + * 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. + */ + +#include linux/platform_device.h +#include prm.h +#include cm.h +#ifdef CONFIG_BRIDGE_DVFS +#include plat/omap-pm.h +#endif + +#include plat/dsp.h + +extern phys_addr_t omap_dsp_get_mempool_base(void); + +static struct platform_device *omap_dsp_pdev; + +static struct omap_dsp_platform_data omap_dsp_pdata __initdata = { +#ifdef CONFIG_BRIDGE_DVFS + .dsp_set_min_opp = omap_pm_dsp_set_min_opp, + .dsp_get_opp = omap_pm_dsp_get_opp, + .cpu_set_freq = omap_pm_cpu_set_freq, + .cpu_get_freq = omap_pm_cpu_get_freq, +#endif + .dsp_prm_read = prm_read_mod_reg, + .dsp_prm_write = prm_write_mod_reg, + .dsp_prm_rmw_bits = prm_rmw_mod_reg_bits, + .dsp_cm_read = cm_read_mod_reg, + .dsp_cm_write = cm_write_mod_reg, + .dsp_cm_rmw_bits = cm_rmw_mod_reg_bits, +}; + +static int __init omap_dsp_init(void) +{ + struct platform_device *pdev; + int err = -ENOMEM; + struct omap_dsp_platform_data *pdata = omap_dsp_pdata; + + pdata-phys_mempool_base = omap_dsp_get_mempool_base(); + + if (pdata-phys_mempool_base) { + pdata-phys_mempool_size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE; + pr_info(%s: %x bytes @ %x\n, __func__, + pdata-phys_mempool_size, pdata-phys_mempool_base); + } + + pdev = platform_device_alloc(omap-dsp, -1); + if (!pdev) + goto err_out; + + err = platform_device_add_data(pdev, pdata, sizeof(*pdata)); + if (err) + goto err_out; + + err = platform_device_add(pdev); + if (err) + goto err_out; + + omap_dsp_pdev = pdev; + return 0; + +err_out: + platform_device_put(pdev); + return err; +} +module_init(omap_dsp_init); + +static void __exit omap_dsp_exit(void) +{ + platform_device_unregister(omap_dsp_pdev); +} +module_exit(omap_dsp_exit); + +MODULE_AUTHOR(Hiroshi DOYU); +MODULE_DESCRIPTION(TI's OMAP DSP platform device registration); +MODULE_LICENSE(GPL); diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 3008e71..57205a4 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -37,6 +37,7 @@ #include plat/fpga.h #include plat/serial.h #include plat/vram.h +#include plat/dsp.h #include plat/clock.h @@ -87,6 +88,7 @@ void __init omap_reserve(void) { omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); + omap_dsp_reserve_sdram_memblock(); } /* diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c index d1920be..4c8f9b9 100644 --- a/arch/arm/plat-omap/devices.c +++ b/arch/arm/plat-omap/devices.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/io.h #include linux/slab.h +#include linux/memblock.h #include mach/hardware.h #include asm/mach-types.h @@ -272,6 +273,35 @@ static void omap_init_wdt(void) static inline void omap_init_wdt(void) {} #endif +#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE) + +static phys_addr_t omap_dsp_phys_mempool_base; + +void __init omap_dsp_reserve_sdram_memblock(void)
[PATCH 2/2] staging: tidspbridge: use omap_dsp_platform_data
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- drivers/staging/tidspbridge/core/tiomap3430.c | 14 -- drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 14 -- drivers/staging/tidspbridge/core/tiomap_io.c |4 +++- .../tidspbridge/include/dspbridge/host_os.h| 19 --- drivers/staging/tidspbridge/rmgr/drv_interface.c | 10 ++ 5 files changed, 25 insertions(+), 36 deletions(-) diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c index f914829..5aefc95 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430.c +++ b/drivers/staging/tidspbridge/core/tiomap3430.c @@ -16,6 +16,8 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +#include plat/dsp.h + #include linux/types.h /* --- Host OS */ #include dspbridge/host_os.h @@ -264,8 +266,8 @@ static int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt) { struct bridge_dev_context *dev_context = dev_ctxt; u32 temp; - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; temp = (*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) OMAP_POWERSTATEST_MASK; @@ -374,8 +376,8 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt, u32 clk_cmd; struct io_mgr *hio_mgr; u32 ul_load_monitor_timer; - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; /* The device context contains all the mmu setup info from when the * last dsp base image was loaded. The first entry is always @@ -627,8 +629,8 @@ static int bridge_brd_stop(struct bridge_dev_context *dev_ctxt) struct pg_table_attrs *pt_attrs; u32 dsp_pwr_state; int clk_status; - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; if (dev_context-dw_brd_state == BRD_STOPPED) return status; diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c index b789f8f..1bea23f 100644 --- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c +++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c @@ -16,6 +16,8 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +#include plat/dsp.h + /* --- DSP/BIOS Bridge */ #include dspbridge/dbdefs.h #include dspbridge/cfg.h @@ -54,8 +56,8 @@ int handle_constraints_set(struct bridge_dev_context *dev_context, { #ifdef CONFIG_TIDSPBRIDGE_DVFS u32 *constraint_val; - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; constraint_val = (u32 *) (pargs); /* Read the target value requested by DSP */ @@ -83,8 +85,8 @@ int handle_hibernation_from_dsp(struct bridge_dev_context *dev_context) u32 opplevel; struct io_mgr *hio_mgr; #endif - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; pwr_state = (*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, OMAP2_PM_PWSTST) OMAP_POWERSTATEST_MASK; @@ -152,8 +154,8 @@ int sleep_dsp(struct bridge_dev_context *dev_context, u32 dw_cmd, #endif /* CONFIG_TIDSPBRIDGE_NTFY_PWRERR */ u16 timeout = PWRSTST_TIMEOUT / 10; u32 pwr_state, target_pwr_state; - struct dspbridge_platform_data *pdata = - omap_dspbridge_dev-dev.platform_data; + struct omap_dsp_platform_data *pdata = + omap_dspbridge_dev-dev.platform_data; /* Check if sleep code is valid */ if ((dw_cmd != PWR_DEEPSLEEP) (dw_cmd != PWR_EMERGENCYDEEPSLEEP)) diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c b/drivers/staging/tidspbridge/core/tiomap_io.c index 190c028..2a3cd45 100644 --- a/drivers/staging/tidspbridge/core/tiomap_io.c +++ b/drivers/staging/tidspbridge/core/tiomap_io.c @@ -16,6 +16,8 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ +#include plat/dsp.h + /* --- DSP/BIOS Bridge */ #include dspbridge/dbdefs.h @@ -388,7 +390,7 @@ int sm_interrupt_dsp(struct
Re: [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space
Hi - Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING option in order to provide backward compatibility with the user space tracing tools. This is clever: +/* Map new events trace points calls to old ones */ +#define trace_processor_idle(state, cpu_id) \ + do {\ + if (state != 0) \ + trace_power_start(POWER_CSTATE, state, cpu_id); \ + else\ + trace_power_end(cpu_id);\ + } while (0) but with this code, are the new tracepoints firing at all? In other words, does this backward-compatibility config option effectively disable the newer ones? If so, this is probably avoidable. Instead of redirecting the new tracepoint calls to these macros, an alternative may intercept (un)registration for the old tracepoint names, and map them to (un)registration of the real tracepoints. See how syscall tracepoints map to a special (un)registration callback in include/trace/events/syscalls.h (syscall_*regfunc). Instead of setting a TIF flag, the new functions can call register_processor_idle() et al., and their respective callbacks can call the backward-compatibility tracepoints. The starting point would be to recast the power_start, power_end, power_frequency tracepoints via TRACE_EVENT_FN() instead of TRACE_EVENT(). - FChE -- 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] OMAP3: SDRC : Add comments on Errata i520 for Global SW reset
Hi Vishwa, On Mon, 4 Oct 2010, Vishwanath BS wrote: This patch adds comments on precatution to be taken if Global Warm reset is used as the means to trigger sysem reset. thanks for this but the comment style still needs at least one more fix per Documentation/CodingStyle: The preferred style for long (multi-line) comments is: /* * This is the preferred style for multi-line * comments in the Linux kernel source code. * Please use it consistently. * * Description: A column of asterisks on the left side, * with beginning and ending almost-blank lines. */ - Please make sure that every line in the comment block has an asterisk on the left side. Once you fix that and repost, I'll queue for 2.6.38. - Paul Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prcm.c | 28 1 files changed, 28 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c index c201374..6494a88 --- a/arch/arm/mach-omap2/prcm.c +++ b/arch/arm/mach-omap2/prcm.c @@ -157,6 +157,34 @@ void omap_prcm_arch_reset(char mode, const char *cmd) else WARN_ON(1); + /* + * As per Errata i520, In some cases, user will not be able to + * access DDR memory after warm-reset. + * This situation occurs while the warm-reset happens during a read + * access to DDR memory. In that particular condition, DDR memory + * does not respond to a corrupted read command due to the warm + * reset occurence but SDRC is waiting for read completion. + * SDRC is not sensitive to the warm reset, but the interconect is + * reset on the fly, thus causing a misalignment between SDRC logic, + * interconect logic and DDR memory state. + * WORKAROUND: + * Steps to perform before a Warm reset is trigged: + * 1. enable self-refresh on idle request + * 2. put SDRC in idle + * 3. wait until SDRC goes to idle + * 4. generate SW reset (Global SW reset) + + * Steps to be performed after warm reset occurs (in bootloader): + * if HW warm reset is the source, apply below steps before any + * accesses to SDRAM: + * 1. Reset SMS and SDRC and wait till reset is complete + * 2. Re-initialize SMS, SDRC and memory + + * NOTE: Above work around is required only if arch reset is implemented + * using Global SW reset(GLOBAL_SW_RST). DPLL3 reset does not need + * the WA since it resets SDRC as well as part of cold reset. + */ + if (cpu_is_omap24xx() || cpu_is_omap34xx()) prm_set_mod_reg_bits(OMAP_RST_DPLL3_MASK, prcm_offs, OMAP2_RM_RSTCTRL); -- 1.7.0.4 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beagle hangs in uart3 disabling clocks
2010/10/4 Kevin Hilman khil...@deeprootsystems.com: Why? What do you need from the PM branch that is not in l-o master? Seems master branch works fine for me, my beagle board doesn't hang uart3 disabling clocks. I only want to have a try of the runtime pm feature of omap3, so use PM branch to do the test. The PM branch is *experimental*, and is under significant change while parts that are not yet ready for mainline are being reworked and in some cases completely re-written. IOW, the PM branch is unstable and should not be trusted. (I can say that, I am the maintainer.) ;) I see now, :-) -- Lei Ming -- 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: tidspbridge broken?
Hi, On Mon, Oct 4, 2010 at 6:59 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote: Felipe Contreras wrote: I was trying the iommu patches but I noticed the tidspbridge driver doesn't work at all, I found two critical issues: First, the platform device is missing, so there's no way the driver can work. It seems to have been dropped from the migration to staging which happened some time ago... I would have expected somebody to notice a thing like this. I already have patches that fix this. Yes this is missing from beginning, I seeked advice on whether to send a patch for this or not, and since it would be touching mach dependent files it would be out of the scope of staging tree, however if needed: http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=4dcb41d484653d162b2bc6e1bf226c2dad0b953c This was meant to placed under dspbridge wiki, I still have to do that one. This seems to be worth mentioning in the TODO file: * Make it actually work Anyway, first, I think I tried a version similar to that one, and doesn't apply on mainline any more, also, bootmem doesn't seem to be working on ARM either, so I had to move to memblock, and third, I don't think that platform device is correct since it depends on the headers of a driver. My version is basically the same, but using memblock, and stands on it's own. Even if tidspbridge wasn't in staging I think this could go to mainline, plus, perhaps other implementations like dsp-link could make use of it (who knows): http://article.gmane.org/gmane.linux.kernel/1044209 And second, since 2.6.35, ioremap() doesn't work on RAM, so this driver cannot work anymore unless 309caa9 is reverted. I am reserving the memory with memblock, but it still fails the ioremap(), and __va() doesn't seem to work (don't know why). Yes that's true, so far the only solution I have seen is to move the allocation on memory outside kernel control, I believe framebuffer has the same problem, but I haven't contacted them to see if we can align on a common solution. At least on my N900 the framebuffer is not working either, and I've heard the same on beagleboard. Maybe something like this: http://article.gmane.org/gmane.linux.kernel.mm/52757 Has anyone tried the driver on 2.6.36-rcX? Yes I have, I guess by applying your patches on top and reverting 309caa9. I was rebasing your mailbox hwmod patches but seems something has changed since they don't work, I was trying to write my own version. You should have said so, I'll try to rebase myself. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve -- 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/2] mmc: omap_hsmmc: support SDIO cards (#2)
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:32 AM To: Mike Rapoport Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; madhu...@ti.com Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve, I have not been able to test SDIO card interrupts. If you could help test that it's great. Regards, Madhu Steve -- 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: NOTE: hwmod changes merged to linux-omap master for testing
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Monday, October 04, 2010 8:36 PM To: G, Manjunath Kondaiah Cc: Tony Lindgren; linux-omap@vger.kernel.org Subject: Re: NOTE: hwmod changes merged to linux-omap master for testing G, Manjunath Kondaiah manj...@ti.com writes: Hi Tony, With latest merges on master branch with commit ID: 0882b1455797b0a104978000a622c3f2412e7cf5 omap: READ CAREFULLY: Fix build after merging in hwmod support for testing Booting with zoom3 seems to be fine but observed issues with omap4 blaze board. Looks like multiple warning dumps and finally it crashes after Freeing init memory with both NFS and ramdisk file systems. The complete bootlogs are available at: NFS bootlog: http://pastebin.com/nrWQ5FGG In the future, it helps greatly if you state what defconfig you're using, ok. I have used omap2plus_defconfig and specifically what you've changed from the default defconfig. No changes to defconfig Looking at this log, you've enabled CPUidle in your config, which is not (yet) supported for OMAP4 in mainline. As I mentioned no changes to defconfig and it looks like cpu idle is disabled and cpu idle wait is enabled in .config after running make omap2plus_defconfig $ cat arch/arm/configs/omap2plus_defconfig | grep CPU_IDLE $ $ make omap2plus_defconfig # # configuration written to .config # $ cat .config | grep CPU_IDLE CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y # CONFIG_CPU_IDLE is not set $ Even if I disable CPU_IDLE_WAIT manually, behaviour is same -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: [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space
Hi, On Mon, Oct 4, 2010 at 6:10 PM, Frank Ch. Eigler f...@redhat.com wrote: Hi - Provide a CONFIG_DEPRECATED_POWER_EVENT_TRACING option in order to provide backward compatibility with the user space tracing tools. This is clever: +/* Map new events trace points calls to old ones */ +#define trace_processor_idle(state, cpu_id) \ + do { \ + if (state != 0) \ + trace_power_start(POWER_CSTATE, state, cpu_id); \ + else \ + trace_power_end(cpu_id); \ + } while (0) but with this code, are the new tracepoints firing at all? In other words, does this backward-compatibility config option effectively disable the newer ones? If so, this is probably avoidable. Yes the events are fired. In fact with the CONFIG option defined the trace_processor_* trace points are not defined, only the macro remaps them (at compile time) to the old ones. Instead of redirecting the new tracepoint calls to these macros, an alternative may intercept (un)registration for the old tracepoint names, and map them to (un)registration of the real tracepoints. See how syscall tracepoints map to a special (un)registration callback in include/trace/events/syscalls.h (syscall_*regfunc). Instead of setting a TIF flag, the new functions can call register_processor_idle() et al., and their respective callbacks can call the backward-compatibility tracepoints. The starting point would be to recast the power_start, power_end, power_frequency tracepoints via TRACE_EVENT_FN() instead of TRACE_EVENT(). That could be done but it is not easy to do. In fact the power.h is included and parsed multiple times in order to generate the trace points prototype function _and_ the trace generation code. Please check 'include/trace/ftrace.h' which is really smart but rather complicated. I am aiming at simple to read and maintainable code. Furthermore the code is going to be removed soon or later. Thanks for the suggestion! - FChE 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: mmc: remove ifdef in omap_mmc_platform_data defination
From: Ming Lei tom.leim...@gmail.com The instance of omap_mmc_platform_data is alwasy passed to mmc omap host driver from board, so remove ifdef in omap_mmc_platform_data defination to simplify handling it in mmc omap host driver. The patch fixes the compile error below: drivers/mmc/host/omap.c: In function 'mmc_omap_new_slot': drivers/mmc/host/omap.c:1320: error: 'struct omap_mmc_slot_data' has no member named 'wires' make[3]: *** [drivers/mmc/host/omap.o] Error 1 make[2]: *** [drivers/mmc/host] Error 2 make[1]: *** [drivers/mmc] Error 2 make: *** [drivers] Error 2 Signed-off-by: Ming Lei tom.leim...@gmail.com --- arch/arm/plat-omap/include/plat/mmc.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h index 3107892..f57f36a 100644 --- a/arch/arm/plat-omap/include/plat/mmc.h +++ b/arch/arm/plat-omap/include/plat/mmc.h @@ -80,12 +80,8 @@ struct omap_mmc_platform_data { * 4/8 wires and any additional host capabilities * need to OR'd all capabilities (ref. linux/mmc/host.h) */ -#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2420) u8 wires; /* Used for the MMC driver on omap1 and 2420 */ -#endif -#ifdef CONFIG_ARCH_OMAP2PLUS u32 caps; /* Used for the MMC driver on 2430 and later */ -#endif /* * nomux means standard muxing is wrong on this board, and -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
* Peter Ujfalusi peter.ujfal...@nokia.com [101004 03:33]: On Monday 04 October 2010 12:17:41 ext G, Manjunath Kondaiah wrote: ... + /* OMAP3 Errata i541: sDMA FIFO draining does not finish */ This logic is required for multiple erratas. As Tony requested, I have added a variable for flags to handle the different erratas. I even added a macro to check that the errata applies, so one can use: if (IS_DMA_ERRATA(DMA_ERRATA_X)) Can we have seperate function for handling this logic. More details at: https://patchwork.kernel.org/patch/126271/ I see. That patch is for hwmod converted dma code, right? We need this fix without the hwmod to applied, and than backport it to earlier kernel releases. As I mentioned in other mail, if you are introducing this feature, it is better to convert existing erratas also to use this feature. The upcoming hwmod conversion will take care of the cleanup. We _need_ these two small fixes ASAP, since it is fixing serious problem in audio (and the same issue might bite other areas as well). It is not the intention of this series to clean up the arc/arm/plat-omap/dma.c. I have added the dma_errata variable, since Tony asked for it, but even that addition is a bigger change than what I was planning to do here. Yeah.. Let's just use your original patch for the fix, then queue adding the errata flag for the upcoming merge window. 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