Re: [GIT PULL] OMAP-GPMC cleanup for common zImage
Hi Tony, On Wednesday 17 October 2012 03:27 AM, Tony Lindgren wrote: * Afzal Mohammedaf...@ti.com [121015 05:15]: The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: g...@gitorious.org:x0148406-public/linux-kernel.git tags/gpmc-czimage for you to fetch changes up to 3ef5d0071cf6c8b9a00b559232bb700ad5d7: ARM: OMAP2+: gpmc: localize gpmc header (2012-10-15 14:42:15 +0530) gpmc cleanup for common ARM zImage Thanks pulling into omap-for-v3.8/cleanup-headers-gpmc I ended up using the following url instead: git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-czimage Thanks, realised after sending that wrong url was provided, and then sent a new pull request with proper git url as you mentioned above (new pull request was seen only in some of the archives, seems it didn't reach your mail box also). Regards Afzal -- 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
discrepancy while save and restore of debounce registers
Hi, I came across a peculiar issue while updating GPIO debounce registers on OMAP platform. According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537 gpio/omap: save and restore debounce registers GPIO debounce registers need to be saved and restored for proper functioning of driver. ... @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank *bank) __raw_writel(bank-context.fallingdetect, bank-base + bank-regs-fallingdetect); __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout); + if (bank-dbck_enable_mask) { + __raw_writel(bank-context.debounce, bank-base + + bank-regs-debounce); + __raw_writel(bank-context.debounce_en, + bank-base + bank-regs-debounce_en); + } } Due to copy/paste of this commit into my local tree, I missed the check for bank-dbck_enable_mask, and directly restored the saved value from context. After this, I saw random crashes when accessing different registers (sometimes its OE register and sometime its DATAOUT register). These crashes were seen across 2nd and subsequent suspend/resume. My doubt/questions are 1. Why should debounce registers be updated only when it's accessed previously? 2. What is the relation between updating debounce registers and crash seen on others registers? Thanks in advance for the support. Regards Gururaja
Re: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com The runtime PM framework assumes that the hardware state of devices when initialized is disabled. For all omap_devices, we idle/disable device by default. However, the console uart uses a no idle option during omap_device init in order to allow earlyprintk usage to work seamlessly during boot. Because the hardware is left partially enabled after init (whatever the bootloader settings were), the omap_device should later be fully initialized (including mux) and the runtime PM framework should be told that the device is active, and not disabled so that the hardware state is in sync with runtime PM state. To fix, after the device has been created/registered, call omap_device_enable() to finialize init and use pm_runtime_set_active() to tell the runtime PM core the device is enabled. I still believe you're better off with the approach I gave. Why? Because every driver you have contains virtually the same sequence of runtime PM initialization which is to runtime PM enable the device and then do a get on it. Why not do that in bus code if all your drivers are doing the same thing, and kill off a bunch of code in the drivers? It's fairly easy to do with the BUS_NOTIFY_BIND_DRIVER / BUS_NOTIFY_UNBIND_DRIVER bus level notifies, and you've already hooked the notifier list for these callbacks in omap_device.c -- 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: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
On Tue, Oct 16, 2012 at 8:26 PM, Tony Lindgren t...@atomide.com wrote: Hmm looking at it repeats the same code over again. Can you rather add some wl12xx_board_init() helper function to mach-omap2/devices.c to do it? Nice, see below. Note that I can only compile test this now, which may be ok because it's pretty trivial. But do let me know if you want me to get it tested. From b940fb88a97494ad3a0a093279a5f176c0b29e44 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen o...@wizery.com Date: Sun, 14 Oct 2012 20:16:01 +0200 Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't configured Stop intimidating users with scary wlan error messages in case wl12xx support wasn't even built. In addition, when wl12xx_set_platform_data() fails, don't bother registering wl12xx's fixed regulator device (on the relevant boards). While we're at it, extract the wlan init code to a dedicated function to make (the relevant boards') init code look a bit nicer. Compile tested only. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-davinci/board-da850-evm.c | 8 ++-- arch/arm/mach-omap2/board-4430sdp.c | 7 --- arch/arm/mach-omap2/board-omap3evm.c | 6 +++--- arch/arm/mach-omap2/board-omap3pandora.c | 9 +++-- arch/arm/mach-omap2/board-omap4panda.c | 20 ++-- arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++- arch/arm/mach-omap2/common-board-devices.h | 2 ++ arch/arm/mach-omap2/devices.c| 26 ++ 8 files changed, 64 insertions(+), 29 deletions(-) diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 32ee3f8..7243c22 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -1401,13 +1401,9 @@ static __init int da850_wl12xx_init(void) goto free_wlan_en; } - da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ); - - ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data); - if (ret) { - pr_err(Could not set wl12xx data: %d\n, ret); + ret = wl12xx_board_init(da850_wl12xx_wlan_data, DA850_WLAN_IRQ); + if (ret) goto free_wlan_irq; - } return 0; diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index 3669c12..bc48679 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -825,10 +825,11 @@ static void __init omap4_sdp4430_wifi_init(void) int ret; omap4_sdp4430_wifi_mux_init(); - omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ); - ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data); + + ret = wl12xx_board_init(omap4_sdp4430_wlan_data, GPIO_WIFI_IRQ); if (ret) - pr_err(Error setting wl12xx data: %d\n, ret); + return; + ret = platform_device_register(omap_vwlan_device); if (ret) pr_err(Error registering wl12xx device: %d\n, ret); diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c index b9b776b..8e3a075 100644 --- a/arch/arm/mach-omap2/board-omap3evm.c +++ b/arch/arm/mach-omap2/board-omap3evm.c @@ -636,10 +636,10 @@ static void __init omap3_evm_wl12xx_init(void) int ret; /* WL12xx WLAN Init */ - omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO); - ret = wl12xx_set_platform_data(omap3evm_wlan_data); + ret = wl12xx_board_init(omap3evm_wlan_data, OMAP3EVM_WLAN_IRQ_GPIO); if (ret) - pr_err(error setting wl12xx data: %d\n, ret); + return; + ret = platform_device_register(omap3evm_wlan_regulator); if (ret) pr_err(error registering wl12xx device: %d\n, ret); diff --git a/arch/arm/mach-omap2/board-omap3pandora.c b/arch/arm/mach-omap2/board-omap3pandora.c index 00a1f4a..bfdc7aa 100644 --- a/arch/arm/mach-omap2/board-omap3pandora.c +++ b/arch/arm/mach-omap2/board-omap3pandora.c @@ -543,13 +543,10 @@ static void __init pandora_wl1251_init(void) if (ret 0) goto fail; - pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO); - if (pandora_wl1251_pdata.irq 0) - goto fail_irq; - pandora_wl1251_pdata.use_eeprom = true; - ret = wl12xx_set_platform_data(pandora_wl1251_pdata); - if (ret 0) + + ret = wl12xx_board_init(pandora_wl1251_pdata, PANDORA_WIFI_IRQ_GPIO); + if (ret) goto fail_irq; return; diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index bfcd397..f203cd9 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -486,24 +486,32 @@ static void omap4_panda_init_rev(void) } } +static void __init
Multimachine uImage and cpufreq-cpu0/cpufreq-omap2 breakage
Hi, I'm currently building 3.7rc1 kernels meant to run on beagleboards (omap3), pandaboards (omap4) and beaglebones (am335x). At the moment I'm only testing it on beaglebone and I noticed a problem with the different cpufreq drivers getting in eachothers way. I patched in cpufreq-cpu0 support for AM335x and that's was working great. After rebasing to 3.7-rc1 it stopped working because cpufreq-omap2 tried to load, failed and made the cpufreq-cpu0 driver error out. The workaround is simple: only enable on driver. So my question is: Is this the intended behaviour? I would expect the cpufreq-omap2 driver to not load when booted on am335x using DT, but it is a persistent bugger. Thanks, Koen-- 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
[PATCHv3 0/5] OMAP: VRFB: convert to platform device
This is the third version of the series. Changes to v2 are: * rebased on 3.7-rc1 to resolve conflicts * add omap_vrfb_supported() so that cpu_is_* check can be removed from omapfb As Kevin Hilman pointed out, the context restore is not functional. I didn't touch that, as it's not functional with the current kernel either (and nobody has complained, so it can't be that critical). Tomi Tomi Valkeinen (5): OMAP: VRFB: convert vrfb to platform device OMAP: move arch/arm/plat-omap/include/plat/vrfb.h OMAP: SDRC: remove VRFB code OMAPDSS: VRFB: add omap_vrfb_supported() OMAPFB: use omap_vrfb_supported() arch/arm/mach-omap2/sdrc.c | 16 --- arch/arm/plat-omap/fb.c | 61 +++ arch/arm/plat-omap/include/plat/sdrc.h |7 -- arch/arm/plat-omap/include/plat/vrfb.h | 66 drivers/media/platform/omap/omap_vout.c |2 +- drivers/media/platform/omap/omap_vout_vrfb.c |2 +- drivers/media/platform/omap/omap_voutdef.h |2 +- drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +- drivers/video/omap2/omapfb/omapfb-main.c |8 +- drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +- drivers/video/omap2/vrfb.c | 142 ++ include/video/omapvrfb.h | 68 12 files changed, 257 insertions(+), 121 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h create mode 100644 include/video/omapvrfb.h -- 1.7.9.5 -- 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
[PATCHv3 1/5] OMAP: VRFB: convert vrfb to platform device
This patch converts vrfb library into a platform device, in an effort to remove omap dependencies. The platform device is registered in arch/arm/plat-omap/fb.c and assigned resources depending on whether running on omap2 or omap3. The vrfb driver will parse those resources and use them to access vrfb configuration registers and the vrfb virtual rotation areas. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/fb.c| 61 ++ drivers/video/omap2/vrfb.c | 124 +--- 2 files changed, 165 insertions(+), 20 deletions(-) diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index bcbb9d5..f868cae 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -33,6 +33,67 @@ #include mach/hardware.h #include asm/mach/map.h +#include plat/cpu.h + +#ifdef CONFIG_OMAP2_VRFB + +/* + * The first memory resource is the register region for VRFB, + * the rest are VRFB virtual memory areas for each VRFB context. + */ + +static const struct resource omap2_vrfb_resources[] = { + DEFINE_RES_MEM_NAMED(0x68008000u, 0x40, vrfb-regs), + DEFINE_RES_MEM_NAMED(0x7000u, 0x400, vrfb-area-0), + DEFINE_RES_MEM_NAMED(0x7400u, 0x400, vrfb-area-1), + DEFINE_RES_MEM_NAMED(0x7800u, 0x400, vrfb-area-2), + DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, vrfb-area-3), +}; + +static const struct resource omap3_vrfb_resources[] = { + DEFINE_RES_MEM_NAMED(0x6C000180u, 0xc0, vrfb-regs), + DEFINE_RES_MEM_NAMED(0x7000u, 0x400, vrfb-area-0), + DEFINE_RES_MEM_NAMED(0x7400u, 0x400, vrfb-area-1), + DEFINE_RES_MEM_NAMED(0x7800u, 0x400, vrfb-area-2), + DEFINE_RES_MEM_NAMED(0x7c00u, 0x400, vrfb-area-3), + DEFINE_RES_MEM_NAMED(0xe000u, 0x400, vrfb-area-4), + DEFINE_RES_MEM_NAMED(0xe400u, 0x400, vrfb-area-5), + DEFINE_RES_MEM_NAMED(0xe800u, 0x400, vrfb-area-6), + DEFINE_RES_MEM_NAMED(0xec00u, 0x400, vrfb-area-7), + DEFINE_RES_MEM_NAMED(0xf000u, 0x400, vrfb-area-8), + DEFINE_RES_MEM_NAMED(0xf400u, 0x400, vrfb-area-9), + DEFINE_RES_MEM_NAMED(0xf800u, 0x400, vrfb-area-10), + DEFINE_RES_MEM_NAMED(0xfc00u, 0x400, vrfb-area-11), +}; + +static int __init omap_init_vrfb(void) +{ + struct platform_device *pdev; + const struct resource *res; + unsigned int num_res; + + if (cpu_is_omap24xx()) { + res = omap2_vrfb_resources; + num_res = ARRAY_SIZE(omap2_vrfb_resources); + } else if (cpu_is_omap34xx()) { + res = omap3_vrfb_resources; + num_res = ARRAY_SIZE(omap3_vrfb_resources); + } else { + return 0; + } + + pdev = platform_device_register_resndata(NULL, omapvrfb, -1, + res, num_res, NULL, 0); + + if (IS_ERR(pdev)) + return PTR_ERR(pdev); + else + return 0; +} + +arch_initcall(omap_init_vrfb); +#endif + #if defined(CONFIG_FB_OMAP) || defined(CONFIG_FB_OMAP_MODULE) static bool omapfb_lcd_configured; diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c index 7e99022..fda45cc 100644 --- a/drivers/video/omap2/vrfb.c +++ b/drivers/video/omap2/vrfb.c @@ -26,9 +26,9 @@ #include linux/io.h #include linux/bitops.h #include linux/mutex.h +#include linux/platform_device.h #include plat/vrfb.h -#include plat/sdrc.h #ifdef DEBUG #define DBG(format, ...) pr_debug(VRFB: format, ## __VA_ARGS__) @@ -36,10 +36,10 @@ #define DBG(format, ...) #endif -#define SMS_ROT_VIRT_BASE(context, rot) \ - (((context = 4) ? 0xD000 : 0x7000) \ -+ (0x400 * (context)) \ -+ (0x100 * (rot))) +#define SMS_ROT_CONTROL(context) (0x0 + 0x10 * context) +#define SMS_ROT_SIZE(context) (0x4 + 0x10 * context) +#define SMS_ROT_PHYSICAL_BA(context) (0x8 + 0x10 * context) +#define SMS_ROT_VIRT_BASE(rot) (0x100 * (rot)) #define OMAP_VRFB_SIZE (2048 * 2048 * 4) @@ -53,10 +53,16 @@ #define SMS_PW_OFFSET 4 #define SMS_PS_OFFSET 0 -#define VRFB_NUM_CTXS 12 /* bitmap of reserved contexts */ static unsigned long ctx_map; +struct vrfb_ctx { + u32 base; + u32 physical_ba; + u32 control; + u32 size; +}; + static DEFINE_MUTEX(ctx_lock); /* @@ -65,17 +71,32 @@ static DEFINE_MUTEX(ctx_lock); * we don't need locking, since no drivers will run until after the wake-up * has finished. */ -static struct { - u32 physical_ba; - u32 control; - u32 size; -} vrfb_hw_context[VRFB_NUM_CTXS]; + +static void __iomem *vrfb_base; + +static int num_ctxs; +static struct vrfb_ctx *ctxs; + +static void omap2_sms_write_rot_control(u32 val, unsigned ctx) +{ + __raw_writel(val, vrfb_base +
[PATCHv3 2/5] OMAP: move arch/arm/plat-omap/include/plat/vrfb.h
Now that vrfb driver is not omap dependent anymore, we can move vrfb.h from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/plat-omap/include/plat/vrfb.h | 66 -- drivers/media/platform/omap/omap_vout.c |2 +- drivers/media/platform/omap/omap_vout_vrfb.c |2 +- drivers/media/platform/omap/omap_voutdef.h |2 +- drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +- drivers/video/omap2/omapfb/omapfb-main.c |2 +- drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +- drivers/video/omap2/vrfb.c |2 +- include/video/omapvrfb.h | 66 ++ 9 files changed, 73 insertions(+), 73 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h create mode 100644 include/video/omapvrfb.h diff --git a/arch/arm/plat-omap/include/plat/vrfb.h b/arch/arm/plat-omap/include/plat/vrfb.h deleted file mode 100644 index 3792bde..000 --- a/arch/arm/plat-omap/include/plat/vrfb.h +++ /dev/null @@ -1,66 +0,0 @@ -/* - * VRFB Rotation Engine - * - * Copyright (C) 2009 Nokia Corporation - * Author: Tomi Valkeinen tomi.valkei...@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. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - */ - -#ifndef __OMAP_VRFB_H__ -#define __OMAP_VRFB_H__ - -#define OMAP_VRFB_LINE_LEN 2048 - -struct vrfb { - u8 context; - void __iomem *vaddr[4]; - unsigned long paddr[4]; - u16 xres; - u16 yres; - u16 xoffset; - u16 yoffset; - u8 bytespp; - bool yuv_mode; -}; - -#ifdef CONFIG_OMAP2_VRFB -extern int omap_vrfb_request_ctx(struct vrfb *vrfb); -extern void omap_vrfb_release_ctx(struct vrfb *vrfb); -extern void omap_vrfb_adjust_size(u16 *width, u16 *height, - u8 bytespp); -extern u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp); -extern u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp); -extern void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr, - u16 width, u16 height, - unsigned bytespp, bool yuv_mode); -extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot); -extern void omap_vrfb_restore_context(void); - -#else -static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; } -static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {} -static inline void omap_vrfb_adjust_size(u16 *width, u16 *height, - u8 bytespp) {} -static inline u32 omap_vrfb_min_phys_size(u16 width, u16 height, u8 bytespp) - { return 0; } -static inline u16 omap_vrfb_max_height(u32 phys_size, u16 width, u8 bytespp) - { return 0; } -static inline void omap_vrfb_setup(struct vrfb *vrfb, unsigned long paddr, - u16 width, u16 height, unsigned bytespp, bool yuv_mode) {} -static inline int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot) - { return 0; } -static inline void omap_vrfb_restore_context(void) {} -#endif -#endif /* __VRFB_H */ diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c index a3b1a34..3ff94a3 100644 --- a/drivers/media/platform/omap/omap_vout.c +++ b/drivers/media/platform/omap/omap_vout.c @@ -46,7 +46,7 @@ #include plat/cpu.h #include plat/dma.h -#include plat/vrfb.h +#include video/omapvrfb.h #include video/omapdss.h #include omap_voutlib.h diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c b/drivers/media/platform/omap/omap_vout_vrfb.c index 4be26abf6c..6c37f92 100644 --- a/drivers/media/platform/omap/omap_vout_vrfb.c +++ b/drivers/media/platform/omap/omap_vout_vrfb.c @@ -17,7 +17,7 @@ #include media/v4l2-device.h #include plat/dma.h -#include plat/vrfb.h +#include video/omapvrfb.h #include omap_voutdef.h #include omap_voutlib.h diff --git a/drivers/media/platform/omap/omap_voutdef.h b/drivers/media/platform/omap/omap_voutdef.h index 27a95d2..9ccfe1f 100644 --- a/drivers/media/platform/omap/omap_voutdef.h +++ b/drivers/media/platform/omap/omap_voutdef.h @@ -12,7 +12,7 @@ #define OMAP_VOUTDEF_H #include video/omapdss.h -#include plat/vrfb.h +#include video/omapvrfb.h #define YUYV_BPP2 #define RGB565_BPP 2 diff --git
[PATCHv3 3/5] OMAP: SDRC: remove VRFB code
Now that VRFB driver handles its registers independently, we can remove the VRFB related code from OMAP's sdrc. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/sdrc.c | 16 arch/arm/plat-omap/include/plat/sdrc.h |7 --- 2 files changed, 23 deletions(-) diff --git a/arch/arm/mach-omap2/sdrc.c b/arch/arm/mach-omap2/sdrc.c index e3d345f..4282e6e 100644 --- a/arch/arm/mach-omap2/sdrc.c +++ b/arch/arm/mach-omap2/sdrc.c @@ -160,19 +160,3 @@ void __init omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0, sdrc_write_reg(l, SDRC_POWER); omap2_sms_save_context(); } - -void omap2_sms_write_rot_control(u32 val, unsigned ctx) -{ - sms_write_reg(val, SMS_ROT_CONTROL(ctx)); -} - -void omap2_sms_write_rot_size(u32 val, unsigned ctx) -{ - sms_write_reg(val, SMS_ROT_SIZE(ctx)); -} - -void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx) -{ - sms_write_reg(val, SMS_ROT_PHYSICAL_BA(ctx)); -} - diff --git a/arch/arm/plat-omap/include/plat/sdrc.h b/arch/arm/plat-omap/include/plat/sdrc.h index 36d6a76..c68bab2 100644 --- a/arch/arm/plat-omap/include/plat/sdrc.h +++ b/arch/arm/plat-omap/include/plat/sdrc.h @@ -94,9 +94,6 @@ /* SMS register offsets - read/write with sms_{read,write}_reg() */ #define SMS_SYSCONFIG 0x010 -#define SMS_ROT_CONTROL(context) (0x180 + 0x10 * context) -#define SMS_ROT_SIZE(context) (0x184 + 0x10 * context) -#define SMS_ROT_PHYSICAL_BA(context) (0x188 + 0x10 * context) /* REVISIT: fill in other SMS registers here */ @@ -137,10 +134,6 @@ int omap2_sdrc_get_params(unsigned long r, void omap2_sms_save_context(void); void omap2_sms_restore_context(void); -void omap2_sms_write_rot_control(u32 val, unsigned ctx); -void omap2_sms_write_rot_size(u32 val, unsigned ctx); -void omap2_sms_write_rot_physical_ba(u32 val, unsigned ctx); - #ifdef CONFIG_ARCH_OMAP2 struct memory_timings { -- 1.7.9.5 -- 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
[PATCHv3 4/5] OMAPDSS: VRFB: add omap_vrfb_supported()
Add an exported function omap_vrfb_supported() which returns true if the vrfb driver has been loaded succesfully. This can be used to decide if VRFB can be used or not. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/vrfb.c | 16 include/video/omapvrfb.h |2 ++ 2 files changed, 18 insertions(+) diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c index e4a0450..5d8fdac 100644 --- a/drivers/video/omap2/vrfb.c +++ b/drivers/video/omap2/vrfb.c @@ -77,6 +77,8 @@ static void __iomem *vrfb_base; static int num_ctxs; static struct vrfb_ctx *ctxs; +static bool vrfb_loaded; + static void omap2_sms_write_rot_control(u32 val, unsigned ctx) { __raw_writel(val, vrfb_base + SMS_ROT_CONTROL(ctx)); @@ -336,6 +338,12 @@ out: } EXPORT_SYMBOL(omap_vrfb_request_ctx); +bool omap_vrfb_supported(void) +{ + return vrfb_loaded; +} +EXPORT_SYMBOL(omap_vrfb_supported); + static int __init vrfb_probe(struct platform_device *pdev) { struct resource *mem; @@ -375,11 +383,19 @@ static int __init vrfb_probe(struct platform_device *pdev) ctxs[i].base = mem-start; } + vrfb_loaded = true; + return 0; } +static void __exit vrfb_remove(struct platform_device *pdev) +{ + vrfb_loaded = false; +} + static struct platform_driver vrfb_driver = { .driver.name= omapvrfb, + .remove = __exit_p(vrfb_remove), }; static int __init vrfb_init(void) diff --git a/include/video/omapvrfb.h b/include/video/omapvrfb.h index 3792bde..bb0bd89 100644 --- a/include/video/omapvrfb.h +++ b/include/video/omapvrfb.h @@ -36,6 +36,7 @@ struct vrfb { }; #ifdef CONFIG_OMAP2_VRFB +extern bool omap_vrfb_supported(void); extern int omap_vrfb_request_ctx(struct vrfb *vrfb); extern void omap_vrfb_release_ctx(struct vrfb *vrfb); extern void omap_vrfb_adjust_size(u16 *width, u16 *height, @@ -49,6 +50,7 @@ extern int omap_vrfb_map_angle(struct vrfb *vrfb, u16 height, u8 rot); extern void omap_vrfb_restore_context(void); #else +static inline bool omap_vrfb_supported(void) { return false; } static inline int omap_vrfb_request_ctx(struct vrfb *vrfb) { return 0; } static inline void omap_vrfb_release_ctx(struct vrfb *vrfb) {} static inline void omap_vrfb_adjust_size(u16 *width, u16 *height, -- 1.7.9.5 -- 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
[PATCHv3 5/5] OMAPFB: use omap_vrfb_supported()
Replace cpu_is_*() check with omap_vrfb_supported(). Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/omapfb/omapfb-main.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index 5943b3a..bc225e4 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -31,7 +31,6 @@ #include linux/omapfb.h #include video/omapdss.h -#include plat/cpu.h #include plat/vram.h #include video/omapvrfb.h @@ -2396,10 +2395,7 @@ static int __init omapfb_probe(struct platform_device *pdev) goto err0; } - /* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE - *available for OMAP2 and OMAP3 - */ - if (def_vrfb !cpu_is_omap24xx() !cpu_is_omap34xx()) { + if (def_vrfb !omap_vrfb_supported()) { def_vrfb = 0; dev_warn(pdev-dev, VRFB is not supported on this hardware, ignoring the module parameter vrfb=y\n); -- 1.7.9.5 -- 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 0/5] OMAP: VRFB: convert to platform device
Hi Tony, I have pushed this vrfb series and the omapdss version series to: git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version git://gitorious.org/linux-omap-dss2/linux.git 3.8/vrfb-conversion If they look ok to you and we don't get any other comments, I think these branches can be considered stable and you can pull them. After these are merged: $ git grep -E (plat/)|(mach/) drivers/video/omap2/ drivers/video/omap2/omapfb/omapfb-ioctl.c:#include plat/vram.h drivers/video/omap2/omapfb/omapfb-main.c:#include plat/vram.h drivers/video/omap2/vram.c:#include plat/vram.h So the vram stuff should be the only omap dependency left in omapdss and omapfb. I'll start working on that soon. Tomi On 2012-10-17 13:18, Tomi Valkeinen wrote: This is the third version of the series. Changes to v2 are: * rebased on 3.7-rc1 to resolve conflicts * add omap_vrfb_supported() so that cpu_is_* check can be removed from omapfb As Kevin Hilman pointed out, the context restore is not functional. I didn't touch that, as it's not functional with the current kernel either (and nobody has complained, so it can't be that critical). Tomi Tomi Valkeinen (5): OMAP: VRFB: convert vrfb to platform device OMAP: move arch/arm/plat-omap/include/plat/vrfb.h OMAP: SDRC: remove VRFB code OMAPDSS: VRFB: add omap_vrfb_supported() OMAPFB: use omap_vrfb_supported() arch/arm/mach-omap2/sdrc.c | 16 --- arch/arm/plat-omap/fb.c | 61 +++ arch/arm/plat-omap/include/plat/sdrc.h |7 -- arch/arm/plat-omap/include/plat/vrfb.h | 66 drivers/media/platform/omap/omap_vout.c |2 +- drivers/media/platform/omap/omap_vout_vrfb.c |2 +- drivers/media/platform/omap/omap_voutdef.h |2 +- drivers/video/omap2/omapfb/omapfb-ioctl.c|2 +- drivers/video/omap2/omapfb/omapfb-main.c |8 +- drivers/video/omap2/omapfb/omapfb-sysfs.c|2 +- drivers/video/omap2/vrfb.c | 142 ++ include/video/omapvrfb.h | 68 12 files changed, 257 insertions(+), 121 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/vrfb.h create mode 100644 include/video/omapvrfb.h signature.asc Description: OpenPGP digital signature
[PATCH 0/9] OMAPDSS: minor fixes cleanups
Hi, This series contains minor cleanups and fixes for omapdss. Tomi Tomi Valkeinen (9): OMAPDSS: DSI: fix dsi_get_dsidev_from_id() OMAPDSS: fix registering the vsync isr in apply OMAPDSS: DISPC: constify function parameters OMAPDSS: combine LCD related config into one func OMAPDSS: remove declarations for non-existing funcs OMAPDSS: DISPC: remove struct omap_overlay use OMAPDSS: DISPC: cleanup lcd and digit enable OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq() OMAPDSS: DISPC: cleanup lcd/digit enable/disable drivers/video/omap2/dss/apply.c | 27 ++--- drivers/video/omap2/dss/dispc.c | 235 --- drivers/video/omap2/dss/dsi.c | 13 ++- drivers/video/omap2/dss/dss.h | 21 ++-- 4 files changed, 174 insertions(+), 122 deletions(-) -- 1.7.9.5 -- 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/9] OMAPDSS: DSI: fix dsi_get_dsidev_from_id()
If dsi_get_dsidev_from_id() is called with a DSI module id that does not exist on the board, the function will crash as omap_dss_get_output() will return NULL. This happens on omap3 boards when dumping DSI clocks, as the dumping code will try to get the dsidev for DSI modules 0 and 1, but omap3 only has DSI module 0. Also clean up the id - output mapping, so that if the function is called with invalid module ID it will return NULL. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Archit Taneja arc...@ti.com --- drivers/video/omap2/dss/dsi.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index d64ac38..bee9284 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -365,11 +365,20 @@ struct platform_device *dsi_get_dsidev_from_id(int module) struct omap_dss_output *out; enum omap_dss_output_id id; - id = module == 0 ? OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2; + switch (module) { + case 0: + id = OMAP_DSS_OUTPUT_DSI1; + break; + case 1: + id = OMAP_DSS_OUTPUT_DSI2; + break; + default: + return NULL; + } out = omap_dss_get_output(id); - return out-pdev; + return out ? out-pdev : NULL; } static inline void dsi_write_reg(struct platform_device *dsidev, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/9] OMAPDSS: fix registering the vsync isr in apply
When we enable an output we don't check if we need to register the vsync isr. This causes us to miss vsync interrupts until somebody changes the configuration of an overlay or an overlay manager. Add the registration to dss_mgr_enable to fix the problem. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/apply.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c index 19d66f4..29ce5a8 100644 --- a/drivers/video/omap2/dss/apply.c +++ b/drivers/video/omap2/dss/apply.c @@ -1035,6 +1035,9 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr) if (!mgr_manual_update(mgr)) mp-updating = true; + if (!dss_data.irq_enabled need_isr()) + dss_register_vsync_isr(); + spin_unlock_irqrestore(data_lock, flags); if (!mgr_manual_update(mgr)) -- 1.7.9.5 -- 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/9] OMAPDSS: combine LCD related config into one func
Dispc has a bunch of functions used to configure output related parameters: - dispc_mgr_set_io_pad_mode - dispc_mgr_enable_stallmode - dispc_mgr_enable_fifohandcheck - dispc_mgr_set_clock_div - dispc_mgr_set_tft_data_lines - dispc_lcd_enable_signal_polarity - dispc_mgr_set_lcd_type_tft These are all called together, and the configuration values are taken from struct dss_lcd_mgr_config. Instead of exposing those individual dispc functions, create a new one, dispc_mgr_set_lcd_config(), which is used to configure the above parameters from values in struct dss_lcd_mgr_config. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/apply.c | 18 ++ drivers/video/omap2/dss/dispc.c | 29 +++-- drivers/video/omap2/dss/dss.h |8 ++-- 3 files changed, 27 insertions(+), 28 deletions(-) diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c index 29ce5a8..ae9f70d 100644 --- a/drivers/video/omap2/dss/apply.c +++ b/drivers/video/omap2/dss/apply.c @@ -666,22 +666,8 @@ static void dss_mgr_write_regs_extra(struct omap_overlay_manager *mgr) dispc_mgr_set_timings(mgr-id, mp-timings); /* lcd_config parameters */ - if (dss_mgr_is_lcd(mgr-id)) { - dispc_mgr_set_io_pad_mode(mp-lcd_config.io_pad_mode); - - dispc_mgr_enable_stallmode(mgr-id, mp-lcd_config.stallmode); - dispc_mgr_enable_fifohandcheck(mgr-id, - mp-lcd_config.fifohandcheck); - - dispc_mgr_set_clock_div(mgr-id, mp-lcd_config.clock_info); - - dispc_mgr_set_tft_data_lines(mgr-id, - mp-lcd_config.video_port_width); - - dispc_lcd_enable_signal_polarity(mp-lcd_config.lcden_sig_polarity); - - dispc_mgr_set_lcd_type_tft(mgr-id); - } + if (dss_mgr_is_lcd(mgr-id)) + dispc_mgr_set_lcd_config(mgr-id, mp-lcd_config); mp-extra_info_dirty = false; if (mp-updating) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 4dfc90a..d3c58eb 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -2769,7 +2769,7 @@ bool dispc_wb_is_enabled(void) return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0); } -void dispc_lcd_enable_signal_polarity(bool act_high) +static void dispc_lcd_enable_signal_polarity(bool act_high) { if (!dss_has_feature(FEAT_LCDENABLEPOL)) return; @@ -2793,13 +2793,13 @@ void dispc_pck_free_enable(bool enable) REG_FLD_MOD(DISPC_CONTROL, enable ? 1 : 0, 27, 27); } -void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool enable) +static void dispc_mgr_enable_fifohandcheck(enum omap_channel channel, bool enable) { mgr_fld_write(channel, DISPC_MGR_FLD_FIFOHANDCHECK, enable); } -void dispc_mgr_set_lcd_type_tft(enum omap_channel channel) +static void dispc_mgr_set_lcd_type_tft(enum omap_channel channel) { mgr_fld_write(channel, DISPC_MGR_FLD_STNTFT, 1); } @@ -2855,7 +2855,7 @@ void dispc_mgr_setup(enum omap_channel channel, } } -void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines) +static void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines) { int code; @@ -2880,7 +2880,7 @@ void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines) mgr_fld_write(channel, DISPC_MGR_FLD_TFTDATALINES, code); } -void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode) +static void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode) { u32 l; int gpout0, gpout1; @@ -2909,11 +2909,28 @@ void dispc_mgr_set_io_pad_mode(enum dss_io_pad_mode mode) dispc_write_reg(DISPC_CONTROL, l); } -void dispc_mgr_enable_stallmode(enum omap_channel channel, bool enable) +static void dispc_mgr_enable_stallmode(enum omap_channel channel, bool enable) { mgr_fld_write(channel, DISPC_MGR_FLD_STALLMODE, enable); } +void dispc_mgr_set_lcd_config(enum omap_channel channel, + const struct dss_lcd_mgr_config *config) +{ + dispc_mgr_set_io_pad_mode(config-io_pad_mode); + + dispc_mgr_enable_stallmode(channel, config-stallmode); + dispc_mgr_enable_fifohandcheck(channel, config-fifohandcheck); + + dispc_mgr_set_clock_div(channel, config-clock_info); + + dispc_mgr_set_tft_data_lines(channel, config-video_port_width); + + dispc_lcd_enable_signal_polarity(config-lcden_sig_polarity); + + dispc_mgr_set_lcd_type_tft(channel); +} + static bool _dispc_mgr_size_ok(u16 width, u16 height) { return width = dss_feat_get_param_max(FEAT_PARAM_MGR_WIDTH) diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h index eaf0856..8447871 100644 --- a/drivers/video/omap2/dss/dss.h +++ b/drivers/video/omap2/dss/dss.h @@ -435,7 +435,6 @@ void dispc_runtime_put(void); void
[PATCH 5/9] OMAPDSS: remove declarations for non-existing funcs
dss_mgr_set_device and dss_mgr_unset_device are declared in dss.h, but the functions do not exist. Remove the declarations. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dss.h |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h index 8447871..373847c 100644 --- a/drivers/video/omap2/dss/dss.h +++ b/drivers/video/omap2/dss/dss.h @@ -217,9 +217,6 @@ int dss_mgr_set_info(struct omap_overlay_manager *mgr, struct omap_overlay_manager_info *info); void dss_mgr_get_info(struct omap_overlay_manager *mgr, struct omap_overlay_manager_info *info); -int dss_mgr_set_device(struct omap_overlay_manager *mgr, - struct omap_dss_device *dssdev); -int dss_mgr_unset_device(struct omap_overlay_manager *mgr); int dss_mgr_set_output(struct omap_overlay_manager *mgr, struct omap_dss_output *output); int dss_mgr_unset_output(struct omap_overlay_manager *mgr); -- 1.7.9.5 -- 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 6/9] OMAPDSS: DISPC: remove struct omap_overlay use
dispc_ovl_setup() uses struct omap_overlay to get the caps for the overlay. We can change the code to get the caps directly from dss features, thus removing the dependency to struct omap_overlay. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dispc.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index d3c58eb..9f0ce18 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -2505,7 +2505,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi, bool mem_to_mem) { int r; - const struct omap_overlay *ovl = omap_dss_get_overlay(plane); + enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane); enum omap_channel channel; channel = dispc_ovl_get_channel_out(plane); @@ -2516,7 +2516,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi, oi-pos_y, oi-width, oi-height, oi-out_width, oi-out_height, oi-color_mode, oi-rotation, oi-mirror, channel, replication); - r = dispc_ovl_setup_common(plane, ovl-caps, oi-paddr, oi-p_uv_addr, + r = dispc_ovl_setup_common(plane, caps, oi-paddr, oi-p_uv_addr, oi-screen_width, oi-pos_x, oi-pos_y, oi-width, oi-height, oi-out_width, oi-out_height, oi-color_mode, oi-rotation, oi-mirror, oi-zorder, oi-pre_mult_alpha, oi-global_alpha, -- 1.7.9.5 -- 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 7/9] OMAPDSS: DISPC: cleanup lcd and digit enable
dispc.c's functions to enable LCD and DIGIT outputs can be cleaned up a bit by using common functions to set the enable bit and to check if the output is enabled. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dispc.c | 27 ++- 1 file changed, 10 insertions(+), 17 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 9f0ce18..492740e 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -2591,13 +2591,18 @@ static void dispc_disable_isr(void *data, u32 mask) complete(compl); } -static void _enable_lcd_out(enum omap_channel channel, bool enable) +static void _enable_mgr_out(enum omap_channel channel, bool enable) { mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable); /* flush posted write */ mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); } +bool dispc_mgr_is_enabled(enum omap_channel channel) +{ + return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); +} + static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) { struct completion frame_done_completion; @@ -2608,7 +2613,7 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) /* When we disable LCD output, we need to wait until frame is done. * Otherwise the DSS is still working, and turning off the clocks * prevents DSS from going to OFF mode */ - is_on = mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); + is_on = dispc_mgr_is_enabled(channel); irq = mgr_desc[channel].framedone_irq; @@ -2622,7 +2627,7 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) DSSERR(failed to register FRAMEDONE isr\n); } - _enable_lcd_out(channel, enable); + _enable_mgr_out(channel, enable); if (!enable is_on) { if (!wait_for_completion_timeout(frame_done_completion, @@ -2637,13 +2642,6 @@ static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) } } -static void _enable_digit_out(bool enable) -{ - REG_FLD_MOD(DISPC_CONTROL, enable ? 1 : 0, 1, 1); - /* flush posted write */ - dispc_read_reg(DISPC_CONTROL); -} - static void dispc_mgr_enable_digit_out(bool enable) { struct completion frame_done_completion; @@ -2652,7 +2650,7 @@ static void dispc_mgr_enable_digit_out(bool enable) u32 irq_mask; int num_irqs; - if (REG_GET(DISPC_CONTROL, 1, 1) == enable) + if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == enable) return; src = dss_get_hdmi_venc_clk_source(); @@ -2689,7 +2687,7 @@ static void dispc_mgr_enable_digit_out(bool enable) if (r) DSSERR(failed to register %x isr\n, irq_mask); - _enable_digit_out(enable); + _enable_mgr_out(OMAP_DSS_CHANNEL_DIGIT, enable); for (i = 0; i num_irqs; ++i) { if (!wait_for_completion_timeout(frame_done_completion, @@ -2713,11 +2711,6 @@ static void dispc_mgr_enable_digit_out(bool enable) } } -bool dispc_mgr_is_enabled(enum omap_channel channel) -{ - return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); -} - void dispc_mgr_enable(enum omap_channel channel, bool enable) { if (dss_mgr_is_lcd(channel)) -- 1.7.9.5 -- 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 8/9] OMAPDSS: DISPC: add dispc_mgr_get_sync_lost_irq()
Add function that returns the sync lost irq mask for the given channel. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dispc.c |5 + drivers/video/omap2/dss/dss.h |1 + 2 files changed, 6 insertions(+) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 492740e..82339ad 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -543,6 +543,11 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel) return mgr_desc[channel].framedone_irq; } +u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel) +{ + return mgr_desc[channel].sync_lost_irq; +} + u32 dispc_wb_get_framedone_irq(void) { return DISPC_IRQ_FRAMEDONEWB; diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h index 373847c..b6e3a06 100644 --- a/drivers/video/omap2/dss/dss.h +++ b/drivers/video/omap2/dss/dss.h @@ -460,6 +460,7 @@ void dispc_ovl_set_channel_out(enum omap_plane plane, u32 dispc_mgr_get_vsync_irq(enum omap_channel channel); u32 dispc_mgr_get_framedone_irq(enum omap_channel channel); +u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel); bool dispc_mgr_go_busy(enum omap_channel channel); void dispc_mgr_go(enum omap_channel channel); bool dispc_mgr_is_enabled(enum omap_channel channel); -- 1.7.9.5 -- 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 9/9] OMAPDSS: DISPC: cleanup lcd/digit enable/disable
We currently have a single function to enable and disable the manager output for LCD and DIGIT. The functions are a bit complex, as handling both enable and disable require some extra steps to ensure that the output is enabled or disabled properly without errors before exiting the function. The code can be made simpler to understand by splitting the functions into separate enable and disable functions. We'll also clean up the comments and some parameter names at the same time. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/apply.c |6 +- drivers/video/omap2/dss/dispc.c | 178 --- drivers/video/omap2/dss/dss.h |3 +- 3 files changed, 116 insertions(+), 71 deletions(-) diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c index ae9f70d..4fff8ac 100644 --- a/drivers/video/omap2/dss/apply.c +++ b/drivers/video/omap2/dss/apply.c @@ -772,7 +772,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr) if (!dss_data.irq_enabled need_isr()) dss_register_vsync_isr(); - dispc_mgr_enable(mgr-id, true); + dispc_mgr_enable(mgr-id); mgr_clear_shadow_dirty(mgr); @@ -1027,7 +1027,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr) spin_unlock_irqrestore(data_lock, flags); if (!mgr_manual_update(mgr)) - dispc_mgr_enable(mgr-id, true); + dispc_mgr_enable(mgr-id); out: mutex_unlock(apply_lock); @@ -1052,7 +1052,7 @@ void dss_mgr_disable(struct omap_overlay_manager *mgr) goto out; if (!mgr_manual_update(mgr)) - dispc_mgr_enable(mgr-id, false); + dispc_mgr_disable(mgr-id); spin_lock_irqsave(data_lock, flags); diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 82339ad..94f393ec 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -2590,7 +2590,7 @@ int dispc_ovl_enable(enum omap_plane plane, bool enable) return 0; } -static void dispc_disable_isr(void *data, u32 mask) +static void dispc_mgr_disable_isr(void *data, u32 mask) { struct completion *compl = data; complete(compl); @@ -2608,122 +2608,166 @@ bool dispc_mgr_is_enabled(enum omap_channel channel) return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); } -static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) +static void dispc_mgr_enable_lcd_out(enum omap_channel channel) { - struct completion frame_done_completion; - bool is_on; + _enable_mgr_out(channel, true); +} + +static void dispc_mgr_disable_lcd_out(enum omap_channel channel) +{ + DECLARE_COMPLETION_ONSTACK(framedone_compl); int r; u32 irq; - /* When we disable LCD output, we need to wait until frame is done. -* Otherwise the DSS is still working, and turning off the clocks -* prevents DSS from going to OFF mode */ - is_on = dispc_mgr_is_enabled(channel); + if (dispc_mgr_is_enabled(channel) == false) + return; + + /* +* When we disable LCD output, we need to wait for FRAMEDONE to know +* that DISPC has finished with the LCD output. +*/ - irq = mgr_desc[channel].framedone_irq; + irq = dispc_mgr_get_framedone_irq(channel); - if (!enable is_on) { - init_completion(frame_done_completion); + r = omap_dispc_register_isr(dispc_mgr_disable_isr, framedone_compl, + irq); + if (r) + DSSERR(failed to register FRAMEDONE isr\n); - r = omap_dispc_register_isr(dispc_disable_isr, - frame_done_completion, irq); + _enable_mgr_out(channel, false); - if (r) - DSSERR(failed to register FRAMEDONE isr\n); + /* if we couldn't register for framedone, just sleep and exit */ + if (r) { + msleep(200); + return; } - _enable_mgr_out(channel, enable); + if (!wait_for_completion_timeout(framedone_compl, + msecs_to_jiffies(100))) + DSSERR(timeout waiting for FRAME DONE\n); - if (!enable is_on) { - if (!wait_for_completion_timeout(frame_done_completion, - msecs_to_jiffies(100))) - DSSERR(timeout waiting for FRAME DONE\n); + r = omap_dispc_unregister_isr(dispc_mgr_disable_isr, framedone_compl, + irq); + if (r) + DSSERR(failed to unregister FRAMEDONE isr\n); +} - r = omap_dispc_unregister_isr(dispc_disable_isr, - frame_done_completion, irq); +static void dispc_digit_out_enable_isr(void *data, u32 mask) +{ + struct completion *compl = data; - if
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
Hi Ohad, On 10/17/12 11:10, Ohad Ben-Cohen wrote: On Tue, Oct 16, 2012 at 8:26 PM, Tony Lindgren t...@atomide.com wrote: Hmm looking at it repeats the same code over again. Can you rather add some wl12xx_board_init() helper function to mach-omap2/devices.c to do it? Nice, see below. Note that I can only compile test this now, which may be ok because it's pretty trivial. But do let me know if you want me to get it tested. The patch looks good, though minor comment below. From b940fb88a97494ad3a0a093279a5f176c0b29e44 Mon Sep 17 00:00:00 2001 From: Ohad Ben-Cohen o...@wizery.com Date: Sun, 14 Oct 2012 20:16:01 +0200 Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't configured Stop intimidating users with scary wlan error messages in case wl12xx support wasn't even built. In addition, when wl12xx_set_platform_data() fails, don't bother registering wl12xx's fixed regulator device (on the relevant boards). While we're at it, extract the wlan init code to a dedicated function to make (the relevant boards') init code look a bit nicer. Compile tested only. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-davinci/board-da850-evm.c | 8 ++-- arch/arm/mach-omap2/board-4430sdp.c | 7 --- arch/arm/mach-omap2/board-omap3evm.c | 6 +++--- arch/arm/mach-omap2/board-omap3pandora.c | 9 +++-- arch/arm/mach-omap2/board-omap4panda.c | 20 ++-- arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++- arch/arm/mach-omap2/common-board-devices.h | 2 ++ arch/arm/mach-omap2/devices.c| 26 ++ 8 files changed, 64 insertions(+), 29 deletions(-) [...] diff --git a/arch/arm/mach-omap2/common-board-devices.h b/arch/arm/mach-omap2/common-board-devices.h index a0b4a428..52e91424 100644 --- a/arch/arm/mach-omap2/common-board-devices.h +++ b/arch/arm/mach-omap2/common-board-devices.h @@ -7,9 +7,11 @@ struct mtd_partition; struct ads7846_platform_data; +struct wl12xx_platform_data; void omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce, struct ads7846_platform_data *board_pdata); void omap_nand_flash_init(int opts, struct mtd_partition *parts, int n_parts); +int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int gpio); You are adding declarations inside the common-board-devices.h, but the implementation inside the devices.c. I can see that devices.c has only on-soc devices in it. So, I would expect to have the wl12xx_board_init() function implementation inside the common-board-devices.c file. Another minor nit: I don't think you need to mark the declaration as __init, only the implementation, or is it for documenting it so? #endif /* __OMAP_COMMON_BOARD_DEVICES__ */ diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index c8c2117..9e86bb9 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -19,6 +19,7 @@ #include linux/of.h #include linux/pinctrl/machine.h #include linux/platform_data/omap4-keypad.h +#include linux/wl12xx.h #include asm/mach-types.h #include asm/mach/map.h @@ -38,6 +39,31 @@ #define L3_MODULES_MAX_LEN 12 #define L3_MODULES 3 +int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int gpio) +{ + int ret; + + wlan_data-irq = gpio_to_irq(gpio); + if (wlan_data-irq 0) { + ret = wlan_data-irq; + pr_err(wl12xx: gpio_to_irq(%d) failed: %d\n, gpio, ret); + return ret; + } + + ret = wl12xx_set_platform_data(wlan_data); + /* bail out silently in case wl12xx isn't configured */ + if (ret == -ENOSYS) + return ret; Instead of the above, wouldn't it be better to have: #if defined(CONFIG_WL12XX_PLATFORM_DATA) int __init wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int irq_gpio) { ... } #else inline int wl12xx_board_init(struct wl12xx_platform_data *wlan_data, int irq_gpio) { return 0; } #endif + + /* bail out verbosely on any other error */ + if (ret) { + pr_err(error setting wl12xx data: %d\n, ret); + return ret; + } + + return 0; +} + static int __init omap3_l3_init(void) { struct omap_hwmod *oh; -- Regards, Igor. -- 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] drivers: bus: omap_interconnect: Fix rand-config build warning
When building omap_l3_noc/smx drivers as modules, the following warning appears: CC [M] drivers/bus/omap_l3_smx.o drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync' drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used CC [M] drivers/bus/omap_l3_noc.o drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync' drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used Adding module_init() and macros in omap_l3_noc/smx drivers when building as modules to remove the above warning. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/bus/omap_l3_noc.c |9 + drivers/bus/omap_l3_smx.c | 10 ++ 2 files changed, 19 insertions(+) diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c index d15225f..8222a33 100644 --- a/drivers/bus/omap_l3_noc.c +++ b/drivers/bus/omap_l3_noc.c @@ -257,10 +257,19 @@ static int __init omap4_l3_init(void) { return platform_driver_register(omap4_l3_driver); } +#ifndef CONFIG_OMAP_INTERCONNECT_MODULE postcore_initcall_sync(omap4_l3_init); +#else +module_init(omap4_l3_init); +#endif static void __exit omap4_l3_exit(void) { platform_driver_unregister(omap4_l3_driver); } module_exit(omap4_l3_exit); + +MODULE_ALIAS(platform: omap_l3_noc); +MODULE_AUTHOR(Texas Instruments Inc.); +MODULE_DESCRIPTION(OMAP4XXX L3 Interconnect Driver); +MODULE_LICENSE(GPL v2); diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c index acc2164..00f712d 100644 --- a/drivers/bus/omap_l3_smx.c +++ b/drivers/bus/omap_l3_smx.c @@ -22,6 +22,7 @@ * USA */ +#include linux/module.h #include linux/kernel.h #include linux/slab.h #include linux/platform_device.h @@ -288,10 +289,19 @@ static int __init omap3_l3_init(void) { return platform_driver_probe(omap3_l3_driver, omap3_l3_probe); } +#ifndef CONFIG_OMAP_INTERCONNECT_MODULE postcore_initcall_sync(omap3_l3_init); +#else +module_init(omap3_l3_init); +#endif static void __exit omap3_l3_exit(void) { platform_driver_unregister(omap3_l3_driver); } module_exit(omap3_l3_exit); + +MODULE_ALIAS(platform: omap_l3_smx); +MODULE_AUTHOR(Texas Instruments Inc.); +MODULE_DESCRIPTION(OMAP3XXX L3 Interconnect Driver); +MODULE_LICENSE(GPL v2); -- 1.7.10.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] drivers: bus: omap_interconnect: Fix rand-config build warning
(Looping Arnd and Olof) On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: When building omap_l3_noc/smx drivers as modules, the following warning appears: CC [M] drivers/bus/omap_l3_smx.o drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync' drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used CC [M] drivers/bus/omap_l3_noc.o drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync' drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used Adding module_init() and macros in omap_l3_noc/smx drivers when building as modules to remove the above warning. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- Thanks for the fix Lokesh. Looks fine to me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.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: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)
Hi, On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote: + peterz, tglx Felipe Balbi ba...@ti.com writes: [...] The problem I see is that even though we properly return IRQ_WAKE_THREAD and wake_up_process() manages to wakeup the IRQ thread (it returns 1), the thread is never scheduled. To make things even worse, ouw irq thread runs once, but doesn't run on a consecutive call. Here's some (rather nasty) debug prints showing the problem: [...] [ 88.721923] try_to_wake_up 1411 [ 88.725189] === irq_wake_thread 139: IRQ 72 wake_up_process 0 [ 88.731292] [sched_delayed] sched: RT throttling activated This throttling message is the key one. With RT throttling activated, the IRQ thread will not be run (it eventually will be allowed much later on, but by then, the I2C xfers have timed out.) As a quick hack, the throttling can be disabled by seeting the sched_rt_runtime to RUNTIME_INF: # sysctl -w kernel.sched_rt_runtime_us=-1 and a quick test shows that things go back to working as expected. But we still need to figure out why the throttling is hapenning... So I started digging into why the RT runtime was so high, and noticed that time spent in suspend was being counted as RT runtime! So spending time in suspend anywhere near sched_rt_runtime (0.95s) will cause the RT throttling to always be triggered, and thus prevent IRQ threads from running in the resume path. Ouch. I think I'm already in over my head in the RT runtime stuff, but counting the time spent in suspend as RT runtime smells like a bug to me. no? Peter? Thomas? it looks like removing console output completely (echo 0 /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for a few more iterations to make sure what I'm saying is correct. -- balbi signature.asc Description: Digital signature
Re: [PATCH 9/9] OMAPDSS: DISPC: cleanup lcd/digit enable/disable
Hi, On Wednesday 17 October 2012 04:50 PM, Tomi Valkeinen wrote: We currently have a single function to enable and disable the manager output for LCD and DIGIT. The functions are a bit complex, as handling both enable and disable require some extra steps to ensure that the output is enabled or disabled properly without errors before exiting the function. The code can be made simpler to understand by splitting the functions into separate enable and disable functions. We'll also clean up the comments and some parameter names at the same time. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/apply.c |6 +- drivers/video/omap2/dss/dispc.c | 178 --- drivers/video/omap2/dss/dss.h |3 +- 3 files changed, 116 insertions(+), 71 deletions(-) diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c index ae9f70d..4fff8ac 100644 --- a/drivers/video/omap2/dss/apply.c +++ b/drivers/video/omap2/dss/apply.c @@ -772,7 +772,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr) if (!dss_data.irq_enabled need_isr()) dss_register_vsync_isr(); - dispc_mgr_enable(mgr-id, true); + dispc_mgr_enable(mgr-id); mgr_clear_shadow_dirty(mgr); @@ -1027,7 +1027,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr) spin_unlock_irqrestore(data_lock, flags); if (!mgr_manual_update(mgr)) - dispc_mgr_enable(mgr-id, true); + dispc_mgr_enable(mgr-id); out: mutex_unlock(apply_lock); @@ -1052,7 +1052,7 @@ void dss_mgr_disable(struct omap_overlay_manager *mgr) goto out; if (!mgr_manual_update(mgr)) - dispc_mgr_enable(mgr-id, false); + dispc_mgr_disable(mgr-id); spin_lock_irqsave(data_lock, flags); diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index 82339ad..94f393ec 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -2590,7 +2590,7 @@ int dispc_ovl_enable(enum omap_plane plane, bool enable) return 0; } -static void dispc_disable_isr(void *data, u32 mask) +static void dispc_mgr_disable_isr(void *data, u32 mask) { struct completion *compl = data; complete(compl); @@ -2608,122 +2608,166 @@ bool dispc_mgr_is_enabled(enum omap_channel channel) return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); } -static void dispc_mgr_enable_lcd_out(enum omap_channel channel, bool enable) +static void dispc_mgr_enable_lcd_out(enum omap_channel channel) { - struct completion frame_done_completion; - bool is_on; + _enable_mgr_out(channel, true); +} + +static void dispc_mgr_disable_lcd_out(enum omap_channel channel) +{ + DECLARE_COMPLETION_ONSTACK(framedone_compl); int r; u32 irq; - /* When we disable LCD output, we need to wait until frame is done. -* Otherwise the DSS is still working, and turning off the clocks -* prevents DSS from going to OFF mode */ - is_on = dispc_mgr_is_enabled(channel); + if (dispc_mgr_is_enabled(channel) == false) + return; + + /* +* When we disable LCD output, we need to wait for FRAMEDONE to know +* that DISPC has finished with the LCD output. +*/ - irq = mgr_desc[channel].framedone_irq; + irq = dispc_mgr_get_framedone_irq(channel); - if (!enable is_on) { - init_completion(frame_done_completion); + r = omap_dispc_register_isr(dispc_mgr_disable_isr, framedone_compl, + irq); + if (r) + DSSERR(failed to register FRAMEDONE isr\n); - r = omap_dispc_register_isr(dispc_disable_isr, - frame_done_completion, irq); + _enable_mgr_out(channel, false); - if (r) - DSSERR(failed to register FRAMEDONE isr\n); + /* if we couldn't register for framedone, just sleep and exit */ + if (r) { + msleep(200); We sleep for 200 ms if we fail to register for framedone. But we just wait for 100ms for FRAMEDONE to occur. It seems a bit incorrect, both should be kept the same, shouldn't they? + return; } - _enable_mgr_out(channel, enable); + if (!wait_for_completion_timeout(framedone_compl, + msecs_to_jiffies(100))) + DSSERR(timeout waiting for FRAME DONE\n); - if (!enable is_on) { - if (!wait_for_completion_timeout(frame_done_completion, - msecs_to_jiffies(100))) - DSSERR(timeout waiting for FRAME DONE\n); + r = omap_dispc_unregister_isr(dispc_mgr_disable_isr, framedone_compl, + irq); + if (r) + DSSERR(failed to unregister FRAMEDONE isr\n); +} -
Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
On 10/16/2012 04:26 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121016 14:00]: Hi Tony, On 10/16/2012 12:48 PM, Tony Lindgren wrote: * Richard Cochran richardcoch...@gmail.com [121015 12:18]: From: hvaib...@ti.com hvaib...@ti.com With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. I'm applying this one into omap-for-v3.7-rc1/fixes-part2. Next time, please also cc linux-omap@vger.kernel.org for series like this. I'm sure the people reading the omap list are interested in these. This patch appears to be masking an underlying issue. How about something like the following ... OK that looks good to me. I'll drop the earlier fix and use yours instead. Hi Tony, sorry but I realised now that in my patch that I need to take care of releasing and memory and clocks that were acquired during the probe. Here is a V2. If you prefer I can create a delta patch also with the previous. Cheers Jon From 91f5234d567c07ce1579b50e52de1a1e06ce5c68 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Tue, 16 Oct 2012 15:22:58 -0500 Subject: [PATCH V2] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory Currently, if the GPMC driver fails to reserve memory when probed we will call BUG() and the kernel will not boot. Instead of calling BUG(), return an error from probe and allow kernel to boot. Boot tested on AM335x beagle bone board and OMAP4430 Panda board. V2 changes: - Ensure that clock and memory resources are released on error. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/gpmc.c | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index 5ac5cf3..92b5718 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void) } -static void __devinit gpmc_mem_init(void) +static int __devinit gpmc_mem_init(void) { - int cs; + int cs, rc; unsigned long boot_rom_space = 0; /* never allocate the first page, to facilitate bug detection; @@ -890,13 +890,21 @@ static void __devinit gpmc_mem_init(void) if (!gpmc_cs_mem_enabled(cs)) continue; gpmc_cs_get_memconf(cs, base, size); - if (gpmc_cs_insert_mem(cs, base, size) 0) - BUG(); + rc = gpmc_cs_insert_mem(cs, base, size); + if (IS_ERR_VALUE(rc)) { + while (--cs = 0) + if (gpmc_cs_mem_enabled(cs)) + gpmc_cs_delete_mem(cs); + return rc; + } } + + return 0; } static __devinit int gpmc_probe(struct platform_device *pdev) { + int rc; u32 l; struct resource *res; @@ -936,7 +944,13 @@ static __devinit int gpmc_probe(struct platform_device *pdev) dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l), GPMC_REVISION_MINOR(l)); - gpmc_mem_init(); + rc = gpmc_mem_init(); + if (IS_ERR_VALUE(rc)) { + clk_disable_unprepare(gpmc_l3_clk); + clk_put(gpmc_l3_clk); + dev_err(gpmc_dev, failed to reserve memory\n); + return rc; + } if (IS_ERR_VALUE(gpmc_setup_irq())) dev_warn(gpmc_dev, gpmc_setup_irq failed\n); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi Afzal, On 17.10.2012 07:42, Afzal Mohammed wrote: On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. I commented on auxdata usage without visualising in more detail how it can be implemented, it was bad of me. I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Maybe slightly off-topic, but still: When GPMC is used for driving NAND chips that comply to CFI, the timings could actually be derived from the connected peripheral as well. I believe a slowest-possible-mode will have to be selected first for the identication phase. Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific. Daniel -- 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
[RFC/NOT FOR MERGING 0/5] OMAP PM patches
Hi guys, this series is actually *REALLY* far from ready, but I wanted to ask if I should continue down this track because it really looks (to me at least) that OMAP's PM layer took a few uneecessary shortcuts. I'm trying to understand the reasoning behind that, so bear with me for a while. At least patches 1 and 4 look like they could go upstream, but please give it a very good review. I will continue to work on these if the rest of the community thinks it's valid, otherwise I would like to get some explanation for the way OMAP PM layer is implemented today. cheers Felipe Balbi (5): arm: omap: fix up _od_suspend_noirq and _od_resume_noirq arm: omap: don't forcefully runtime suspend a device arm: omap: introduce other PM methods i2c: omap: don't re-enable IRQs after masking them i2c: omap: introduce suspend/resume methods arch/arm/plat-omap/omap_device.c | 162 +-- drivers/i2c/busses/i2c-omap.c| 70 - 2 files changed, 207 insertions(+), 25 deletions(-) -- 1.8.0.rc0 -- 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
[RFC/NOT FOR MERGING 2/5] arm: omap: don't forcefully runtime suspend a device
device drivers should be smart enough to provide -suspend/-resume callbacks when needed and they should take care of doing whatever needs to be done in order to allow a device to be suspended. Calling pm_runtime_* from system suspend isn't the right way to achieve that, as it creates a situation where OMAP's PM has different requirements and semantics than all other architectures. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/omap_device.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 935f416..cd84eac 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -817,11 +817,9 @@ static int _od_suspend_noirq(struct device *dev) ret = pm_generic_suspend_noirq(dev); if (!ret !pm_runtime_status_suspended(dev)) { - if (pm_generic_runtime_suspend(dev) == 0) { - if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) - omap_device_idle(pdev); - od-flags |= OMAP_DEVICE_SUSPENDED; - } + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_idle(pdev); + od-flags |= OMAP_DEVICE_SUSPENDED; } return ret; @@ -841,7 +839,6 @@ static int _od_resume_noirq(struct device *dev) od-flags = ~OMAP_DEVICE_SUSPENDED; if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) omap_device_enable(pdev); - pm_generic_runtime_resume(dev); } return pm_generic_resume_noirq(dev); -- 1.8.0.rc0 -- 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
[RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods
current omap_device PM implementation defines omap-specific *_noirq methods but uses the generic versions for all other PM methods. As it turns out, if a device decides to implement non-runtime PM callbacks, we might fall into a situation where the hwmod is still idled which will generate an abort exception when we try to access device's address space while clocks are still gated. In order to solve that, we implement all other methods taking into account that devices might not implement those, in which case we return early. Signed-off-by: Felipe Balbi ba...@ti.com --- notice here that it would be far better to avoid the code duplication and have another function (e.g. _od_generic_suspend/resume) which would receive pm_message_t and omap_device as arguments so it can decide what to do. That can be done on a later version, though. arch/arm/plat-omap/omap_device.c | 145 ++- 1 file changed, 144 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index cd84eac..60ce750 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -843,16 +843,159 @@ static int _od_resume_noirq(struct device *dev) return pm_generic_resume_noirq(dev); } + +static int _od_suspend(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + int ret; + + if (!pm || !pm-suspend) + return 0; + + /* Don't attempt suspend on a driver that is not bound */ + if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER) + return 0; + + ret = pm_generic_suspend(dev); + if (ret) + return ret; + + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_idle(pdev); + od-flags |= OMAP_DEVICE_SUSPENDED; + + return 0; +} + +static int _od_resume(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + + if (!pm || !pm-resume) + return 0; + + if (od-flags OMAP_DEVICE_SUSPENDED) { + od-flags = ~OMAP_DEVICE_SUSPENDED; + + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_enable(pdev); + } + + return pm_generic_resume(dev); +} + +static int _od_freeze(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + int ret; + + if (!pm || !pm-freeze) + return 0; + + /* Don't attempt late suspend on a driver that is not bound */ + if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER) + return 0; + + ret = pm_generic_freeze(dev); + if (ret) + return ret; + + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_idle(pdev); + od-flags |= OMAP_DEVICE_SUSPENDED; + + return 0; +} + +static int _od_thaw(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + + if (!pm || !pm-thaw) + return 0; + + if (od-flags OMAP_DEVICE_SUSPENDED) { + od-flags = ~OMAP_DEVICE_SUSPENDED; + + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_enable(pdev); + } + + return pm_generic_thaw(dev); +} + +static int _od_poweroff(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + int ret; + + if (!pm || !pm-poweroff) + return 0; + + /* Don't attempt late suspend on a driver that is not bound */ + if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER) + return 0; + + ret = pm_generic_poweroff(dev); + if (ret) + return ret; + + if (!(od-flags OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) + omap_device_idle(pdev); + od-flags |= OMAP_DEVICE_SUSPENDED; + + return 0; +} + +static int _od_restore(struct device *dev) +{ + struct platform_device *pdev = to_platform_device(dev); + struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + + if (!pm || !pm-restore) + return 0; + + if (od-flags OMAP_DEVICE_SUSPENDED) { + od-flags = ~OMAP_DEVICE_SUSPENDED; +
[RFC/NOT FOR MERGING 5/5] i2c: omap: introduce suspend/resume methods
during system-wide (static) suspend, we also want to save our context and restore it when waking up. Let's introduce new suspend/resume methods so that we can survive a suspend-to-ram transition. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 60 +++ 1 file changed, 50 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 7eeae11..ceab138 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1236,13 +1236,8 @@ static int __devexit omap_i2c_remove(struct platform_device *pdev) } #ifdef CONFIG_PM -#ifdef CONFIG_PM_RUNTIME -static int omap_i2c_runtime_suspend(struct device *dev) +static int omap_i2c_low_level_suspend(struct omap_i2c_dev *_dev) { - struct platform_device *pdev = to_platform_device(dev); - struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); - u16 iv; - _dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG); omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0); @@ -1253,11 +1248,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) return 0; } -static int omap_i2c_runtime_resume(struct device *dev) +static int omap_i2c_low_level_resume(struct omap_i2c_dev *_dev) { - struct platform_device *pdev = to_platform_device(dev); - struct omap_i2c_dev *_dev = platform_get_drvdata(pdev); - if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) { omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0); omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate); @@ -1278,9 +1270,57 @@ static int omap_i2c_runtime_resume(struct device *dev) return 0; } + +static int omap_i2c_suspend(struct device *dev) +{ + struct omap_i2c_dev *_dev = dev_get_drvdata(dev); + + if (pm_runtime_suspended(dev)) + return 0; + + return omap_i2c_low_level_suspend(_dev); +} + +static int omap_i2c_resume(struct device *dev) +{ + struct omap_i2c_dev *_dev = dev_get_drvdata(dev); + int r; + + r = omap_i2c_low_level_resume(_dev); + if (r) + return r; + + pm_runtime_disable(dev); + pm_runtime_set_active(dev); + pm_runtime_enable(dev); + pm_runtime_mark_last_busy(dev); + pm_runtime_put_autosuspend(dev); + + return 0; +} + +#ifdef CONFIG_PM_RUNTIME +static int omap_i2c_runtime_suspend(struct device *dev) +{ + struct omap_i2c_dev *_dev = dev_get_drvdata(dev); + + return omap_i2c_low_level_suspend(_dev); +} + +static int omap_i2c_runtime_resume(struct device *dev) +{ + struct omap_i2c_dev *_dev = dev_get_drvdata(dev); + + return omap_i2c_low_level_resume(_dev); +} +#else +#define omap_i2c_runtime_suspend NULL +#define omap_i2c_runtime_resume NULL #endif /* CONFIG_PM_RUNTIME */ static struct dev_pm_ops omap_i2c_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(omap_i2c_suspend, + omap_i2c_resume) SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend, omap_i2c_runtime_resume, NULL) }; -- 1.8.0.rc0 -- 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
[RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them
OMAP I2C driver will re-enable IRQs right after masking them during suspend. That's not what we want. We want to keep IRQs masked until our resume method is called. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/i2c/busses/i2c-omap.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index db31eae..7eeae11 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1247,14 +1247,8 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0); - if (_dev-rev OMAP_I2C_OMAP1_REV_2) { - iv = omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */ - } else { - omap_i2c_write_reg(_dev, OMAP_I2C_STAT_REG, _dev-iestate); - - /* Flush posted write */ - omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); - } + /* Flush posted write */ + omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); return 0; } -- 1.8.0.rc0 -- 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
[RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
current implementation doesn't take care about drivers which don't provide *_noirq methods and we could fall into a situation where we would suspend/resume devices even though they haven't asked for it. One such case happened with the I2C driver which was getting suspended during suspend_noirq() just to be resume right after by any other device doing an I2C transfer on its suspend method. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/plat-omap/omap_device.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7a7d1f2..935f416 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -804,8 +804,12 @@ static int _od_suspend_noirq(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; int ret; + if (!pm || !pm-suspend_noirq) + return 0; + /* Don't attempt late suspend on a driver that is not bound */ if (od-_driver_status != BUS_NOTIFY_BOUND_DRIVER) return 0; @@ -827,6 +831,10 @@ static int _od_resume_noirq(struct device *dev) { struct platform_device *pdev = to_platform_device(dev); struct omap_device *od = to_omap_device(pdev); + const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL; + + if (!pm || !pm-resume_noirq) + return 0; if ((od-flags OMAP_DEVICE_SUSPENDED) !pm_runtime_status_suspended(dev)) { -- 1.8.0.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h
In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/usb-host.c | 1 + arch/arm/mach-omap2/usb-musb.c | 1 + arch/arm/mach-omap2/usb-tusb6010.c | 1 + arch/arm/plat-omap/include/plat/usb.h | 126 + drivers/mfd/omap-usb-host.c| 2 +- drivers/usb/musb/am35x.c | 3 +- drivers/usb/musb/musb_dsps.c | 3 +- drivers/usb/musb/omap2430.h| 2 +- .../linux/platform_data/usb-omap.h | 80 + 9 files changed, 36 insertions(+), 183 deletions(-) copy arch/arm/plat-omap/include/plat/usb.h = include/linux/platform_data/usb-omap.h (69%) diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c index 3c43449..e0c2cad 100644 --- a/arch/arm/mach-omap2/usb-host.c +++ b/arch/arm/mach-omap2/usb-host.c @@ -22,6 +22,7 @@ #include linux/platform_device.h #include linux/slab.h #include linux/dma-mapping.h +#include linux/platform_data/usb-omap.h #include asm/io.h diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 51da21c..4fcd3a6 100644 --- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/dma-mapping.h #include linux/io.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h #include plat/usb.h diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 805bea6..5e24289 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/gpio.h #include linux/export.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 87ee140..550e40e 100644 --- a/arch/arm/plat-omap/include/plat/usb.h +++ b/arch/arm/plat-omap/include/plat/usb.h @@ -3,86 +3,15 @@ #ifndef__ASM_ARCH_OMAP_USB_H #define__ASM_ARCH_OMAP_USB_H -#include linux/io.h #include linux/platform_device.h -#include linux/usb/musb.h - -#define OMAP3_HS_USB_PORTS 3 - -enum usbhs_omap_port_mode { - OMAP_USBHS_PORT_MODE_UNUSED, - OMAP_EHCI_PORT_MODE_PHY, - OMAP_EHCI_PORT_MODE_TLL, - OMAP_EHCI_PORT_MODE_HSIC, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM -}; - -struct usbhs_omap_board_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - /* have to be valid if phy_reset is true and portx is in phy mode */ - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - - /* Set this to true for ES2.x silicon */ - unsignedes2_compatibility:1; - - unsignedphy_reset:1; - - /* -* Regulators for USB PHYs. -* Each PHY can have a separate regulator. -*/ - struct regulator*regulator[OMAP3_HS_USB_PORTS]; -}; +#include linux/platform_data/usb-omap.h #ifdef CONFIG_ARCH_OMAP2PLUS -struct ehci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - struct regulator*regulator[OMAP3_HS_USB_PORTS]; - unsignedphy_reset:1; -}; - -struct ohci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - unsignedes2_compatibility:1; -}; - -struct usbhs_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - struct ehci_hcd_omap_platform_data *ehci_data; - struct ohci_hcd_omap_platform_data *ohci_data; -}; struct usbtll_omap_platform_data { enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; }; -/*-*/ - -struct omap_musb_board_data { - u8 interface_type; - u8 mode; - u16 power; - unsigned extvbus:1; - void(*set_phy_power)(u8 on); - void(*clear_irq)(void); - void(*set_mode)(u8 mode); - void(*reset)(void); -}; -
Re: [PATCH] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h
Hi, On Wed, Oct 17, 2012 at 06:43:41PM +0300, Felipe Balbi wrote: In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/usb-host.c | 1 + arch/arm/mach-omap2/usb-musb.c | 1 + arch/arm/mach-omap2/usb-tusb6010.c | 1 + arch/arm/plat-omap/include/plat/usb.h | 126 + drivers/mfd/omap-usb-host.c| 2 +- drivers/usb/musb/am35x.c | 3 +- drivers/usb/musb/musb_dsps.c | 3 +- drivers/usb/musb/omap2430.h| 2 +- .../linux/platform_data/usb-omap.h | 80 + 9 files changed, 36 insertions(+), 183 deletions(-) copy arch/arm/plat-omap/include/plat/usb.h = include/linux/platform_data/usb-omap.h (69%) diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c index 3c43449..e0c2cad 100644 --- a/arch/arm/mach-omap2/usb-host.c +++ b/arch/arm/mach-omap2/usb-host.c @@ -22,6 +22,7 @@ #include linux/platform_device.h #include linux/slab.h #include linux/dma-mapping.h +#include linux/platform_data/usb-omap.h #include asm/io.h diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 51da21c..4fcd3a6 100644 --- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/dma-mapping.h #include linux/io.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h #include plat/usb.h diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 805bea6..5e24289 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/gpio.h #include linux/export.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 87ee140..550e40e 100644 --- a/arch/arm/plat-omap/include/plat/usb.h +++ b/arch/arm/plat-omap/include/plat/usb.h @@ -3,86 +3,15 @@ #ifndef __ASM_ARCH_OMAP_USB_H #define __ASM_ARCH_OMAP_USB_H -#include linux/io.h #include linux/platform_device.h -#include linux/usb/musb.h - -#define OMAP3_HS_USB_PORTS 3 - -enum usbhs_omap_port_mode { - OMAP_USBHS_PORT_MODE_UNUSED, - OMAP_EHCI_PORT_MODE_PHY, - OMAP_EHCI_PORT_MODE_TLL, - OMAP_EHCI_PORT_MODE_HSIC, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM -}; - -struct usbhs_omap_board_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - /* have to be valid if phy_reset is true and portx is in phy mode */ - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - - /* Set this to true for ES2.x silicon */ - unsignedes2_compatibility:1; - - unsignedphy_reset:1; - - /* - * Regulators for USB PHYs. - * Each PHY can have a separate regulator. - */ - struct regulator*regulator[OMAP3_HS_USB_PORTS]; -}; +#include linux/platform_data/usb-omap.h #ifdef CONFIG_ARCH_OMAP2PLUS -struct ehci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - struct regulator*regulator[OMAP3_HS_USB_PORTS]; - unsignedphy_reset:1; -}; - -struct ohci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - unsignedes2_compatibility:1; -}; - -struct usbhs_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - struct ehci_hcd_omap_platform_data *ehci_data; - struct ohci_hcd_omap_platform_data *ohci_data; -}; struct usbtll_omap_platform_data { enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; }; looks like should be moved too... I'll respin the patch. -- balbi signature.asc Description: Digital signature
[PATCH v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h
In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/mach-omap2/usb-host.c | 1 + arch/arm/mach-omap2/usb-musb.c | 1 + arch/arm/mach-omap2/usb-tusb6010.c | 1 + arch/arm/plat-omap/include/plat/usb.h | 130 + drivers/mfd/omap-usb-host.c| 2 +- drivers/usb/musb/am35x.c | 3 +- drivers/usb/musb/musb_dsps.c | 3 +- drivers/usb/musb/omap2430.h| 2 +- .../linux/platform_data/usb-omap.h | 84 + 9 files changed, 40 insertions(+), 187 deletions(-) copy arch/arm/plat-omap/include/plat/usb.h = include/linux/platform_data/usb-omap.h (71%) diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c index 3c43449..e0c2cad 100644 --- a/arch/arm/mach-omap2/usb-host.c +++ b/arch/arm/mach-omap2/usb-host.c @@ -22,6 +22,7 @@ #include linux/platform_device.h #include linux/slab.h #include linux/dma-mapping.h +#include linux/platform_data/usb-omap.h #include asm/io.h diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c index 51da21c..4fcd3a6 100644 --- a/arch/arm/mach-omap2/usb-musb.c +++ b/arch/arm/mach-omap2/usb-musb.c @@ -23,6 +23,7 @@ #include linux/clk.h #include linux/dma-mapping.h #include linux/io.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h #include plat/usb.h diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 805bea6..5e24289 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -15,6 +15,7 @@ #include linux/platform_device.h #include linux/gpio.h #include linux/export.h +#include linux/platform_data/usb-omap.h #include linux/usb/musb.h diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h index 87ee140..2d5c027 100644 --- a/arch/arm/plat-omap/include/plat/usb.h +++ b/arch/arm/plat-omap/include/plat/usb.h @@ -3,86 +3,11 @@ #ifndef__ASM_ARCH_OMAP_USB_H #define__ASM_ARCH_OMAP_USB_H -#include linux/io.h #include linux/platform_device.h -#include linux/usb/musb.h - -#define OMAP3_HS_USB_PORTS 3 - -enum usbhs_omap_port_mode { - OMAP_USBHS_PORT_MODE_UNUSED, - OMAP_EHCI_PORT_MODE_PHY, - OMAP_EHCI_PORT_MODE_TLL, - OMAP_EHCI_PORT_MODE_HSIC, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0, - OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM -}; - -struct usbhs_omap_board_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - /* have to be valid if phy_reset is true and portx is in phy mode */ - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - - /* Set this to true for ES2.x silicon */ - unsignedes2_compatibility:1; - - unsignedphy_reset:1; - - /* -* Regulators for USB PHYs. -* Each PHY can have a separate regulator. -*/ - struct regulator*regulator[OMAP3_HS_USB_PORTS]; -}; +#include linux/platform_data/usb-omap.h #ifdef CONFIG_ARCH_OMAP2PLUS -struct ehci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - int reset_gpio_port[OMAP3_HS_USB_PORTS]; - struct regulator*regulator[OMAP3_HS_USB_PORTS]; - unsignedphy_reset:1; -}; - -struct ohci_hcd_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - unsignedes2_compatibility:1; -}; - -struct usbhs_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; - - struct ehci_hcd_omap_platform_data *ehci_data; - struct ohci_hcd_omap_platform_data *ohci_data; -}; - -struct usbtll_omap_platform_data { - enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS]; -}; -/*-*/ - -struct omap_musb_board_data { - u8 interface_type; - u8 mode; - u16 power; - unsigned extvbus:1; - void(*set_phy_power)(u8 on); - void(*clear_irq)(void); - void(*set_mode)(u8 mode); - void(*reset)(void); -}; -
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Daniel Mack zon...@gmail.com [121017 08:15]: Hi Afzal, On 17.10.2012 07:42, Afzal Mohammed wrote: On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote: I certainly don't think it is easier, rather tougher, cleaner as well. One thing that worried me was, if we pursue the auxdata path (a last resort option) and later if it is objected, we would be back to square one. I commented on auxdata usage without visualising in more detail how it can be implemented, it was bad of me. I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Maybe slightly off-topic, but still: When GPMC is used for driving NAND chips that comply to CFI, the timings could actually be derived from the connected peripheral as well. I believe a slowest-possible-mode will have to be selected first for the identication phase. I wish.. Just getting things working to the identification phase requires quite a bit of configuration for the timings. Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific. Yes and the level shifters affect timings too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
Hi, On Thu, Oct 11, 2012 at 02:08:25PM -0700, Kevin Hilman wrote: Hi Kalle, Kalle Jokiniemi kalle.jokini...@jollamobile.com writes: The resume_noirq enables interrupts one-by-one starting from first one. Now if the wake up event for suspend came from i2c device, the i2c bus irq gets enabled before the threaded i2c device irq, causing a flood of i2c bus interrupts as the threaded irq that should clear the event is not enabled yet. Fixed the issue by adding suspend_noirq and resume_early functions that keep i2c bus interrupts disabled until resume_noirq has run completely. Issue was detected doing a wake up from autosleep with twl4030 power key on N9. Patch tested on N9. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com This version looks good, thanks for the extra comments. Reviewed-by: Kevin Hilman khil...@ti.com Tested-by: Kevin Hilman khil...@ti.com Wolfram, This should also probably be Cc'd to stable since it affects earlier kernels as well. Thanks, just to make sure we're not fixing the wrong problem... does [1] help in any way ? [1] http://marc.info/?l=linux-omapm=135048839915719w=2 -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
* Jon Hunter jon-hun...@ti.com [121017 07:43]: On 10/16/2012 04:26 PM, Tony Lindgren wrote: * Jon Hunter jon-hun...@ti.com [121016 14:00]: Hi Tony, On 10/16/2012 12:48 PM, Tony Lindgren wrote: * Richard Cochran richardcoch...@gmail.com [121015 12:18]: From: hvaib...@ti.com hvaib...@ti.com With recent changes in omap gpmc driver code, in case of DT boot mode, where bootloader does not configure gpmc cs space will result into kernel BUG() inside gpmc_mem_init() function, as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and gpmc_config7[0].baseaddress is set to '0' on reset. This use-case is applicable for any board/EVM which doesn't have any peripheral connected to gpmc cs0, for example BeagleXM and BeagleBone, so DT boot mode fails. This patch adds of_have_populated_dt() check before creating device, so that for DT boot mode, gpmc probe will not be called which is expected behavior, as gpmc is not supported yet from DT. I'm applying this one into omap-for-v3.7-rc1/fixes-part2. Next time, please also cc linux-omap@vger.kernel.org for series like this. I'm sure the people reading the omap list are interested in these. This patch appears to be masking an underlying issue. How about something like the following ... OK that looks good to me. I'll drop the earlier fix and use yours instead. Hi Tony, sorry but I realised now that in my patch that I need to take care of releasing and memory and clocks that were acquired during the probe. Here is a V2. If you prefer I can create a delta patch also with the previous. OK thanks I'll update it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: adopt pinctrl support
On Tue, Oct 16, 2012 at 8:53 PM, Sebastien Guiriec s-guir...@ti.com wrote: Some GPIO expanders need some early pin control muxing. Due to legacy boards sometimes the driver uses subsys_initcall instead of module_init. This patch takes advantage of defer probe feature and pin control in order to wait until pin control probing before GPIO driver probing. It has been tested on OMAP5 board with TCA6424 driver. log: [0.482299] omap_i2c i2c.15: could not find pctldev for node /ocp/pinmux@4a00 2840/pinmux_i2c5_pins, deferring probe [0.482330] platform i2c.15: Driver omap_i2c requests probe deferral [0.484466] Advanced Linux Sound Architecture Driver Initialized. [4.746917] omap_i2c i2c.15: bus 4 rev2.4.0 at 100 kHz [4.755279] gpiochip_find_base: found new base at 477 [4.761169] gpiochip_add: registered GPIOs 477 to 500 on device: tca6424a Thanks, Acked-by: Shubhrajyoti D shubhrajy...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: move plat-omap/include/plat/sdrc.h into mach-omap2/sdrc.h
* Paul Walmsley p...@pwsan.com [121016 17:48]: Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in cleaning out arch/arm/plat-omap/, as his upstreams request. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com --- This has a dependency on Tomi's OMAP: VRFB: convert to platform device series. Thanks applying this into omap-for-v3.8/cleanup-headers-dss. 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
[PATCH V3 0/5] ARM: OMAP2+: Add device-tree support for timers
This series adds device-tree support for the timers on OMAP2+ devices including AM33xx. Testing: 1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430 Panda and AM335x Beagle Bone with/without ... a). device-tree present b). CONFIG_OMAP_32K_TIMER set c). kernel boot parameter clocksource=gp_timer present 2. I have tested the all the timers (not used by the kernel as sys-timers) on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree with this series. The testing includes ... a. Configuring, starting a timer and checking the counter value is incrementing. b. Testing timer overflow interrupt when timer expires. c. Using different clock sources to operate the timer with. V3 changes: - Removed definition TIMER_PROP_ALWON per Rob Herring's feedback - Updated OMAP system timer (clock-events and clock-source) code so that HWMOD is NOT used for getting resource (memory and interrupt) information when device-tree is present. V2 changes: - Remove use of device-tree alias property - Migrate OMAP timers to request timers by property instead of device ID - Include OMAP2 support Jon Hunter (5): ARM: dts: OMAP: Add timer nodes ARM: OMAP3: Dynamically disable secure timer nodes for secure devices ARM: OMAP: Add function to request a timer by capability ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices ARM: OMAP: Add DT support for timer driver .../devicetree/bindings/arm/omap/timer.txt | 29 arch/arm/boot/dts/am33xx.dtsi | 61 +++ arch/arm/boot/dts/omap2.dtsi | 86 ++ arch/arm/boot/dts/omap2420.dtsi|8 + arch/arm/boot/dts/omap2430.dtsi|8 + arch/arm/boot/dts/omap3.dtsi | 96 +++ arch/arm/boot/dts/omap4.dtsi | 86 ++ arch/arm/mach-omap2/board-generic.c| 17 ++ arch/arm/mach-omap2/timer.c| 174 arch/arm/plat-omap/dmtimer.c | 93 ++- arch/arm/plat-omap/include/plat/dmtimer.h |1 + 11 files changed, 622 insertions(+), 37 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt -- 1.7.9.5 -- 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 V3 1/5] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2. Add the 12 GP timers nodes present in OMAP3. Add the 11 GP timers nodes present in OMAP4. Add the 7 GP timers nodes present in AM33xx. Add documentation for timer properties specific to OMAP. Please note that for OMAP2/3 devices, there is only one interrupt controller for the ARM CPU (which has the label intc) and so globally define this as the interrupt parent to save duplicating the interrupt parent for all device nodes. Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified Vaibhav's original nodes adding information on which timers support a PWM output. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com --- .../devicetree/bindings/arm/omap/timer.txt | 29 ++ arch/arm/boot/dts/am33xx.dtsi | 61 + arch/arm/boot/dts/omap2.dtsi | 86 ++ arch/arm/boot/dts/omap2420.dtsi|8 ++ arch/arm/boot/dts/omap2430.dtsi|8 ++ arch/arm/boot/dts/omap3.dtsi | 96 arch/arm/boot/dts/omap4.dtsi | 86 ++ 7 files changed, 374 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt new file mode 100644 index 000..d9449d0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt @@ -0,0 +1,29 @@ +OMAP Timer bindings + +Required properties: +- compatible: Must be ti,omap2-timer for OMAP2+ controllers +- reg: Contains timer register address range (base address and length) +- interrupts: Contains the interrupt information for the timer. The format is + being dependent on which interrupt controller the OMAP device + uses. +- ti,hwmods: Name of the hwmod associated to the timer, timerX, where + X is the instance number of the timer from the HW spec. + +Optional properties: +- ti,timer-alwon: Indicates the timer is in an alway-on power domain. +- ti,timer-dsp:Indicates the timer can interrupt the on-chip DSP in + addition to the ARM CPU. +- ti,timer-pwm:Indicates the timer can generate a PWM output. +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device + and therefore cannot be used by the kernel. + +Example: + +timer12: timer@48304000 { + compatible = ti,omap2-timer; + reg = 0x48304000 0xfff; + interrupts = 95; + ti,hwmods = timer12 + ti,timer-alwon; + ti,timer-secure; +}; diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index bb31bff..fd5074c 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -210,5 +210,66 @@ interrupt-parent = intc; interrupts = 91; }; + + timer1: timer@44e31000 { + compatible = ti,omap2-timer; + reg = 0x44e31000 0x1000; + interrupt-parent = intc; + interrupts = 67; + ti,hwmods = timer1; + ti,timer-alwon; + }; + + timer2: timer@4804 { + compatible = ti,omap2-timer; + reg = 0x4804 0x1000; + interrupt-parent = intc; + interrupts = 68; + ti,hwmods = timer2; + }; + + timer3: timer@48042000 { + compatible = ti,omap2-timer; + reg = 0x48042000 0x1000; + interrupt-parent = intc; + interrupts = 69; + ti,hwmods = timer3; + }; + + timer4: timer@48044000 { + compatible = ti,omap2-timer; + reg = 0x48044000 0x1000; + interrupt-parent = intc; + interrupts = 92; + ti,hwmods = timer4; + ti,timer-pwm; + }; + + timer5: timer@48046000 { + compatible = ti,omap2-timer; + reg = 0x48046000 0x1000; + interrupt-parent = intc; + interrupts = 93; + ti,hwmods = timer5; + ti,timer-pwm; + }; + + timer6: timer@48048000 { + compatible = ti,omap2-timer; + reg = 0x48048000 0x1000; + interrupt-parent = intc; + interrupts = 94; + ti,hwmods = timer6; + ti,timer-pwm;
[PATCH V3 2/5] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP). For OMAP3 devices there are 12 general purpose timers available. On secure devices the 12th timer is reserved for secure usage and so cannot be used by the kernel, where as for a GP device it is available. We can detect the OMAP device type, secure or GP, at runtime via an on-chip register. Today, when not using DT, we do not register the 12th timer as a linux device if the device is secure. When using device tree, device tree is going to register all the timer devices it finds in the device tree blob. To prevent device tree from registering 12th timer on a secure OMAP3 device we can add a status property to the timer binding with the value disabled at boot time. Note that timer 12 on a OMAP3 device has a property ti,timer-secure to indicate that it will not be available on a secure device and so for secure OMAP3 devices, we search for timers with this property and then disable them. Using the prom_add_property() function to dynamically add a property was a recommended approach suggested by Rob Herring [1]. I have tested this on an OMAP3 GP device and faking it to pretend to be a secure device to ensure that any timers marked with ti,timer-secure are not registered on boot. I have also made sure that all timers are registered as expected on a GP device by default. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203 Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c | 36 1 file changed, 36 insertions(+) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 44f9aa7..96d26f2 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -144,6 +144,41 @@ static struct clock_event_device clockevent_gpt = { .set_mode = omap2_gp_timer_set_mode, }; +static struct property device_disabled = { + .name = status, + .length = sizeof(disabled), + .value = disabled, +}; + +static struct of_device_id omap_timer_match[] __initdata = { + { .compatible = ti,omap2-timer, }, + { } +}; + +/** + * omap_dmtimer_init - initialisation function when device tree is used + * + * For secure OMAP3 devices, timers with device type timer-secure cannot + * be used by the kernel as they are reserved. Therefore, to prevent the + * kernel registering these devices remove them dynamically from the device + * tree on boot. + */ +void __init omap_dmtimer_init(void) +{ + struct device_node *np; + + if (!cpu_is_omap34xx()) + return; + + /* If we are a secure device, remove any secure timer nodes */ + if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) { + for_each_matching_node(np, omap_timer_match) { + if (of_get_property(np, ti,timer-secure, NULL)) + prom_add_property(np, device_disabled); + } + } +} + static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer, int gptimer_id, const char *fck_source) @@ -437,6 +472,7 @@ static inline void __init realtime_counter_init(void) clksrc_nr, clksrc_src) \ static void __init omap##name##_timer_init(void) \ { \ + omap_dmtimer_init();\ omap2_gp_clockevent_init((clkev_nr), clkev_src);\ omap2_clocksource_init((clksrc_nr), clksrc_src);\ } -- 1.7.9.5 -- 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 V3 3/5] ARM: OMAP: Add function to request a timer by capability
Currently OMAP timers can be requested by requesting any available or by a numerical device ID. If a specific timer is required because it has a particular capability, such as can interrupt the on-chip DSP in addition to the ARM CPU, then the user needs to know the device ID of the timer with this feature. Therefore, add a new API called omap_dm_timer_request_by_cap() that allows drivers to request a timer by capability. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/plat-omap/dmtimer.c | 52 + arch/arm/plat-omap/include/plat/dmtimer.h |1 + 2 files changed, 53 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 938b50a..2574b86 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -237,6 +237,58 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id) } EXPORT_SYMBOL_GPL(omap_dm_timer_request_specific); +/** + * omap_dm_timer_request_by_cap - Request a timer by capability + * @cap: Bit mask of capabilities to match + * + * Find a timer based upon capabilities bit mask. Callers of this function + * should use the definitions found in the plat/dmtimer.h file under the + * comment timer capabilities used in hwmod database. Returns pointer to + * timer handle on success and a NULL pointer on failure. + */ +struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap) +{ + struct omap_dm_timer *timer = NULL, *t; + unsigned long flags; + + if (!cap) + return NULL; + + spin_lock_irqsave(dm_timer_lock, flags); + list_for_each_entry(t, omap_timer_list, node) { + if ((!t-reserved) ((t-capability cap) == cap)) { + /* +* If timer is not NULL, we have already found one timer +* but it was not an exact match because it had more +* capabilites that what was required. Therefore, +* unreserve the last timer found and see if this one +* is a better match. +*/ + if (timer) + timer-reserved = 0; + + timer = t; + timer-reserved = 1; + + /* Exit loop early if we find an exact match */ + if (t-capability == cap) + break; + } + } + spin_unlock_irqrestore(dm_timer_lock, flags); + + if (timer omap_dm_timer_prepare(timer)) { + timer-reserved = 0; + timer = NULL; + } + + if (!timer) + pr_debug(%s: timer request failed!\n, __func__); + + return timer; +} +EXPORT_SYMBOL_GPL(omap_dm_timer_request_by_cap); + int omap_dm_timer_free(struct omap_dm_timer *timer) { if (unlikely(!timer)) diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h index 85868e9..348f855 100644 --- a/arch/arm/plat-omap/include/plat/dmtimer.h +++ b/arch/arm/plat-omap/include/plat/dmtimer.h @@ -99,6 +99,7 @@ struct dmtimer_platform_data { int omap_dm_timer_reserve_systimer(int id); struct omap_dm_timer *omap_dm_timer_request(void); struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id); +struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap); int omap_dm_timer_free(struct omap_dm_timer *timer); void omap_dm_timer_enable(struct omap_dm_timer *timer); void omap_dm_timer_disable(struct omap_dm_timer *timer); -- 1.7.9.5 -- 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 V3 4/5] ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP devices
OMAP3 devices may or may not have security features enabled. Security enabled devices are known as high-secure (HS) and devices without security are known as general purpose (GP). Some OMAP3 boards, such as the OMAP3 beagle board, only use GP devices and for GP devices there is a 12th timer available on-chip that can operate at 32kHz. The clock for 12th timer is generated by an internal oscillator and is unique this timer. Boards such as the beagle board use this timer as a 32kHz based clock-events timer because early versions of the board had a hardware problem preventing them from using other on-chip timers clocked by a external 32kHz clock. When booting with device-tree all OMAP3 devices use timer 1 by default for the clock-events timer. Therefore, add a generic machine descriptor for boards with OMAP3 GP devices so that they can use the 12th timer as the clock-events timer instead of the default. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/board-generic.c | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c index 601ecdf..d690180 100644 --- a/arch/arm/mach-omap2/board-generic.c +++ b/arch/arm/mach-omap2/board-generic.c @@ -97,6 +97,23 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device Tree)) .dt_compat = omap3_boards_compat, .restart= omap_prcm_restart, MACHINE_END + +static const char *omap3_gp_boards_compat[] __initdata = { + ti,omap3-beagle, + NULL, +}; + +DT_MACHINE_START(OMAP3_GP_DT, Generic OMAP3-GP (Flattened Device Tree)) + .reserve= omap_reserve, + .map_io = omap3_map_io, + .init_early = omap3430_init_early, + .init_irq = omap_intc_of_init, + .handle_irq = omap3_intc_handle_irq, + .init_machine = omap_generic_init, + .timer = omap3_secure_timer, + .dt_compat = omap3_gp_boards_compat, + .restart= omap_prcm_restart, +MACHINE_END #endif #ifdef CONFIG_SOC_AM33XX -- 1.7.9.5 -- 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 V3 5/5] ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes were made ... 1. Allocate system timers (used for clock-events and clock-source) based upon timer properties rather than using an hard-coded timer instance ID. To allow this a new helper function called omap_dmtimer_find_by_property() has been added for finding a timer with the particular properties in the device-tree blob. Please note that this is an internal helper function for system timers only to find a timer in the device-tree blob. This cannot be used by device drivers, another API has been added for that (see below). Timers that are allocated for system timers are dynamically disabled at boot time by adding a status property with the value disabled to the timer's device-tree node. Please note that when allocating system timers we now pass a timer ID and timer property. The timer ID is only be used for allocating a timer when booting without device-tree. Once device-tree migration is complete, all the timer ID references will be removed. 2. System timer resources (memory and interrupts) are directly obtained from the device-tree timer node when booting with device-tree, so that system timers are no longer reliant upon the OMAP HWMOD framework to provide these resources. 3. If DT blob is present, then let device-tree create the timer devices dynamically. 4. When device-tree is present the id field in the platform_device structure (pdev-id) is initialised to -1 and hence cannot be used to identify a timer instance. Due to this the following changes were made ... a). The API omap_dm_timer_request_specific() is not supported when using device-tree, because it uses the device ID to request a specific timer. This function will return an error if called when device-tree is present. Users of this API should use omap_dm_timer_request_by_cap() instead. b). When removing the DMTIMER driver, the timer id was used to identify the timer instance. The remove function has been modified to use the device name instead of the id. 5. When device-tree is present the platform_data structure will be NULL and so check for this. 6. The OMAP timer device tree binding has the following optional parameters ... a). ti,timer-alwon -- Timer is in an always-on power domain b). ti,timer-dsp-- Timer can generate an interrupt to the on-chip DSP c). ti,timer-pwm-- Timer can generate a PWM output d). ti,timer-secure -- Timer is reserved on a secure OMAP device Search for the above parameters and set the appropriate timer attribute flags. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c | 146 -- arch/arm/plat-omap/dmtimer.c | 41 ++-- 2 files changed, 146 insertions(+), 41 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 96d26f2..d064afd 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -37,6 +37,8 @@ #include linux/clockchips.h #include linux/slab.h #include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h #include asm/mach/time.h #include asm/smp_twd.h @@ -66,11 +68,13 @@ #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 +#define TIMER_PROP_SECURE ti,timer-secure #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 +#define TIMER_PROP_SECURE ti,timer-alwon #endif #define REALTIME_COUNTER_BASE 0x48243200 @@ -156,6 +160,40 @@ static struct of_device_id omap_timer_match[] __initdata = { }; /** + * omap_get_timer_dt - get a timer using device-tree + * @match - device-tree match structure for matching a device type + * @property - optional timer property to match + * + * Helper function to get a timer during early boot using device-tree for use + * as kernel system timer. Optionally, the property argument can be used to + * select a timer with a specific property. Once a timer is found then mark + * the timer node in device-tree as disabled, to prevent the kernel from + * registering this timer as a platform device and so no one else can use it. + */ +static struct device_node * __init omap_get_timer_dt(struct of_device_id *match, +const char *property) +{ + struct device_node *np; + + for_each_matching_node(np, match) { + if (!of_device_is_available(np)) { + of_node_put(np); + continue; + } + + if (property !of_get_property(np, property, NULL)) { + of_node_put(np); + continue; + } + +
Re: [PATCH V3 0/5] ARM: OMAP2+: Add device-tree support for timers
On 10/17/2012 01:01 PM, Jon Hunter wrote: This series adds device-tree support for the timers on OMAP2+ devices including AM33xx. Testing: 1. I have booted tested this series on OMAP2420 H4, OMAP3430 Beagle, OMAP4430 Panda and AM335x Beagle Bone with/without ... a). device-tree present b). CONFIG_OMAP_32K_TIMER set c). kernel boot parameter clocksource=gp_timer present 2. I have tested the all the timers (not used by the kernel as sys-timers) on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree with this series. The testing includes ... a. Configuring, starting a timer and checking the counter value is incrementing. b. Testing timer overflow interrupt when timer expires. c. Using different clock sources to operate the timer with. V3 changes: - Removed definition TIMER_PROP_ALWON per Rob Herring's feedback - Updated OMAP system timer (clock-events and clock-source) code so that HWMOD is NOT used for getting resource (memory and interrupt) information when device-tree is present. V2 changes: - Remove use of device-tree alias property - Migrate OMAP timers to request timers by property instead of device ID - Include OMAP2 support Forgot to mention that this is based on top of v3.7-rc1. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
* Tony Lindgren t...@atomide.com [121015 17:09]: * Tony Lindgren t...@atomide.com [121009 17:21]: * Péter Ujfalusi peter.ujfal...@ti.com [121009 02:03]: On 10/08/2012 07:35 PM, Tony Lindgren wrote: - omap-dma.c and omap-pcm.c can test the arch locally as omap1 and omap2 cannot be compiled together because of conflicting compiler flags sound/soc/omap/omap-pcm.c |9 +++-- Tony: is this going to be included in 3.7? Hmm I guess we could try to get this out of the way to cut down the dependencies. Let's if maintainers of the other affected drivers this is OK for the -rc series. It seems that nobody needs these until for v3.8, so I'll be applying this into omap-for-v3.8/cleanup-headers-prepare branch soon. Anybody else care to ack? OK pushed out now with just that patch in the branch in case driver branches need to merge it in too to avoid conflicts. 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
Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
Paul, Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html Thanks, Richard - Forwarded message from Richard Cochran richardcoch...@gmail.com - Date: Mon, 15 Oct 2012 21:16:32 +0200 From: Richard Cochran richardcoch...@gmail.com To: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de, David Miller da...@davemloft.net, Russell King li...@arm.linux.org.uk, Mugunthan V N mugunthan...@ti.com Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio X-Mailer: git-send-email 1.7.2.5 From: Mugunthan V N mugunthan...@ti.com This patch adds minimal hwmod support for davinci mdio driver. This patch requires rework on parent child relation between cpsw and davinci mdio hwmod data to support runtime PM. Signed-off-by: Mugunthan V N mugunthan...@ti.com --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 34 ++- 1 files changed, 32 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c index 59d5c1c..f96bbc0 100644 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = { .rev_offs = 0x0, .sysc_offs = 0x8, .syss_offs = 0x4, - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE | - SYSS_HAS_RESET_STATUS), + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE), .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE | MSTANDBY_NO), .sysc_fields= omap_hwmod_sysc_type3, @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = { .modulemode = MODULEMODE_SWCTRL, }, }, + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY | + HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE), }; /* @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = { { } }; +/* mdio class */ +static struct omap_hwmod_class am33xx_mdio_hwmod_class = { + .name = davinci_mdio, +}; + +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = { + { + .pa_start = 0x4A101000, + .pa_end = 0x4A101000 + SZ_256 - 1, + .flags = ADDR_MAP_ON_INIT, + }, + { } +}; + +static struct omap_hwmod am33xx_mdio_hwmod = { + .name = davinci_mdio, + .class = am33xx_mdio_hwmod_class, + .clkdm_name = cpsw_125mhz_clkdm, + .main_clk = cpsw_125mhz_gclk, +}; + +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = { + .master = am33xx_cpgmac0_hwmod, + .slave = am33xx_mdio_hwmod, + .addr = am33xx_mdio_addr_space, + .user = OCP_USER_MPU, +}; + static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = { .master = am33xx_l4_ls_hwmod, .slave = am33xx_elm_hwmod, @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { am33xx_l3_main__tptc2, am33xx_l3_s__usbss, am33xx_l4_hs__cpgmac0, + am33xx_cpgmac0__mdio, NULL, }; -- 1.7.2.5 - End forwarded message - -- 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
Fwd: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
Benoit, Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html Thanks, Richard - Forwarded message from Richard Cochran richardcoch...@gmail.com - Date: Mon, 15 Oct 2012 21:16:35 +0200 From: Richard Cochran richardcoch...@gmail.com To: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de, David Miller da...@davemloft.net, Russell King li...@arm.linux.org.uk, Mugunthan V N mugunthan...@ti.com, Vaibhav Hiremath hvaib...@ti.com Subject: [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX X-Mailer: git-send-email 1.7.2.5 From: Mugunthan V N mugunthan...@ti.com Add CPSW and MDIO related device tree data for AM33XX. Also enable them into board/evm dts files by providing respective phy-id. Signed-off-by: Mugunthan V N mugunthan...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- arch/arm/boot/dts/am335x-bone.dts |8 ++ arch/arm/boot/dts/am335x-evm.dts |8 ++ arch/arm/boot/dts/am33xx.dtsi | 50 + 3 files changed, 66 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts index c634f87..e233cfa 100644 --- a/arch/arm/boot/dts/am335x-bone.dts +++ b/arch/arm/boot/dts/am335x-bone.dts @@ -78,3 +78,11 @@ }; }; }; + +cpsw_emac0 { + phy_id = 4a101000.mdio:00; +}; + +cpsw_emac1 { + phy_id = 4a101000.mdio:01; +}; diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 185d632..415c3b3 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -118,3 +118,11 @@ }; }; }; + +cpsw_emac0 { + phy_id = 4a101000.mdio:00; +}; + +cpsw_emac1 { + phy_id = 4a101000.mdio:01; +}; diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index bb31bff..f6bea04 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -210,5 +210,55 @@ interrupt-parent = intc; interrupts = 91; }; + + mac: ethernet@4A10 { + compatible = ti,cpsw; + ti,hwmods = cpgmac0; + cpdma_channels = 8; + host_port_no = 0; + cpdma_reg_ofs = 0x800; + cpdma_sram_ofs = 0xa00; + ale_reg_ofs = 0xd00; + ale_entries = 1024; + host_port_reg_ofs = 0x108; + hw_stats_reg_ofs = 0x900; + bd_ram_ofs = 0x2000; + bd_ram_size = 0x2000; + no_bd_ram = 0; + rx_descs = 64; + mac_control = 0x20; + slaves = 2; + reg = 0x4a10 0x800 + 0x4a101200 0x100 + 0x4a101000 0x100; + #address-cells = 1; + #size-cells = 1; + interrupt-parent = intc; + /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend c0_misc_pend*/ + interrupts = 40 41 42 43; + ranges; + cpsw_emac0: slave@0 { + slave_reg_ofs = 0x208; + sliver_reg_ofs = 0xd80; + /* Filled in by U-Boot */ + mac-address = [ 00 00 00 00 00 00 ]; + }; + cpsw_emac1: slave@1 { + slave_reg_ofs = 0x308; + sliver_reg_ofs = 0xdc0; + /* Filled in by U-Boot */ + mac-address = [ 00 00 00 00 00 00 ]; + }; + + davinci_mdio: mdio@4a101000 { + compatible = ti,davinci_mdio; + #address-cells = 1; + #size-cells = 0; + ti,hwmods = davinci_mdio; + bus_freq = 100; + reg = 0x4a101000 0x100; + }; + + }; }; }; -- 1.7.2.5 - End forwarded message - -- 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 0/5] OMAP: VRFB: convert to platform device
* Tomi Valkeinen tomi.valkei...@ti.com [121017 03:27]: Hi Tony, I have pushed this vrfb series and the omapdss version series to: git://gitorious.org/linux-omap-dss2/linux.git 3.8/dss-version I used this branch up to commit 35f70935c64ae229ebd1fc65398ec68d4d803712, but left out the x86 compile changes as those seem unrelated to the plat issue. git://gitorious.org/linux-omap-dss2/linux.git 3.8/vrfb-conversion And then I merged in this branch. I have the merged branch at omap-for-v3.8/cleanup-headers-dss. If they look ok to you and we don't get any other comments, I think these branches can be considered stable and you can pull them. Thanks yes let's consider those frozen and if something needs to be fixed it should be done on top of those commits. After these are merged: $ git grep -E (plat/)|(mach/) drivers/video/omap2/ drivers/video/omap2/omapfb/omapfb-ioctl.c:#include plat/vram.h drivers/video/omap2/omapfb/omapfb-main.c:#include plat/vram.h drivers/video/omap2/vram.c:#include plat/vram.h So the vram stuff should be the only omap dependency left in omapdss and omapfb. I'll start working on that soon. OK thanks a lot. Then there's also the two vout files that you may already have patches for: drivers/media/platform/omap/omap_vout.c drivers/media/platform/omap/omap_voutlib.c 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
[PATCH] Nokia N9/N900/N950 -- mention product names
Hi! This adds product names (that most users know) to Kconfig and board comments. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 346fd26..da08226 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680/696 board + bool Nokia N9/N950 (RM-680/696) phones depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select MACH_NOKIA_RM696 config MACH_NOKIA_RX51 - bool Nokia RX-51 board + bool Nokia N900 phone (RX-51) depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 0ad1bb3b..26965f3 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680/696. + * Board support file for Nokia N9/N950 (aka RM-680/696). * * Copyright (C) 2010 Nokia * diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c index 345dd93..b60ca9d 100644 --- a/arch/arm/mach-omap2/board-rx51.c +++ b/arch/arm/mach-omap2/board-rx51.c @@ -1,5 +1,5 @@ /* - * linux/arch/arm/mach-omap2/board-rx51.c + * Board support file for Nokia N900 (aka RX-51). * * Copyright (C) 2007, 2008 Nokia * -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[PATCH 0/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
This series adds device-tree support for the 32kHz counter on OMAP2+ devices, which is used as the default kernel clock-source for OMAP devices. Boot tested on OMAP2420 H4, OMAP3430 Beagle Board and OMAP4430 Panda Board with and without device-tree present. Based and dependent upon OMAP2+ series that adds device-tree support for DMTIMERs [1]. [1] http://marc.info/?l=linux-omapm=135049690119218w=2 Jon Hunter (2): ARM: dts: OMAP: Add counter-32k nodes ARM: OMAP2+: Add device-tree support for 32kHz counter .../devicetree/bindings/arm/omap/counter32k.txt| 15 +++ arch/arm/boot/dts/omap2420.dtsi|6 + arch/arm/boot/dts/omap2430.dtsi|6 + arch/arm/boot/dts/omap3.dtsi |6 + arch/arm/boot/dts/omap4.dtsi |6 + arch/arm/mach-omap2/timer.c| 28 +++- 6 files changed, 66 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt -- 1.7.9.5 -- 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] ARM: dts: OMAP: Add counter-32k nodes
Adds the counter-32k timers nodes present in OMAP2/3/4 devices and device-tree binding documentation for OMAP counter-32k. Signed-off-by: Jon Hunter jon-hun...@ti.com --- .../devicetree/bindings/arm/omap/counter32k.txt| 15 +++ arch/arm/boot/dts/omap2420.dtsi|6 ++ arch/arm/boot/dts/omap2430.dtsi|6 ++ arch/arm/boot/dts/omap3.dtsi |6 ++ arch/arm/boot/dts/omap4.dtsi |6 ++ 5 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/counter32k.txt diff --git a/Documentation/devicetree/bindings/arm/omap/counter32k.txt b/Documentation/devicetree/bindings/arm/omap/counter32k.txt new file mode 100644 index 000..1983fae --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/counter32k.txt @@ -0,0 +1,15 @@ +OMAP Counter-32K bindings + +Required properties: +- compatible: Must be ti,omap-counter32k for OMAP controllers +- reg: Contains timer register address range (base address and length) +- ti,hwmods: Name of the hwmod associated to the counter, which is typically + counter_32k + +Example: + +counter32k: counter32k@4a304000 { + compatible = ti,omap-counter32k; + reg = 0x4a304000 0x001f; + ti,hwmods = counter_32k; +}; diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi index 5f68a70..082193f 100644 --- a/arch/arm/boot/dts/omap2420.dtsi +++ b/arch/arm/boot/dts/omap2420.dtsi @@ -14,6 +14,12 @@ compatible = ti,omap2420, ti,omap2; ocp { + counter32k: counter32k@48004000 { + compatible = ti,omap-counter32k; + reg = 0x48004000 0x001f; + ti,hwmods = counter_32k; + }; + omap2420_pmx: pinmux@4830 { compatible = ti,omap2420-padconf, pinctrl-single; reg = 0x4830 0x0113; diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 7439987..2e568cf 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -14,6 +14,12 @@ compatible = ti,omap2430, ti,omap2; ocp { + counter32k: counter32k@4902 { + compatible = ti,omap-counter32k; + reg = 0x4902 0x001f; + ti,hwmods = counter_32k; + }; + omap2430_pmx: pinmux@49002030 { compatible = ti,omap2430-padconf, pinctrl-single; reg = 0x49002030 0x0154; diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 3fb910f..aa775b2 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -61,6 +61,12 @@ ranges; ti,hwmods = l3_main; + counter32k: counter32k@4832 { + compatible = ti,omap-counter32k; + reg = 0x4832 0x001f; + ti,hwmods = counter_32k; + }; + intc: interrupt-controller@4820 { compatible = ti,omap2-intc; interrupt-controller; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index f6ac2b7..3eb66ee 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -95,6 +95,12 @@ ranges; ti,hwmods = l3_main_1, l3_main_2, l3_main_3; + counter32k: counter32k@4a304000 { + compatible = ti,omap-counter32k; + reg = 0x4a304000 0x001f; + ti,hwmods = counter_32k; + }; + omap4_pmx_core: pinmux@4a100040 { compatible = ti,omap4-padconf, pinctrl-single; reg = 0x4a100040 0x0196; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: Add device-tree support for 32kHz counter
For OMAP devices, the 32kHz counter is the default clock-source for the kernel. However, this is not the only possible clock-source the kernel can use for OMAP devices. When booting with device-tree, if the 32kHz counter is the desired clock-source for the kernel, then parse the device-tree blob to ensure that the counter is present and if so map memory for the counter using the device-tree of_iomap() function so we are no longer reliant on the OMAP HWMOD framework to do this for us. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index d064afd..a67688f 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -159,6 +159,11 @@ static struct of_device_id omap_timer_match[] __initdata = { { } }; +static struct of_device_id omap_counter_match[] __initdata = { + { .compatible = ti,omap-counter32k, }, + { } +}; + /** * omap_get_timer_dt - get a timer using device-tree * @match - device-tree match structure for matching a device type @@ -378,11 +383,26 @@ static u32 notrace dmtimer_read_sched_clock(void) static int __init omap2_sync32k_clocksource_init(void) { int ret; + struct device_node *np = NULL; struct omap_hwmod *oh; void __iomem *vbase; const char *oh_name = counter_32k; /* +* If device-tree is present, then search the DT blob +* to see if the 32kHz counter is supported. +*/ + if (of_have_populated_dt()) { + np = omap_get_timer_dt(omap_counter_match, NULL); + if (!np) + return -ENODEV; + + of_property_read_string_index(np, ti,hwmods, 0, oh_name); + if (!oh_name) + return -ENODEV; + } + + /* * First check hwmod data is available for sync32k counter */ oh = omap_hwmod_lookup(oh_name); @@ -391,7 +411,13 @@ static int __init omap2_sync32k_clocksource_init(void) omap_hwmod_setup_one(oh_name); - vbase = omap_hwmod_get_mpu_rt_va(oh); + if (of_have_populated_dt()) { + vbase = of_iomap(np, 0); + of_node_put(np); + } else { + vbase = omap_hwmod_get_mpu_rt_va(oh); + } + if (!vbase) { pr_warn(%s: failed to get counter_32k resource\n, __func__); return -ENXIO; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driver
From: Vaibhav Hiremath hvaib...@ti.com Add dmtimer clock aliases for AM33XX devices so that the parent clock for the dmtimer can be set correctly by the dmtimer driver. Without these clock aliases the dmtimer driver will fail to find the parent clocks for the dmtimer. Verified that DMTIMERs can be successfully requested on AM335x beagle bone. Original patch was provided by Vaibhav Hiremath [1]. Changelog and additional verification performed by Jon Hunter. [1] http://marc.info/?l=linux-omapm=134693631608018w=2 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Tested-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/clock33xx_data.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-omap2/clock33xx_data.c b/arch/arm/mach-omap2/clock33xx_data.c index 114ab4b..1a45d6b 100644 --- a/arch/arm/mach-omap2/clock33xx_data.c +++ b/arch/arm/mach-omap2/clock33xx_data.c @@ -1073,6 +1073,8 @@ static struct omap_clk am33xx_clks[] = { CLK(NULL, gfx_fck_div_ck, gfx_fck_div_ck, CK_AM33XX), CLK(NULL, sysclkout_pre_ck, sysclkout_pre_ck, CK_AM33XX), CLK(NULL, clkout2_ck, clkout2_ck,CK_AM33XX), + CLK(NULL, timer_32k_ck, clkdiv32k_ick, CK_AM33XX), + CLK(NULL, timer_sys_ck, sys_clkin_ck, CK_AM33XX), }; int __init am33xx_clk_init(void) -- 1.7.9.5 -- 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] Nokia N9/N900/N950 -- mention product names
Hi, Some minor comments: On Wed, Oct 17, 2012 at 08:33:08PM +0200, Pavel Machek wrote: This adds product names (that most users know) to Kconfig and board comments. Good idea. :-) Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 346fd26..da08226 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680/696 board + bool Nokia N9/N950 (RM-680/696) phones This should be N950/N9 (RM-680/RM-696) or perhaps for clarity N950 (RM-680) / N9 (RM-696). depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select MACH_NOKIA_RM696 config MACH_NOKIA_RX51 - bool Nokia RX-51 board + bool Nokia N900 phone (RX-51) depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 0ad1bb3b..26965f3 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680/696. + * Board support file for Nokia N9/N950 (aka RM-680/696). Same here. Thanks, A. -- 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
IS_ERR_OR_NULL - please STOP telling people to use this on a whim
People, This is not aimed at anyone specifically - but it is aimed at everyone who reviews patches to make them aware of this issue, and to modify their behaviour. I'm geting sick and tired of telling people about this. I've just floated the idea of removing IS_ERR_OR_NULL from the kernel tree because it's one of the most incorrectly used and abused macros we have in the source tree. It would be one thing if this was only being done by people who are submitting new code, but it's far worse than that. Reviewers who should know better are telling people to use it _incorrectly_. Reviewers really need to think about your review comments. Looking through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(), many of them are *buggy*. Take a moment to think about this: int error_value(struct device *dev, void *foo) { if (IS_ERR_OR_NULL(foo)) return PTR_ERR(foo); return 0; } Consider the value this function returns for three arguments: 1. an errno encoded pointer 2. a NULL pointer. 3. a valid pointer. If you can't see the problem, then *do* *not* tell anyone to use IS_ERR_OR_NULL(), because you do *not* have the understanding necessary to make that judgement yourself - you're probably telling people to create buggy code. Here's the list so far of what looks like buggy uses specific to ARM. There _are_ others elsewhere in the kernel. drivers/media/video/s5p-mfc/s5p_mfc.c: if (IS_ERR_OR_NULL(dev-alloc_ctx[0])) { drivers/media/video/s5p-mfc/s5p_mfc.c- ret = PTR_ERR(dev-alloc_ctx[0]); drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_res; drivers/media/video/s5p-mfc/s5p_mfc.c- } -- drivers/media/video/s5p-mfc/s5p_mfc.c: if (IS_ERR_OR_NULL(dev-alloc_ctx[1])) { drivers/media/video/s5p-mfc/s5p_mfc.c- ret = PTR_ERR(dev-alloc_ctx[1]); drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_mem_init_ctx_1; drivers/media/video/s5p-mfc/s5p_mfc.c- } -- drivers/staging/omapdrm/omap_dmm_tiler.c: if (IS_ERR_OR_NULL(txn)) drivers/staging/omapdrm/omap_dmm_tiler.c- return PTR_ERR(txn); drivers/staging/omapdrm/omap_dmm_tiler.c- drivers/staging/omapdrm/omap_dmm_tiler.c- tcm_for_each_slice(slice, *area, area_s) { -- drivers/staging/omap-thermal/omap-bandgap.c:if (IS_ERR_OR_NULL(bg_ptr)) { drivers/staging/omap-thermal/omap-bandgap.c-dev_err(pdev-dev, failed to fetch platform data\n); drivers/staging/omap-thermal/omap-bandgap.c-return PTR_ERR(bg_ptr); drivers/staging/omap-thermal/omap-bandgap.c-} -- drivers/staging/omap-thermal/omap-thermal-common.c: if (IS_ERR_OR_NULL(data-omap_thermal)) { drivers/staging/omap-thermal/omap-thermal-common.c- dev_err(bg_ptr-dev, thermal zone device is NULL\n); drivers/staging/omap-thermal/omap-thermal-common.c- return PTR_ERR(data-omap_thermal); drivers/staging/omap-thermal/omap-thermal-common.c- } -- drivers/staging/omap-thermal/omap-thermal-common.c: if (IS_ERR_OR_NULL(freq_table)) { drivers/staging/omap-thermal/omap-thermal-common.c- dev_err(bg_ptr-dev, drivers/staging/omap-thermal/omap-thermal-common.c- %s: failed to get cpufreq table (%p)\n, drivers/staging/omap-thermal/omap-thermal-common.c- __func__, freq_table); -- drivers/staging/omap-thermal/omap-thermal-common.c: if (IS_ERR_OR_NULL(data-cool_dev)) { drivers/staging/omap-thermal/omap-thermal-common.c- dev_err(bg_ptr-dev, drivers/staging/omap-thermal/omap-thermal-common.c- Failed to register cpufreq cooling device\n); drivers/staging/omap-thermal/omap-thermal-common.c- return PTR_ERR(data-cool_dev); -- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c: if (IS_ERR_OR_NULL(sgt)) { drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- ret = PTR_ERR(sgt); drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- goto err_buf_detach; drivers/gpu/drm/exynos/exynos_drm_dmabuf.c- } -- drivers/gpu/drm/exynos/exynos_drm_fbdev.c: if (IS_ERR_OR_NULL(helper-fb)) { drivers/gpu/drm/exynos/exynos_drm_fbdev.c- DRM_ERROR(failed to create drm framebuffer.\n); drivers/gpu/drm/exynos/exynos_drm_fbdev.c- ret = PTR_ERR(helper-fb); drivers/gpu/drm/exynos/exynos_drm_fbdev.c- goto out; -- -- 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 0/2] ASoC: omap-mcpdm updates for 3.7
Hi Mark, * Peter Ujfalusi peter.ujfal...@ti.com [121004 01:27]: Hello Mark, Tony, Change since v1: - Fixed the second patch to keep the omap_mcpdm_open_stream() - after a coffee The mcpdm driver no longer needs to include any plat/*.h file, clearing the way for the single kernel image. Regards, Peter --- Peter Ujfalusi (1): ASoC: omap-mcpdm: Remove OMAP revision check Tony Lindgren (1): ASoC: Fix wrong include for McPDM sound/soc/omap/omap-mcpdm.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) Is it OK for me to merge in your ASoC for-3.7 branch at commit 68214d99 (ASoC: omap-mcpdm: Remove OMAP revision check) also into my omap cleanup branch for v3.8? I need that to avoid compile errors with some of my test configs. 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
[PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
Currently, whenever we idle a device _idle_sysc() is called and writes to the devices SYSCONFIG register to set the idle mode. A lot devices are using the smart-idle mode and so the write to the SYSCONFIG register is programming the same value that is already stored in the register. Writes to the devices SYSCONFIG register can be slow, for example, writing to the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can take ~100us. Furthermore, during boot on an OMAP4430 panda board, I see that there are 100 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write the SYSCONFIG register with a new value. Therefore, to avoid unnecessary writes to device SYSCONFIG registers when idling the device, only write the value if the value has changed. It should be safe to do this on idle as the context of the register will never be lost while the device is active. Verified that suspend, CORE off and retention states are working with this change on OMAP3430 Beagle board. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index b969ab1..962773b 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -1389,6 +1389,10 @@ static void _idle_sysc(struct omap_hwmod *oh) if ((sf SYSC_HAS_SIDLEMODE) !(oh-flags HWMOD_SWSUP_SIDLE)) _enable_wakeup(oh, v); + /* If the cached value is the same as the new value, skip the write */ + if (oh-_sysc_cache == v) + return; + _write_sysconfig(v, oh); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
cc Rajendra Hi Jon On Wed, 17 Oct 2012, Jon Hunter wrote: Currently, whenever we idle a device _idle_sysc() is called and writes to the devices SYSCONFIG register to set the idle mode. A lot devices are using the smart-idle mode and so the write to the SYSCONFIG register is programming the same value that is already stored in the register. Writes to the devices SYSCONFIG register can be slow, for example, writing to the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can take ~100us. Furthermore, during boot on an OMAP4430 panda board, I see that there are 100 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write the SYSCONFIG register with a new value. Therefore, to avoid unnecessary writes to device SYSCONFIG registers when idling the device, only write the value if the value has changed. It should be safe to do this on idle as the context of the register will never be lost while the device is active. Verified that suspend, CORE off and retention states are working with this change on OMAP3430 Beagle board. The code used to do what you propose in _write_sysconfig(), which applied to all sysconfig writes, not just idle. But it was changed by commit 233cbe5b94096f95ba7bca2162d63275b0b90b5b (OMAP2+: hwmod: Update the sysc_cache in case module context is lost). Could you take a look at this and maybe discuss it with Rajendra? It seems to make more sense to me to cache it by default, and only invalidate it when we know that context is lost. - 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 v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h
* Felipe Balbi ba...@ti.com [121017 08:54]: In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Thanks, looks like I can't make this apply against v3.7-rc1: patching file arch/arm/plat-omap/include/plat/usb.h Hunk #1 FAILED at 1. Hunk #2 FAILED at 26. Hunk #3 FAILED at 44. Hunk #4 FAILED at 65. Hunk #5 FAILED at 81. Hunk #6 succeeded at 28 with fuzz 2 (offset -128 lines). 5 out of 6 hunks FAILED -- rejects in file arch/arm/plat-omap/include/plat/usb.h Can you please check it? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
On 10/17/2012 03:25 PM, Paul Walmsley wrote: cc Rajendra Hi Jon On Wed, 17 Oct 2012, Jon Hunter wrote: Currently, whenever we idle a device _idle_sysc() is called and writes to the devices SYSCONFIG register to set the idle mode. A lot devices are using the smart-idle mode and so the write to the SYSCONFIG register is programming the same value that is already stored in the register. Writes to the devices SYSCONFIG register can be slow, for example, writing to the DMTIMER SYSCONFIG register takes 3 interface clock cycles and 3 functional clock cycles. If the DMTIMER is using the slow 32kHz functional clock this can take ~100us. Furthermore, during boot on an OMAP4430 panda board, I see that there are 100 calls to _idle_sysc(), however, only 3 out of the 100 calls actually write the SYSCONFIG register with a new value. Therefore, to avoid unnecessary writes to device SYSCONFIG registers when idling the device, only write the value if the value has changed. It should be safe to do this on idle as the context of the register will never be lost while the device is active. Verified that suspend, CORE off and retention states are working with this change on OMAP3430 Beagle board. The code used to do what you propose in _write_sysconfig(), which applied to all sysconfig writes, not just idle. But it was changed by commit 233cbe5b94096f95ba7bca2162d63275b0b90b5b (OMAP2+: hwmod: Update the sysc_cache in case module context is lost). Could you take a look at this and maybe discuss it with Rajendra? It seems to make more sense to me to cache it by default, and only invalidate it when we know that context is lost. Ok, thanks. Yes, only updating the register when the cache value changed would not work due to the possibility of context being lost. So Rajendra's change makes sense. However, I think there is room to optimise this. With this change, on idle, the cache value and register value are only updated when needed. This should be safe. Are you looking to go one step further and only update the sysconfig on enabling when the context has been lost? That would require more changes. This was a quick optimisation I saw when reviewing the code. Rajendra, let me know if you have any comments. Cheers Jon -- 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: IS_ERR_OR_NULL - please STOP telling people to use this on a whim
On 17/10/12 20:41 +0100, Russell King - ARM Linux wrote: People, This is not aimed at anyone specifically - but it is aimed at everyone who reviews patches to make them aware of this issue, and to modify their behaviour. I'm geting sick and tired of telling people about this. I've just floated the idea of removing IS_ERR_OR_NULL from the kernel tree because it's one of the most incorrectly used and abused macros we have in the source tree. This makes me sad. I was responsible for its introduction, and my motive was exactly yours in sending the above. It would be one thing if this was only being done by people who are submitting new code, but it's far worse than that. Reviewers who should know better are telling people to use it _incorrectly_. Reviewers really need to think about your review comments. Looking through the kernel tree today, I see lots of uses of IS_ERR_OR_NULL(), many of them are *buggy*. Take a moment to think about this: int error_value(struct device *dev, void *foo) { if (IS_ERR_OR_NULL(foo)) return PTR_ERR(foo); return 0; } Consider the value this function returns for three arguments: 1. an errno encoded pointer 2. a NULL pointer. 3. a valid pointer. If you can't see the problem, then *do* *not* tell anyone to use IS_ERR_OR_NULL(), because you do *not* have the understanding necessary to make that judgement yourself - you're probably telling people to create buggy code. The problem I saw was functions returning -ERRORs or NULL. There were too many, and there was too much sloppy code inconsistently handling one or either of the two, and not always both. I did consider trying to fix some of the core functions that were returning -ERRORs or NULL to the drivers I was involved in, but it seemed like there were too many, and that would be too brave. I imagined that my macro would help catch that undesirable situation, and permit people to map the error onto whatever was most appropriate to propagate on. The idea of them propagating the undesirable problem up further in the call chain is the exact antithesis of what I intended. Thank you for highlighting the issue I didn't foresee (neither did my colleagues at Nokia, they made good use of it fairly quickly) and in such unambiguous terms. Better to nip it in the bud, certainly. Here's the list so far of what looks like buggy uses specific to ARM. There _are_ others elsewhere in the kernel. drivers/media/video/s5p-mfc/s5p_mfc.c: if (IS_ERR_OR_NULL(dev-alloc_ctx[0])) { drivers/media/video/s5p-mfc/s5p_mfc.c- ret = PTR_ERR(dev-alloc_ctx[0]); drivers/media/video/s5p-mfc/s5p_mfc.c- goto err_res; drivers/media/video/s5p-mfc/s5p_mfc.c- } ... :-( So, what to do? It can and has been used sensibly, so I don't think removing it is the best option. Phil pcarm...@nokia.com is no more, I'm now pc+l...@asdf.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
On Wed, 17 Oct 2012, Jon Hunter wrote: Are you looking to go one step further and only update the sysconfig on enabling when the context has been lost? That would require more changes. Yes that's exactly it. That would avoid adding a special case for what should be the common case. From a quick glance it looks like the cache needs to be loaded in _reset(), omap_hwmod_softreset(), and _enable(). Other than that, seems like the cached value should work. It should also be possible to avoid the reload in _enable() in most cases since the PM code should know whether the IP block's powerdomain was programmed to go off and indeed whether it did so. It shouldn't involve any extra register reads. But I wouldn't expect you to add that optimization; would just be nice to have a comment to that effect. If the meta-theme of your message is that commit 233cbe5b94096f95ba7bca2162d63275b0b90b5b should have had closer scrutiny, I agree with you, but we're beyond that point now... - 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] Nokia N9/N900/N950 -- mention product names
This adds product names (that most users know) to Kconfig and board comments. Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 346fd26..f03f19a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680/696 board + bool Nokia N950 (RM-680) / N9 (RM-696) phones depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select MACH_NOKIA_RM696 config MACH_NOKIA_RX51 - bool Nokia RX-51 board + bool Nokia N900 (RX-51) phone depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 0ad1bb3b..96f8757 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680/696. + * Board support file for Nokia N950 (RM-680) / N9 (RM-696). * * Copyright (C) 2010 Nokia * diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c index 345dd93..b60ca9d 100644 --- a/arch/arm/mach-omap2/board-rx51.c +++ b/arch/arm/mach-omap2/board-rx51.c @@ -1,5 +1,5 @@ /* - * linux/arch/arm/mach-omap2/board-rx51.c + * Board support file for Nokia N900 (aka RX-51). * * Copyright (C) 2007, 2008 Nokia * -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: discrepancy while save and restore of debounce registers
Hi Gururaja, On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote: Hi, I came across a peculiar issue while updating GPIO debounce registers on OMAP platform. According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537 gpio/omap: save and restore debounce registers GPIO debounce registers need to be saved and restored for proper functioning of driver. ... @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank *bank) __raw_writel(bank-context.fallingdetect, bank-base + bank-regs-fallingdetect); __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout); + if (bank-dbck_enable_mask) { + __raw_writel(bank-context.debounce, bank-base + + bank-regs-debounce); + __raw_writel(bank-context.debounce_en, + bank-base + bank-regs-debounce_en); + } } Due to copy/paste of this commit into my local tree, I missed the check for bank-dbck_enable_mask, and directly restored the saved value from context. After this, I saw random crashes when accessing different registers (sometimes its OE register and sometime its DATAOUT register). These crashes were seen across 2nd and subsequent suspend/resume. My doubt/questions are 1. Why should debounce registers be updated only when it's accessed previously? If debounce is not being used by any of the gpios, then there is no need to restore them as there are no bits set. So this makes sense and saves a couple register writes. 2. What is the relation between updating debounce registers and crash seen on others registers? This I am not sure about. I gave this a quick try on my omap3430 beagle board, but I did not see any side-effects from doing this. However, if you are always restoring the debounce context regardless of whether debounce is being used, then you could be writing bad values to the debounce registers as the context variables bank-context.debouce and bank-context.debouce_en may not initialised. So that is bad. However, that said I am still not sure how this could cause a crash. Can you share more details on ... 1. The OMAP platform you are using? 2. What linux distro/environment you are using? 3. If there are any specific steps to reproduce this 100% of the time? Cheers Jon -- 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] Nokia N9/N900/N950 -- mention product names
On Wed, Oct 17, 2012 at 11:03:00PM +0200, Pavel Machek wrote: This adds product names (that most users know) to Kconfig and board comments. Signed-off-by: Pavel Machek pa...@ucw.cz Reviewed-by: Aaro Koskinen aaro.koski...@iki.fi A. diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 346fd26..f03f19a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -263,14 +263,14 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680/696 board + bool Nokia N950 (RM-680) / N9 (RM-696) phones depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select MACH_NOKIA_RM696 config MACH_NOKIA_RX51 - bool Nokia RX-51 board + bool Nokia N900 (RX-51) phone depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 0ad1bb3b..96f8757 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680/696. + * Board support file for Nokia N950 (RM-680) / N9 (RM-696). * * Copyright (C) 2010 Nokia * diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c index 345dd93..b60ca9d 100644 --- a/arch/arm/mach-omap2/board-rx51.c +++ b/arch/arm/mach-omap2/board-rx51.c @@ -1,5 +1,5 @@ /* - * linux/arch/arm/mach-omap2/board-rx51.c + * Board support file for Nokia N900 (aka RX-51). * * Copyright (C) 2007, 2008 Nokia * -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
On 10/17/2012 03:58 PM, Paul Walmsley wrote: On Wed, 17 Oct 2012, Jon Hunter wrote: Are you looking to go one step further and only update the sysconfig on enabling when the context has been lost? That would require more changes. Yes that's exactly it. That would avoid adding a special case for what should be the common case. From a quick glance it looks like the cache needs to be loaded in _reset(), omap_hwmod_softreset(), and _enable(). Other than that, seems like the cached value should work. It should also be possible to avoid the reload in _enable() in most cases since the PM code should know whether the IP block's powerdomain was programmed to go off and indeed whether it did so. It shouldn't involve any extra register reads. But I wouldn't expect you to add that optimization; would just be nice to have a comment to that effect. Ah, so you really want the cache to behave like a cache. That would be nice! If the meta-theme of your message is that commit 233cbe5b94096f95ba7bca2162d63275b0b90b5b should have had closer scrutiny, I agree with you, but we're beyond that point now... No under-lying theme here, just more of a I stumbled across this while debugging something else and I am a nut-case about saving cpu cycles where I can. Although not always possible and I am probably responsible for burning more cycles than I am saving these days! Cheers Jon -- 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: IS_ERR_OR_NULL - please STOP telling people to use this on a whim
On Wed, Oct 17, 2012 at 11:28:48PM +0300, Phil Carmody wrote: So, what to do? It can and has been used sensibly, so I don't think removing it is the best option. Well, the first thing that needs to be done is a full review of every user and fixes applied. The second thing is that we need eyes on code _and_ review comments, and educate those who are telling people to use IS_ERR_OR_NULL() whenever they see an IS_ERR() to think about the code a little more - that's kind of the purpose of my email. Unfortunately, it's going to take time to achieve a change, and if I end up being the only one who's spotting these errors, I'm going to get incredibly pissed off at doing so (because it will feel like I'm being ignored when there's a constant stream of it.) Another thing would be to work out whether we can get checkpatch to detect usage of IS_ERR_OR_NULL(p) followed by PTR_ERR(p) without any explicit NULL checks against p in the same block. That's probably going to be interesting to code up in perl. -- 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: Updated status of the removal of plat headers
Hi Tony, On 10/16/2012 06:00 PM, Tony Lindgren wrote: Hi all, Here's a quick status update on the removal of remaining #include plat/*.h files. Most files are now fixed up, and we only have the following remaining: cpu.h wrapper only left, will be removed as soon as drivers are fixed dmtimer.h Jon is fixing this I have patches ready for this. However, as you know I have a few timer series cooking at the moment and just sent out the latest timer DT series today [1][2]. I have also updated my timer fixes series [3] too, however, I was not going to send out until the DT stuff is sorted. At the moment I have included the dmtimer header patches with the fixes series as there are some dependencies but this series has now grown into a 20+ patch series. So if it is easier to manage, I could split this into a fixes series and a clean-up series. Or if you only want the header stuff now, I could send this and send the fixes and clean-up later. Cheers Jon [1] http://marc.info/?l=linux-omapm=135049690119218w=2 [2] http://marc.info/?l=linux-omapm=135049882020029w=2 [3] http://marc.info/?l=linux-arm-kernelm=134687192121865w=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: Updated status of the removal of plat headers
* Jon Hunter jon-hun...@ti.com [121017 14:53]: Hi Tony, On 10/16/2012 06:00 PM, Tony Lindgren wrote: Hi all, Here's a quick status update on the removal of remaining #include plat/*.h files. Most files are now fixed up, and we only have the following remaining: cpu.h wrapper only left, will be removed as soon as drivers are fixed dmtimer.h Jon is fixing this I have patches ready for this. However, as you know I have a few timer series cooking at the moment and just sent out the latest timer DT series today [1][2]. I have also updated my timer fixes series [3] too, however, I was not going to send out until the DT stuff is sorted. At the moment I have included the dmtimer header patches with the fixes series as there are some dependencies but this series has now grown into a 20+ patch series. So if it is easier to manage, I could split this into a fixes series and a clean-up series. Or if you only want the header stuff now, I could send this and send the fixes and clean-up later. When they are ready, two separate pull requests against v3.7-rc1 for fixes and cleanup would be perfect. Thanks, Tony [1] http://marc.info/?l=linux-omapm=135049690119218w=2 [2] http://marc.info/?l=linux-omapm=135049882020029w=2 [3] http://marc.info/?l=linux-arm-kernelm=134687192121865w=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
[GIT PULL] omap fixes ready to go for v3.7-rc1
Hi Arnd Olof, Here are the fixes ready to pull, there's at least one more fix in works but it still requires minor changes. The two top commits are recent as Jon Hunter noticed an issue freeing resources in his fix and I did a new branch to swap in the fixed patch. Regards, Tony The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc1/fixes-take5-signed for you to fetch changes up to 8119024ef7363591fd958ec89ebfaee7c18209e3: ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory (2012-10-17 09:01:14 -0700) A boot problem fix for am33xx beaglebone caused by GPMC, a regression fix for local timer, and a clockdomain locking fix. Also few minor fixes for boot time and sparse warnings. Benoit Cousson (1): ARM: OMAP2+: clock data: Add dev-id for the omap-gpmc dummy fck Jon Hunter (1): ARM: OMAP2+: Allow kernel to boot even if GPMC fails to reserve memory Paul Walmsley (1): ARM: OMAP: resolve sparse warning concerning debug_card_init() Sebastien Guiriec (1): ARM: OMAP4: devices: fixup OMAP4 DMIC platform device error message Tero Kristo (1): ARM: OMAP: clockdomain: Fix locking on _clkdm_clk_hwmod_enable / disable Tony Lindgren (1): ARM: OMAP4: Fix twd_local_timer_register regression arch/arm/mach-omap2/clock44xx_data.c |2 +- arch/arm/mach-omap2/clockdomain.c| 15 +++ arch/arm/mach-omap2/devices.c|2 +- arch/arm/mach-omap2/gpmc.c | 24 +++- arch/arm/mach-omap2/timer.c |2 +- arch/arm/plat-omap/debug-devices.c |1 + 6 files changed, 34 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)
Felipe Balbi ba...@ti.com writes: On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote: On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote: + peterz, tglx Felipe Balbi ba...@ti.com writes: [...] The problem I see is that even though we properly return IRQ_WAKE_THREAD and wake_up_process() manages to wakeup the IRQ thread (it returns 1), the thread is never scheduled. To make things even worse, ouw irq thread runs once, but doesn't run on a consecutive call. Here's some (rather nasty) debug prints showing the problem: [...] [ 88.721923] try_to_wake_up 1411 [ 88.725189] === irq_wake_thread 139: IRQ 72 wake_up_process 0 [ 88.731292] [sched_delayed] sched: RT throttling activated This throttling message is the key one. With RT throttling activated, the IRQ thread will not be run (it eventually will be allowed much later on, but by then, the I2C xfers have timed out.) As a quick hack, the throttling can be disabled by seeting the sched_rt_runtime to RUNTIME_INF: # sysctl -w kernel.sched_rt_runtime_us=-1 and a quick test shows that things go back to working as expected. But we still need to figure out why the throttling is hapenning... So I started digging into why the RT runtime was so high, and noticed that time spent in suspend was being counted as RT runtime! So spending time in suspend anywhere near sched_rt_runtime (0.95s) will cause the RT throttling to always be triggered, and thus prevent IRQ threads from running in the resume path. Ouch. I think I'm already in over my head in the RT runtime stuff, but counting the time spent in suspend as RT runtime smells like a bug to me. no? Peter? Thomas? it looks like removing console output completely (echo 0 /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for a few more iterations to make sure what I'm saying is correct. Yeah, really looks like removing console output makes the problem go away. Ran a few iterations and it always worked fine. Full logs attached Removing console output during resume is going to significantly change the timing of what is happening during suspend/resume, so I suspect that combined with all your other debug prints is somehow masking the problem. How log are you letting the system stay in suspend? That being said, I can still easily reproduce the problem, even with console output disabled. With vanilla v3.7-rc1 + the debug patch below[1], with and without console output, I see RT throttling kicking in on resume, and the RT runtime on resume corresponds to the time spent in suspend. Here's an example of debug output of my patch below after ~3 sec in suspend: [ 43.198028] sched_rt_runtime_exceeded: rt_time 2671752930 runtime 95000 [ 43.198028] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c [ 43.198059] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c [ 43.203704] [sched_delayed] sched: RT throttling activated I see this rather consistently, and the rt_time value is always roughly the time I spent in suspend. So the primary question remains: is RT runtime supposed to include the time spent suspended? I suspect not. Kevin [1] diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 418feb0..39de750 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -891,6 +891,8 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq) if (!once) { once = true; printk_sched(sched: RT throttling activated\n); + pr_warn(%s: rt_time %llu runtime %llu\n, + __func__, rt_rq-rt_time, runtime); } } else { /* @@ -948,8 +950,11 @@ static void update_curr_rt(struct rq *rq) if (sched_rt_runtime(rt_rq) != RUNTIME_INF) { raw_spin_lock(rt_rq-rt_runtime_lock); rt_rq-rt_time += delta_exec; - if (sched_rt_runtime_exceeded(rt_rq)) + if (sched_rt_runtime_exceeded(rt_rq)) { + pr_warn(%s: RT runtime exceeded: %s\n, + __func__, curr-comm); resched_task(curr); + } raw_spin_unlock(rt_rq-rt_runtime_lock); } } -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
Hi Richard On Wed, 17 Oct 2012, Richard Cochran wrote: Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html This patch appears to add a new feature, correct? I don't think the CPSW could have worked in the past without this data present. So it looks to me like this is 3.8 material, unless Tony would like it to go in sooner? - Paul Thanks, Richard - Forwarded message from Richard Cochran richardcoch...@gmail.com - Date: Mon, 15 Oct 2012 21:16:32 +0200 From: Richard Cochran richardcoch...@gmail.com To: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org, Arnd Bergmann a...@arndb.de, David Miller da...@davemloft.net, Russell King li...@arm.linux.org.uk, Mugunthan V N mugunthan...@ti.com Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio X-Mailer: git-send-email 1.7.2.5 From: Mugunthan V N mugunthan...@ti.com This patch adds minimal hwmod support for davinci mdio driver. This patch requires rework on parent child relation between cpsw and davinci mdio hwmod data to support runtime PM. Signed-off-by: Mugunthan V N mugunthan...@ti.com --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 34 ++- 1 files changed, 32 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c index 59d5c1c..f96bbc0 100644 --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = { .rev_offs = 0x0, .sysc_offs = 0x8, .syss_offs = 0x4, - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE | -SYSS_HAS_RESET_STATUS), + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE), .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE | MSTANDBY_NO), .sysc_fields= omap_hwmod_sysc_type3, @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = { .modulemode = MODULEMODE_SWCTRL, }, }, + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY | +HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE), }; /* @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = { { } }; +/* mdio class */ +static struct omap_hwmod_class am33xx_mdio_hwmod_class = { + .name = davinci_mdio, +}; + +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = { + { + .pa_start = 0x4A101000, + .pa_end = 0x4A101000 + SZ_256 - 1, + .flags = ADDR_MAP_ON_INIT, + }, + { } +}; + +static struct omap_hwmod am33xx_mdio_hwmod = { + .name = davinci_mdio, + .class = am33xx_mdio_hwmod_class, + .clkdm_name = cpsw_125mhz_clkdm, + .main_clk = cpsw_125mhz_gclk, +}; + +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = { + .master = am33xx_cpgmac0_hwmod, + .slave = am33xx_mdio_hwmod, + .addr = am33xx_mdio_addr_space, + .user = OCP_USER_MPU, +}; + static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = { .master = am33xx_l4_ls_hwmod, .slave = am33xx_elm_hwmod, @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = { am33xx_l3_main__tptc2, am33xx_l3_s__usbss, am33xx_l4_hs__cpgmac0, + am33xx_cpgmac0__mdio, NULL, }; -- 1.7.2.5 - End forwarded message - - 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
* Paul Walmsley p...@pwsan.com [121017 16:39]: Hi Richard On Wed, 17 Oct 2012, Richard Cochran wrote: Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html This patch appears to add a new feature, correct? I don't think the CPSW could have worked in the past without this data present. So it looks to me like this is 3.8 material, unless Tony would like it to go in sooner? Yeah unless it fixes something, we should just queue it for v3.8 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
Re: [PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote: On probe this patch does pm_runtime_enable, however this doesn't mean the device is turned ON or resumed or kept ON all the time. In fact it's the other way around; pm_runtime_enable turns off the power (if it's ON). pm_runtime_enable just decrements the disable_depth counter. Doesn't turn off anything by itself. @@ -1009,7 +1001,8 @@ static int __devexit omap_iommu_remove(struct platform_device *pdev) release_mem_region(res-start, resource_size(res)); iounmap(obj-regbase); - clk_put(obj-clk); + pm_runtime_disable(obj-dev); This will turn on the device unnecessarily, wasting power, and there's no need for that, kfree will take care of that without resuming. Left aside the aesthetics of having balanced calls, the device will be enabled if there was a pending resume to be executed, otherwise it won't, kfree won't increment the disable_depth counter and I don't think that freeing the pointer is enough reason to ignore pm_runtime_disable. You are doing __pm_runtime_disable(dev, true), kfree will do __pm_runtime_disable(dev, false), which is what we want. Both will decrement the disable_depth. I'm quite confused here, could you please point me to the kfree snip that does __pm_runtime_disable(dev, false)? Sorry, not kfree, but the device removal process: device_del device_pm_remove pm_runtime_remove __pm_runtime_disable - HERE I'm not entirely convinced _iommu_ follows this path, it doesn't create any devices nor register them... whereas mailbox does create devices and mailbox does follow this path for the devices created which are child devices. So this path won't take care of the omap-iommu device pm_runtime_disable. But at least you agree that there's a chance that the device will be waken up. Of course, if there is a pending resume to be executed, it must honor that resume request and then turn off the device before removing the iommu, IMHO. Who will turn off the device afterwards? What I meant is that omap_iommu_detach should turn off the device before removing the iommu. Cheers, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
On 16 October 2012 12:22, Tony Lindgren t...@atomide.com wrote: * Omar Ramirez Luna omar.l...@linaro.org [121011 18:07]: These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. For this series I just dropped the patches already included in mainline. These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu when I have that pushed out as that removes plat/*iommu*.h files. Ok, will wait and rebase on top of it. Thanks, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes ready to go for v3.7-rc1
On Wed, Oct 17, 2012 at 3:02 PM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here are the fixes ready to pull, there's at least one more fix in works but it still requires minor changes. The two top commits are recent as Jon Hunter noticed an issue freeing resources in his fix and I did a new branch to swap in the fixed patch. Regards, Tony The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc1/fixes-take5-signed Pulled into fixes, thanks. -Olof -- 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 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer (fwd)
Hi Wim, When you have the opportunity, could you take a look at this patch, and the subsequent patch 6/7, and ack them if you're okay with them? We'd like to merge thse as part of a larger cleanup series through the arm-soc tree. They like cleanup patches to arrive at the beginning of the -rc series, which means that we need to have the pull request sent pretty soon. thanks, - Paul -- Forwarded message -- Date: Mon, 15 Oct 2012 19:32:33 -0600 From: Paul Walmsley p...@pwsan.com To: linux-omap@vger.kernel.org, linux-arm-ker...@lists.infradead.org Cc: Wim Van Sebroeck w...@iguana.be, linux-watch...@vger.kernel.org Subject: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer The OMAP watchdog timer driver directly calls a function exported by code in arch/arm/mach-omap2. This is not good; it tightly couples this driver to the mach-omap2 integration code. Instead, add a temporary platform_data function pointer to abstract this function call. A subsequent patch will convert the watchdog driver to use this function pointer. This patch also moves the device creation code out of arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c. This is another step towards the removal of arch/arm/mach-omap2/devices.c. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Wim Van Sebroeck w...@iguana.be --- arch/arm/mach-omap1/devices.c | 21 +-- arch/arm/mach-omap2/devices.c | 26 -- arch/arm/mach-omap2/wd_timer.c | 33 +++ include/linux/platform_data/omap-wd-timer.h | 38 +++ 4 files changed, 89 insertions(+), 29 deletions(-) create mode 100644 include/linux/platform_data/omap-wd-timer.h diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c index d3fec92..c3408e7 100644 --- a/arch/arm/mach-omap1/devices.c +++ b/arch/arm/mach-omap1/devices.c @@ -17,6 +17,8 @@ #include linux/platform_device.h #include linux/spi/spi.h +#include linux/platform_data/omap-wd-timer.h + #include asm/mach/map.h #include plat/tc.h @@ -439,18 +441,31 @@ static struct resource wdt_resources[] = { }; static struct platform_device omap_wdt_device = { - .name = omap_wdt, - .id = -1, + .name = omap_wdt, + .id = -1, .num_resources = ARRAY_SIZE(wdt_resources), .resource = wdt_resources, }; static int __init omap_init_wdt(void) { + struct omap_wd_timer_platform_data pdata; + int ret; + if (!cpu_is_omap16xx()) return -ENODEV; - return platform_device_register(omap_wdt_device); + pdata.read_reset_sources = omap1_read_reset_sources; + + ret = platform_device_register(omap_wdt_device); + if (!ret) { + ret = platform_device_add_data(omap_wdt_device, pdata, + sizeof(pdata)); + if (ret) + platform_device_del(omap_wdt_device); + } + + return ret; } subsys_initcall(omap_init_wdt); #endif diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index c8c2117..2ab2c99 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -644,29 +644,3 @@ static int __init omap2_init_devices(void) return 0; } arch_initcall(omap2_init_devices); - -#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE) -static int __init omap_init_wdt(void) -{ - int id = -1; - struct platform_device *pdev; - struct omap_hwmod *oh; - char *oh_name = wd_timer2; - char *dev_name = omap_wdt; - - if (!cpu_class_is_omap2() || of_have_populated_dt()) - return 0; - - oh = omap_hwmod_lookup(oh_name); - if (!oh) { - pr_err(Could not look up wd_timer%d hwmod\n, id); - return -EINVAL; - } - - pdev = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0); - WARN(IS_ERR(pdev), Can't build omap_device for %s:%s.\n, - dev_name, oh-name); - return 0; -} -subsys_initcall(omap_init_wdt); -#endif diff --git a/arch/arm/mach-omap2/wd_timer.c b/arch/arm/mach-omap2/wd_timer.c index b2f1c67..00ef54c 100644 --- a/arch/arm/mach-omap2/wd_timer.c +++ b/arch/arm/mach-omap2/wd_timer.c @@ -11,10 +11,14 @@ #include linux/io.h #include linux/err.h +#include linux/platform_data/omap-wd-timer.h + #include plat/omap_hwmod.h +#include plat/omap_device.h #include wd_timer.h #include common.h +#include prm.h /* * In order to avoid any assumptions from bootloader regarding WDT @@ -99,3 +103,32 @@ int omap2_wd_timer_reset(struct omap_hwmod *oh) return (c == MAX_MODULE_SOFTRESET_WAIT) ? -ETIMEDOUT : omap2_wd_timer_disable(oh); } + +static int __init omap_init_wdt(void) +{ + int id = -1; +
Re: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
On Wed, Oct 17, 2012 at 04:50:46PM -0700, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [121017 16:39]: Hi Richard On Wed, 17 Oct 2012, Richard Cochran wrote: Would you please take this bugfix for 3.7-rc2? The suggestion to mail you came from Toni Lindgren. The context where it came from is here: http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html This patch appears to add a new feature, correct? I don't think the CPSW could have worked in the past without this data present. So it looks to me like this is 3.8 material, unless Tony would like it to go in sooner? Yeah unless it fixes something, we should just queue it for v3.8 merge window. So there has been this cpsw driver since v3.4-rc1~177^2~5 df82859 netdev: driver: ethernet: Add TI CPSW driver and four people signed off on it, so it must have been working at one point. Since the device tree make-over, the driver is a derelict, and thus the present patch is fixing a regression. I just want the already merged driver to work with the vanilla kernel. Is that too much to ask? Thanks, Richard -- 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
On Thu, 18 Oct 2012, Richard Cochran wrote: So there has been this cpsw driver since v3.4-rc1~177^2~5 df82859 netdev: driver: ethernet: Add TI CPSW driver and four people signed off on it, so it must have been working at one point. The signoffs just mean that those people are asserting that the code is covered under an appropriate license, or are passing it on through the maintainer hierarchy. See http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches;h=c379a2a6949f1c1cac04fb6f185c633512f37061;hb=HEAD#l298 It doesn't necessarily mean that the driver is usable in that kernel release. Since the device tree make-over, the driver is a derelict, and thus the present patch is fixing a regression. Probably the driver was submitted before any SoC integration support was available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x didn't have device enumeration support in the mainline kernel until 3.7, via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 (ARM: OMAP3+: hwmod: Add AM33XX HWMOD data). So I don't see how it could have worked with mainline. I just want the already merged driver to work with the vanilla kernel. Is that too much to ask? It's a very reasonable wish and your patches are certainly appreciated. But it seems that the CPSW has never worked in the mainline kernel. So this particular patch is not fixing a regression. Therefore we shouldn't send it upstream during the -rc time period. Instead we'll schedule it to be sent a few weeks later, during the 3.8 merge window. Either way, the patch is likely to make it into the mainline kernel. It's just that it will probably take a few weeks longer than you might like. - 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 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
On Thu, Oct 18, 2012 at 1:51 AM, Omar Ramirez Luna omar.l...@linaro.org wrote: On 15 October 2012 22:23, Felipe Contreras felipe.contre...@gmail.com wrote: On probe this patch does pm_runtime_enable, however this doesn't mean the device is turned ON or resumed or kept ON all the time. In fact it's the other way around; pm_runtime_enable turns off the power (if it's ON). pm_runtime_enable just decrements the disable_depth counter. Doesn't turn off anything by itself. pm_runtime_enable turns on power management, without it the device remains in whatever state it booted. device_del device_pm_remove pm_runtime_remove __pm_runtime_disable - HERE I'm not entirely convinced _iommu_ follows this path, it doesn't create any devices nor register them... whereas mailbox does create devices and mailbox does follow this path for the devices created which are child devices. So this path won't take care of the omap-iommu device pm_runtime_disable. Are you sure? What code-path calls omap_iommu_remove then? Anyway, it was just an observation. I've seen other code do this. -- 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
OMAP baseline test results for v3.7-rc1
Here are some basic OMAP test results for Linux v3.7-rc1. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ Changes from previous tests --- Kernel configs have been reorganized and updated. AM335x Beaglebone and OMAP4460 Pandaboard-ES boards have been added to the testbed. Passing tests - Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html Other: * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control - http://lkml.org/lkml/2012/9/3/265 Failing tests: needing investigation Boot tests: * 2420n800: boot hangs during UART initialization - http://lkml.org/lkml/2012/9/11/454 - Various attempts at fixes posted; etiology known; issue still unresolved * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs with NFS root - Likely some Kconfig, board file, and PM issues with EMAC * CM-T3517: boot hangs with MMC boot - Due to missing MMC setup in board file PM tests: * 3530es3beagle, 37xxevm, 3730beaglexm: I2C fails during resume from suspend - Causes MMC to become unusable since regulators are not reenabled - Can be worked around by reverting the I2C driver conversion to threaded IRQs: - http://marc.info/?l=linux-i2cm=135026587102887w=2 - Appears to be due to an accounting problem; under discussion: - http://marc.info/?l=linux-arm-kernelm=135042360725821w=2 * 3530es3beagle: hangs during off-mode dynamic idle test - Unknown cause; not investigated * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown Kernel size/memory differences -- vmlinux object size (delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)): text data bsstotal kernel +118682 -66688+2280 +54274 am33xx_only +57789 -88928+2148 -28991 n800_multi_omap2xxx +58669 -86432+2180 -25583 n800_only_a +54196+4616 -136 +58676 omap1_defconfig +53420+3096 -104 +56412 omap1_defconfig_1510innovator_only +54384+3112 -168 +57328 omap1_defconfig_5912osk_only +128332 -67728+2144 +62748 omap2plus_defconfig +106894 -83664+1992 +25222 omap2plus_defconfig_2430sdp_only +128296 -67744+2080 +62632 omap2plus_defconfig_cpupm +130151 -67552+1824 +64423 omap2plus_defconfig_no_pm +107810 -88848+1952 +20914 omap2plus_defconfig_omap2_4_only +107293 -88232+2016 +21077 omap2plus_defconfig_omap3_4_only +113921 -66976+2348 +49293 rmk_omap3430_ldp_oldconfig +106849 -47216+2760 +62393 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.6 (a0d271cbfed1dd50278c6b06bead3d00ba0a88f9)) avail rsrvd high freed board kconfig 20k -20k . -152k 2420n800 omap2plus_defconfig -60k60k . 4k 2430sdpomap2plus_defconfig -60k60k . 4k 3517evmomap2plus_defconfig -60k60k . 4k 3530es3beagle omap2plus_defconfig -60k60k . 4k 3730beaglexm omap2plus_defconfig -60k60k . 4k 37xxevmomap2plus_defconfig -60k60k . 4k 4430es2panda omap2plus_defconfig -52k52k . . 5912oskomap2plus_defconfig -60k60k . . cmt3517omap2plus_defconfig - 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 0/4] OMAP-GPMC generic timing migration
Hi Daniel, On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote: On 17.10.2012 07:42, Afzal Mohammed wrote: I doubt whether auxdata would help here, it seems using compatible field alone would help in deciding relevant custom timing routine. Whether we want this kind of peripheral knowledge in gpmc driver instead of using generic timing routine has to be decided though. Another thing that might be worth thinking about is that apart from the GPMC host controller and the peripherals, there could be other components like level shifters or series resistors on the board that limit the maximum speed of transactions. So in fact we might be better off storing all that timing details in the DT, as they are in fact highly application specific. Yes, making it future proof for these kind of scenarios was one of the reason's that initially triggered generic timing path. Regards Afzal -- 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: discrepancy while save and restore of debounce registers
Jon, On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote: Hi Gururaja, On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote: Hi, I came across a peculiar issue while updating GPIO debounce registers on OMAP platform. According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537 gpio/omap: save and restore debounce registers GPIO debounce registers need to be saved and restored for proper functioning of driver. ... @@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank *bank) __raw_writel(bank-context.fallingdetect, bank-base + bank-regs-fallingdetect); __raw_writel(bank-context.dataout, bank-base + bank-regs-dataout); + if (bank-dbck_enable_mask) { + __raw_writel(bank-context.debounce, bank-base + + bank-regs-debounce); + __raw_writel(bank-context.debounce_en, + bank-base + bank-regs-debounce_en); + } } Due to copy/paste of this commit into my local tree, I missed the check for bank-dbck_enable_mask, and directly restored the saved value from context. After this, I saw random crashes when accessing different registers (sometimes its OE register and sometime its DATAOUT register). These crashes were seen across 2nd and subsequent suspend/resume. My doubt/questions are 1. Why should debounce registers be updated only when it's accessed previously? If debounce is not being used by any of the gpios, then there is no need to restore them as there are no bits set. So this makes sense and saves a couple register writes. What I want to know is that other than saving register writes, is there any other important stuff that specifies this requirement. 2. What is the relation between updating debounce registers and crash seen on others registers? This I am not sure about. I gave this a quick try on my omap3430 beagle board, but I did not see any side-effects from doing this. However, if you are always restoring the debounce context regardless of whether debounce is being used, then you could be writing bad values to the debounce registers as the context variables bank-context.debouce and bank-context.debouce_en may not initialised. So that is bad. However, that said I am still not sure how this could cause a crash. Can you share more details on ... Sorry for missing below details in first post. 1. The OMAP platform you are using? I was trying this on TI AM335x platform (repo below). On AM335x EVM board http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog; h=refs/heads/v3.2-staging 2. What linux distro/environment you are using? Arago AM335x PSP release (linux 3.2 + am335x patch-set) 3. If there are any specific steps to reproduce this 100% of the time? On top of this tree, try suspend/resume using echo mem /syspower/state Cheers Jon Regards, Gururaja -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: AM33XX: Add tsl2550 ambient light sensor DT data
On Fri, Sep 21, 2012 at 21:19:11, AnilKumar, Chimata wrote: Add tsl2550 ambient light sensor DT data to am335x-evm.dts. In AM335x EVM tsl2550 ambient light sensor is connected to I2C2 bus. So this patch adds child node inside i2c2 node with i2c slave address. TAOS tsl2550 sensor with two-wire SMBus serial interface. This patch also reduces I2C2 clock frequency to 100KHz from 400KHz because the maximum clock frequency of SMBus is 100KHz. Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/boot/dts/am335x-evm.dts |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts index 3b1f313..d99aa0f 100644 --- a/arch/arm/boot/dts/am335x-evm.dts +++ b/arch/arm/boot/dts/am335x-evm.dts @@ -49,7 +49,7 @@ i2c2: i2c@4802a000 { status = okay; - clock-frequency = 40; + clock-frequency = 10; lis331dlh: lis331dlh@18 { compatible = st,lis331dlh, st,lis3lv02d; @@ -79,6 +79,11 @@ st,max-limit-z = 750; }; + tsl2550: tsl2550@39 { + compatible = taos,tsl2550; + reg = 0x39; + }; + tmp275: tmp275@48 { compatible = ti,tmp275; reg = 0x48; Hi Tony/Benoit, If there are no comments in this patch could you please take this in? Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Only write the sysconfig on idle when necessary
On Thursday 18 October 2012 02:07 AM, Jon Hunter wrote: Ok, thanks. Yes, only updating the register when the cache value changed would not work due to the possibility of context being lost. So Rajendra's change makes sense. However, I think there is room to optimise this. With this change, on idle, the cache value and register value are only updated when needed. This should be safe. Are you looking to go one step further and only update the sysconfig on enabling when the context has been lost? That would require more changes. This was a quick optimisation I saw when reviewing the code. Rajendra, let me know if you have any comments. Makes sense to me. To handle the more generic case of avoiding all reads and writes whenever possible, and making the cache really behave like a cache, as Paul suggested, is certainly more work and more importantly more testing, as it would rely heavily on the context lost counters to work correctly. I feel there is still some work needed around those counters to make them more robust before we start heading in that direction. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h
Hi, On Wed, Oct 17, 2012 at 01:34:04PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121017 08:54]: In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Thanks, looks like I can't make this apply against v3.7-rc1: patching file arch/arm/plat-omap/include/plat/usb.h Hunk #1 FAILED at 1. Hunk #2 FAILED at 26. Hunk #3 FAILED at 44. Hunk #4 FAILED at 65. Hunk #5 FAILED at 81. Hunk #6 succeeded at 28 with fuzz 2 (offset -128 lines). 5 out of 6 hunks FAILED -- rejects in file arch/arm/plat-omap/include/plat/usb.h Can you please check it? Are you sure you have a clean v3.7-rc1 ? commit 9b1ebba0f43e7bf6a8fdd8aa84da65e5e0344fb7 Author: Felipe Balbi ba...@ti.com Date: Fri Sep 28 09:51:01 2012 +0300 arm: omap: move OMAP USB platform data to linux/platform_data/omap-usb.h In order to make single zImage work for ARM architecture, we need to make sure we don't depend on private headers. Move USB platform_data to linux/platform_data/omap-usb.h and keep only internal functions in plat/usb.h. Signed-off-by: Felipe Balbi ba...@ti.com commit ddffeb8c4d0331609ef2581d84de4d763607bd37 Author: Linus Torvalds torva...@linux-foundation.org Date: Sun Oct 14 14:41:04 2012 -0700 Linux 3.7-rc1 That's my branch. Patch is right on top of v3.7-rc1 commit. -- balbi signature.asc Description: Digital signature
Re: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)
On Wed, Oct 17, 2012 at 04:06:54PM -0700, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: On Wed, Oct 17, 2012 at 05:00:02PM +0300, Felipe Balbi wrote: On Tue, Oct 16, 2012 at 02:39:50PM -0700, Kevin Hilman wrote: + peterz, tglx Felipe Balbi ba...@ti.com writes: [...] The problem I see is that even though we properly return IRQ_WAKE_THREAD and wake_up_process() manages to wakeup the IRQ thread (it returns 1), the thread is never scheduled. To make things even worse, ouw irq thread runs once, but doesn't run on a consecutive call. Here's some (rather nasty) debug prints showing the problem: [...] [ 88.721923] try_to_wake_up 1411 [ 88.725189] === irq_wake_thread 139: IRQ 72 wake_up_process 0 [ 88.731292] [sched_delayed] sched: RT throttling activated This throttling message is the key one. With RT throttling activated, the IRQ thread will not be run (it eventually will be allowed much later on, but by then, the I2C xfers have timed out.) As a quick hack, the throttling can be disabled by seeting the sched_rt_runtime to RUNTIME_INF: # sysctl -w kernel.sched_rt_runtime_us=-1 and a quick test shows that things go back to working as expected. But we still need to figure out why the throttling is hapenning... So I started digging into why the RT runtime was so high, and noticed that time spent in suspend was being counted as RT runtime! So spending time in suspend anywhere near sched_rt_runtime (0.95s) will cause the RT throttling to always be triggered, and thus prevent IRQ threads from running in the resume path. Ouch. I think I'm already in over my head in the RT runtime stuff, but counting the time spent in suspend as RT runtime smells like a bug to me. no? Peter? Thomas? it looks like removing console output completely (echo 0 /proc/sysrq-trigger) I don't see the issue anymore. Let me just run for a few more iterations to make sure what I'm saying is correct. Yeah, really looks like removing console output makes the problem go away. Ran a few iterations and it always worked fine. Full logs attached Removing console output during resume is going to significantly change the timing of what is happening during suspend/resume, so I suspect that combined with all your other debug prints is somehow masking the problem. How log are you letting the system stay in suspend? about 2 minutes That being said, I can still easily reproduce the problem, even with console output disabled. With vanilla v3.7-rc1 + the debug patch below[1], with and without console output, I see RT throttling kicking in on resume, and the RT runtime on resume corresponds to the time spent in suspend. Here's an example of debug output of my patch below after ~3 sec in suspend: [ 43.198028] sched_rt_runtime_exceeded: rt_time 2671752930 runtime 95000 [ 43.198028] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c [ 43.198059] update_curr_rt: RT runtime exceeded: irq/72-omap_i2c [ 43.203704] [sched_delayed] sched: RT throttling activated I see this rather consistently, and the rt_time value is always roughly the time I spent in suspend. So the primary question remains: is RT runtime supposed to include the time spent suspended? I suspect not. you might be right there, though we need Thomas or Peter to answer :-s -- balbi signature.asc Description: Digital signature