Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [110920 14:12]: On Tuesday 20 September 2011, Arnd Bergmann wrote: One more thing: my randconfig tests are running now and have spit out a new error after merging lost of stuff today: Good to hear you got arndconfig running :) Do you think we could also add support for something like this: $ echo CONFIG_ARCH_OMAP=y .config $ make randconfig or $ make --force=CONFIG_ARCH_OMAP randconfig Where randconfig would keep the forced CONFIG_ARCH_OMAP static while randomly selecting the others? This would allow targeted randconfig for each patch more or less.. The mechanism I use is setting KCONFIG_ALLCONFIG= to a file that has the options I want to have set to a specific value. If you don't do that, randconfig will take the default option for each 'choice' statement, which means we build for the ARCH_VERSATILE platform. See the script I'm using at the end of this mail. It should be easy for you to pick out the parts you need. It seems that you replace the #ifdef in the board-flash.c file with a similar #ifdef in the header that replaces this with an empty inline function when the object is not built. Oops. I'll do a fix for that. Those should be now inline functions in the header. As various other omap branches are based on the cleanup I'd rather not go mess with the original patch unless you insist. Totally fine with me. This is just a corner case anyway, since most configurations will have flash enabled I guess. Arnd 8--- #!/bin/bash export ARCH=arm export PATH=/usr/bin:/bin export CROSS_COMPILE=arm-linux-gnueabihf- export PARALLEL=-j6 export CCACHE_DISABLE=1 export O=$PWD/obj-tmp gen_allconfig() { declare -a MACH MACH[1]=OMAP MACH[2]=EXYNOS4 MACH[3]=U8500 MACH[4]=VEXPRESS MACH[5]=MXC MACH[6]=MSM MACH[7]=PXA MACH[8]=MMP MACH[9]=DOVE MACH[10]=KIRKWOOD MACH[11]=ZYNQ MACH[12]=PRIMA2 MACH[13]=TEGRA MACH[14]=SHMOBILE declare -a MXC MXC[1]=MX3 MXC[2]=MX503 MXC[3]=MX51 declare -a AT91 AT91[1]=ARCH_AT91RM9200 AT91[2]=ARCH_AT91SAM9260 AT91[3]=ARCH_AT91SAM9261 AT91[4]=ARCH_AT91SAM9G10 AT91[5]=ARCH_AT91SAM9263 AT91[6]=ARCH_AT91SAM9RL AT91[7]=ARCH_AT91SAM9G20 AT91[8]=ARCH_AT91SAM9G45 AT91[9]=ARCH_AT91CAP9 AT91[10]=ARCH_AT91X40 # pick one ARCH_* option from the main choice statement echo CONFIG_ARCH_${MACH[$[ $RANDOM % ${#MACH[@]} +1 ]]}=y # IMX and AT91 have another choice statement echo CONFIG_ARCH_${MXC[$[ $RANDOM % ${#MXC[@]} +1 ]]}=y echo CONFIG_${MXC[$[ $RANDOM % ${#AT91[@]} +1 ]]}=y # These have to be fixed in order to avoid huge build breakage. echo # CONFIG_XIP_KERNEL is not set echo # CONFIG_STAGING is not set echo CONFIG_MMU=y echo CONFIG_PREVENT_FIRMWARE_BUILD=y # add a few choice options that don't normally get selected [ $[RANDOM % 2 ] == 1 ] || echo CONFIG_PROFILE_ALL_BRANCHES=y [ $[RANDOM % 2 ] == 1 ] || echo CONFIG_SLAB=y [ $[RANDOM % 2 ] == 1 ] || echo CONFIG_PREEMPT=y } prepare() { mkdir -p ${O} make O=${O} clean gen_allconfig ${O}/allconfig make O=${O} KCONFIG_ALLCONFIG=${O}/allconfig randconfig } mkdir -p out prepare for i in `seq -w ` ; do if ! make O=${O} -k -s ${PARALLEL} CFLAGS_KERNEL+=-Wno-uninitialized KALLSYMS_EXTRA_PASS=1 2 out/warnings-$i ; then make O=${O} -k -s CFLAGS_KERNEL+=-Wno-uninitialized KALLSYMS_EXTRA_PASS=1 2 out/errors-$i cp ${O}/.config out/config-broken-$i else cp ${O}/.config out/config-ok-$i fi prepare done -- 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
omap3: I2C: failure in wakeup from S2R
Hi, Looks like beagle xM can't wakeup from S2R, and the kernel is 3.1-rc4. See dmesg below: root@beagleboard:~# root@beagleboard:~# echo 9 /proc/sys/kernel/printk root@beagleboard:~# echo platform /sys/power/pm_test root@beagleboard:~# echo mem /sys/power/state [ 69.132354] PM: Syncing filesystems ... done. [ 78.607269] PM: Preparing system for mem sleep [ 78.631347] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 78.664215] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 78.695129] PM: Entering mem sleep [ 78.712402] usb 1-2.1: usb suspend [ 78.739471] hub 1-2:1.0: hub_suspend [ 78.743652] usb 1-2: unlink qh256-0001/def54320 start 1 [1/0 us] [ 78.751007] usb 1-2: usb suspend [ 78.778625] hub 1-0:1.0: hub_suspend [ 78.782440] usb usb1: bus suspend [ 78.786163] ehci-omap ehci-omap.0: suspend root hub [ 78.916076] PM: suspend of devices complete after 206.665 msecs [ 78.928649] omap_device: omap_hsmmc.0: new worst case deactivate latency 0: 152587 [ 78.937438] omap_device: usbhs_omap.-1: new worst case deactivate latency 0: 152587 [ 78.946044] PM: late suspend of devices complete after 23.620 msecs [ 78.952728] suspend debug: Waiting for 5 seconds. [ 83.395080] PM: early resume of devices complete after 3.936 msecs [ 83.405548] [ cut here ] [ 83.410430] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0x114/0x15c() [ 83.419281] In-band Error seen by MPU at address 0 [ 83.424377] Modules linked in: [ 83.427612] [c001ada8] (unwind_backtrace+0x0/0x124) from [c004f1ac] (warn_slowpath_common+0x54/0x6c) [ 83.437591] [c004f1ac] (warn_slowpath_common+0x54/0x6c) from [c004f25c] (warn_slowpath_fmt+0x34/0x44) [ 83.447631] [c004f25c] (warn_slowpath_fmt+0x34/0x44) from [c0032298] (omap3_l3_app_irq+0x114/0x15c) [ 83.457489] [c0032298] (omap3_l3_app_irq+0x114/0x15c) from [c0097c4c] (handle_irq_event_percpu+0xb8/0x280) [ 83.467987] [c0097c4c] (handle_irq_event_percpu+0xb8/0x280) from [c0097e58] (handle_irq_event+0x44/0x64) [ 83.478271] [c0097e58] (handle_irq_event+0x44/0x64) from [c009a2bc] (handle_level_irq+0xe0/0x114) [ 83.487945] [c009a2bc] (handle_level_irq+0xe0/0x114) from [c0097678] (generic_handle_irq+0x28/0x38) [ 83.497833] [c0097678] (generic_handle_irq+0x28/0x38) from [c0014098] (handle_IRQ+0x80/0xc0) [ 83.507049] [c0014098] (handle_IRQ+0x80/0xc0) from [c04072fc] (__irq_svc+0x3c/0x11c) [ 83.515563] [c04072fc] (__irq_svc+0x3c/0x11c) from [c0319a80] (omap_i2c_unidle+0x1e8/0x2ac) [ 83.524688] [c0319a80] (omap_i2c_unidle+0x1e8/0x2ac) from [c031a144] (omap_i2c_xfer+0x2c/0x36c) [ 83.534179] [c031a144] (omap_i2c_xfer+0x2c/0x36c) from [c0317cc4] (i2c_transfer+0xc0/0x150) [ 83.543304] [c0317cc4] (i2c_transfer+0xc0/0x150) from [c02b2014] (twl_i2c_write+0xcc/0x114) [ 83.552429] [c02b2014] (twl_i2c_write+0xcc/0x114) from [c02b255c] (twl4030_sih_do_mask+0x6c/0x9c) [ 83.562103] [c02b255c] (twl4030_sih_do_mask+0x6c/0x9c) from [c0069b7c] (process_one_work+0x2dc/0x500) [ 83.572174] [c0069b7c] (process_one_work+0x2dc/0x500) from [c006a2a8] (worker_thread+0x1c0/0x2d8) [ 83.581848] [c006a2a8] (worker_thread+0x1c0/0x2d8) from [c006e0b0] (kthread+0x8c/0x94) [ 83.590515] [c006e0b0] (kthread+0x8c/0x94) from [c00142c0] (kernel_thread_exit+0x0/0x8) [ 83.599243] ---[ end trace 1b75b31a2719ed1e ]--- [ 83.617126] [ cut here ] [ 83.622009] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0x114/0x15c() [ 83.630859] In-band Error seen by MPU at address 0 [ 83.635955] Modules linked in: [ 83.639190] [c001ada8] (unwind_backtrace+0x0/0x124) from [c004f1ac] (warn_slowpath_common+0x54/0x6c) [ 83.649169] [c004f1ac] (warn_slowpath_common+0x54/0x6c) from [c004f25c] (warn_slowpath_fmt+0x34/0x44) [ 83.659210] [c004f25c] (warn_slowpath_fmt+0x34/0x44) from [c0032298] (omap3_l3_app_irq+0x114/0x15c) [ 83.669067] [c0032298] (omap3_l3_app_irq+0x114/0x15c) from [c0097c4c] (handle_irq_event_percpu+0xb8/0x280) [ 83.679595] [c0097c4c] (handle_irq_event_percpu+0xb8/0x280) from [c0097e58] (handle_irq_event+0x44/0x64) [ 83.689910] [c0097e58] (handle_irq_event+0x44/0x64) from [c009a2bc] (handle_level_irq+0xe0/0x114) [ 83.699584] [c009a2bc] (handle_level_irq+0xe0/0x114) from [c0097678] (generic_handle_irq+0x28/0x38) [ 83.709442] [c0097678] (generic_handle_irq+0x28/0x38) from [c0014098] (handle_IRQ+0x80/0xc0) [ 83.718688] [c0014098] (handle_IRQ+0x80/0xc0) from [c04072fc] (__irq_svc+0x3c/0x11c) [ 83.727203] [c04072fc] (__irq_svc+0x3c/0x11c) from [c0319ac8] (omap_i2c_unidle+0x230/0x2ac) [ 83.736328] [c0319ac8] (omap_i2c_unidle+0x230/0x2ac) from [c031a144] (omap_i2c_xfer+0x2c/0x36c) [ 83.745819] [c031a144] (omap_i2c_xfer+0x2c/0x36c) from [c0317cc4] (i2c_transfer+0xc0/0x150) [ 83.754943] [c0317cc4] (i2c_transfer+0xc0/0x150) from [c02b2014] (twl_i2c_write+0xcc/0x114) [ 83.764068] [c02b2014] (twl_i2c_write+0xcc/0x114) from
Re: [PATCHv8 01/16] power: add omap prm driver skeleton
Hi a few comments. First, as Govindraj mentioned, this should be cc'ed to linux-arm-ker...@lists.infradead.org. It's surprising that the linux-arm mailing list is still running... On Fri, 16 Sep 2011, Tero Kristo wrote: This driver will eventually support OMAP soc PRM module features, e.g. PRCM chain interrupts. This driver should be a separate series and should be posted to linux-ker...@vger.kernel.org also, since it will presumably need to be acked or merged by someone else who is responsible for the appropriate drivers directory. Since it should probably go into drivers/mfd (see below), it should also be sent to the MFD tree maintainer, Samuel Ortiz sa...@linux.intel.com. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com --- drivers/power/Kconfig|7 drivers/power/Makefile |1 + drivers/power/omap_prm.c | 83 ++ A couple of comments here: This driver is eventually going to need to create the VC and VP subdevices, so it makes sense to me to place the main portion of the driver into drivers/mfd, rather than drivers/power, to avoid churn. Also, the driver should probably be renamed to something like 'omap2430_prm.c' or something like that. It looks to me like there are at least three different hardware PRM IP block designs: - OMAP2420 (integrated into the PRCM) - OMAP2430/3430/3630/3517 (standalone PRM) - OMAP4430/4460, possibly also the 816x (standalone PRM with very different register layout) The idea being that the hwmods for these would all have different names and would therefore be associated with different drivers/mfd drivers. Looking at your patch 6/16, it looks like there's some code that can be shared between OMAP3/4 for interrupt handling, so maybe that can go into a shared file, like omap_prm_common.c. The omap2430_prm.c or omap4430_prm.c files could pass the number of registers and IRQ register offset arrays to the common code in platform_data. drivers/mfd/wm8350-{core,irq}.c is what I'm looking at here as a reasonable approach to compare to; see wm8350_irq_init(). 3 files changed, 91 insertions(+), 0 deletions(-) create mode 100644 drivers/power/omap_prm.c diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 57de051..e735a95 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -249,4 +249,11 @@ config CHARGER_MAX8998 Say Y to enable support for the battery charger control sysfs and platform data of MAX8998/LP3974 PMICs. +config OMAP_PRM + bool OMAP Power and Reset Management driver + depends on (ARCH_OMAP) PM + help + Say Y to enable support for the OMAP Power and Reset Management + driver. + endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index b4af13d..8df93c2 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -13,6 +13,7 @@ obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o obj-$(CONFIG_WM831X_POWER) += wm831x_power.o obj-$(CONFIG_WM8350_POWER) += wm8350_power.o obj-$(CONFIG_TEST_POWER) += test_power.o +obj-$(CONFIG_OMAP_PRM) += omap_prm.o obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o obj-$(CONFIG_BATTERY_DS2780) += ds2780_battery.o diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c new file mode 100644 index 000..dfc0920 --- /dev/null +++ b/drivers/power/omap_prm.c @@ -0,0 +1,83 @@ +/* + * OMAP Power and Reset Management (PRM) driver + * + * Copyright (C) 2011 Texas Instruments, Inc. + * + * Author: Tero Kristo t-kri...@ti.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include linux/kernel.h +#include linux/ctype.h +#include linux/module.h +#include linux/io.h +#include linux/slab.h +#include linux/init.h +#include linux/err.h +#include linux/platform_device.h + +#define DRIVER_NAME omap-prm + +struct omap_prm_device { + struct platform_device pdev; +}; Hmm. This doesn't look right. The platform_device should be created as part of an omap_device_build() call in code that resides in arch/arm/mach-omap2/ - see for example arch/arm/mach-omap2/hwspinlock.c + +static struct omap_prm_device prm_dev = { + .pdev = { + .name = DRIVER_NAME, + .id = -1, + }, +}; + +static int __init omap_prm_probe(struct platform_device *pdev) +{ + return 0; +} + +static int __devexit omap_prm_remove(struct platform_device *pdev) +{ + return 0; +} + +static struct platform_driver prm_driver = { + .remove = __exit_p(omap_prm_remove), This should define a probe function that the LDM core
RE: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation
-Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:30 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap prevent requesting a larger size buffer than what is allocated at kernel boot during omap_vout_probe. The requested size is compared with vout-buffer_size, this isn't correct as vout-buffer_size is later set to the size requested in reqbuf. When the video device is opened the next time, this check will prevent us to allocate a buffer which is larger than what we requested the last time. Don't use vout-buffer_size, always check with the parameters video1_bufsize or video2_bufsize. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/video/omap/omap_vout.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 95daf98..e14c82b 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, u32 phy_addr = 0, virt_addr = 0; struct omap_vout_device *vout = q-priv_data; struct omapvideo_info *ovid = vout-vid_info; + int vid_max_buf_size; if (!vout) return -EINVAL; + vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type) return -EINVAL; @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, video1_numbuffers : video2_numbuffers; /* Check the size of the buffer */ - if (*size vout-buffer_size) { + if (*size vid_max_buf_size) { Good catch !!! v4l2_err(vout-vid_dev-v4l2_dev, buffer allocation mismatch [%u] [%u]\n, *size, vout-buffer_size); @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) unsigned long size = (vma-vm_end - vma-vm_start); struct omap_vout_device *vout = file-private_data; struct videobuf_queue *q = vout-vbq; + int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; v4l2_dbg(1, debug, vout-vid_dev-v4l2_dev, %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__, @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) return -EINVAL; } /* Check the size of the buffer */ - if (size vout-buffer_size) { + if (size vid_max_buf_size) { Don't you think in case of mmap we should still check for the vout-buffer_size, since this is the size user has requested in req_buf. Thanks, Vaibhav v4l2_err(vout-vid_dev-v4l2_dev, insufficient memory [%lu] [%u]\n, size, vout-buffer_size); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/16] power: omap-prm: added chain interrupt handler
Hi some comments (also see the comments for the 1/16 patch, some of which apply to this patch) On Fri, 16 Sep 2011, Tero Kristo wrote: diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c index dfc0920..880748a 100644 --- a/drivers/power/omap_prm.c +++ b/drivers/power/omap_prm.c ... +static int __init omap_prm_probe(struct platform_device *pdev) +{ + struct omap_hwmod *oh; This is a sign that something is wrong here. Device driver code shouldn't have any hwmod dependencies. The driver should just use whatever data it gets from the struct platform_device / platform_data. Code in arch/arm/mach-omap2 can use hwmod data to populate platform_data, if needed. But it doesn't even look like that would be needed in this case. The PRM revision register resides inside the PRM IP block, so it's valid for the PRM driver to read it directly. Anyway, this PRM revision code is presumably mooted anyway if different drivers are probed for OMAP2430 vs. OMAP4-style PRMs. + int rev; + + oh = omap_hwmod_lookup(prm); + + if (!oh) { + pr_err(prm hwmod not found\n); + return -ENODEV; + } + + prm_dev.base = omap_hwmod_get_mpu_rt_va(oh); + + rev = prm_read_reg(oh-class-sysc-rev_offs); + + switch (rev) { + case OMAP3_PRM_REVISION: + prm_dev.irq_setup = omap3_prcm_irq_setup; + prm_dev.revision = PRM_OMAP3; + break; + case OMAP4_PRM_REVISION: + prm_dev.irq_setup = omap4_prcm_irq_setup; + prm_dev.revision = PRM_OMAP4; + break; + default: + pr_err(unknown PRM revision: %08x\n, rev); + return -ENODEV; + } + + prm_dev.irq = oh-mpu_irqs[0].irq; + + omap_prcm_irq_init(); + + return 0; +} - 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 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
Hi Deepthy, On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote: On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote: On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote: Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats. Signed-off-by: Deepthy Ravi deepthy.r...@ti.com --- drivers/media/video/omap3isp/ispccdc.c | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc, syn_mode = ~ISPCCDC_SYN_MODE_INPMOD_MASK; if (format-code == V4L2_MBUS_FMT_YUYV8_2X8 || - format-code == V4L2_MBUS_FMT_UYVY8_2X8) - syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8; + format-code == V4L2_MBUS_FMT_UYVY8_2X8){ + if (pdata pdata-bt656) + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8; + else + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16; + } else if (format-code == V4L2_MBUS_FMT_YUYV8_1X16 || format-code == V4L2_MBUS_FMT_UYVY8_1X16) syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16; @@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc) syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ; /* Use PACK8 mode for 1byte per pixel formats. */ - if (omap3isp_video_format_info(format-code)-width = 8) + if ((omap3isp_video_format_info(format-code)-width = 8) + (omap3isp_video_format_info(format-code)-bpp = 8)) I'm not sure to follow you. This will clear the PACK8 bit for the YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be set to store samples on 8 bits instead of 16 bits ? Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode with the bridge enabled ? In that case, what would you think about setting the CCDC input format to YUYV8_1X16 instead ? This would better reflect the reality, as the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC is then fed with YUYV8_1X16. Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit bridge enabled. So the data has to be stored as 16 bits per sample. Thats why PACK8 is cleared . I am not sure about using YUYV8_1X16. My original idea when I wrote the YV support patches was to implement this use case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the CCDC input. The ISP driver could then enable the bridge automatically. I'm not sure if that's the best solution though, it might be confusing for the users. What I would like to keep, however, is the idea of enabling the bridge automatically. Sakari, any opinion on this ? syn_mode |= ISPCCDC_SYN_MODE_PACK8; else syn_mode = ~ISPCCDC_SYN_MODE_PACK8; -- Regards, Laurent Pinchart -- 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: [PATCHv8 06/16] power: omap-prm: added chain interrupt handler
Hi a few more comments here: On Fri, 16 Sep 2011, Tero Kristo wrote: diff --git a/drivers/power/omap_prm.c b/drivers/power/omap_prm.c index dfc0920..880748a 100644 --- a/drivers/power/omap_prm.c +++ b/drivers/power/omap_prm.c #define DRIVER_NAME omap-prm +#define OMAP_PRCM_MAX_NR_PENDING_REG 2 + +struct omap_prcm_irq_setup { + u32 ack; + u32 mask; + int nr_regs; +}; struct omap_prm_device { - struct platform_device pdev; + struct platform_device pdev; + const struct omap_prcm_irq_setup*irq_setup; + struct irq_chip_generic **irq_chips; + int suspended; + u32 *saved_ena; + u32 *priority_mask; + int base_irq; + int irq; + void __iomem*base; + int revision; +}; + +#define OMAP3_PRM_REVISION 0x10 +#define OMAP4_PRM_REVISION 0x4100 + +#define PRM_OMAP30x1 +#define PRM_OMAP40x2 These should no longer be needed, as far as I can see. +#define OMAP3_PRM_IRQSTATUS_OFFSET 0x818 +#define OMAP3_PRM_IRQENABLE_OFFSET 0x81c +#define OMAP4_PRM_IRQSTATUS_OFFSET 0x10 +#define OMAP4_PRM_IRQENABLE_OFFSET 0x18 It probably would be best to put these in header files, and also just to cut and paste the needed macros from the arch/arm/mach-omap2/prm*.h files - the 44xx files are autogenerated and the 24xx/34xx files were partially autogenerated. + +static const struct omap_prcm_irq_setup omap3_prcm_irq_setup = { + .ack= OMAP3_PRM_IRQSTATUS_OFFSET, + .mask = OMAP3_PRM_IRQENABLE_OFFSET, + .nr_regs= 1, +}; + +static const struct omap_prcm_irq_setup omap4_prcm_irq_setup = { + .ack= OMAP4_PRM_IRQSTATUS_OFFSET, + .mask = OMAP4_PRM_IRQENABLE_OFFSET, + .nr_regs= 2, }; static struct omap_prm_device prm_dev = { @@ -33,20 +77,321 @@ static struct omap_prm_device prm_dev = { }, }; -static int __init omap_prm_probe(struct platform_device *pdev) +struct omap_prcm_irq { + const char *name; + unsigned int offset; + bool priority; + u32 supported_rev; +}; + +#define OMAP_PRCM_IRQ(_name, _offset, _high_priority, _rev) {\ + .name = _name, \ + .offset = _offset, \ + .priority = _high_priority, \ + .supported_rev = _rev \ + } + +static struct omap_prcm_irq omap_prcm_irqs[] = { + OMAP_PRCM_IRQ(wkup, 0, 0, PRM_OMAP3), + OMAP_PRCM_IRQ(io, 9, 1, PRM_OMAP3 | PRM_OMAP4), +}; + +static inline u32 prm_read_reg(int offset) +{ + return __raw_readl(prm_dev.base + offset); +} + +static inline void prm_write_reg(u32 value, int offset) +{ + __raw_writel(value, prm_dev.base + offset); +} What to do with these functions will depend on how you split the files up. Based on a naïve look, I'd suggest putting copies of prcm_irq_handler() into each of the omap*_prm.c files, calling local static functions for read_pending_events() and save_and_disable_irqenable_bits(), and then calling into common code in omap_prm_common.c for the rest of the function. Looks like omap_prm_complete() would also need PRM-variant-specific copies. I guess most of the rest could be common code? + +static void prm_pending_events(unsigned long *events) +{ + u32 ena, st; + int i; + + memset(events, 0, prm_dev.irq_setup-nr_regs * 4); + + for (i = 0; i prm_dev.irq_setup-nr_regs; i++) { + ena = prm_read_reg(prm_dev.irq_setup-mask + i * 4); + st = prm_read_reg(prm_dev.irq_setup-ack + i * 4); + events[i] = ena st; + } +} + +static void prm_events_filter_priority(unsigned long *events, + unsigned long *priority_events) +{ + int i; + + for (i = 0; i prm_dev.irq_setup-nr_regs; i++) { + priority_events[i] = events[i] prm_dev.priority_mask[i]; + events[i] ^= priority_events[i]; + } +} + +/* + * PRCM Interrupt Handler + * + * The PRM_IRQSTATUS_MPU register indicates if there are any pending + * interrupts from the PRCM for the MPU. These bits must be cleared in + * order to clear the PRCM interrupt. The PRCM interrupt handler is + * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear + * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU + * register indicates that a wake-up event is pending for the MPU and + * this bit can only be cleared if the all the wake-up events latched + * in the various PM_WKST_x registers have been cleared. The interrupt + *
[PATCH 37/57] mmc: irq: Remove IRQF_DISABLED
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com --- drivers/mmc/host/omap_hsmmc.c |5 ++--- drivers/mmc/host/tmio_mmc.c |4 ++-- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 21e4a79..75c6395 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2015,7 +2015,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) } /* Request IRQ for MMC operations */ - ret = request_irq(host-irq, omap_hsmmc_irq, IRQF_DISABLED, + ret = request_irq(host-irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); if (ret) { dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n); @@ -2043,8 +2043,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if ((mmc_slot(host).card_detect_irq)) { ret = request_irq(mmc_slot(host).card_detect_irq, omap_hsmmc_cd_handler, - IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING - | IRQF_DISABLED, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, mmc_hostname(mmc), host); if (ret) { dev_dbg(mmc_dev(host-mmc), diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c index 44a9668..a4ea102 100644 --- a/drivers/mmc/host/tmio_mmc.c +++ b/drivers/mmc/host/tmio_mmc.c @@ -88,8 +88,8 @@ static int __devinit tmio_mmc_probe(struct platform_device *pdev) if (ret) goto cell_disable; - ret = request_irq(irq, tmio_mmc_irq, IRQF_DISABLED | - IRQF_TRIGGER_FALLING, dev_name(pdev-dev), host); + ret = request_irq(irq, tmio_mmc_irq, IRQF_TRIGGER_FALLING, + dev_name(pdev-dev), host); if (ret) goto host_remove; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 49/57] video: irq: Remove IRQF_DISABLED
Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com --- drivers/video/au1200fb.c |2 +- drivers/video/bf54x-lq043fb.c |2 +- drivers/video/bfin-lq035q1-fb.c |2 +- drivers/video/bfin-t350mcqb-fb.c |2 +- drivers/video/bfin_adv7393fb.c|2 +- drivers/video/mb862xx/mb862xxfbdrv.c |4 ++-- drivers/video/msm/mddi.c |2 +- drivers/video/msm/mdp.c |2 +- drivers/video/nuc900fb.c |2 +- drivers/video/omap2/displays/panel-taal.c |2 +- drivers/video/ps3fb.c |2 +- drivers/video/pxa3xx-gcu.c|2 +- drivers/video/pxafb.c |2 +- drivers/video/s3c2410fb.c |2 +- drivers/video/sa1100fb.c |3 +-- drivers/video/sh_mobile_lcdcfb.c |2 +- drivers/video/tmiofb.c|2 +- drivers/video/vt8500lcdfb.c |2 +- 18 files changed, 19 insertions(+), 20 deletions(-) diff --git a/drivers/video/au1200fb.c b/drivers/video/au1200fb.c index a19a40e..7200559 100644 --- a/drivers/video/au1200fb.c +++ b/drivers/video/au1200fb.c @@ -1673,7 +1673,7 @@ static int __devinit au1200fb_drv_probe(struct platform_device *dev) /* Now hook interrupt too */ irq = platform_get_irq(dev, 0); ret = request_irq(irq, au1200fb_handle_irq, - IRQF_DISABLED | IRQF_SHARED, lcd, (void *)dev); + IRQF_SHARED, lcd, (void *)dev); if (ret) { print_err(fail to request interrupt line %d (err: %d), irq, ret); diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c index 2464b91..56720fb 100644 --- a/drivers/video/bf54x-lq043fb.c +++ b/drivers/video/bf54x-lq043fb.c @@ -633,7 +633,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev) goto out7; } - if (request_irq(info-irq, bfin_bf54x_irq_error, IRQF_DISABLED, + if (request_irq(info-irq, bfin_bf54x_irq_error, 0, PPI ERROR, info) 0) { printk(KERN_ERR DRIVER_NAME : unable to request PPI ERROR IRQ\n); diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c index 23b6c4b..c633068 100644 --- a/drivers/video/bfin-lq035q1-fb.c +++ b/drivers/video/bfin-lq035q1-fb.c @@ -695,7 +695,7 @@ static int __devinit bfin_lq035q1_probe(struct platform_device *pdev) goto out7; } - ret = request_irq(info-irq, bfin_lq035q1_irq_error, IRQF_DISABLED, + ret = request_irq(info-irq, bfin_lq035q1_irq_error, 0, DRIVER_NAME PPI ERROR, info); if (ret 0) { dev_err(pdev-dev, unable to request PPI ERROR IRQ\n); diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c index d8de29f..d5e1267 100644 --- a/drivers/video/bfin-t350mcqb-fb.c +++ b/drivers/video/bfin-t350mcqb-fb.c @@ -529,7 +529,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev) goto out7; } - ret = request_irq(info-irq, bfin_t350mcqb_irq_error, IRQF_DISABLED, + ret = request_irq(info-irq, bfin_t350mcqb_irq_error, 0, PPI ERROR, info); if (ret 0) { printk(KERN_ERR DRIVER_NAME diff --git a/drivers/video/bfin_adv7393fb.c b/drivers/video/bfin_adv7393fb.c index 8486f54..811dd7f 100644 --- a/drivers/video/bfin_adv7393fb.c +++ b/drivers/video/bfin_adv7393fb.c @@ -481,7 +481,7 @@ static int __devinit bfin_adv7393_fb_probe(struct i2c_client *client, goto out_4; } - if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, IRQF_DISABLED, + if (request_irq(IRQ_PPI_ERROR, ppi_irq_error, 0, PPI ERROR, fbdev) 0) { dev_err(client-dev, unable to request PPI ERROR IRQ\n); ret = -EFAULT; diff --git a/drivers/video/mb862xx/mb862xxfbdrv.c b/drivers/video/mb862xx/mb862xxfbdrv.c index 12a634a..11a7a33 100644 --- a/drivers/video/mb862xx/mb862xxfbdrv.c +++ b/drivers/video/mb862xx/mb862xxfbdrv.c @@ -738,7 +738,7 @@ static int __devinit of_platform_mb862xx_probe(struct platform_device *ofdev) if (mb862xx_gdc_init(par)) goto io_unmap; - if (request_irq(par-irq, mb862xx_intr, IRQF_DISABLED, + if (request_irq(par-irq, mb862xx_intr, 0, DRV_NAME, (void *)par)) { dev_err(dev, Cannot request irq\n); goto io_unmap;
Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote: It seems that you replace the #ifdef in the board-flash.c file with a similar #ifdef in the header that replaces this with an empty inline function when the object is not built. Found another similar problem over night, presumably in the voltage series: arch/arm/mach-omap2/built-in.o: In function `pwrdm_register_pwrdms': twl-common.c:(.text+0x5e20): undefined reference to `voltdm_lookup' twl-common.c:(.text+0x5e40): undefined reference to `voltdm_add_pwrdm' arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure': twl-common.c:(.init.text+0x3a4): undefined reference to `omap2xxx_voltagedomains_init' twl-common.c:(.init.text+0x3c8): undefined reference to `omap3xxx_voltagedomains_init' arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage': twl-common.c:(.init.text+0x13c8): undefined reference to `voltdm_lookup' arch/arm/mach-omap2/built-in.o: In function `omap3_twl_init': twl-common.c:(.init.text+0x1f44): undefined reference to `voltdm_lookup' twl-common.c:(.init.text+0x1f4c): undefined reference to `voltdm_lookup' Arnd -- 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/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
-Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/video/omap/omap_vout.c | 172 - - 1 files changed, 82 insertions(+), 90 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index e14c82b..c5f2ea0 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device *vout) return 0; } +static int omapvid_handle_interlace_display(struct omap_vout_device *vout, + unsigned int irqstatus, struct timeval timevalue) +{ + u32 fid; + + if (vout-first_int) { + vout-first_int = 0; + goto err; + } + + if (irqstatus DISPC_IRQ_EVSYNC_ODD) + fid = 1; + else if (irqstatus DISPC_IRQ_EVSYNC_EVEN) + fid = 0; + else + goto err; + + vout-field_id ^= 1; + if (fid != vout-field_id) { + /* reset field ID */ + vout-field_id = 0; [Hiremath, Vaibhav] You should check whether fid == 0 before resetting it. + } else if (0 == fid) { [Hiremath, Vaibhav] This is not matching with the original code, probably I have to be more careful here. I need to spend more time here... + if (vout-cur_frm == vout-next_frm) + goto err; + + vout-cur_frm-ts = timevalue; + vout-cur_frm-state = VIDEOBUF_DONE; + wake_up_interruptible(vout-cur_frm-done); + vout-cur_frm = vout-next_frm; + } else { + if (list_empty(vout-dma_queue) || + (vout-cur_frm != vout-next_frm)) + goto err; + } + + return vout-field_id; +err: + return 0; +} + static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret; - u32 addr, fid; + int ret, fid; + u32 addr; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) spin_lock(vout-vbq_lock); do_gettimeofday(timevalue); - if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) { - switch (cur_display-type) { - case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) - goto vout_isr_err; - break; - case OMAP_DISPLAY_TYPE_HDMI: - if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN)) - goto vout_isr_err; - break; - default: + switch (cur_display-type) { + case OMAP_DISPLAY_TYPE_DPI: + if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; - } - if (!vout-first_int (vout-cur_frm != vout-next_frm)) { - vout-cur_frm-ts = timevalue; - vout-cur_frm-state = VIDEOBUF_DONE; - wake_up_interruptible(vout-cur_frm-done); - vout-cur_frm = vout-next_frm; - } - vout-first_int = 0; - if (list_empty(vout-dma_queue)) + break; + case OMAP_DISPLAY_TYPE_VENC: + fid = omapvid_handle_interlace_display(vout, irqstatus, + timevalue); + if (!fid) goto vout_isr_err; [Hiremath, Vaibhav] Have you tested TV out functionality? + break; + case OMAP_DISPLAY_TYPE_HDMI: + if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN)) + goto vout_isr_err; + break; + default: + goto vout_isr_err; + } - vout-next_frm = list_entry(vout-dma_queue.next, - struct videobuf_buffer, queue); - list_del(vout-next_frm-queue); - - vout-next_frm-state = VIDEOBUF_ACTIVE; - - addr = (unsigned long) vout-queued_buf_addr[vout-next_frm- i] - + vout-cropped_offset; + if (!vout-first_int (vout-cur_frm != vout-next_frm)) { + vout-cur_frm-ts = timevalue; + vout-cur_frm-state = VIDEOBUF_DONE;
Re: [PATCH 37/57] mmc: irq: Remove IRQF_DISABLED
On Wed, 21 Sep 2011, Yong Zhang wrote: Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com --- drivers/mmc/host/omap_hsmmc.c |5 ++--- drivers/mmc/host/tmio_mmc.c |4 ++-- For tmio_mmc.c: Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 21e4a79..75c6395 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2015,7 +2015,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) } /* Request IRQ for MMC operations */ - ret = request_irq(host-irq, omap_hsmmc_irq, IRQF_DISABLED, + ret = request_irq(host-irq, omap_hsmmc_irq, 0, mmc_hostname(mmc), host); if (ret) { dev_dbg(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n); @@ -2043,8 +2043,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if ((mmc_slot(host).card_detect_irq)) { ret = request_irq(mmc_slot(host).card_detect_irq, omap_hsmmc_cd_handler, - IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING - | IRQF_DISABLED, + IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, mmc_hostname(mmc), host); if (ret) { dev_dbg(mmc_dev(host-mmc), diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c index 44a9668..a4ea102 100644 --- a/drivers/mmc/host/tmio_mmc.c +++ b/drivers/mmc/host/tmio_mmc.c @@ -88,8 +88,8 @@ static int __devinit tmio_mmc_probe(struct platform_device *pdev) if (ret) goto cell_disable; - ret = request_irq(irq, tmio_mmc_irq, IRQF_DISABLED | - IRQF_TRIGGER_FALLING, dev_name(pdev-dev), host); + ret = request_irq(irq, tmio_mmc_irq, IRQF_TRIGGER_FALLING, + dev_name(pdev-dev), host); if (ret) goto host_remove; -- 1.7.4.1 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
Hi, On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Tanejaarc...@ti.com --- drivers/media/video/omap/omap_vout.c | 172 - - 1 files changed, 82 insertions(+), 90 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index e14c82b..c5f2ea0 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device *vout) return 0; } +static int omapvid_handle_interlace_display(struct omap_vout_device *vout, + unsigned int irqstatus, struct timeval timevalue) +{ + u32 fid; + + if (vout-first_int) { + vout-first_int = 0; + goto err; + } + + if (irqstatus DISPC_IRQ_EVSYNC_ODD) + fid = 1; + else if (irqstatus DISPC_IRQ_EVSYNC_EVEN) + fid = 0; + else + goto err; + + vout-field_id ^= 1; + if (fid != vout-field_id) { + /* reset field ID */ + vout-field_id = 0; [Hiremath, Vaibhav] You should check whether fid == 0 before resetting it. + } else if (0 == fid) { [Hiremath, Vaibhav] This is not matching with the original code, probably I have to be more careful here. I need to spend more time here... If you do a dry run of it you'll see that it does the same thing functionally. If fid was 1, vout-field_id would have been 0 anyway. So the check for fid == 0 looked a bit redundant to me. However, if you think that doing this makes the code less clear, we can surely keep this check. + if (vout-cur_frm == vout-next_frm) + goto err; + + vout-cur_frm-ts = timevalue; + vout-cur_frm-state = VIDEOBUF_DONE; + wake_up_interruptible(vout-cur_frm-done); + vout-cur_frm = vout-next_frm; + } else { + if (list_empty(vout-dma_queue) || + (vout-cur_frm != vout-next_frm)) + goto err; + } + + return vout-field_id; +err: + return 0; +} + static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret; - u32 addr, fid; + int ret, fid; + u32 addr; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) spin_lock(vout-vbq_lock); do_gettimeofday(timevalue); - if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) { - switch (cur_display-type) { - case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) - goto vout_isr_err; - break; - case OMAP_DISPLAY_TYPE_HDMI: - if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN)) - goto vout_isr_err; - break; - default: + switch (cur_display-type) { + case OMAP_DISPLAY_TYPE_DPI: + if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; - } - if (!vout-first_int (vout-cur_frm != vout-next_frm)) { - vout-cur_frm-ts = timevalue; - vout-cur_frm-state = VIDEOBUF_DONE; - wake_up_interruptible(vout-cur_frm-done); - vout-cur_frm = vout-next_frm; - } - vout-first_int = 0; - if (list_empty(vout-dma_queue)) + break; + case OMAP_DISPLAY_TYPE_VENC: + fid = omapvid_handle_interlace_display(vout, irqstatus, + timevalue); + if (!fid) goto vout_isr_err; [Hiremath, Vaibhav] Have you tested TV out functionality? I haven't checked it yet to be totally honest. Its hard to find a VENC TV! I wanted to anyway get some kind of Ack from you before starting to test this. Since you also feel that this clean up is needed, I'll start testing this out :) + break; + case OMAP_DISPLAY_TYPE_HDMI: + if (!(irqstatus
Re: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation
Hi, On Wednesday 21 September 2011 02:10 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:30 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf mmap for buf_size allocation The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap prevent requesting a larger size buffer than what is allocated at kernel boot during omap_vout_probe. The requested size is compared with vout-buffer_size, this isn't correct as vout-buffer_size is later set to the size requested in reqbuf. When the video device is opened the next time, this check will prevent us to allocate a buffer which is larger than what we requested the last time. Don't use vout-buffer_size, always check with the parameters video1_bufsize or video2_bufsize. Signed-off-by: Archit Tanejaarc...@ti.com --- drivers/media/video/omap/omap_vout.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 95daf98..e14c82b 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, u32 phy_addr = 0, virt_addr = 0; struct omap_vout_device *vout = q-priv_data; struct omapvideo_info *ovid =vout-vid_info; + int vid_max_buf_size; if (!vout) return -EINVAL; + vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type) return -EINVAL; @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, video1_numbuffers : video2_numbuffers; /* Check the size of the buffer */ - if (*size vout-buffer_size) { + if (*size vid_max_buf_size) { Good catch !!! v4l2_err(vout-vid_dev-v4l2_dev, buffer allocation mismatch [%u] [%u]\n, *size, vout-buffer_size); @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) unsigned long size = (vma-vm_end - vma-vm_start); struct omap_vout_device *vout = file-private_data; struct videobuf_queue *q =vout-vbq; + int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; v4l2_dbg(1, debug,vout-vid_dev-v4l2_dev, %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__, @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) return -EINVAL; } /* Check the size of the buffer */ - if (size vout-buffer_size) { + if (size vid_max_buf_size) { Don't you think in case of mmap we should still check for the vout-buffer_size, since this is the size user has requested in req_buf. Ah, you are right, the check for the maximum size should only be in the reqbuf path. vout-buffer_size would have been updated correctly at time of mmap. I'll change this back to vout-buffer_size. Thanks, Archit Thanks, Vaibhav v4l2_err(vout-vid_dev-v4l2_dev, insufficient memory [%lu] [%u]\n, size, vout-buffer_size); -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/15] OMAP2+: Serial: Runtime adaptation + cleanup
Converting uart driver to adapt to pm runtime API's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c Changes involves: 1.) Cleaning up certain uart calls from sram_idle func. 2.) Removed all types of uart clock handling code from serial.c 3.) Using hwmod_mux API enable wakeup capability for uart pad during hwmod_idle state i.e., when uart clocks are disabled we can enable io-pad wakeup capability for uart if mux_data is available for given uart. Also during during resume from idle call to uart we need to enable clocks back conditionally and this can be done only when io-pad wakeup event bit is set for uart_rx pad. So we need a hwmod API which can probe the uart pad and let us know whether a uart wakeup happened. So omap_hmwod_pad_wakeup_status API is added to meet this requirement. 3.) Adapted omap-serial driver to use runtime API's. 4.) Modify serial_init calls to accept uart parameters from board file. Like dma_usage, rx_timeout, dma_rx_pollrate, auto_suspend_timeout etc. 5.) Use the omap_prm driver with irq_chaining to wake up uart after clocks are cut. Patch series is based on 3.1.0-rc4 + omap_device fixes. From Kevin's tree. git://gitorious.org/khilman/linux-omap-pm.git for_3.2/omap_device Also the patch series depends on Tero's Irq_chaining patches. Dependent irq_chaining patches are as below. 3d5b543 omap3: pm: use prcm chain handler c00b340 OMAP2+: mux: add support for PAD wakeup interrupts db6397c power: omap-prm: added chain interrupt handler b3f8628 TEMP: OMAP4xxx: hwmod data: add PRM hwmod 61ec0fc TEMP: OMAP3xxx: hwmod data: add PRM hwmod a1ecf8c power: add omap prm driver skeleton Same combination is hosted at: git://gitorious.org/runtime_3-0/runtime_3-0.git v5_uart_irqchn Ensure CONFIG_OMAP_PRM is set while testing irq_chaining with uart. Changes from v4: --- 1.) Fixing v4 comments from Kevin. Spilt into smaller logical patches. 2.) Using Irq_chaining OMAP_PRM driver for waking up uart. Testing updates: 3430SDP: retention, off_mode, system_wide suspend is tested. (earlyprintk no_console_suspend checked) OMAP3630 - Zoom3: pm-retention checked with quart/omap-uart3 [Also tested with uart3 as console uart and pm-ret checked] OMAP4430-SDP: Boot tested. OMAP2420/2430SDP: Boot tested. Deepak K (1): OMAP2+: UART: Allow UART parameters to be configured from board file. Govindraj.R (13): OMAP2+: hwmod: Add API to enable IO ring wakeup. OMAP2+: hwmod: Add API to check IO PAD wakeup status OMAP2+: UART: cleanup + remove uart pm specific API OMAP2+: UART: cleanup 8250 console driver support OMAP2+: UART: Cleanup part of clock gating mechanism for uart OMAP2+: UART: Remove certain feilds from omap_uart_state struct OMAP2+: UART: Add default mux for all uarts. OMAP2+: UART: Store certain reg values to port structure OMAP2+: UART: Add runtime pm support for omap-serial driver OMAP2+: UART: Move errata handling from serial.c to omap-serial OMAP2+: UART: Take console_lock in suspend path if not taken OMAP2+: UART: Enable back uart clocks with runtime API for early console OMAP2+: UART: Do not gate uart clocks if used for debug_prints Jon Hunter (1): OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART arch/arm/mach-omap2/board-3430sdp.c | 100 +--- arch/arm/mach-omap2/board-4430sdp.c |8 +- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c|8 +- arch/arm/mach-omap2/mux.c | 30 + arch/arm/mach-omap2/mux.h | 13 + arch/arm/mach-omap2/omap_hwmod.c | 66 ++ arch/arm/mach-omap2/pm24xx.c | 19 - arch/arm/mach-omap2/pm34xx.c | 24 - arch/arm/mach-omap2/serial.c | 933 +++-- arch/arm/plat-omap/include/plat/omap-serial.h | 30 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/include/plat/serial.h | 11 +- drivers/tty/serial/omap-serial.c | 305 +++-- 14 files changed, 654 insertions(+), 900 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/15] OMAP2+: hwmod: Add API to enable IO ring wakeup.
Add API to enable IO pad wakeup capability based on mux dynamic pad and wake_up enable flag available from hwmod_mux initialization. Use the wakeup_enable flag and enable wakeup capability for the given pads. Wakeup capability will be enabled/disabled during hwmod idle transition based on whether wakeup_flag is set or cleared. Call the omap_hwmod_set_ioring_wakeup from hwmod_wakeup_enable/disable. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 59 ++ 1 files changed, 59 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 84cc0bd..e751dd9 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2062,6 +2062,34 @@ static int __init omap_hwmod_setup_all(void) core_initcall(omap_hwmod_setup_all); /** + * omap_hwmod_set_ioring_wakeup - enable io pad wakeup flag. + * @oh: struct omap_hwmod * + * @set: bool value indicating to set or clear wakeup status. + * + * Set or Clear wakeup flag for the io_pad. + */ +static int omap_hwmod_set_ioring_wakeup(struct omap_hwmod *oh, bool set_wake) +{ + struct omap_device_pad *pad; + int ret = -EINVAL, j; + + if (oh-mux oh-mux-enabled) { + for (j = 0; j oh-mux-nr_pads_dynamic; j++) { + pad = oh-mux-pads_dynamic[j]; + if (pad-flags OMAP_DEVICE_PAD_WAKEUP) { + if (set_wake) + pad-idle |= OMAP_WAKEUP_EN; + else + pad-idle = ~OMAP_WAKEUP_EN; + ret = 0; + } + } + } + + return ret; +} + +/** * omap_hwmod_enable - enable an omap_hwmod * @oh: struct omap_hwmod * * @@ -2393,6 +2421,35 @@ int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh, { return _del_initiator_dep(oh, init_oh); } +/** + * omap_hwmod_enable_ioring_wakeup - Set wakeup flag for iopad. + * @oh: struct omap_hwmod * + * + * Traverse through dynamic pads, if pad is enabled then + * set wakeup enable bit flag for the mux pin. Wakeup pad bit + * will be set during hwmod idle transistion. + * Return error if pads are not enabled or not available. + */ +int omap_hwmod_enable_ioring_wakeup(struct omap_hwmod *oh) +{ + /* Enable pad wake-up capability */ + return omap_hwmod_set_ioring_wakeup(oh, true); +} + +/** + * omap_hwmod_disable_ioring_wakeup - Clear wakeup flag for iopad. + * @oh: struct omap_hwmod * + * + * Traverse through dynamic pads, if pad is enabled then + * clear wakeup enable bit flag for the mux pin. Wakeup pad bit + * will be set during hwmod idle transistion. + * Return error if pads are not enabled or not available. + */ +int omap_hwmod_disable_ioring_wakeup(struct omap_hwmod *oh) +{ + /* Disable pad wakeup capability */ + return omap_hwmod_set_ioring_wakeup(oh, false); +} /** * omap_hwmod_enable_wakeup - allow device to wake up the system @@ -2419,6 +2476,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh) v = oh-_sysc_cache; _enable_wakeup(oh, v); _write_sysconfig(v, oh); + omap_hwmod_enable_ioring_wakeup(oh); spin_unlock_irqrestore(oh-_lock, flags); return 0; @@ -2449,6 +2507,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh) v = oh-_sysc_cache; _disable_wakeup(oh, v); _write_sysconfig(v, oh); + omap_hwmod_disable_ioring_wakeup(oh); spin_unlock_irqrestore(oh-_lock, flags); return 0; -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 02/15] OMAP2+: hwmod: Add API to check IO PAD wakeup status
Add API to determine IO-PAD wakeup event status for a given hwmod dynamic_mux pad. Wake up event set will be cleared on pad mux_read. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/mux.c| 30 ++ arch/arm/mach-omap2/mux.h| 13 +++ arch/arm/mach-omap2/omap_hwmod.c |7 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 4 files changed, 51 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index 655e948..fb75aae 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -351,6 +351,36 @@ err1: return NULL; } +/** + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup + * @hmux: Pads for a hwmod + * + * Gets the wakeup status of given pad from omap-hwmod. + * Returns true if wakeup capability is set and wakeup event occurred. + * Returns false if wakeup event has not occurred or pads are not available. + */ +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux) +{ + int i; + unsigned int val; + u8 ret = false; + + for (i = 0; i hmux-nr_pads; i++) { + struct omap_device_pad *pad = hmux-pads[i]; + + if (pad-flags OMAP_DEVICE_PAD_WAKEUP) { + val = omap_mux_read(pad-partition, + pad-mux-reg_offset); + if (val OMAP_WAKEUP_EVENT) { + ret = true; + break; + } + } + } + + return ret; +} + /* Assumes the calling function takes care of locking */ void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state) { diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h index 2132308..8b2150a 100644 --- a/arch/arm/mach-omap2/mux.h +++ b/arch/arm/mach-omap2/mux.h @@ -225,8 +225,21 @@ omap_hwmod_mux_init(struct omap_device_pad *bpads, int nr_pads); */ void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state); +/** + * omap_hwmod_mux_get_wake_status - omap hwmod check pad wakeup + * @hmux: Pads for a hwmod + * + * Called only from omap_hwmod.c, do not use. + */ +bool omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux); #else +static inline bool +omap_hwmod_mux_get_wake_status(struct omap_hwmod_mux_info *hmux) +{ + return 0; +} + static inline int omap_mux_init_gpio(int gpio, int val) { return 0; diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index e751dd9..a8b24d7 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2724,3 +2724,10 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh) return 0; } + +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh) +{ + if (oh oh-mux) + return omap_hwmod_mux_get_wake_status(oh-mux); + return -EINVAL; +} diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 0e329ca..9a6195c 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -607,6 +607,7 @@ u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh); int omap_hwmod_no_setup_reset(struct omap_hwmod *oh); +int omap_hwmod_pad_get_wakeup_status(struct omap_hwmod *oh); /* * Chip variant-specific hwmod init routines - XXX should be converted * to use initcalls once the initial boot ordering is straightened out -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/15] OMAP2+: UART: Cleanup part of clock gating mechanism for uart
Currently we use a shared irq handler to identify uart activity and then trigger a timer. Based the timeout value set from sysfs the timer used to expire. If no uart-activity was detected timer-expiry func sets can_sleep flag. Based on this we will disable the uart clocks in idle path. Since the clock gating mechanism is outside the uart driver, we currently use this mechanism. In preparation to runtime implementation for omap-serial driver we can cleanup this mechanism and use runtime API's to gate uart clocks. Also remove timer related info from local uart_state struct and remove the code used to set timeout value from sysfs. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 116 + arch/arm/plat-omap/include/plat/omap-serial.h |1 - 2 files changed, 1 insertions(+), 116 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 784a8f9..3465fd7 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -57,8 +57,6 @@ struct omap_uart_state { int num; int can_sleep; - struct timer_list timer; - u32 timeout; void __iomem *wk_st; void __iomem *wk_en; @@ -66,13 +64,9 @@ struct omap_uart_state { u32 padconf; u32 dma_enabled; - struct clk *ick; - struct clk *fck; int clocked; - int irq; int regshift; - int irqflags; void __iomem *membase; resource_size_t mapbase; @@ -339,51 +333,6 @@ static void omap_uart_block_sleep(struct omap_uart_state *uart) omap_uart_smart_idle_enable(uart, 0); uart-can_sleep = 0; - if (uart-timeout) - mod_timer(uart-timer, jiffies + uart-timeout); - else - del_timer(uart-timer); -} - -static void omap_uart_allow_sleep(struct omap_uart_state *uart) -{ - if (device_may_wakeup(uart-pdev-dev)) - omap_uart_enable_wakeup(uart); - else - omap_uart_disable_wakeup(uart); - - if (!uart-clocked) - return; - - omap_uart_smart_idle_enable(uart, 1); - uart-can_sleep = 1; - del_timer(uart-timer); -} - -static void omap_uart_idle_timer(unsigned long data) -{ - struct omap_uart_state *uart = (struct omap_uart_state *)data; - - omap_uart_allow_sleep(uart); -} - -/** - * omap_uart_interrupt() - * - * This handler is used only to detect that *any* UART interrupt has - * occurred. It does _nothing_ to handle the interrupt. Rather, - * any UART interrupt will trigger the inactivity timer so the - * UART will not idle or sleep for its timeout period. - * - **/ -/* static int first_interrupt; */ -static irqreturn_t omap_uart_interrupt(int irq, void *dev_id) -{ - struct omap_uart_state *uart = dev_id; - - omap_uart_block_sleep(uart); - - return IRQ_NONE; } static void omap_uart_idle_init(struct omap_uart_state *uart) @@ -391,11 +340,6 @@ static void omap_uart_idle_init(struct omap_uart_state *uart) int ret; uart-can_sleep = 0; - uart-timeout = DEFAULT_TIMEOUT; - setup_timer(uart-timer, omap_uart_idle_timer, - (unsigned long) uart); - if (uart-timeout) - mod_timer(uart-timer, jiffies + uart-timeout); omap_uart_smart_idle_enable(uart, 0); if (cpu_is_omap34xx() !cpu_is_ti816x()) { @@ -457,51 +401,8 @@ static void omap_uart_idle_init(struct omap_uart_state *uart) uart-wk_mask = 0; uart-padconf = 0; } - - uart-irqflags |= IRQF_SHARED; - ret = request_threaded_irq(uart-irq, NULL, omap_uart_interrupt, - IRQF_SHARED, serial idle, (void *)uart); - WARN_ON(ret); -} - -static ssize_t sleep_timeout_show(struct device *dev, - struct device_attribute *attr, - char *buf) -{ - struct platform_device *pdev = to_platform_device(dev); - struct omap_device *odev = to_omap_device(pdev); - struct omap_uart_state *uart = odev-hwmods[0]-dev_attr; - - return sprintf(buf, %u\n, uart-timeout / HZ); } -static ssize_t sleep_timeout_store(struct device *dev, - struct device_attribute *attr, - const char *buf, size_t n) -{ - struct platform_device *pdev = to_platform_device(dev); - struct omap_device *odev = to_omap_device(pdev); - struct omap_uart_state *uart = odev-hwmods[0]-dev_attr; - unsigned int value; - - if (sscanf(buf, %u, value) != 1) { - dev_err(dev, sleep_timeout_store: Invalid value\n); - return -EINVAL; - } - - uart-timeout = value * HZ; - if (uart-timeout) - mod_timer(uart-timer, jiffies + uart-timeout); - else - /* A zero value means disable timeout feature
[PATCH v5 04/15] OMAP2+: UART: cleanup 8250 console driver support
We had been using traditional 8250 driver as uart console driver prior to omap-serial driver. Since we have omap-serial driver in mainline kernel for some time now it has been used as default uart console driver on omap2+ platforms. Remove 8250 support for omap-uarts. Serial_in and serial_out override for 8250 serial driver is also removed. Empty fifo read fix is already taken care with omap-serial driver with data ready bit check from LSR reg before reading RX fifo. Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr in omap-serial driver. Remove headers that were necessary to support 8250 support and remove all config bindings done to keep 8250 backward compatibility while adding omap-serial driver. Remove omap_uart_reset needed for 8250 autoconf. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 111 -- 1 files changed, 0 insertions(+), 111 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 60108fd..784a8f9 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -19,22 +19,16 @@ */ #include linux/kernel.h #include linux/init.h -#include linux/serial_reg.h #include linux/clk.h #include linux/io.h #include linux/delay.h #include linux/platform_device.h #include linux/slab.h -#include linux/serial_8250.h #include linux/console.h -#ifdef CONFIG_SERIAL_OMAP #include plat/omap-serial.h -#endif - #include plat/common.h #include plat/board.h -#include plat/clock.h #include plat/dma.h #include plat/omap_hwmod.h #include plat/omap_device.h @@ -46,10 +40,8 @@ #include control.h #include mux.h -#define UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV0x52 #define UART_OMAP_WER 0x17/* Wake-up enable register */ -#define UART_ERRATA_FIFO_FULL_ABORT(0x1 0) #define UART_ERRATA_i202_MDR1_ACCESS (0x1 1) /* @@ -156,19 +148,6 @@ static inline void serial_write_reg(struct omap_uart_state *uart, int offset, __raw_writeb(value, uart-membase + offset); } -/* - * Internal UARTs need to be initialized for the 8250 autoconfig to work - * properly. Note that the TX watermark initialization may not be needed - * once the 8250.c watermark handling code is merged. - */ - -static inline void __init omap_uart_reset(struct omap_uart_state *uart) -{ - serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE); - serial_write_reg(uart, UART_OMAP_SCR, 0x08); - serial_write_reg(uart, UART_OMAP_MDR1, UART_OMAP_MDR1_16X_MODE); -} - #if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) /* @@ -533,41 +512,6 @@ static void omap_uart_block_sleep(struct omap_uart_state *uart) #define DEV_CREATE_FILE(dev, attr) #endif /* CONFIG_PM */ -#ifndef CONFIG_SERIAL_OMAP -/* - * Override the default 8250 read handler: mem_serial_in() - * Empty RX fifo read causes an abort on omap3630 and omap4 - * This function makes sure that an empty rx fifo is not read on these silicons - * (OMAP1/2/3430 are not affected) - */ -static unsigned int serial_in_override(struct uart_port *up, int offset) -{ - if (UART_RX == offset) { - unsigned int lsr; - lsr = __serial_read_reg(up, UART_LSR); - if (!(lsr UART_LSR_DR)) - return -EPERM; - } - - return __serial_read_reg(up, offset); -} - -static void serial_out_override(struct uart_port *up, int offset, int value) -{ - unsigned int status, tmout = 1; - - status = __serial_read_reg(up, UART_LSR); - while (!(status UART_LSR_THRE)) { - /* Wait up to 10ms for the character(s) to be sent. */ - if (--tmout == 0) - break; - udelay(1); - status = __serial_read_reg(up, UART_LSR); - } - __serial_write_reg(up, offset, value); -} -#endif - static int __init omap_serial_early_init(void) { int i = 0; @@ -628,15 +572,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata) void *pdata = NULL; u32 pdata_size = 0; char *name; -#ifndef CONFIG_SERIAL_OMAP - struct plat_serial8250_port ports[2] = { - {}, - {.flags = 0}, - }; - struct plat_serial8250_port *p = ports[0]; -#else struct omap_uart_port_info omap_up; -#endif if (WARN_ON(!bdata)) return; @@ -651,51 +587,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata) oh = uart-oh; uart-dma_enabled = 0; -#ifndef CONFIG_SERIAL_OMAP - name = serial8250; - - /* -* !! 8250 driver does not use standard IORESOURCE* It -* has it's own custom pdata that can be taken from -* the hwmod resource data. But, this needs to be -* done after the build. -* -* ?? does it have to be done before the register ?? -* YES, because platform_device_data_add()
[PATCH v5 03/15] OMAP2+: UART: cleanup + remove uart pm specific API
In preparation to UART runtime conversion remove uart specific calls from pm24xx/34xx files and their definition from serial.c These func calls will no more be used with upcoming uart runtime design. 1.) omap_uart_can_sleep :- currently used to set uart-can_sleep flag based on which uart clocks can be gated, not needed further as driver can autosuspend based on usage_count and autosuspend delay with runtime API's. 2.) omap_uart_prepare_suspend :- can be taken care with driver suspend hooks. 3.) omap_uart_enable_irqs :- Used to enable/disable uart irq's in suspend path from PM code, this is removed as same is handled by uart_suspend_port/uart_resume_port in omap-serial driver which will do an port_shutdown on suspend freeing irq and port_startup on resume enabling back irq. 4.) Remove prepare_idle/resume_idle calls used to gate uart clocks. UART clocks can be gated within driver using runtime funcs and be woken up using irq_chaining from omap_prm driver. 5.) Remove console_locking from idle path as clock gating is done withing driver itself with runtime API. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/pm24xx.c | 19 --- arch/arm/mach-omap2/pm34xx.c | 24 arch/arm/mach-omap2/serial.c | 87 -- arch/arm/plat-omap/include/plat/serial.h |5 -- 4 files changed, 0 insertions(+), 135 deletions(-) diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c index bf089e7..83a8b96 100644 --- a/arch/arm/mach-omap2/pm24xx.c +++ b/arch/arm/mach-omap2/pm24xx.c @@ -133,27 +133,11 @@ static void omap2_enter_full_retention(void) if (omap_irq_pending()) goto no_sleep; - /* Block console output in case it is on one of the OMAP UARTs */ - if (!is_suspending()) - if (!console_trylock()) - goto no_sleep; - - omap_uart_prepare_idle(0); - omap_uart_prepare_idle(1); - omap_uart_prepare_idle(2); - /* Jump to SRAM suspend code */ omap2_sram_suspend(sdrc_read_reg(SDRC_DLLA_CTRL), OMAP_SDRC_REGADDR(SDRC_DLLA_CTRL), OMAP_SDRC_REGADDR(SDRC_POWER)); - omap_uart_resume_idle(2); - omap_uart_resume_idle(1); - omap_uart_resume_idle(0); - - if (!is_suspending()) - console_unlock(); - no_sleep: if (omap2_pm_debug) { unsigned long long tmp; @@ -265,8 +249,6 @@ static int omap2_can_sleep(void) { if (omap2_fclks_active()) return 0; - if (!omap_uart_can_sleep()) - return 0; if (osc_ck-usecount 1) return 0; if (omap_dma_running()) @@ -317,7 +299,6 @@ static int omap2_pm_suspend(void) mir1 = omap_readl(0x480fe0a4); omap_writel(1 5, 0x480fe0ac); - omap_uart_prepare_suspend(); omap2_enter_full_retention(); omap_writel(mir1, 0x480fe0a4); diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 7255d9b..4ea6aa7 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -379,18 +379,9 @@ void omap_sram_idle(void) omap3_enable_io_chain(); } - /* Block console output in case it is on one of the OMAP UARTs */ - if (!is_suspending()) - if (per_next_state PWRDM_POWER_ON || - core_next_state PWRDM_POWER_ON) - if (!console_trylock()) - goto console_still_active; - /* PER */ if (per_next_state PWRDM_POWER_ON) { per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0; - omap_uart_prepare_idle(2); - omap_uart_prepare_idle(3); omap2_gpio_prepare_for_idle(per_going_off); if (per_next_state == PWRDM_POWER_OFF) omap3_per_save_context(); @@ -398,8 +389,6 @@ void omap_sram_idle(void) /* CORE */ if (core_next_state PWRDM_POWER_ON) { - omap_uart_prepare_idle(0); - omap_uart_prepare_idle(1); if (core_next_state == PWRDM_POWER_OFF) { omap3_core_save_context(); omap3_cm_save_context(); @@ -446,8 +435,6 @@ void omap_sram_idle(void) omap3_sram_restore_context(); omap2_sms_restore_context(); } - omap_uart_resume_idle(0); - omap_uart_resume_idle(1); if (core_next_state == PWRDM_POWER_OFF) omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK, OMAP3430_GR_MOD, @@ -461,14 +448,8 @@ void omap_sram_idle(void) omap2_gpio_resume_after_idle(); if (per_prev_state ==
[PATCH v5 06/15] OMAP2+: UART: Remove certain feilds from omap_uart_state struct
Removing some of the uart info that is maintained in omap_uart_state struct used for UART PM in serial.c. Remove omap_uart_state struct dependency from omap_serial_init, omap_serial_init_port, omap_serial_early_init and omap_uart_idle_init functions. And populate the same info in omap_uart_port_info struct used as pdata struct. Added omap_uart_hwmod_lookup function to look up oh by name used in serial_port_init and omap_serial_early_init functions. A list of omap_uart_state was maintained one for each uart, the same is removed. Number of uarts available is maintained in num_uarts field, re-use the same in omap_serial_init func to register each uart. Remove omap_info which used details from omap_uart_state and use a pdata pointer to pass platform specific info to driver. The mapbase (start_address), membase(io_remap cookie) maintained as part of uart_state struct and pdata struct are removed as this is handled within driver. Errata field is also moved to pdata. These changes are done to cleanup serial.c file and prepare for runtime changes. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 132 +--- arch/arm/plat-omap/include/plat/omap-serial.h |4 +- drivers/tty/serial/omap-serial.c | 12 ++- 3 files changed, 61 insertions(+), 87 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 3465fd7..fd0c345 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -67,14 +67,6 @@ struct omap_uart_state { int clocked; int regshift; - void __iomem *membase; - resource_size_t mapbase; - - struct list_head node; - struct omap_hwmod *oh; - struct platform_device *pdev; - - u32 errata; #if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM) int context_valid; @@ -89,7 +81,6 @@ struct omap_uart_state { #endif }; -static LIST_HEAD(uart_list); static u8 num_uarts; static int uart_idle_hwmod(struct omap_device *od) @@ -142,7 +133,7 @@ static inline void serial_write_reg(struct omap_uart_state *uart, int offset, __raw_writeb(value, uart-membase + offset); } -#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) +#if defined(CONFIG_PM) /* * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) @@ -335,22 +326,17 @@ static void omap_uart_block_sleep(struct omap_uart_state *uart) uart-can_sleep = 0; } -static void omap_uart_idle_init(struct omap_uart_state *uart) +static void omap_uart_idle_init(struct omap_uart_port_info *uart, + unsigned short num) { - int ret; - - uart-can_sleep = 0; - omap_uart_smart_idle_enable(uart, 0); - if (cpu_is_omap34xx() !cpu_is_ti816x()) { - u32 mod = (uart-num 1) ? OMAP3430_PER_MOD : CORE_MOD; + u32 mod = (num 1) ? OMAP3430_PER_MOD : CORE_MOD; u32 wk_mask = 0; u32 padconf = 0; - /* XXX These PRM accesses do not belong here */ uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1); uart-wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1); - switch (uart-num) { + switch (num) { case 0: wk_mask = OMAP3430_ST_UART1_MASK; padconf = 0x182; @@ -369,12 +355,11 @@ static void omap_uart_idle_init(struct omap_uart_state *uart) break; } uart-wk_mask = wk_mask; - uart-padconf = padconf; } else if (cpu_is_omap24xx()) { u32 wk_mask = 0; u32 wk_en = PM_WKEN1, wk_st = PM_WKST1; - switch (uart-num) { + switch (num) { case 0: wk_mask = OMAP24XX_ST_UART1_MASK; break; @@ -399,7 +384,6 @@ static void omap_uart_idle_init(struct omap_uart_state *uart) uart-wk_en = NULL; uart-wk_st = NULL; uart-wk_mask = 0; - uart-padconf = 0; } } @@ -412,28 +396,27 @@ static void omap_uart_block_sleep(struct omap_uart_state *uart) } #endif /* CONFIG_PM */ -static int __init omap_serial_early_init(void) +struct omap_hwmod *omap_uart_hwmod_lookup(int num) { - int i = 0; + struct omap_hwmod *oh; + char oh_name[MAX_UART_HWMOD_NAME_LEN]; + + snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN, uart%d, num + 1); + oh = omap_hwmod_lookup(oh_name); + WARN(IS_ERR(oh), Could not lookup hmwod info for %s\n, + oh_name); + return oh; +} +static int __init omap_serial_early_init(void) +{ do { - char oh_name[MAX_UART_HWMOD_NAME_LEN]; struct omap_hwmod *oh; - struct omap_uart_state *uart; - snprintf(oh_name, MAX_UART_HWMOD_NAME_LEN, -
[PATCH v5 08/15] OMAP2+: UART: Store certain reg values to port structure
In preparation to runtime conversion add missing uart regs to port structure which can be used in context restore. Also ensuring all uart reg info's are part of port structure. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h |3 ++ drivers/tty/serial/omap-serial.c | 33 ++-- 2 files changed, 22 insertions(+), 14 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 0f061b4..74822b3 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -99,6 +99,9 @@ struct uart_omap_port { unsigned char mcr; unsigned char fcr; unsigned char efr; + unsigned char dll; + unsigned char dlh; + unsigned char mdr1; int use_dma; /* diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6c2ea54..9a0eac2 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -433,8 +433,9 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl) if (mctrl TIOCM_LOOP) mcr |= UART_MCR_LOOP; - mcr |= up-mcr; - serial_out(up, UART_MCR, mcr); + up-mcr = serial_in(up, UART_MCR); + up-mcr |= mcr; + serial_out(up, UART_MCR, up-mcr); } static void serial_omap_break_ctl(struct uart_port *port, int break_state) @@ -573,8 +574,6 @@ static inline void serial_omap_configure_xonxoff (struct uart_omap_port *up, struct ktermios *termios) { - unsigned char efr = 0; - up-lcr = serial_in(up, UART_LCR); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); up-efr = serial_in(up, UART_EFR); @@ -584,8 +583,7 @@ serial_omap_configure_xonxoff serial_out(up, UART_XOFF1, termios-c_cc[VSTOP]); /* clear SW control mode bits */ - efr = up-efr; - efr = OMAP_UART_SW_CLR; + up-efr = OMAP_UART_SW_CLR; /* * IXON Flag: @@ -593,7 +591,7 @@ serial_omap_configure_xonxoff * Transmit XON1, XOFF1 */ if (termios-c_iflag IXON) - efr |= OMAP_UART_SW_TX; + up-efr |= OMAP_UART_SW_TX; /* * IXOFF Flag: @@ -601,7 +599,7 @@ serial_omap_configure_xonxoff * Receiver compares XON1, XOFF1. */ if (termios-c_iflag IXOFF) - efr |= OMAP_UART_SW_RX; + up-efr |= OMAP_UART_SW_RX; serial_out(up, UART_EFR, up-efr | UART_EFR_ECB); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); @@ -624,7 +622,7 @@ serial_omap_configure_xonxoff * load the new software flow control mode IXON or IXOFF * and restore the UARTi.EFR_REG[4] ENHANCED_EN value. */ - serial_out(up, UART_EFR, efr | UART_EFR_SCD); + serial_out(up, UART_EFR, up-efr | UART_EFR_SCD); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A); serial_out(up, UART_MCR, up-mcr ~UART_MCR_TCRTLR); @@ -671,6 +669,10 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk/13); quot = serial_omap_get_divisor(port, baud); + up-dll = quot 0xff; + up-dlh = quot 8; + up-mdr1 = UART_OMAP_MDR1_DISABLE; + up-fcr = UART_FCR_R_TRIG_01 | UART_FCR_T_TRIG_01 | UART_FCR_ENABLE_FIFO; if (up-use_dma) @@ -723,6 +725,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, up-ier |= UART_IER_MSI; serial_out(up, UART_IER, up-ier); serial_out(up, UART_LCR, cval); /* reset DLAB */ + up-lcr = cval; /* FIFOs and DMA Settings */ @@ -759,7 +762,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, /* Protocol, Baud Rate, and Interrupt Settings */ - serial_out(up, UART_OMAP_MDR1, UART_OMAP_MDR1_DISABLE); + serial_out(up, UART_OMAP_MDR1, up-mdr1); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); up-efr = serial_in(up, UART_EFR); @@ -769,8 +772,8 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_out(up, UART_IER, 0); serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B); - serial_out(up, UART_DLL, quot 0xff); /* LS of divisor */ - serial_out(up, UART_DLM, quot 8);/* MS of divisor */ + serial_out(up, UART_DLL, up-dll); /* LS of divisor */ + serial_out(up, UART_DLM, up-dlh); /* MS of divisor */ serial_out(up, UART_LCR, 0); serial_out(up, UART_IER, up-ier); @@ -780,9 +783,11 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, serial_out(up, UART_LCR,
[PATCH v5 07/15] OMAP2+: UART: Add default mux for all uarts.
Prior to this change rx-pad wakeup was done by writing to rx-pad offset value populated in serial.c idle_init. Now with mux framework support we can use mux_utilities along with hmwod framework to handle io-pad configuration and enable rx-pad wake-up mechanism. Add default mux data for all uart's if mux info is not passed from board file to avoid breaking any board support. With the default pads we have populated wakeup capability for rx pads which can be used to enable uart_rx io-pad wakeup from hwmod framework. The pad values in 3430 board file are same as the default pad values populated in serial.c. Remove pad values from 3430 board file and use the default pads from serial.c file. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c | 100 +-- arch/arm/mach-omap2/serial.c| 190 +++ 2 files changed, 128 insertions(+), 162 deletions(-) diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index bd600cf..b12b38f 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -482,106 +482,8 @@ static const struct usbhs_omap_board_data usbhs_bdata __initconst = { static struct omap_board_mux board_mux[] __initdata = { { .reg_offset = OMAP_MUX_TERMINATOR }, }; - -static struct omap_device_pad serial1_pads[] __initdata = { - /* -* Note that off output enable is an active low -* signal. So setting this means pin is a -* input enabled in off mode -*/ - OMAP_MUX_STATIC(uart1_cts.uart1_cts, -OMAP_PIN_INPUT | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart1_rts.uart1_rts, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart1_rx.uart1_rx, -OMAP_PIN_INPUT | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart1_tx.uart1_tx, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), -}; - -static struct omap_device_pad serial2_pads[] __initdata = { - OMAP_MUX_STATIC(uart2_cts.uart2_cts, -OMAP_PIN_INPUT_PULLUP | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart2_rts.uart2_rts, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart2_rx.uart2_rx, -OMAP_PIN_INPUT | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart2_tx.uart2_tx, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), -}; - -static struct omap_device_pad serial3_pads[] __initdata = { - OMAP_MUX_STATIC(uart3_cts_rctx.uart3_cts_rctx, -OMAP_PIN_INPUT_PULLDOWN | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart3_rts_sd.uart3_rts_sd, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart3_rx_irrx.uart3_rx_irrx, -OMAP_PIN_INPUT | -OMAP_PIN_OFF_INPUT_PULLDOWN | -OMAP_OFFOUT_EN | -OMAP_MUX_MODE0), - OMAP_MUX_STATIC(uart3_tx_irtx.uart3_tx_irtx, -OMAP_PIN_OUTPUT | -OMAP_OFF_EN | -OMAP_MUX_MODE0), -}; - -static struct omap_board_data serial1_data __initdata = { - .id = 0, - .pads = serial1_pads, - .pads_cnt = ARRAY_SIZE(serial1_pads), -}; - -static struct omap_board_data serial2_data __initdata = { - .id = 1, - .pads = serial2_pads, - .pads_cnt = ARRAY_SIZE(serial2_pads), -}; - -static struct omap_board_data serial3_data __initdata = { - .id = 2, - .pads = serial3_pads, - .pads_cnt = ARRAY_SIZE(serial3_pads), -}; - -static inline void board_serial_init(void) -{ - omap_serial_init_port(serial1_data); - omap_serial_init_port(serial2_data); - omap_serial_init_port(serial3_data); -} #else #define board_mux NULL - -static inline void board_serial_init(void) -{ - omap_serial_init(); -} #endif
[PATCH v5 09/15] OMAP2+: UART: Add runtime pm support for omap-serial driver
Adapts omap-serial driver to use pm_runtime API's. Use runtime runtime API's to handle uart clocks and obtain device_usage statics. Set runtime API's usage to irq_safe so that we can use get_sync from irq context. Auto-suspend for port specific activities and put for reg access. Use device_may_wakeup to check whether uart has wakeup capabilities and then enable uart runtime usage for the uart. Removing save_context/restore_context functions from serial.c Adding context restore to .runtime_suspend and using reg values from port structure to restore the uart port context based on context_loss_count. Maintain internal state machine using wakeups_enabled field for avoiding repeated enable/disable of uart port wakeup mechanism. Remove omap_uart_disable_wakeup and modify omap_uart_enable_wakeup to accept pdev and bool value to enable/disable the uart wakeup mechanism after uart clock's are cut. omap_hwmod_enable_wakeup is used to set pad wakeup for the uarts. PM_WKEN reg values are left to default. Removed omap_uart_enable/disable_clocks in serial.c now clock handling done with runtime API's. By default uart autosuspend delay is set to -1 to avoid character loss if uart's are autoidled and woken up on rx pin. After boot up UART's can be autoidled by setting autosuspendi delay from sysfs. echo 3000 /sys/devices/platform/omap/omap_uart.X/power/autosuspend_delay_ms X=0,1,2,3 for UART1/2/3/4. Number of uarts available may vary across omap_soc. Acked-by: Alan Cox a...@linux.intel.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 206 ++-- arch/arm/plat-omap/include/plat/omap-serial.h |5 + drivers/tty/serial/omap-serial.c | 169 +++-- 3 files changed, 179 insertions(+), 201 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 1561140..43d8f0d 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -32,6 +32,7 @@ #include plat/dma.h #include plat/omap_hwmod.h #include plat/omap_device.h +#include plat/omap-pm.h #include prm2xxx_3xxx.h #include pm.h @@ -40,8 +41,6 @@ #include control.h #include mux.h -#define UART_OMAP_WER 0x17/* Wake-up enable register */ - #define UART_ERRATA_i202_MDR1_ACCESS (0x1 1) /* @@ -56,24 +55,7 @@ struct omap_uart_state { int num; - int can_sleep; u32 dma_enabled; - - int clocked; - - int regshift; -#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM) - int context_valid; - - /* Registers to be saved/restored for OFF-mode */ - u16 dll; - u16 dlh; - u16 ier; - u16 sysc; - u16 scr; - u16 wer; - u16 mcr; -#endif }; static u8 num_uarts; @@ -100,34 +82,6 @@ static struct omap_device_pm_latency omap_uart_latency[] = { }, }; -static inline unsigned int __serial_read_reg(struct uart_port *up, -int offset) -{ - offset = up-regshift; - return (unsigned int)__raw_readb(up-membase + offset); -} - -static inline unsigned int serial_read_reg(struct omap_uart_state *uart, - int offset) -{ - offset = uart-regshift; - return (unsigned int)__raw_readb(uart-membase + offset); -} - -static inline void __serial_write_reg(struct uart_port *up, int offset, - int value) -{ - offset = up-regshift; - __raw_writeb(value, up-membase + offset); -} - -static inline void serial_write_reg(struct omap_uart_state *uart, int offset, - int value) -{ - offset = uart-regshift; - __raw_writeb(value, uart-membase + offset); -} - #if defined(CONFIG_PM) /* @@ -164,134 +118,8 @@ static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val, udelay(1); } } - -static void omap_uart_save_context(struct omap_uart_state *uart) -{ - u16 lcr = 0; - - if (!enable_off_mode) - return; - - lcr = serial_read_reg(uart, UART_LCR); - serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_B); - uart-dll = serial_read_reg(uart, UART_DLL); - uart-dlh = serial_read_reg(uart, UART_DLM); - serial_write_reg(uart, UART_LCR, lcr); - uart-ier = serial_read_reg(uart, UART_IER); - uart-sysc = serial_read_reg(uart, UART_OMAP_SYSC); - uart-scr = serial_read_reg(uart, UART_OMAP_SCR); - uart-wer = serial_read_reg(uart, UART_OMAP_WER); - serial_write_reg(uart, UART_LCR, UART_LCR_CONF_MODE_A); - uart-mcr = serial_read_reg(uart, UART_MCR); - serial_write_reg(uart, UART_LCR, lcr); - - uart-context_valid = 1; -} - -static void omap_uart_restore_context(struct omap_uart_state *uart) -{ - u16 efr = 0; - - if (!enable_off_mode) - return; - - if (!uart-context_valid) - return; - -
[PATCH v5 11/15] OMAP2+: UART: Allow UART parameters to be configured from board file.
From: Deepak K deepa...@ti.com The following UART parameters are defined within the UART driver: 1). Whether the UART uses DMA (dma_enabled), by default set to 0 2). The size of dma buffer (set to 4096 bytes) 3). The time after which the dma should stop if no more data is received. 4). The auto suspend delay that will be passed for pm_runtime_autosuspend where uart will be disabled after timeout Different UARTs may be used for different purpose such as the console, for interfacing bluetooth chip, for interfacing to a modem chip, etc. Therefore, it is necessary to be able to customize the above settings for a given board on a per UART basis. This change allows these parameters to be configured from the board file and allows the parameters to be configured for each UART independently. If a board does not define its own custom parameters for the UARTs, then use the default parameters in the structure omap_serial_default_info. The default parameters are defined to be the same as the current settings in the UART driver to avoid breaking the UART for any cuurnelty supported boards. By default, make all boards use the default UART parameters. Signed-off-by: Deepak K deepa...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- This patch is derived and reworked from a custom 2.6.35 kernel Available here: http://git.omapzoom.org/?p=kernel/omap.git; a=commitdiff;h=584ef316542f77312be7ba96a0f3013c8f64852b; hp=7233a76cb362c0fc603f773274159adff91d3513 arch/arm/mach-omap2/board-4430sdp.c |8 ++-- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap4panda.c|8 ++-- arch/arm/mach-omap2/serial.c | 56 arch/arm/plat-omap/include/plat/omap-serial.h |7 ++- arch/arm/plat-omap/include/plat/serial.h |6 ++- drivers/tty/serial/omap-serial.c |8 +-- 7 files changed, 69 insertions(+), 30 deletions(-) diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c index c7cef44..41b43cb 100644 --- a/arch/arm/mach-omap2/board-4430sdp.c +++ b/arch/arm/mach-omap2/board-4430sdp.c @@ -743,11 +743,11 @@ static inline void board_serial_init(void) bdata.pads_cnt = 0; bdata.id= 0; /* pass dummy data for UART1 */ - omap_serial_init_port(bdata); + omap_serial_init_port(bdata, NULL); - omap_serial_init_port(serial2_data); - omap_serial_init_port(serial3_data); - omap_serial_init_port(serial4_data); + omap_serial_init_port(serial2_data, NULL); + omap_serial_init_port(serial3_data, NULL); + omap_serial_init_port(serial4_data, NULL); } #else #define board_mux NULL diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c index e11f0c5..3408726 100644 --- a/arch/arm/mach-omap2/board-n8x0.c +++ b/arch/arm/mach-omap2/board-n8x0.c @@ -656,15 +656,15 @@ static inline void board_serial_init(void) bdata.pads_cnt = 0; bdata.id = 0; - omap_serial_init_port(bdata); + omap_serial_init_port(bdata, NULL); bdata.id = 1; - omap_serial_init_port(bdata); + omap_serial_init_port(bdata, NULL); bdata.id = 2; bdata.pads = serial2_pads; bdata.pads_cnt = ARRAY_SIZE(serial2_pads); - omap_serial_init_port(bdata); + omap_serial_init_port(bdata, NULL); } #else diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index 9aaa960..fdfac0c 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -425,11 +425,11 @@ static inline void board_serial_init(void) bdata.pads_cnt = 0; bdata.id= 0; /* pass dummy data for UART1 */ - omap_serial_init_port(bdata); + omap_serial_init_port(bdata, NULL); - omap_serial_init_port(serial2_data); - omap_serial_init_port(serial3_data); - omap_serial_init_port(serial4_data); + omap_serial_init_port(serial2_data, NULL); + omap_serial_init_port(serial3_data, NULL); + omap_serial_init_port(serial4_data, NULL); } #else #define board_mux NULL diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 9fe248e..0e45d9a 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -42,17 +42,29 @@ #include mux.h /* - * NOTE: By default the serial timeout is disabled as it causes lost characters - * over the serial ports. This means that the UART clocks will stay on until - * disabled via sysfs. This also causes that any deeper omap sleep states are - * blocked. + * NOTE: By default the serial auto_suspend timeout is disabled as it causes + * lost characters over the serial ports. This means that the UART clocks will + * stay on until power/autosuspend_delay is set for the uart from sysfs. + * This also causes that any
[PATCH v5 10/15] OMAP2+: UART: Move errata handling from serial.c to omap-serial
Move the errata handling mechanism from serial.c to omap-serial file and utilise the same func in driver file. Errata i202, i291 are moved to be handled with omap-serial Moving the errata macro from serial.c file to driver header file as from on errata will be handled in driver file itself. Corrected errata id from chapter reference 2.15 to errata id i291. Acked-by: Alan Cox a...@linux.intel.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 78 + arch/arm/plat-omap/include/plat/omap-serial.h |5 ++ drivers/tty/serial/omap-serial.c | 63 ++-- 3 files changed, 77 insertions(+), 69 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 43d8f0d..9fe248e 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -41,8 +41,6 @@ #include control.h #include mux.h -#define UART_ERRATA_i202_MDR1_ACCESS (0x1 1) - /* * NOTE: By default the serial timeout is disabled as it causes lost characters * over the serial ports. This means that the UART clocks will stay on until @@ -53,11 +51,6 @@ #define MAX_UART_HWMOD_NAME_LEN16 -struct omap_uart_state { - int num; - u32 dma_enabled; -}; - static u8 num_uarts; static int uart_idle_hwmod(struct omap_device *od) @@ -84,63 +77,6 @@ static struct omap_device_pm_latency omap_uart_latency[] = { #if defined(CONFIG_PM) -/* - * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6) - * The access to uart register after MDR1 Access - * causes UART to corrupt data. - * - * Need a delay = - * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS) - * give 10 times as much - */ -static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val, - u8 fcr_val) -{ - u8 timeout = 255; - - serial_write_reg(uart, UART_OMAP_MDR1, mdr1_val); - udelay(2); - serial_write_reg(uart, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT | - UART_FCR_CLEAR_RCVR); - /* -* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and -* TX_FIFO_E bit is 1. -*/ - while (UART_LSR_THRE != (serial_read_reg(uart, UART_LSR) - (UART_LSR_THRE | UART_LSR_DR))) { - timeout--; - if (!timeout) { - /* Should *never* happen. we warn and carry on */ - dev_crit(uart-pdev-dev, Errata i202: timedout %x\n, - serial_read_reg(uart, UART_LSR)); - break; - } - udelay(1); - } -} -#endif /* CONFIG_PM CONFIG_ARCH_OMAP3 */ - -static void omap_uart_smart_idle_enable(struct omap_uart_state *uart, - int enable) -{ - u8 idlemode; - - if (enable) { - /** -* Errata 2.15: [UART]:Cannot Acknowledge Idle Requests -* in Smartidle Mode When Configured for DMA Operations. -*/ - if (uart-dma_enabled) - idlemode = HWMOD_IDLEMODE_FORCE; - else - idlemode = HWMOD_IDLEMODE_SMART; - } else { - idlemode = HWMOD_IDLEMODE_NO; - } - - omap_hwmod_set_slave_idlemode(uart-oh, idlemode); -} - #ifdef CONFIG_OMAP_MUX static struct omap_device_pad default_uart1_pads[] __initdata = { { @@ -282,7 +218,20 @@ static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable) omap_hwmod_disable_wakeup(od-hwmods[0]); } +/* + * Errata i291: [UART]:Cannot Acknowledge Idle Requests + * in Smartidle Mode When Configured for DMA Operations. + * WA: configure uart in force idle mode. + */ +static void omap_uart_set_forceidle(struct platform_device *pdev) +{ + struct omap_device *od = to_omap_device(pdev); + + omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_FORCE); +} + #else +static void omap_uart_set_forceidle(struct platform_device *pdev) {} static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable) {} #endif /* CONFIG_PM */ @@ -369,6 +318,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata) pdata-flags = UPF_BOOT_AUTOCONF; pdata-enable_wakeup = omap_uart_enable_wakeup; pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count; + pdata-set_force_idle = omap_uart_set_forceidle; /* Enable the MDR1 errata for OMAP3 */ if (cpu_is_omap34xx() !cpu_is_ti816x()) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 8ef81ce..12f5262 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -56,6 +56,8 @@ #define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA +#define
[PATCH v5 13/15] OMAP2+: UART: Take console_lock in suspend path if not taken
In suspend path the console_lock is taken by uart_port_suspend however when no_console_suspend is used console_lock is not taken. During system wide suspend omap_pwr_domain hooks cut all clocks that are left enabled. So its unsafe to proceed printing after clocks are cut by pwr_domain hooks. Also pm_runtime will be disabled after dpm_suspend devices happens. So buffer all prints in suspend path by taking console_lock and print them back safely after power domain hooks re-enable clocks back. Use CONFIG_SERIAL_OMAP_CONSOLE macro check to take console_lock since console ops are available only if omap console is defined. omap-serial can be built as module without console support. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/plat-omap/include/plat/omap-serial.h |1 + drivers/tty/serial/omap-serial.c | 20 ++-- 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index 28abc6b..de8de87 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -126,6 +126,7 @@ struct uart_omap_port { u32 context_loss_cnt; u8 wakeups_enabled; u32 errata; + u8 console_locked; }; diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 64e4ab5..92a1f10 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1133,8 +1133,15 @@ static int serial_omap_suspend(struct device *dev) { struct uart_omap_port *up = dev_get_drvdata(dev); - if (up) + if (up) { uart_suspend_port(serial_omap_reg, up-port); +#ifdef CONFIG_SERIAL_OMAP_CONSOLE + if (up-port.line == up-port.cons-index + !is_console_locked()) + up-console_locked = console_trylock(); +#endif + } + return 0; } @@ -1142,8 +1149,17 @@ static int serial_omap_resume(struct device *dev) { struct uart_omap_port *up = dev_get_drvdata(dev); - if (up) + if (up) { uart_resume_port(serial_omap_reg, up-port); +#ifdef CONFIG_SERIAL_OMAP_CONSOLE + if (up-port.line == up-port.cons-index + up-console_locked) { + console_unlock(); + up-console_locked = 0; + } +#endif + } + return 0; } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 15/15] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
If OMAP UART is used as console uart and debug is enabled, avoid gating of uart clocks to print all debug prints. If uart clocks are gated then the debug prints from omap_device framework or hwmod framework can cause uart to enter recursive pm_runtime calls, which can cause a deadlock over power lock usage. For example: Say, uart clocks are cut and we get a print from omap_device_disable stating disabling uart clocks. This print calls omap_uart driver console_write which will call runtime API get_sync which means we enter from runtime API put context to runtime API get context. -- runtime put (take power lock) -- print disabling uart clocks -- call uart console write -- call get_sync (try to take power lock) Also any clock enable API call from uart driver should not call any uart operation until clocks are enabled back. Like get_sync having debug print calling uart console write even before clocks are enabled. So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used in debug mode. If so, do not set device_may_wakeup. This will prevent pm_runtime_enable in uart driver probe and will avoid uart clock gating. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- More details on this topic and experiments done listed here: http://www.spinics.net/lists/linux-serial/msg04128.html arch/arm/mach-omap2/serial.c | 18 +- 1 files changed, 17 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 87696bf..3d92b77f 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -266,8 +266,24 @@ struct omap_hwmod *omap_uart_hwmod_lookup(int num) return oh; } +static int uart_debug; + +char *cmdline_find_option(char *str) +{ + extern char *saved_command_line; + + return strstr(saved_command_line, str); +} + static int __init omap_serial_early_init(void) { + if (cmdline_find_option(debug) + cmdline_find_option(OMAP_SERIAL_NAME)) { + uart_debug = true; + pr_info(OMAP UART used as console in debug mode +uart clocks will not be gated); + } + do { struct omap_hwmod *oh; @@ -361,7 +377,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata, oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt); - if ((cpu_is_omap34xx() bdata-pads)) + if ((cpu_is_omap34xx() bdata-pads) !uart_debug) device_init_wakeup(pdev-dev, true); kfree(pdata); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 14/15] OMAP2+: UART: Enable back uart clocks with runtime API for early console
For the early console probing we had avoided hwmod reset and idling and uart was idled using hwmod API and enabled back using omap_device API after omap_device registration. Now since we are using runtime API's to enable back uart move hwmod idling and use runtime API to enable back UART. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/serial.c | 26 arch/arm/plat-omap/include/plat/omap-serial.h |1 + drivers/tty/serial/omap-serial.c |1 + 3 files changed, 11 insertions(+), 17 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 57d063a..87696bf 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -24,13 +24,11 @@ #include linux/delay.h #include linux/platform_device.h #include linux/slab.h -#include linux/console.h #include plat/omap-serial.h #include plat/common.h #include plat/board.h #include plat/dma.h -#include plat/omap_hwmod.h #include plat/omap_device.h #include plat/omap-pm.h @@ -244,10 +242,16 @@ static void omap_uart_set_forceidle(struct platform_device *pdev) omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_FORCE); } +static void omap_uart_hwmod_idle(struct platform_device *pdev) +{ + struct omap_device *od = to_omap_device(pdev); + + omap_hwmod_idle(od-hwmods[0]); +} + #else static void omap_uart_set_forceidle(struct platform_device *pdev) {} -static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable) -{} +static void omap_uart_hwmod_idle(struct platform_device *pdev) {} #endif /* CONFIG_PM */ struct omap_hwmod *omap_uart_hwmod_lookup(int num) @@ -338,6 +342,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata, pdata-enable_wakeup = omap_uart_enable_wakeup; pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count; pdata-set_force_idle = omap_uart_set_forceidle; + pdata-hwmod_idle = omap_uart_hwmod_idle; pdata-dma_enabled = info-dma_enabled; pdata-dma_rx_buf_size = info-dma_rx_buf_size; pdata-dma_rx_poll_rate = info-dma_rx_poll_rate; @@ -356,19 +361,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata, oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt); - console_lock(); /* in case the earlycon is on the UART */ - - /* -* Because of early UART probing, UART did not get idled -* on init. Now that omap_device is ready, ensure full idle -* before doing omap_device_enable(). -*/ - omap_hwmod_idle(oh); - - omap_device_enable(pdev); - - console_unlock(); - if ((cpu_is_omap34xx() bdata-pads)) device_init_wakeup(pdev-dev, true); diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index de8de87..800f215 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -71,6 +71,7 @@ struct omap_uart_port_info { void (*enable_wakeup)(struct platform_device *, bool); u32 (*get_context_loss_count)(struct device *); void (*set_force_idle)(struct platform_device *); + void (*hwmod_idle)(struct platform_device *); }; struct uart_omap_dma { diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 92a1f10..8125a89 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -1394,6 +1394,7 @@ static int serial_omap_probe(struct platform_device *pdev) pm_runtime_irq_safe(pdev-dev); if (device_may_wakeup(pdev-dev)) { pm_runtime_enable(pdev-dev); + omap_up_info-hwmod_idle(pdev); pm_runtime_get_sync(pdev-dev); } -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 12/15] OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART
From: Jon Hunter jon-hun...@ti.com When using DMA there are two timeouts defined. The first timeout, rx_timeout, is really a polling rate in which software polls the DMA status to see if the DMA has finished. This is necessary for the RX side because we do not know how much data we will receive. The secound timeout, RX_TIMEOUT, is a timeout after which the DMA will be stopped if no more data is received. To make this clearer, rename rx_timeout as rx_poll_rate and rename the function serial_omap_rx_timeout() to serial_omap_rxdma_poll(). The OMAP-Serial driver defines an RX_TIMEOUT of 3 seconds that is used to indicate when the DMA for UART can be stopped if no more data is received. The value is a global definition that is applied to all instances of the UART. Each UART may be used for a different purpose and so the timeout required may differ. Make this value configurable for each UART so that this value can be optimised for power savings. Acked-by: Kevin Hilman khil...@ti.com Signed-off-by: Jon Hunter jon-hun...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- This patch is derived from a custom 2.6.35 kernel Available here: http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff; h=b47839fb84e68333ea29a327cf5aa694b71be7d6; hp=f62f570e8580507be48ad004defc2ec714b6e05d arch/arm/mach-omap2/serial.c |5 - arch/arm/plat-omap/include/plat/omap-serial.h |3 ++- drivers/tty/serial/omap-serial.c | 15 --- 3 files changed, 14 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c index 0e45d9a..57d063a 100644 --- a/arch/arm/mach-omap2/serial.c +++ b/arch/arm/mach-omap2/serial.c @@ -53,13 +53,15 @@ static u8 num_uarts; -#define DEFAULT_RXDMA_TIMEOUT 1 /* RX DMA polling rate (us) */ +#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */ #define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */ +#define DEFAULT_RXDMA_TIMEOUT (3 * HZ)/* RX DMA timeout (jiffies) */ static struct omap_uart_port_info omap_serial_default_info[] = { { .dma_enabled= 0, .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE, + .dma_rx_poll_rate = DEFAULT_RXDMA_POLLRATE, .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT, .autosuspend_timeout = DEFAULT_AUTOSUSPEND_DELAY, }, @@ -338,6 +340,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata, pdata-set_force_idle = omap_uart_set_forceidle; pdata-dma_enabled = info-dma_enabled; pdata-dma_rx_buf_size = info-dma_rx_buf_size; + pdata-dma_rx_poll_rate = info-dma_rx_poll_rate; pdata-dma_rx_timeout = info-dma_rx_timeout; pdata-autosuspend_timeout = info-autosuspend_timeout; diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h index a40a41a..28abc6b 100644 --- a/arch/arm/plat-omap/include/plat/omap-serial.h +++ b/arch/arm/plat-omap/include/plat/omap-serial.h @@ -51,7 +51,6 @@ #define OMAP_UART_DMA_CH_FREE -1 -#define RX_TIMEOUT (3 * HZ) #define OMAP_MAX_HSUART_PORTS 4 #define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA @@ -67,6 +66,7 @@ struct omap_uart_port_info { unsigned intdma_rx_buf_size; unsigned intdma_rx_timeout; unsigned intautosuspend_timeout; + unsigned intdma_rx_poll_rate; void (*enable_wakeup)(struct platform_device *, bool); u32 (*get_context_loss_count)(struct device *); @@ -95,6 +95,7 @@ struct uart_omap_dma { /* timer to poll activity on rx dma */ struct timer_list rx_timer; unsigned intrx_buf_size; + unsigned intrx_poll_rate; unsigned intrx_timeout; }; diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 15e0655..64e4ab5 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -47,7 +47,7 @@ static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS]; /* Forward declaration of functions */ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data); -static void serial_omap_rx_timeout(unsigned long uart_no); +static void serial_omap_rxdma_poll(unsigned long uart_no); static int serial_omap_start_rxdma(struct uart_omap_port *up); static void serial_omap_mdr1_errataset(struct uart_omap_port *up, u8 mdr1); @@ -542,7 +542,7 @@ static int serial_omap_startup(struct uart_port *port) (dma_addr_t *)(up-uart_dma.tx_buf_dma_phys), 0); init_timer((up-uart_dma.rx_timer)); - up-uart_dma.rx_timer.function = serial_omap_rx_timeout; + up-uart_dma.rx_timer.function = serial_omap_rxdma_poll; up-uart_dma.rx_timer.data = up-pdev-id;
RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
-Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr Currently, in omap_vout_isr(), if the panel type is DPI, and if we get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the current buffers state to VIDEOBUF_DONE and prepare to display the next frame in the queue. On OMAP4, because we have 2 LCD managers, the panel type itself is not sufficient to tell if we have received the correct irq, i.e, we shouldn't proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2 interrupt for LCD manager. Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager to VSYNC2 interrupt. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/video/omap/omap_vout.c | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index c5f2ea0..20638c3 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -566,8 +566,8 @@ err: static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret, fid; - u32 addr; + int ret, fid, mgr_id; + u32 addr, irq; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) if (!ovl-manager || !ovl-manager-device) return; + mgr_id = ovl-manager-id; cur_display = ovl-manager-device; spin_lock(vout-vbq_lock); @@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) switch (cur_display-type) { case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) + if (mgr_id == OMAP_DSS_CHANNEL_LCD) + irq = DISPC_IRQ_VSYNC; + else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) + irq = DISPC_IRQ_VSYNC2; + else + goto vout_isr_err; + + if (!(irqstatus irq)) goto vout_isr_err; break; I understand what this patch meant for, but I am more curious to know What is value addition of this patch? if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) Vs if (mgr_id == OMAP_DSS_CHANNEL_LCD) irq = DISPC_IRQ_VSYNC; else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) irq = DISPC_IRQ_VSYNC2; Isn't this same, because we are not doing anything separate and special for VSYNC and VSYNC2? Thanks, Vaibhav case OMAP_DISPLAY_TYPE_VENC: -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
Kevin, * Arnd Bergmann a...@arndb.de [110921 01:55]: On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote: It seems that you replace the #ifdef in the board-flash.c file with a similar #ifdef in the header that replaces this with an empty inline function when the object is not built. Found another similar problem over night, presumably in the voltage series: arch/arm/mach-omap2/built-in.o: In function `pwrdm_register_pwrdms': twl-common.c:(.text+0x5e20): undefined reference to `voltdm_lookup' twl-common.c:(.text+0x5e40): undefined reference to `voltdm_add_pwrdm' arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure': twl-common.c:(.init.text+0x3a4): undefined reference to `omap2xxx_voltagedomains_init' twl-common.c:(.init.text+0x3c8): undefined reference to `omap3xxx_voltagedomains_init' arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage': twl-common.c:(.init.text+0x13c8): undefined reference to `voltdm_lookup' arch/arm/mach-omap2/built-in.o: In function `omap3_twl_init': twl-common.c:(.init.text+0x1f44): undefined reference to `voltdm_lookup' twl-common.c:(.init.text+0x1f4c): undefined reference to `voltdm_lookup' Can you take a look at this one? 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 00/10] hwspinlock-next
On Wednesday 21 September 2011, Tony Lindgren wrote: * Ohad Ben-Cohen o...@wizery.com [110920 01:34]: On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: I'm wondering how hwspinlock updates like this should go upstream. The first hwspinlock batch was picked by Tony, because it involved a bulk of OMAP changes. Hwspinlock isn't OMAP-specific anymore though (we gained support for STE's u8500) and the vast majority of changes are in drivers/. We're still very much ARM-related, though this may change too at some point (c6x has a similar hardware semaphore peripheral like the u8500 does). Tony, if you're still willing to pick up these updates I'd be happy to send you pull requests of course. I'd prefer for Greg to take these as these are drivers. If he's not taking it at this point based on it being ARM only, I can take it then. Sorry for replying late, I had accidentally ignored the entire thread. My feeling is that it would be best for Ohad to send these directly to Linus, since it's basically a standalone subsystem and he's listed as the maintainer (well, after this series at least). I'm also fine with any of the other paths like ohad-GregKH-torvalds ohad-arnd-torvalds ohad-tmlind-torvalds ohad-tmlind-arnd-torvalds Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 01/26] gpio/omap: remove dependency on gpio_bank_count
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: From: Charulatha V ch...@ti.com The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove this dependency from the driver by using list. Also remove the dependency on array of pointers to gpio_bank struct of all GPIO devices. Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 04/26] gpio/omap: fix pwrdm_post_transition call sequence
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: From: Charulatha V ch...@ti.com The context lost count is modified in omap_sram_idle() path when pwrdm_post_transition() is called. But pwrdm_post_transition() is called only after omap_gpio_resume_after_idle() is called. Correct this so that context lost count is modified before calling omap_gpio_resume_after_idle(). This would be useful when OMAP GPIO save/restore context is called by the OMAP GPIO driver itself. Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com This should be acked by Kevin, looks OK to me: Acked-by: Tony Lindgren t...@atomide.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 v7 05/26] gpio/omap: handle save/restore context in GPIO driver
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: From: Charulatha V ch...@ti.com Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions to handle save context restore context respectively in the OMAP GPIO driver itself instead of calling these functions from pm specific files. For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in gpio_resume_after_idle() call it again. If the count is different, do restore context. The workaround_enabled flag is no more required and is removed. Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com This to should be also acked by Kevin, looks OK to me: Acked-by: Tony Lindgren t...@atomide.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 v7 06/26] gpio/omap: make non-wakeup GPIO part of pdata
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]: From: Charulatha V ch...@ti.com Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making non_wakeup_gpios as part of pdata. Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 08/26] gpio/omap: further cleanup using wkup_en register
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: Wakeup enable register offset initialized according to OMAP versions during device registration. Use this to avoid version checks. Starting with OMAP4, legacy registers should not be used in combination with the updated regsiters. Use wkup_en register consistently for all SoCs wherever applicable. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 07/26] gpio/omap: avoid cpu checks during module ena/disable
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]: From: Charulatha V ch...@ti.com Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio request/free. Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 09/26] gpio/omap: use level/edge detect reg offsets
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: By adding level and edge detection register offsets and then initializing them correctly according to OMAP versions during device registrations we can now remove lot of revision checks in these functions. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 10/26] gpio/omap: remove hardcoded offsets in context save/restore
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: It is not required to use hard-coded offsets any more in context save and restore functions and instead use the generic offsets which have been correctly initialized during device registration. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 11/26] gpio/omap: cleanup set_gpio_triggering function
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: Getting rid of ifdefs within the function by adding register offset intctrl and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files. Also, use wkup_status register consistently instead of referring to wakeup clear and wakeup set register offsets. Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 12/26] gpio/omap: cleanup omap_gpio_mod_init function
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]: With register offsets now defined for respective OMAP versions we can get rid of cpu_class_* checks. This function now has common initialization code for all OMAP versions. Initialization specific to OMAP16xx has been moved within omap16xx_gpio_init(). Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 13/26] gpio/omap: use pinctrl offset instead of macro
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: From: Charulatha V ch...@ti.com Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 00/10] hwspinlock-next
On Tue, Sep 20, 2011 at 04:13:40PM -0700, Tony Lindgren wrote: * Ohad Ben-Cohen o...@wizery.com [110920 01:34]: On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: I'm wondering how hwspinlock updates like this should go upstream. The first hwspinlock batch was picked by Tony, because it involved a bulk of OMAP changes. Hwspinlock isn't OMAP-specific anymore though (we gained support for STE's u8500) and the vast majority of changes are in drivers/. We're still very much ARM-related, though this may change too at some point (c6x has a similar hardware semaphore peripheral like the u8500 does). Tony, if you're still willing to pick up these updates I'd be happy to send you pull requests of course. I'd prefer for Greg to take these as these are drivers. What, am I the catch-all for drivers these days? Oh, right, it looks like I am :) If he's not taking it at this point based on it being ARM only, I can take it then. Please do, I don't even have the ability to build them here, as I don't have an arm cross-compiler on this travel laptop. greg k-h -- 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/3] ASoC: tpa6130a2: model handling cleanup
On Tue, Aug 30, 2011 at 04:38:50PM +0300, Jarkko Nikula wrote: Tested-by: Jarkko Nikula jarkko.nik...@bitmer.com I applied these with the last two patches squashed together in order to preserve bisection - the two patches should have been combined as patch 2 removes a field that the existing code is using. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 13/26] gpio/omap: use pinctrl offset instead of macro
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: From: Charulatha V ch...@ti.com Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 15/26] gpio/omap: remove bank-method METHOD_* macros
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]: From: Charulatha V ch...@ti.com The only bank-type (method) used in the OMAP GPIO driver is MPUIO type as they need to be handled separately. Identify the same using a flag and remove all METHOD_* macros. mpuio_init() function is defined under #ifdefs. It is required only in case of MPUIO bank type and only when PM operations are supported by it. This is applicable only in case of OMAP16xx SoC's MPUIO GPIO bank type. For all the other cases it is a dummy function. Hence clean up the same and remove all the OMAP SoC specific #ifdefs. Signed-off-by: Charulatha V ch...@ti.com Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 16/26] gpio/omap: fix bankwidth for OMAP7xx MPUIO
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:30]: From: Charulatha V ch...@ti.com In all OMAP1 SoCs, the MPUIO bank width is 16 bits. But, in OMAP7xx, it is wrongly initialised to 32. Fix this. Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.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 v7 26/26] gpio/omap: add dbclk aliases for all gpio modules
* Tarun Kanti DebBarma tarun.ka...@ti.com [110913 05:29]: Unless the dbclk aliases are assigned, clk_get(bank-dev, dbclk) would not fetch the associated clock handle. As a result, we would not be able to turn on/off the debounce clock. This was preventing the gpio modules going to low power mode whenever dbclk is enabled. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Looks OK to me, Paul should ack this one also: Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/clock3xxx_data.c |6 ++ arch/arm/mach-omap2/clock44xx_data.c |6 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index ffd55b1..7238ec1 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -3462,6 +3462,12 @@ static struct omap_clk omap3xxx_clks[] = { CLK(musb-am35x, fck, hsotgusb_fck_am35xx, CK_AM35XX), CLK(NULL, hecc_ck, hecc_ck, CK_AM35XX), CLK(NULL, uart4_ick,uart4_ick_am35xx, CK_AM35XX), + CLK(omap_gpio.1, dbclk,gpio1_dbck,CK_3XXX), + CLK(omap_gpio.2, dbclk,gpio2_dbck,CK_3XXX), + CLK(omap_gpio.3, dbclk,gpio3_dbck,CK_3XXX), + CLK(omap_gpio.4, dbclk,gpio4_dbck,CK_3XXX), + CLK(omap_gpio.5, dbclk,gpio5_dbck,CK_3XXX), + CLK(omap_gpio.6, dbclk,gpio6_dbck,CK_3XXX), }; diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c index 2af0e3f..4986069 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -3363,6 +3363,12 @@ static struct omap_clk omap44xx_clks[] = { CLK(usbhs-omap.0, usbhost_ick, dummy_ck, CK_443X), CLK(usbhs-omap.0, usbtll_fck, dummy_ck, CK_443X), CLK(omap_wdt, ick, dummy_ck, CK_443X), + CLK(omap_gpio.1, dbclk,gpio1_dbclk, CK_443X), + CLK(omap_gpio.2, dbclk,gpio2_dbclk, CK_443X), + CLK(omap_gpio.3, dbclk,gpio3_dbclk, CK_443X), + CLK(omap_gpio.4, dbclk,gpio4_dbclk, CK_443X), + CLK(omap_gpio.5, dbclk,gpio5_dbclk, CK_443X), + CLK(omap_gpio.6, dbclk,gpio6_dbclk, CK_443X), }; int __init omap4xxx_clk_init(void) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] hwspinlock-next
* Greg KH g...@kroah.com [110921 07:27]: On Tue, Sep 20, 2011 at 04:13:40PM -0700, Tony Lindgren wrote: * Ohad Ben-Cohen o...@wizery.com [110920 01:34]: On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: I'm wondering how hwspinlock updates like this should go upstream. The first hwspinlock batch was picked by Tony, because it involved a bulk of OMAP changes. Hwspinlock isn't OMAP-specific anymore though (we gained support for STE's u8500) and the vast majority of changes are in drivers/. We're still very much ARM-related, though this may change too at some point (c6x has a similar hardware semaphore peripheral like the u8500 does). Tony, if you're still willing to pick up these updates I'd be happy to send you pull requests of course. I'd prefer for Greg to take these as these are drivers. What, am I the catch-all for drivers these days? Oh, right, it looks like I am :) If he's not taking it at this point based on it being ARM only, I can take it then. Please do, I don't even have the ability to build them here, as I don't have an arm cross-compiler on this travel laptop. OK so you're off the hook then :) Now we still need to sort out the remaining options posted by Arnd. 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 00/10] hwspinlock-next
* Arnd Bergmann a...@arndb.de [110921 06:39]: On Wednesday 21 September 2011, Tony Lindgren wrote: * Ohad Ben-Cohen o...@wizery.com [110920 01:34]: On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: I'm wondering how hwspinlock updates like this should go upstream. The first hwspinlock batch was picked by Tony, because it involved a bulk of OMAP changes. Hwspinlock isn't OMAP-specific anymore though (we gained support for STE's u8500) and the vast majority of changes are in drivers/. We're still very much ARM-related, though this may change too at some point (c6x has a similar hardware semaphore peripheral like the u8500 does). Tony, if you're still willing to pick up these updates I'd be happy to send you pull requests of course. I'd prefer for Greg to take these as these are drivers. If he's not taking it at this point based on it being ARM only, I can take it then. Sorry for replying late, I had accidentally ignored the entire thread. My feeling is that it would be best for Ohad to send these directly to Linus, since it's basically a standalone subsystem and he's listed as the maintainer (well, after this series at least). Ohad can you please try this first? Just please make sure your patches are first in next tree before sending in the pull request. I'm also fine with any of the other paths like ohad-GregKH-torvalds Greg does not prefer that as it's ARM only currently. ohad-arnd-torvalds ohad-tmlind-torvalds ohad-tmlind-arnd-torvalds So as a backup plan any of these are also fine with me too. 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 8/8] OMAP4: Fix the emif and dmm virtual mapping
On Tuesday 20 September 2011 08:31 PM, Santosh Shilimkar wrote: On Friday 16 September 2011 11:26 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: [...] #define OMAP44XX_EMIF2_SIZESZ_1M #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + SZ_1M) and '+ OMAP44XX_EMIF2_SIZE' here. Will add OMAP44XX_EMIF_SIZE since 2 EMIFs instaces are and suppose to be identical.Almost missed this email in other traffic. OPPs. It was already there. Dumb of me not using it. Below is the update what I will do. diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index d72ec85..db36292 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -228,13 +228,13 @@ #define OMAP44XX_EMIF2_PHYSOMAP44XX_EMIF2_BASE /* 0x4d00 -- 0xfd20 */ -#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_EMIF2_SIZESZ_1M +#define OMAP44XX_EMIF2_VIRT(OMAP44XX_EMIF1_VIRT + OMAP44XX_EMIF2_SIZE) #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_DMM_SIZE SZ_1M +#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + OMAP44XX_DMM_SIZE) /* * * Omap specific register access -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] hwspinlock-next
On Wed, Sep 21, 2011 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote: My feeling is that it would be best for Ohad to send these directly to Linus, since it's basically a standalone subsystem and he's listed as the maintainer (well, after this series at least). I agree. That's the path of least resistance and trouble. If/when ARM-specific driver subsystems need their own zuper-maintainer we can deal with it, can't we? There aren't many of them yet. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] hwspinlock-next
On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote: Ohad can you please try this first? Just please make sure your patches are first in next tree before sending in the pull request. Sure thing. Stephen, I'll send you the location of my tree in a few. Thanks, Ohad. -- 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 00/10] hwspinlock-next
On Wed, Sep 21, 2011 at 6:56 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote: Ohad can you please try this first? Just please make sure your patches are first in next tree before sending in the pull request. Sure thing. Stephen, I'll send you the location of my tree in a few. Just before I do, Tony can I please have your Ack for the mach-omap2 part of this patch-set: arch/arm/mach-omap2/hwspinlock.c |8 +- Thanks, Ohad. -- 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 04/10] hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
* Ohad Ben-Cohen o...@wizery.com [110912 09:14]: hwspinlock devices provide system-wide hardware locks that are used by remote processors that have no other way to achieve synchronization. For that to work, each physical lock must have a system-wide unique id number that all processors are familiar with, otherwise they can't possibly assume they're using the same hardware lock. Usually SoCs have a single hwspinlock device, which provides several hwspinlocks, and in this case, they can be trivially numbered 0 to (num-of-locks - 1). In case boards have several hwspinlocks devices (each of which providing numerous hardware spinlocks) a different base id should be used for each hwspinlock device (they can't all use 0 as a starting id!). While this is certainly not common, it's just plain wrong to just silently use 0 as a base id whenever the hwspinlock driver is probed. This patch provides a hwspinlock_pdata structure, that boards can use to set a different base id for each of the hwspinlock devices they may have, and demonstrates how to use it with the omap hwspinlock driver (ultimately it will be DT which will supply this base_id information). While we're at it, make sure the hwspinlock core prints an explicit error message in case an hwspinlock is registered with an id number that already exists; this will help users catch such base id issues. Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Ohad Ben-Cohen o...@wizery.com Acked-by: Tony Lindgren t...@atomide.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 00/10] hwspinlock-next
* Ohad Ben-Cohen o...@wizery.com [110921 08:34]: On Wed, Sep 21, 2011 at 6:56 PM, Ohad Ben-Cohen o...@wizery.com wrote: On Wed, Sep 21, 2011 at 6:28 PM, Tony Lindgren t...@atomide.com wrote: Ohad can you please try this first? Just please make sure your patches are first in next tree before sending in the pull request. Sure thing. Stephen, I'll send you the location of my tree in a few. Just before I do, Tony can I please have your Ack for the mach-omap2 part of this patch-set: arch/arm/mach-omap2/hwspinlock.c |8 +- OK acked the related patch. 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 3/8] OMAP2+: powerdomain: control power domains next state
When a PM QoS device latency constraint is requested or removed the PM QoS layer notifies the underlying layer with the updated aggregated constraint value. The constraint is stored in the powerdomain constraints list and then applied to the corresponding power domain. The power domains get the next power state programmed directly in the registers via pwrdm_wakeuplat_update_pwrst. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/powerdomain.c | 197 + arch/arm/mach-omap2/powerdomain.h | 35 ++- 2 files changed, 230 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 9af0847..8fc0aaa 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -17,8 +17,10 @@ #include linux/kernel.h #include linux/types.h #include linux/list.h +#include linux/slab.h #include linux/errno.h #include linux/string.h +#include linux/pm_qos.h #include trace/events/power.h #include cm2xxx_3xxx.h @@ -104,6 +106,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm) for (i = 0; i pwrdm-banks; i++) pwrdm-ret_mem_off_counter[i] = 0; + /* Initialize the per-od wake-up constraints data */ + spin_lock_init(pwrdm-wkup_lat_plist_lock); + plist_head_init(pwrdm-wkup_lat_plist_head); + pwrdm-wkup_lat_next_state = PWRDM_POWER_OFF; + + /* Initialize the pwrdm state */ pwrdm_wait_transition(pwrdm); pwrdm-state = pwrdm_read_pwrst(pwrdm); pwrdm-state_counter[pwrdm-state] = 1; @@ -191,6 +199,83 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) return 0; } +/** + * pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed + * @pwrdm: struct powerdomain * to which requesting device belongs to. + * @min_latency: the allowed wake-up latency for the given power domain. A + * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm. + * + * Finds the power domain next power state that fulfills the constraint. + * Programs a new target state if it is different from current power state. + * The power domains get the next power state programmed directly in the + * registers. + * + * Returns 0 upon success. + */ +static int pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm, + long min_latency) +{ + int ret = 0, new_state; + + if (!pwrdm) { + WARN(1, powerdomain: %s: invalid parameter(s), __func__); + return -EINVAL; + } + + /* +* Apply constraints to power domains by programming +* the pwrdm next power state. +*/ + + /* +* Find the next supported power state with +* wakeup latency minimum constraint +*/ + for (new_state = 0x0; new_state PWRDM_MAX_PWRSTS; new_state++) { + if (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE) + break; + if ((pwrdm-wakeup_lat[new_state] != UNSUP_STATE) + (pwrdm-wakeup_lat[new_state] = min_latency)) + break; + } + + switch (new_state) { + case PWRDM_FUNC_PWRST_OFF: + new_state = PWRDM_POWER_OFF; + break; + case PWRDM_FUNC_PWRST_OSWR: + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF); + new_state = PWRDM_POWER_RET; + break; + case PWRDM_FUNC_PWRST_CSWR: + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + new_state = PWRDM_POWER_RET; + break; + case PWRDM_FUNC_PWRST_INACTIVE: + new_state = PWRDM_POWER_INACTIVE; + break; + case PWRDM_FUNC_PWRST_ON: + new_state = PWRDM_POWER_ON; + break; + default: + pr_warn(powerdomain: requested latency constraint not + supported %s set to ON state\n, pwrdm-name); + new_state = PWRDM_POWER_ON; + break; + } + + pwrdm-wkup_lat_next_state = new_state; + if (pwrdm_read_next_pwrst(pwrdm) != new_state) + ret = omap_set_pwrdm_state(pwrdm, new_state); + + pr_debug(powerdomain: %s pwrst: curr=%d, prev=%d next=%d +min_latency=%ld, set_state=%d\n, pwrdm-name, +pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), +pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + return ret; +} + /* Public functions */ /** @@ -930,6 +1015,118 @@ int pwrdm_post_transition(void) return 0; } +/* + * pwrdm_set_wkup_lat_constraint - Set/update/remove a powerdomain wakeup + * latency constraint and apply it + * @pwrdm: struct powerdomain * which the constraint
[PATCH 4/8] OMAP2+: omap_hwmod: manage the wake-up latency constraints
Hwmod is queried from the OMAP_PM layer to manage the power domains wake-up latency constraints. Hwmod retrieves the correct power domain and if it exists it calls the corresponding power domain function. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 26 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++ 2 files changed, 27 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 84cc0bd..c6b1cc9 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -143,6 +143,7 @@ #include powerdomain.h #include plat/clock.h #include plat/omap_hwmod.h +#include plat/omap_device.h #include plat/prcm.h #include cm2xxx_3xxx.h @@ -2618,11 +2619,34 @@ ohsps_unlock: return ret; } +/* + * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint + * + * @oh: struct omap_hwmod* to which the target device belongs to. + * @cookie: identifier of the constraints list for @oh. + * @min_latency: the minimum allowed wake-up latency for @oh. + * + * Returns 0 upon success. + */ +int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, + void *cookie, long min_latency) +{ + struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh); + + if (!pwrdm) { + pr_err(%s: Error: could not find powerdomain + for %s\n, __func__, oh-name); + return -EINVAL; + } + + return pwrdm_set_wkup_lat_constraint(pwrdm, cookie, min_latency); +} + /** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * - * Query the powerdomain of of @oh to get the context loss + * Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 0e329ca..75e0e7a 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -603,6 +603,8 @@ int omap_hwmod_for_each_by_class(const char *classname, void *user); int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state); +int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, void *cookie, + long min_latency); u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh); int omap_hwmod_no_setup_reset(struct omap_hwmod *oh); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] OMAP3: update cpuidle latency and threshold figures
Update the data from the measurements performed at HW and SW levels. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. ToDo: - Measure the wake-up latencies for all power domains for OMAP3 - Correct some numbers when sys_clkreq and sys_offmode are supported Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 1b8e0da..4b3e994 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -44,20 +44,20 @@ * pass these details from the board file. */ static struct cpuidle_params cpuidle_params_table[] = { - /* C1 */ - {2 + 2, 5, 1}, - /* C2 */ - {10 + 10, 30, 1}, - /* C3 */ - {50 + 50, 300, 1}, - /* C4 */ - {1500 + 1800, 4000, 1}, - /* C5 */ - {2500 + 7500, 12000, 1}, - /* C6 */ - {3000 + 8500, 15000, 1}, - /* C7 */ - {1 + 3, 30, 1}, + /* C1 . MPU WFI + Core active */ + {73 + 78, 152, 1}, + /* C2 . MPU WFI + Core inactive */ + {165 + 88, 345, 1}, + /* C3 . MPU CSWR + Core inactive */ + {163 + 182, 345, 1}, + /* C4 . MPU OFF + Core inactive */ + {2852 + 605, 15, 1}, + /* C5 . MPU RET + Core RET */ + {800 + 366, 2120, 1}, + /* C6 . MPU OFF + Core RET */ + {4080 + 801, 215000, 1}, + /* C7 . MPU OFF + Core OFF */ + {4300 + 13000, 215000, 1}, }; #define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
Figures are added to the power domains structs for RET and OFF modes. Note: the latency figures for MPU, PER, CORE, NEON have been obtained from actual measurements. The latency figures for the other power domains are preliminary and shall be added. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/powerdomains3xxx_data.c | 78 +++ 1 files changed, 78 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c b/arch/arm/mach-omap2/powerdomains3xxx_data.c index 469a920..32922bb 100644 --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c @@ -31,6 +31,14 @@ /* * Powerdomains + * + * The wakeup_lat values are derived from measurements on + * the actual target. + * + * Note: the latency figures for MPU, PER, CORE, NEON have been obtained + * from actual measurements. + * The latency figures for the other power domains are preliminary and + * shall be added. */ static struct powerdomain iva2_pwrdm = { @@ -52,6 +60,13 @@ static struct powerdomain iva2_pwrdm = { [2] = PWRSTS_OFF_ON, [3] = PWRSTS_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 350, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain mpu_3xxx_pwrdm = { @@ -68,6 +83,13 @@ static struct powerdomain mpu_3xxx_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_OFF_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1830, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 121, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; /* @@ -98,6 +120,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 3082, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 153, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain core_3xxx_es3_1_pwrdm = { @@ -121,6 +150,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 3082, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 153, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain dss_pwrdm = { @@ -136,6 +172,13 @@ static struct powerdomain dss_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 70, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 20, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; /* @@ -157,6 +200,13 @@ static struct powerdomain sgx_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1000, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain cam_pwrdm = { @@ -172,6 +222,13 @@ static struct powerdomain cam_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 850, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain per_pwrdm = { @@ -187,6 +244,13 @@ static struct powerdomain per_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 671, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, +
Re: [PATCH 00/10] hwspinlock-next
On Wed, Sep 21, 2011 at 7:14 PM, Tony Lindgren t...@atomide.com wrote: OK acked the related patch. Thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] PM QoS: implement the OMAP low level constraints management code
. Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints . Remove the remove the latency related functions from OMAP PM in favor of the generic per-device PM QoS API . Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . Implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . Add cpuidle and power domains wake-up latency figures for OMAP3, cf. [1] for the details on where the numbers are coming from . Implement the relation between the cpuidle and per-device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the state programmed by the per-device PM QoS. ToDo: 1. validate the constraints framework on OMAP4 HW (done on OMAP3) 2. Re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost 3. Further clean-up the OMAP PM layer, use the generic frameworks instead (OPP, PM QoS...) Based on the pm-qos branch of the linux-pm git tree (3.1.0-rc3), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement [2] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Jean Pihet (8): OMAP: convert I2C driver to PM QoS for latency constraints OMAP: PM: remove the latency related functions from the API OMAP2+: powerdomain: control power domains next state OMAP2+: omap_hwmod: manage the wake-up latency constraints OMAP: PM: register to the per-device PM QoS framework OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints OMAP3: update cpuidle latency and threshold figures OMAP3: powerdomain data: add wake-up latency figures Documentation/arm/OMAP/omap_pm | 55 ++-- arch/arm/mach-omap2/cpuidle34xx.c| 77 ++- arch/arm/mach-omap2/omap_hwmod.c | 26 - arch/arm/mach-omap2/pm.c | 63 arch/arm/mach-omap2/pm.h | 17 ++- arch/arm/mach-omap2/powerdomain.c| 197 ++ arch/arm/mach-omap2/powerdomain.h| 35 +- arch/arm/mach-omap2/powerdomains3xxx_data.c | 78 ++ arch/arm/plat-omap/i2c.c | 20 --- arch/arm/plat-omap/include/plat/omap-pm.h| 99 - arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + arch/arm/plat-omap/omap-pm-noop.c| 88 drivers/i2c/busses/i2c-omap.c| 30 ++-- include/linux/i2c-omap.h |1 - 14 files changed, 480 insertions(+), 308 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] OMAP: PM: remove the latency related functions from the API
Remove the following functions from the API: omap_pm_set_max_mpu_wakeup_lat omap_pm_set_max_dev_wakeup_lat omap_pm_set_max_sdma_lat The generic per-device PM QoS functions shall be used instead, cf. include/linux/pm_qos.h. Signed-off-by: Jean Pihet j-pi...@ti.com --- Documentation/arm/OMAP/omap_pm| 55 +++- arch/arm/plat-omap/include/plat/omap-pm.h | 99 - arch/arm/plat-omap/omap-pm-noop.c | 88 - 3 files changed, 9 insertions(+), 233 deletions(-) diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm index 9012bb0..26f9669 100644 --- a/Documentation/arm/OMAP/omap_pm +++ b/Documentation/arm/OMAP/omap_pm @@ -29,21 +29,12 @@ Drivers need to express PM parameters which: This document proposes the OMAP PM interface, including the following -five power management functions for driver code: +power management functions for driver code: -1. Set the maximum MPU wakeup latency: - (*pdata-set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) - -2. Set the maximum device wakeup latency: - (*pdata-set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) - -3. Set the maximum system DMA transfer start latency (CORE pwrdm): - (*pdata-set_max_sdma_lat)(struct device *dev, long t) - -4. Set the minimum bus throughput needed by a device: +1. Set the minimum bus throughput needed by a device: (*pdata-set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) -5. Return the number of times the device has lost context +2. Return the number of times the device has lost context (*pdata-get_dev_context_loss_count)(struct device *dev) @@ -55,10 +46,12 @@ The OMAP PM layer is intended to be temporary - The intention is that eventually the Linux PM QoS layer should support -the range of power management features present in OMAP3. As this +the range of power management features present in OMAP3. As this happens, existing drivers using the OMAP PM interface can be modified to use the Linux PM QoS code; and the OMAP PM interface can disappear. +The set_min_bus_tput function shall be converted to a throughput PM QoS +framework. Driver usage of the OMAP PM functions - @@ -66,39 +59,9 @@ Driver usage of the OMAP PM functions As the 'pdata' in the above examples indicates, these functions are exposed to drivers through function pointers in driver .platform_data structures. The function pointers are initialized by the board-*.c -files to point to the corresponding OMAP PM functions: -.set_max_dev_wakeup_lat will point to -omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do -not support these functions should leave these function pointers set -to NULL. Drivers should use the following idiom: - -if (pdata-set_max_dev_wakeup_lat) -(*pdata-set_max_dev_wakeup_lat)(dev, t); - -The most common usage of these functions will probably be to specify -the maximum time from when an interrupt occurs, to when the device -becomes accessible. To accomplish this, driver writers should use the -set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup -latency, and the set_max_dev_wakeup_lat() function to constrain the -device wakeup latency (from clk_enable() to accessibility). For -example, - -/* Limit MPU wakeup latency */ -if (pdata-set_max_mpu_wakeup_lat) -(*pdata-set_max_mpu_wakeup_lat)(dev, tc); - -/* Limit device powerdomain wakeup latency */ -if (pdata-set_max_dev_wakeup_lat) -(*pdata-set_max_dev_wakeup_lat)(dev, td); - -/* total wakeup latency in this example: (tc + td) */ - -The PM parameters can be overwritten by calling the function again -with the new value. The settings can be removed by calling the -function with a t argument of -1 (except in the case of -set_max_bus_tput(), which should be called with an r argument of 0). - -The fifth function above, omap_pm_get_dev_context_loss_count(), +files to point to the corresponding OMAP PM functions. + +The omap_pm_get_dev_context_loss_count() function is intended as an optimization to allow drivers to determine whether the device has lost its internal context. If context has been lost, the driver must restore its internal context before proceeding. diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h index 0840df8..c371364 100644 --- a/arch/arm/plat-omap/include/plat/omap-pm.h +++ b/arch/arm/plat-omap/include/plat/omap-pm.h @@ -62,44 +62,6 @@ void omap_pm_if_exit(void); * Device-driver-originated constraints (via board-*.c files, platform_data) */ - -/** - * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency - * @dev: struct device * requesting the constraint - * @t: maximum MPU wakeup latency in microseconds - * - * Request that the maximum interrupt
[PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints
Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. The I2C device latency timing is derived from the FIFO size and the clock speed and so is applicable to all OMAP SoCs. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/plat-omap/i2c.c | 20 drivers/i2c/busses/i2c-omap.c | 30 +++--- include/linux/i2c-omap.h |1 - 3 files changed, 15 insertions(+), 36 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 3341ca4..e1e2502 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -34,7 +34,6 @@ #include mach/irqs.h #include plat/mux.h #include plat/i2c.h -#include plat/omap-pm.h #include plat/omap_device.h #define OMAP_I2C_SIZE 0x3f @@ -113,16 +112,6 @@ static inline int omap1_i2c_add_bus(int bus_id) #ifdef CONFIG_ARCH_OMAP2PLUS -/* - * XXX This function is a temporary compatibility wrapper - only - * needed until the I2C driver can be converted to call - * omap_pm_set_max_dev_wakeup_lat() and handle a return code. - */ -static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t) -{ - omap_pm_set_max_mpu_wakeup_lat(dev, t); -} - static struct omap_device_pm_latency omap_i2c_latency[] = { [0] = { .deactivate_func= omap_device_idle_hwmods, @@ -151,15 +140,6 @@ static inline int omap2_i2c_add_bus(int bus_id) } pdata = i2c_pdata[bus_id - 1]; - /* -* When waiting for completion of a i2c transfer, we need to -* set a wake up latency constraint for the MPU. This is to -* ensure quick enough wakeup from idle, when transfer -* completes. -* Only omap3 has support for constraints -*/ - if (cpu_is_omap34xx()) - pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat; od = omap_device_build(name, bus_id, oh, pdata, sizeof(struct omap_i2c_bus_platform_data), omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0); diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 1a766cf..95e5205 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -40,6 +40,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pm_qos.h /* I2C controller revisions */ #define OMAP_I2C_REV_2 0x20 @@ -179,8 +180,7 @@ struct omap_i2c_dev { struct completion cmd_complete; struct resource *ioarea; u32 latency;/* maximum mpu wkup latency */ - void(*set_mpu_wkup_lat)(struct device *dev, - long latency); + struct pm_qos_request pm_qos_request; u32 speed; /* Speed of bus in Khz */ u16 cmd_err; u8 *buf; @@ -648,8 +648,14 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (r 0) goto out; - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, dev-latency); + /* +* When waiting for completion of a i2c transfer, we need to +* set a wake up latency constraint for the MPU. This is to +* ensure quick enough wakeup from idle, when transfer +* completes. +*/ + pm_qos_add_request(dev-pm_qos_request, PM_QOS_CPU_DMA_LATENCY, + dev-latency); for (i = 0; i num; i++) { r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1))); @@ -657,8 +663,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, -1); + pm_qos_remove_request(dev-pm_qos_request); if (r == 0) r = num; @@ -1007,13 +1012,10 @@ omap_i2c_probe(struct platform_device *pdev) goto err_release_region; } - if (pdata != NULL) { + if (pdata != NULL) speed = pdata-clkrate; - dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat; - } else { + else speed = 100;/* Default speed */ - dev-set_mpu_wkup_lat = NULL; - } dev-speed = speed; dev-idle = 1; @@ -1066,10 +1068,8 @@ omap_i2c_probe(struct platform_device *pdev) dev-fifo_size = (dev-fifo_size / 2); dev-b_hw = 1; /* Enable hardware fixes */ } - /* calculate wakeup latency
Re: [PATCH 00/10] hwspinlock-next
On Wednesday 21 September 2011, Linus Walleij wrote: On Wed, Sep 21, 2011 at 4:12 PM, Arnd Bergmann a...@arndb.de wrote: My feeling is that it would be best for Ohad to send these directly to Linus, since it's basically a standalone subsystem and he's listed as the maintainer (well, after this series at least). I agree. That's the path of least resistance and trouble. If/when ARM-specific driver subsystems need their own zuper-maintainer we can deal with it, can't we? There aren't many of them yet. Definitely, I think that's the ideal case. I would very much like to see independent subsystem maintainers for the device drivers that are currently buried in per-architecture or per-platform directories. Among the ones that we should be moving out of there (or have already) are cpufreq, gpio, irqchip, pinmux, clock, dmaengine, timer, and there are probably some more. Since none of these are strictly ARM specific, my feeling is that they should not be part of the arm or arm-soc tree in the future but have their own trees. Arnd -- 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/8] OMAP: PM: register to the per-device PM QoS framework
Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm.c | 63 ++ 1 files changed, 63 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 3feb359..58b4b76 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -11,13 +11,16 @@ #include linux/kernel.h #include linux/init.h +#include linux/notifier.h #include linux/io.h #include linux/err.h #include linux/opp.h +#include linux/pm_qos.h #include plat/omap-pm.h #include plat/omap_device.h #include plat/common.h +#include plat/omap_hwmod.h #include voltage.h #include powerdomain.h @@ -242,11 +245,71 @@ static void __init omap4_init_voltages(void) omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva_dev); } +/* Interface to the per-device PM QoS framework */ +static int omap2_dev_pm_qos_handler(struct notifier_block *nb, + unsigned long new_value, + void *req) +{ + struct omap_device *od; + struct omap_hwmod *oh; + struct platform_device *pdev; + struct dev_pm_qos_request *dev_pm_qos_req = req; + + pr_debug(OMAP PM CONSTRAINTS: req@0x%p, new_value=%lu\n, +req, new_value); + + /* Look for the platform device for the constraint target device */ + pdev = to_platform_device(dev_pm_qos_req-dev); + + /* Try to catch non platform devices */ + if (pdev-name == NULL) { + pr_err(%s: Error: platform device for device %s not valid\n, + __func__, dev_name(dev_pm_qos_req-dev)); + return -EINVAL; + } + + /* Find the associated omap_device for dev */ + od = container_of(pdev, struct omap_device, pdev); + if (od-hwmods_cnt != 1) { + pr_err(%s: Error: No unique hwmod for device %s\n, + __func__, dev_name(dev_pm_qos_req-dev)); + return -EINVAL; + } + + /* Find the primary omap_hwmod for dev */ + oh = od-hwmods[0]; + + pr_debug(OMAP PM CONSTRAINTS: req@0x%p, dev=0x%p, new_value=%lu\n, +req, dev_pm_qos_req-dev, new_value); + + /* Apply the constraint */ + return omap_hwmod_set_wkup_lat_constraint(oh, dev_pm_qos_req, + new_value); +} + +static struct notifier_block omap2_dev_pm_qos_notifier = { + .notifier_call = omap2_dev_pm_qos_handler, +}; + +static int __init omap2_dev_pm_qos_init(void) +{ + int ret; + + ret = dev_pm_qos_add_global_notifier(omap2_dev_pm_qos_notifier); + if (ret) + WARN(1, KERN_ERR Cannot add global notifier for dev PM QoS\n); + + return ret; +} + static int __init omap2_common_pm_init(void) { omap2_init_processor_devices(); omap_pm_if_init(); + /* Register to the per-device PM QoS framework */ + omap2_dev_pm_qos_init(); + return 0; } postcore_initcall(omap2_common_pm_init); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
The MPU latency figures for cpuidle include the MPU itself and also the peripherals needed for the MPU to execute instructions (e.g. main memory, caches, IRQ controller, MMU etc). On OMAP3 those peripherals belong to the MPU and CORE power domains and so the cpuidle C-states are a combination of MPU and CORE states. This patch implements the relation between the cpuidle and per- device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the next state calculated by the per-device PM QoS. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c | 49 ++--- arch/arm/mach-omap2/pm.h | 17 +++- 2 files changed, 44 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 4bf6e6e..1b8e0da 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -37,7 +37,7 @@ #ifdef CONFIG_CPU_IDLE /* - * The latencies/thresholds for various C states have + * The MPU latencies/thresholds for various C states have * to be configured from the respective board files. * These are some default values (which might not provide * the best power savings) used on boards which do not @@ -72,14 +72,14 @@ struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES]; struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd; static int _cpuidle_allow_idle(struct powerdomain *pwrdm, - struct clockdomain *clkdm) + struct clockdomain *clkdm) { clkdm_allow_idle(clkdm); return 0; } static int _cpuidle_deny_idle(struct powerdomain *pwrdm, - struct clockdomain *clkdm) + struct clockdomain *clkdm) { clkdm_deny_idle(clkdm); return 0; @@ -92,9 +92,13 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm, * * Called from the CPUidle framework to program the device to the * specified target state selected by the governor. + * + * Note: this function does not check for any pending activity or dependency + * between power domains states, so the caller shall check the parameters + * correctness. */ static int omap3_enter_idle(struct cpuidle_device *dev, - struct cpuidle_state *state) + struct cpuidle_state *state) { struct omap3_idle_statedata *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; @@ -146,8 +150,11 @@ return_sleep_time: * Else, this function searches for a lower c-state which is still * valid. * - * A state is valid if the 'valid' field is enabled and - * if it satisfies the enable_off_mode condition. + * A state is valid if: + * . the 'valid' field is enabled, + * . it satisfies the enable_off_mode flag, + * . the next state for MPU and CORE power domains is not lower than the + * state programmed by the per-device PM QoS. */ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, struct cpuidle_state *curr) @@ -156,6 +163,8 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr); u32 mpu_deepest_state = PWRDM_POWER_RET; u32 core_deepest_state = PWRDM_POWER_RET; + u32 mpu_pm_qos_next_state = mpu_pd-wkup_lat_next_state; + u32 core_pm_qos_next_state = core_pd-wkup_lat_next_state; if (enable_off_mode) { mpu_deepest_state = PWRDM_POWER_OFF; @@ -171,7 +180,9 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, /* Check if current state is valid */ if ((cx-valid) (cx-mpu_state = mpu_deepest_state) - (cx-core_state = core_deepest_state)) { + (cx-core_state = core_deepest_state) + (cx-mpu_state = mpu_pm_qos_next_state) + (cx-core_state = core_pm_qos_next_state)) { return curr; } else { int idx = OMAP3_NUM_STATES - 1; @@ -196,7 +207,9 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, cx = cpuidle_get_statedata(dev-states[idx]); if ((cx-valid) (cx-mpu_state = mpu_deepest_state) - (cx-core_state = core_deepest_state)) { + (cx-core_state = core_deepest_state) + (cx-mpu_state = mpu_pm_qos_next_state) + (cx-core_state = core_pm_qos_next_state)) {
[PATCH v2 0/8] PM QoS: implement the OMAP low level constraints management code
From: Jean Pihet j-pi...@ti.com . Convert the OMAP I2C driver to the PM QoS API for MPU latency constraints . Remove the remove the latency related functions from OMAP PM in favor of the generic per-device PM QoS API . Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer . Implement the low level code which controls the power domains next power states, through the hwmod and pwrdm layers . Add cpuidle and power domains wake-up latency figures for OMAP3, cf. [1] for the details on where the numbers are coming from . Implement the relation between the cpuidle and per-device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the state programmed by the per-device PM QoS. ToDo: 1. validate the constraints framework on OMAP4 HW (done on OMAP3) 2. Re-visit the OMAP power domains states initialization procedure. Currently the power states that have been changed from the constraints API which were applied before the initialization of the power domains are lost 3. Further clean-up the OMAP PM layer, use the generic frameworks instead (OPP, PM QoS...) Based on the pm-qos branch of the linux-pm git tree (3.1.0-rc3), cf. [2]. Tested on OMAP3 Beagleboard (ES2.x) with constraints on MPU, CORE, PER in RETention and OFF modes. [1] http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement [2] git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Jean Pihet (8): OMAP: convert I2C driver to PM QoS for latency constraints OMAP: PM: remove the latency related functions from the API OMAP2+: powerdomain: control power domains next state OMAP2+: omap_hwmod: manage the wake-up latency constraints OMAP: PM: register to the per-device PM QoS framework OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints OMAP3: update cpuidle latency and threshold figures OMAP3: powerdomain data: add wake-up latency figures Documentation/arm/OMAP/omap_pm | 55 ++-- arch/arm/mach-omap2/cpuidle34xx.c| 77 ++- arch/arm/mach-omap2/omap_hwmod.c | 26 - arch/arm/mach-omap2/pm.c | 63 arch/arm/mach-omap2/pm.h | 17 ++- arch/arm/mach-omap2/powerdomain.c| 197 ++ arch/arm/mach-omap2/powerdomain.h| 35 +- arch/arm/mach-omap2/powerdomains3xxx_data.c | 78 ++ arch/arm/plat-omap/i2c.c | 20 --- arch/arm/plat-omap/include/plat/omap-pm.h| 99 - arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + arch/arm/plat-omap/omap-pm-noop.c| 88 drivers/i2c/busses/i2c-omap.c| 30 ++-- include/linux/i2c-omap.h |1 - 14 files changed, 480 insertions(+), 308 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints
From: Jean Pihet j-pi...@ti.com Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. The I2C device latency timing is derived from the FIFO size and the clock speed and so is applicable to all OMAP SoCs. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/plat-omap/i2c.c | 20 drivers/i2c/busses/i2c-omap.c | 30 +++--- include/linux/i2c-omap.h |1 - 3 files changed, 15 insertions(+), 36 deletions(-) diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 3341ca4..e1e2502 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -34,7 +34,6 @@ #include mach/irqs.h #include plat/mux.h #include plat/i2c.h -#include plat/omap-pm.h #include plat/omap_device.h #define OMAP_I2C_SIZE 0x3f @@ -113,16 +112,6 @@ static inline int omap1_i2c_add_bus(int bus_id) #ifdef CONFIG_ARCH_OMAP2PLUS -/* - * XXX This function is a temporary compatibility wrapper - only - * needed until the I2C driver can be converted to call - * omap_pm_set_max_dev_wakeup_lat() and handle a return code. - */ -static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t) -{ - omap_pm_set_max_mpu_wakeup_lat(dev, t); -} - static struct omap_device_pm_latency omap_i2c_latency[] = { [0] = { .deactivate_func= omap_device_idle_hwmods, @@ -151,15 +140,6 @@ static inline int omap2_i2c_add_bus(int bus_id) } pdata = i2c_pdata[bus_id - 1]; - /* -* When waiting for completion of a i2c transfer, we need to -* set a wake up latency constraint for the MPU. This is to -* ensure quick enough wakeup from idle, when transfer -* completes. -* Only omap3 has support for constraints -*/ - if (cpu_is_omap34xx()) - pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat; od = omap_device_build(name, bus_id, oh, pdata, sizeof(struct omap_i2c_bus_platform_data), omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0); diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 1a766cf..95e5205 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -40,6 +40,7 @@ #include linux/slab.h #include linux/i2c-omap.h #include linux/pm_runtime.h +#include linux/pm_qos.h /* I2C controller revisions */ #define OMAP_I2C_REV_2 0x20 @@ -179,8 +180,7 @@ struct omap_i2c_dev { struct completion cmd_complete; struct resource *ioarea; u32 latency;/* maximum mpu wkup latency */ - void(*set_mpu_wkup_lat)(struct device *dev, - long latency); + struct pm_qos_request pm_qos_request; u32 speed; /* Speed of bus in Khz */ u16 cmd_err; u8 *buf; @@ -648,8 +648,14 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) if (r 0) goto out; - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, dev-latency); + /* +* When waiting for completion of a i2c transfer, we need to +* set a wake up latency constraint for the MPU. This is to +* ensure quick enough wakeup from idle, when transfer +* completes. +*/ + pm_qos_add_request(dev-pm_qos_request, PM_QOS_CPU_DMA_LATENCY, + dev-latency); for (i = 0; i num; i++) { r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1))); @@ -657,8 +663,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev-set_mpu_wkup_lat != NULL) - dev-set_mpu_wkup_lat(dev-dev, -1); + pm_qos_remove_request(dev-pm_qos_request); if (r == 0) r = num; @@ -1007,13 +1012,10 @@ omap_i2c_probe(struct platform_device *pdev) goto err_release_region; } - if (pdata != NULL) { + if (pdata != NULL) speed = pdata-clkrate; - dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat; - } else { + else speed = 100;/* Default speed */ - dev-set_mpu_wkup_lat = NULL; - } dev-speed = speed; dev-idle = 1; @@ -1066,10 +1068,8 @@ omap_i2c_probe(struct platform_device *pdev) dev-fifo_size = (dev-fifo_size / 2); dev-b_hw = 1; /* Enable hardware fixes */ } -
[PATCH 2/8] OMAP: PM: remove the latency related functions from the API
From: Jean Pihet j-pi...@ti.com Remove the following functions from the API: omap_pm_set_max_mpu_wakeup_lat omap_pm_set_max_dev_wakeup_lat omap_pm_set_max_sdma_lat The generic per-device PM QoS functions shall be used instead, cf. include/linux/pm_qos.h. Signed-off-by: Jean Pihet j-pi...@ti.com --- Documentation/arm/OMAP/omap_pm| 55 +++- arch/arm/plat-omap/include/plat/omap-pm.h | 99 - arch/arm/plat-omap/omap-pm-noop.c | 88 - 3 files changed, 9 insertions(+), 233 deletions(-) diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm index 9012bb0..26f9669 100644 --- a/Documentation/arm/OMAP/omap_pm +++ b/Documentation/arm/OMAP/omap_pm @@ -29,21 +29,12 @@ Drivers need to express PM parameters which: This document proposes the OMAP PM interface, including the following -five power management functions for driver code: +power management functions for driver code: -1. Set the maximum MPU wakeup latency: - (*pdata-set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) - -2. Set the maximum device wakeup latency: - (*pdata-set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) - -3. Set the maximum system DMA transfer start latency (CORE pwrdm): - (*pdata-set_max_sdma_lat)(struct device *dev, long t) - -4. Set the minimum bus throughput needed by a device: +1. Set the minimum bus throughput needed by a device: (*pdata-set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) -5. Return the number of times the device has lost context +2. Return the number of times the device has lost context (*pdata-get_dev_context_loss_count)(struct device *dev) @@ -55,10 +46,12 @@ The OMAP PM layer is intended to be temporary - The intention is that eventually the Linux PM QoS layer should support -the range of power management features present in OMAP3. As this +the range of power management features present in OMAP3. As this happens, existing drivers using the OMAP PM interface can be modified to use the Linux PM QoS code; and the OMAP PM interface can disappear. +The set_min_bus_tput function shall be converted to a throughput PM QoS +framework. Driver usage of the OMAP PM functions - @@ -66,39 +59,9 @@ Driver usage of the OMAP PM functions As the 'pdata' in the above examples indicates, these functions are exposed to drivers through function pointers in driver .platform_data structures. The function pointers are initialized by the board-*.c -files to point to the corresponding OMAP PM functions: -.set_max_dev_wakeup_lat will point to -omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do -not support these functions should leave these function pointers set -to NULL. Drivers should use the following idiom: - -if (pdata-set_max_dev_wakeup_lat) -(*pdata-set_max_dev_wakeup_lat)(dev, t); - -The most common usage of these functions will probably be to specify -the maximum time from when an interrupt occurs, to when the device -becomes accessible. To accomplish this, driver writers should use the -set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup -latency, and the set_max_dev_wakeup_lat() function to constrain the -device wakeup latency (from clk_enable() to accessibility). For -example, - -/* Limit MPU wakeup latency */ -if (pdata-set_max_mpu_wakeup_lat) -(*pdata-set_max_mpu_wakeup_lat)(dev, tc); - -/* Limit device powerdomain wakeup latency */ -if (pdata-set_max_dev_wakeup_lat) -(*pdata-set_max_dev_wakeup_lat)(dev, td); - -/* total wakeup latency in this example: (tc + td) */ - -The PM parameters can be overwritten by calling the function again -with the new value. The settings can be removed by calling the -function with a t argument of -1 (except in the case of -set_max_bus_tput(), which should be called with an r argument of 0). - -The fifth function above, omap_pm_get_dev_context_loss_count(), +files to point to the corresponding OMAP PM functions. + +The omap_pm_get_dev_context_loss_count() function is intended as an optimization to allow drivers to determine whether the device has lost its internal context. If context has been lost, the driver must restore its internal context before proceeding. diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h b/arch/arm/plat-omap/include/plat/omap-pm.h index 0840df8..c371364 100644 --- a/arch/arm/plat-omap/include/plat/omap-pm.h +++ b/arch/arm/plat-omap/include/plat/omap-pm.h @@ -62,44 +62,6 @@ void omap_pm_if_exit(void); * Device-driver-originated constraints (via board-*.c files, platform_data) */ - -/** - * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency - * @dev: struct device * requesting the constraint - * @t: maximum MPU wakeup latency in microseconds - * - * Request
[PATCH 3/8] OMAP2+: powerdomain: control power domains next state
From: Jean Pihet j-pi...@ti.com When a PM QoS device latency constraint is requested or removed the PM QoS layer notifies the underlying layer with the updated aggregated constraint value. The constraint is stored in the powerdomain constraints list and then applied to the corresponding power domain. The power domains get the next power state programmed directly in the registers via pwrdm_wakeuplat_update_pwrst. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/powerdomain.c | 197 + arch/arm/mach-omap2/powerdomain.h | 35 ++- 2 files changed, 230 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 9af0847..8fc0aaa 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -17,8 +17,10 @@ #include linux/kernel.h #include linux/types.h #include linux/list.h +#include linux/slab.h #include linux/errno.h #include linux/string.h +#include linux/pm_qos.h #include trace/events/power.h #include cm2xxx_3xxx.h @@ -104,6 +106,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm) for (i = 0; i pwrdm-banks; i++) pwrdm-ret_mem_off_counter[i] = 0; + /* Initialize the per-od wake-up constraints data */ + spin_lock_init(pwrdm-wkup_lat_plist_lock); + plist_head_init(pwrdm-wkup_lat_plist_head); + pwrdm-wkup_lat_next_state = PWRDM_POWER_OFF; + + /* Initialize the pwrdm state */ pwrdm_wait_transition(pwrdm); pwrdm-state = pwrdm_read_pwrst(pwrdm); pwrdm-state_counter[pwrdm-state] = 1; @@ -191,6 +199,83 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) return 0; } +/** + * pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed + * @pwrdm: struct powerdomain * to which requesting device belongs to. + * @min_latency: the allowed wake-up latency for the given power domain. A + * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm. + * + * Finds the power domain next power state that fulfills the constraint. + * Programs a new target state if it is different from current power state. + * The power domains get the next power state programmed directly in the + * registers. + * + * Returns 0 upon success. + */ +static int pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm, + long min_latency) +{ + int ret = 0, new_state; + + if (!pwrdm) { + WARN(1, powerdomain: %s: invalid parameter(s), __func__); + return -EINVAL; + } + + /* +* Apply constraints to power domains by programming +* the pwrdm next power state. +*/ + + /* +* Find the next supported power state with +* wakeup latency minimum constraint +*/ + for (new_state = 0x0; new_state PWRDM_MAX_PWRSTS; new_state++) { + if (min_latency == PM_QOS_DEV_LAT_DEFAULT_VALUE) + break; + if ((pwrdm-wakeup_lat[new_state] != UNSUP_STATE) + (pwrdm-wakeup_lat[new_state] = min_latency)) + break; + } + + switch (new_state) { + case PWRDM_FUNC_PWRST_OFF: + new_state = PWRDM_POWER_OFF; + break; + case PWRDM_FUNC_PWRST_OSWR: + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF); + new_state = PWRDM_POWER_RET; + break; + case PWRDM_FUNC_PWRST_CSWR: + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + new_state = PWRDM_POWER_RET; + break; + case PWRDM_FUNC_PWRST_INACTIVE: + new_state = PWRDM_POWER_INACTIVE; + break; + case PWRDM_FUNC_PWRST_ON: + new_state = PWRDM_POWER_ON; + break; + default: + pr_warn(powerdomain: requested latency constraint not + supported %s set to ON state\n, pwrdm-name); + new_state = PWRDM_POWER_ON; + break; + } + + pwrdm-wkup_lat_next_state = new_state; + if (pwrdm_read_next_pwrst(pwrdm) != new_state) + ret = omap_set_pwrdm_state(pwrdm, new_state); + + pr_debug(powerdomain: %s pwrst: curr=%d, prev=%d next=%d +min_latency=%ld, set_state=%d\n, pwrdm-name, +pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), +pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + return ret; +} + /* Public functions */ /** @@ -930,6 +1015,118 @@ int pwrdm_post_transition(void) return 0; } +/* + * pwrdm_set_wkup_lat_constraint - Set/update/remove a powerdomain wakeup + * latency constraint and apply it + * @pwrdm: struct
[PATCH 6/8] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
From: Jean Pihet j-pi...@ti.com The MPU latency figures for cpuidle include the MPU itself and also the peripherals needed for the MPU to execute instructions (e.g. main memory, caches, IRQ controller, MMU etc). On OMAP3 those peripherals belong to the MPU and CORE power domains and so the cpuidle C-states are a combination of MPU and CORE states. This patch implements the relation between the cpuidle and per- device PM QoS frameworks in the OMAP3 specific idle callbacks. The chosen C-state shall satisfy the following conditions: . the 'valid' field is enabled, . it satisfies the enable_off_mode flag, . the next state for MPU and CORE power domains is not lower than the next state calculated by the per-device PM QoS. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c | 49 ++--- arch/arm/mach-omap2/pm.h | 17 +++- 2 files changed, 44 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 4bf6e6e..1b8e0da 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -37,7 +37,7 @@ #ifdef CONFIG_CPU_IDLE /* - * The latencies/thresholds for various C states have + * The MPU latencies/thresholds for various C states have * to be configured from the respective board files. * These are some default values (which might not provide * the best power savings) used on boards which do not @@ -72,14 +72,14 @@ struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES]; struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd; static int _cpuidle_allow_idle(struct powerdomain *pwrdm, - struct clockdomain *clkdm) + struct clockdomain *clkdm) { clkdm_allow_idle(clkdm); return 0; } static int _cpuidle_deny_idle(struct powerdomain *pwrdm, - struct clockdomain *clkdm) + struct clockdomain *clkdm) { clkdm_deny_idle(clkdm); return 0; @@ -92,9 +92,13 @@ static int _cpuidle_deny_idle(struct powerdomain *pwrdm, * * Called from the CPUidle framework to program the device to the * specified target state selected by the governor. + * + * Note: this function does not check for any pending activity or dependency + * between power domains states, so the caller shall check the parameters + * correctness. */ static int omap3_enter_idle(struct cpuidle_device *dev, - struct cpuidle_state *state) + struct cpuidle_state *state) { struct omap3_idle_statedata *cx = cpuidle_get_statedata(state); struct timespec ts_preidle, ts_postidle, ts_idle; @@ -146,8 +150,11 @@ return_sleep_time: * Else, this function searches for a lower c-state which is still * valid. * - * A state is valid if the 'valid' field is enabled and - * if it satisfies the enable_off_mode condition. + * A state is valid if: + * . the 'valid' field is enabled, + * . it satisfies the enable_off_mode flag, + * . the next state for MPU and CORE power domains is not lower than the + * state programmed by the per-device PM QoS. */ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, struct cpuidle_state *curr) @@ -156,6 +163,8 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr); u32 mpu_deepest_state = PWRDM_POWER_RET; u32 core_deepest_state = PWRDM_POWER_RET; + u32 mpu_pm_qos_next_state = mpu_pd-wkup_lat_next_state; + u32 core_pm_qos_next_state = core_pd-wkup_lat_next_state; if (enable_off_mode) { mpu_deepest_state = PWRDM_POWER_OFF; @@ -171,7 +180,9 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, /* Check if current state is valid */ if ((cx-valid) (cx-mpu_state = mpu_deepest_state) - (cx-core_state = core_deepest_state)) { + (cx-core_state = core_deepest_state) + (cx-mpu_state = mpu_pm_qos_next_state) + (cx-core_state = core_pm_qos_next_state)) { return curr; } else { int idx = OMAP3_NUM_STATES - 1; @@ -196,7 +207,9 @@ static struct cpuidle_state *next_valid_state(struct cpuidle_device *dev, cx = cpuidle_get_statedata(dev-states[idx]); if ((cx-valid) (cx-mpu_state = mpu_deepest_state) - (cx-core_state = core_deepest_state)) { + (cx-core_state = core_deepest_state) + (cx-mpu_state = mpu_pm_qos_next_state) +
[PATCH 7/8] OMAP3: update cpuidle latency and threshold figures
From: Jean Pihet j-pi...@ti.com Update the data from the measurements performed at HW and SW levels. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. ToDo: - Measure the wake-up latencies for all power domains for OMAP3 - Correct some numbers when sys_clkreq and sys_offmode are supported Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/cpuidle34xx.c | 28 ++-- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c index 1b8e0da..4b3e994 100644 --- a/arch/arm/mach-omap2/cpuidle34xx.c +++ b/arch/arm/mach-omap2/cpuidle34xx.c @@ -44,20 +44,20 @@ * pass these details from the board file. */ static struct cpuidle_params cpuidle_params_table[] = { - /* C1 */ - {2 + 2, 5, 1}, - /* C2 */ - {10 + 10, 30, 1}, - /* C3 */ - {50 + 50, 300, 1}, - /* C4 */ - {1500 + 1800, 4000, 1}, - /* C5 */ - {2500 + 7500, 12000, 1}, - /* C6 */ - {3000 + 8500, 15000, 1}, - /* C7 */ - {1 + 3, 30, 1}, + /* C1 . MPU WFI + Core active */ + {73 + 78, 152, 1}, + /* C2 . MPU WFI + Core inactive */ + {165 + 88, 345, 1}, + /* C3 . MPU CSWR + Core inactive */ + {163 + 182, 345, 1}, + /* C4 . MPU OFF + Core inactive */ + {2852 + 605, 15, 1}, + /* C5 . MPU RET + Core RET */ + {800 + 366, 2120, 1}, + /* C6 . MPU OFF + Core RET */ + {4080 + 801, 215000, 1}, + /* C7 . MPU OFF + Core OFF */ + {4300 + 13000, 215000, 1}, }; #define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table) -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] OMAP2+: omap_hwmod: manage the wake-up latency constraints
From: Jean Pihet j-pi...@ti.com Hwmod is queried from the OMAP_PM layer to manage the power domains wake-up latency constraints. Hwmod retrieves the correct power domain and if it exists it calls the corresponding power domain function. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 26 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++ 2 files changed, 27 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 84cc0bd..c6b1cc9 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -143,6 +143,7 @@ #include powerdomain.h #include plat/clock.h #include plat/omap_hwmod.h +#include plat/omap_device.h #include plat/prcm.h #include cm2xxx_3xxx.h @@ -2618,11 +2619,34 @@ ohsps_unlock: return ret; } +/* + * omap_hwmod_set_wkup_constraint- set/release a wake-up latency constraint + * + * @oh: struct omap_hwmod* to which the target device belongs to. + * @cookie: identifier of the constraints list for @oh. + * @min_latency: the minimum allowed wake-up latency for @oh. + * + * Returns 0 upon success. + */ +int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, + void *cookie, long min_latency) +{ + struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh); + + if (!pwrdm) { + pr_err(%s: Error: could not find powerdomain + for %s\n, __func__, oh-name); + return -EINVAL; + } + + return pwrdm_set_wkup_lat_constraint(pwrdm, cookie, min_latency); +} + /** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * - * Query the powerdomain of of @oh to get the context loss + * Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 0e329ca..75e0e7a 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -603,6 +603,8 @@ int omap_hwmod_for_each_by_class(const char *classname, void *user); int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state); +int omap_hwmod_set_wkup_lat_constraint(struct omap_hwmod *oh, void *cookie, + long min_latency); u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh); int omap_hwmod_no_setup_reset(struct omap_hwmod *oh); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] OMAP: PM: register to the per-device PM QoS framework
From: Jean Pihet j-pi...@ti.com Implement the devices wake-up latency constraints using the global device PM QoS notification handler which applies the constraints to the underlying layer by calling the corresponding function at hwmod level. Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm.c | 63 ++ 1 files changed, 63 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index 3feb359..58b4b76 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -11,13 +11,16 @@ #include linux/kernel.h #include linux/init.h +#include linux/notifier.h #include linux/io.h #include linux/err.h #include linux/opp.h +#include linux/pm_qos.h #include plat/omap-pm.h #include plat/omap_device.h #include plat/common.h +#include plat/omap_hwmod.h #include voltage.h #include powerdomain.h @@ -242,11 +245,71 @@ static void __init omap4_init_voltages(void) omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva_dev); } +/* Interface to the per-device PM QoS framework */ +static int omap2_dev_pm_qos_handler(struct notifier_block *nb, + unsigned long new_value, + void *req) +{ + struct omap_device *od; + struct omap_hwmod *oh; + struct platform_device *pdev; + struct dev_pm_qos_request *dev_pm_qos_req = req; + + pr_debug(OMAP PM CONSTRAINTS: req@0x%p, new_value=%lu\n, +req, new_value); + + /* Look for the platform device for the constraint target device */ + pdev = to_platform_device(dev_pm_qos_req-dev); + + /* Try to catch non platform devices */ + if (pdev-name == NULL) { + pr_err(%s: Error: platform device for device %s not valid\n, + __func__, dev_name(dev_pm_qos_req-dev)); + return -EINVAL; + } + + /* Find the associated omap_device for dev */ + od = container_of(pdev, struct omap_device, pdev); + if (od-hwmods_cnt != 1) { + pr_err(%s: Error: No unique hwmod for device %s\n, + __func__, dev_name(dev_pm_qos_req-dev)); + return -EINVAL; + } + + /* Find the primary omap_hwmod for dev */ + oh = od-hwmods[0]; + + pr_debug(OMAP PM CONSTRAINTS: req@0x%p, dev=0x%p, new_value=%lu\n, +req, dev_pm_qos_req-dev, new_value); + + /* Apply the constraint */ + return omap_hwmod_set_wkup_lat_constraint(oh, dev_pm_qos_req, + new_value); +} + +static struct notifier_block omap2_dev_pm_qos_notifier = { + .notifier_call = omap2_dev_pm_qos_handler, +}; + +static int __init omap2_dev_pm_qos_init(void) +{ + int ret; + + ret = dev_pm_qos_add_global_notifier(omap2_dev_pm_qos_notifier); + if (ret) + WARN(1, KERN_ERR Cannot add global notifier for dev PM QoS\n); + + return ret; +} + static int __init omap2_common_pm_init(void) { omap2_init_processor_devices(); omap_pm_if_init(); + /* Register to the per-device PM QoS framework */ + omap2_dev_pm_qos_init(); + return 0; } postcore_initcall(omap2_common_pm_init); -- 1.7.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] OMAP3: powerdomain data: add wake-up latency figures
From: Jean Pihet j-pi...@ti.com Figures are added to the power domains structs for RET and OFF modes. Note: the latency figures for MPU, PER, CORE, NEON have been obtained from actual measurements. The latency figures for the other power domains are preliminary and shall be added. Cf. http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement for a detailed explanation on where are the numbers magically coming from. Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints on MPU, CORE and PER. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/powerdomains3xxx_data.c | 78 +++ 1 files changed, 78 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c b/arch/arm/mach-omap2/powerdomains3xxx_data.c index 469a920..32922bb 100644 --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c @@ -31,6 +31,14 @@ /* * Powerdomains + * + * The wakeup_lat values are derived from measurements on + * the actual target. + * + * Note: the latency figures for MPU, PER, CORE, NEON have been obtained + * from actual measurements. + * The latency figures for the other power domains are preliminary and + * shall be added. */ static struct powerdomain iva2_pwrdm = { @@ -52,6 +60,13 @@ static struct powerdomain iva2_pwrdm = { [2] = PWRSTS_OFF_ON, [3] = PWRSTS_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 350, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain mpu_3xxx_pwrdm = { @@ -68,6 +83,13 @@ static struct powerdomain mpu_3xxx_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_OFF_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1830, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 121, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; /* @@ -98,6 +120,13 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 3082, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 153, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain core_3xxx_es3_1_pwrdm = { @@ -121,6 +150,13 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 3082, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 153, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain dss_pwrdm = { @@ -136,6 +172,13 @@ static struct powerdomain dss_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 70, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 20, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; /* @@ -157,6 +200,13 @@ static struct powerdomain sgx_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1000, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain cam_pwrdm = { @@ -172,6 +222,13 @@ static struct powerdomain cam_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 850, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_INACTIVE] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain per_pwrdm = { @@ -187,6 +244,13 @@ static struct powerdomain per_pwrdm = { .pwrsts_mem_on= { [0] = PWRSTS_ON, /* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 671, +
Re: [PATCH v2 0/8] PM QoS: implement the OMAP low level constraints management code
Hi, Sorry I was missing the 'From:' line. Patch sent has been resent properly. On Wed, Sep 21, 2011 at 6:24 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap cleanup part1 for v3.2 merge window
Hi Arnd, Arnd Bergmann a...@arndb.de writes: On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote: It seems that you replace the #ifdef in the board-flash.c file with a similar #ifdef in the header that replaces this with an empty inline function when the object is not built. Found another similar problem over night, presumably in the voltage series: Found. Patch below. If this one is OK, I'll push to my for_3.2/voltage-cleanup branch (which is already pulled into arm-soc/next/voltage) so just re-pulling will pick up the fix. Kevin From 473dc975c3ea468049732155467ff08fe3701f98 Mon Sep 17 00:00:00 2001 From: Kevin Hilman khil...@ti.com Date: Wed, 21 Sep 2011 09:24:53 -0700 Subject: [PATCH] ARM: OMAP: voltage layer present, even when CONFIG_PM=n Even when CONFIG_PM=n, we try to scale the boot voltage to a sane, known value using OPP table to find matching voltage based on boot frequency. This should be done, even when CONFIG_PM=n to avoid mis-configured bootloaders and/or boot voltage assumptions made by boot loaders. Also fixes various compile problems due to depenencies between voltage domain and powerdomain code (also present when CONFIG_PM=n). Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Kevin Hilman khil...@ti.com --- Compile tested with CONFIG_PM=n Applies to arm-soc/next/voltage arch/arm/mach-omap2/Makefile |2 -- arch/arm/mach-omap2/voltage.h | 14 -- 2 files changed, 0 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8bd389d..5129785 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -89,7 +89,6 @@ obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \ vp44xx_data.o # OMAP voltage domains -ifeq ($(CONFIG_PM),y) voltagedomain-common := voltage.o vc.o vp.o obj-$(CONFIG_ARCH_OMAP2) += $(voltagedomain-common) \ voltagedomains2xxx_data.o @@ -97,7 +96,6 @@ obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \ voltagedomains3xxx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \ voltagedomains44xx_data.o -endif # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 4c09809..16a1b09 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -148,25 +148,11 @@ void omap_voltage_get_volttable(struct voltagedomain *voltdm, struct omap_volt_data **volt_data); struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm, unsigned long volt); -#ifdef CONFIG_PM int omap_voltage_register_pmic(struct voltagedomain *voltdm, struct omap_voltdm_pmic *pmic); void omap_change_voltscale_method(struct voltagedomain *voltdm, int voltscale_method); int omap_voltage_late_init(void); -#else -static inline int omap_voltage_register_pmic(struct voltagedomain *voltdm, -struct omap_voltdm_pmic *pmic) -{ - return -EINVAL; -} -static inline void omap_change_voltscale_method(struct voltagedomain *voltdm, - int voltscale_method) {} -static inline int omap_voltage_late_init(void) -{ - return -EINVAL; -} -#endif extern void omap2xxx_voltagedomains_init(void); extern void omap3xxx_voltagedomains_init(void); -- 1.7.6 -- 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 8/8] OMAP4: Fix the emif and dmm virtual mapping
Santosh Shilimkar santosh.shilim...@ti.com writes: On Tuesday 20 September 2011 08:31 PM, Santosh Shilimkar wrote: On Friday 16 September 2011 11:26 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: [...] #define OMAP44XX_EMIF2_SIZE SZ_1M #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) +#define OMAP44XX_DMM_VIRT (OMAP44XX_EMIF2_VIRT + SZ_1M) and '+ OMAP44XX_EMIF2_SIZE' here. Will add OMAP44XX_EMIF_SIZE since 2 EMIFs instaces are and suppose to be identical.Almost missed this email in other traffic. OPPs. It was already there. Dumb of me not using it. Below is the update what I will do. diff --git a/arch/arm/plat-omap/include/plat/io.h b/arch/arm/plat-omap/include/plat/io.h index d72ec85..db36292 100644 --- a/arch/arm/plat-omap/include/plat/io.h +++ b/arch/arm/plat-omap/include/plat/io.h @@ -228,13 +228,13 @@ #define OMAP44XX_EMIF2_PHYS OMAP44XX_EMIF2_BASE /* 0x4d00 -- 0xfd20 */ -#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF2_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_EMIF2_SIZE SZ_1M +#define OMAP44XX_EMIF2_VIRT (OMAP44XX_EMIF1_VIRT + OMAP44XX_EMIF2_SIZE) This doesn't look right either. This #define is for the *start* of EMIF2 virtual address space, so assuming the start address of EMIF2 is immediatly after EMIF1, it should be EMIF1_VIRT + EMIF1_SIZE (not EMIF2_SIZE.) #define OMAP44XX_DMM_PHYSOMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ -#define OMAP44XX_DMM_VIRT(OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_DMM_SIZESZ_1M +#define OMAP44XX_DMM_VIRT(OMAP44XX_EMIF2_VIRT + OMAP44XX_DMM_SIZE) And here, assuming DMM range is immediately after EMIF2, this should be EMIF2_VIRT + EMFI2_SIZE) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Add support for TI814X processor series
This patch set adds support for DM814x/AM387x device series having Cortex-A8 MPU. The technical documents are available from following link: http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html This series is referred in code as TI814X. Since these devices share similar architecture as TI816X devices, existing TI816X code is updated to accomodate TI814X support. The code shared across TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable, while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific execution differences. Changes since v1: 1) Rebased and updated after Paul's CHIP_IS removal changes 2) Removed call to omap2_init_common_devices() as per Kevin's comment Hemant Pedanekar (3): TI81XX: Prepare for addition of TI814X support TI814X: Add cpu type macros and detection support TI814X: Create board support and enable build for TI8148 EVM arch/arm/mach-omap2/Kconfig| 11 +++- arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-ti8148evm.c | 51 arch/arm/mach-omap2/board-ti8168evm.c |8 ++-- arch/arm/mach-omap2/clock.c|2 +- arch/arm/mach-omap2/clock.h|2 +- arch/arm/mach-omap2/clock3xxx_data.c |5 ++- arch/arm/mach-omap2/common.c | 22 arch/arm/mach-omap2/control.h |8 ++-- arch/arm/mach-omap2/id.c | 30 ++-- arch/arm/mach-omap2/include/mach/debug-macro.S | 12 ++-- arch/arm/mach-omap2/include/mach/entry-macro.S |4 +- arch/arm/mach-omap2/io.c | 12 ++-- arch/arm/mach-omap2/irq.c |2 +- arch/arm/mach-omap2/opp2xxx.h |2 +- arch/arm/mach-omap2/serial.c |6 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h|3 +- arch/arm/plat-omap/include/plat/common.h |4 +- arch/arm/plat-omap/include/plat/cpu.h | 22 arch/arm/plat-omap/include/plat/hardware.h |2 +- arch/arm/plat-omap/include/plat/io.h |6 +- arch/arm/plat-omap/include/plat/irqs.h |2 +- arch/arm/plat-omap/include/plat/serial.h | 14 +++--- .../plat-omap/include/plat/{ti816x.h = ti81xx.h} | 18 arch/arm/plat-omap/include/plat/uncompress.h | 11 +++-- arch/arm/plat-omap/io.c|2 +- 27 files changed, 186 insertions(+), 77 deletions(-) create mode 100644 arch/arm/mach-omap2/board-ti8148evm.c rename arch/arm/plat-omap/include/plat/{ti816x.h = ti81xx.h} (60%) -- 1.7.3.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 v2 1/3] TI81XX: Prepare for addition of TI814X support
This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/Kconfig|6 ++-- arch/arm/mach-omap2/board-ti8168evm.c |8 +++--- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/common.c | 22 ++-- arch/arm/mach-omap2/control.h |8 +++--- arch/arm/mach-omap2/id.c |8 +++--- arch/arm/mach-omap2/include/mach/debug-macro.S | 12 +- arch/arm/mach-omap2/include/mach/entry-macro.S |4 +- arch/arm/mach-omap2/io.c | 12 +- arch/arm/mach-omap2/irq.c |2 +- arch/arm/mach-omap2/serial.c |6 ++-- arch/arm/plat-omap/include/plat/common.h |4 +- arch/arm/plat-omap/include/plat/cpu.h | 13 +++ arch/arm/plat-omap/include/plat/hardware.h |2 +- arch/arm/plat-omap/include/plat/io.h |6 ++-- arch/arm/plat-omap/include/plat/irqs.h |2 +- arch/arm/plat-omap/include/plat/serial.h | 14 ++-- .../plat-omap/include/plat/{ti816x.h = ti81xx.h} | 18 arch/arm/plat-omap/include/plat/uncompress.h |8 +++--- arch/arm/plat-omap/io.c|2 +- 20 files changed, 86 insertions(+), 73 deletions(-) rename arch/arm/plat-omap/include/plat/{ti816x.h = ti81xx.h} (60%) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 7edf802..a3b9227 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -73,8 +73,8 @@ config SOC_OMAP3430 default y select ARCH_OMAP_OTG -config SOC_OMAPTI816X - bool TI816X support +config SOC_OMAPTI81XX + bool TI81XX support depends on ARCH_OMAP3 default y @@ -313,7 +313,7 @@ config MACH_OMAP_3630SDP config MACH_TI8168EVM bool TI8168 Evaluation Module - depends on SOC_OMAPTI816X + depends on SOC_OMAPTI81XX default y config MACH_OMAP_4430SDP diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-omap2/board-ti8168evm.c index e26c79c..e0c7300 100644 --- a/arch/arm/mach-omap2/board-ti8168evm.c +++ b/arch/arm/mach-omap2/board-ti8168evm.c @@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void) static void __init ti8168_evm_map_io(void) { - omap2_set_globals_ti816x(); - omapti816x_map_common_io(); + omap2_set_globals_ti81xx(); + omapti81xx_map_common_io(); } MACHINE_START(TI8168EVM, ti8168evm) /* Maintainer: Texas Instruments */ .atag_offset= 0x100, .map_io = ti8168_evm_map_io, - .init_early = ti816x_init_early, - .init_irq = ti816x_init_irq, + .init_early = ti81xx_init_early, + .init_irq = ti81xx_init_irq, .timer = omap3_timer, .init_machine = ti8168_evm_init, MACHINE_END diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index dadb8c6..6054654 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -3576,7 +3576,7 @@ int __init omap3xxx_clk_init(void) * Lock DPLL5 -- here only until other device init code can * handle this */ - if (!cpu_is_ti816x() (omap_rev() = OMAP3430_REV_ES2_0)) + if (!cpu_is_ti81xx() (omap_rev() = OMAP3430_REV_ES2_0)) omap3_clk_lock_dpll5(); /* Avoid sleeping during omap3_core_dpll_m2_set_rate() */ diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 3f20cbb..7ce80f2 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -101,23 +101,23 @@ void __init omap3_map_io(void) /* * Adjust TAP register base such that omap3_check_revision accesses the correct - * TI816X register for checking device ID (it adds 0x204 to tap base while - * TI816X DEVICE ID register is at offset 0x600 from control base). + * TI81XX register for checking device ID (it adds 0x204 to tap base while + * TI81XX DEVICE ID register is at offset 0x600 from control base). */ -#define TI816X_TAP_BASE(TI816X_CTRL_BASE + \ - TI816X_CONTROL_DEVICE_ID - 0x204) +#define TI81XX_TAP_BASE(TI81XX_CTRL_BASE + \ + TI81XX_CONTROL_DEVICE_ID - 0x204) -static struct omap_globals ti816x_globals = { +static struct omap_globals ti81xx_globals = { .class = OMAP343X_CLASS, - .tap=
[PATCH v2 2/3] TI814X: Add cpu type macros and detection support
This patch adds cpu type, macros for identification of TI814X device. Note that following update to common OMAP data structures is made: cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/clock.h |2 +- arch/arm/mach-omap2/clock3xxx_data.c |3 +++ arch/arm/mach-omap2/id.c | 22 ++ arch/arm/mach-omap2/opp2xxx.h |2 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |1 + arch/arm/plat-omap/include/plat/clock.h |3 ++- arch/arm/plat-omap/include/plat/cpu.h |9 + 8 files changed, 40 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c index 1f3481f..f57ed5b 100644 --- a/arch/arm/mach-omap2/clock.c +++ b/arch/arm/mach-omap2/clock.c @@ -35,7 +35,7 @@ #include cm-regbits-24xx.h #include cm-regbits-34xx.h -u8 cpu_mask; +u16 cpu_mask; /* * clkdm_control: if true, then when a clock is enabled in the diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 48ac568..687d3d3 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -130,7 +130,7 @@ void omap2_clk_print_new_rates(const char *hfclkin_ck_name, const char *core_ck_name, const char *mpu_ck_name); -extern u8 cpu_mask; +extern u16 cpu_mask; extern const struct clkops clkops_omap2_dflt_wait; extern const struct clkops clkops_dummy; diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c index 6054654..b4d5f84 100644 --- a/arch/arm/mach-omap2/clock3xxx_data.c +++ b/arch/arm/mach-omap2/clock3xxx_data.c @@ -3493,6 +3493,9 @@ int __init omap3xxx_clk_init(void) } else if (cpu_is_ti816x()) { cpu_mask = RATE_IN_TI816X; cpu_clkflg = CK_TI816X; + } else if (cpu_is_ti814x()) { + cpu_mask = RATE_IN_TI814X; + cpu_clkflg = CK_TI814X; } else if (cpu_is_omap34xx()) { if (omap_rev() == OMAP3430_REV_ES1_0) { cpu_mask = RATE_IN_3430ES1; diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index ab2f417..f07faa9 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -337,6 +337,26 @@ static void __init omap3_check_revision(const char **cpu_rev) break; } break; + case 0xb8f2: + switch (rev) { + case 0: + /* FALLTHROUGH */ + case 1: + omap_revision = TI8148_REV_ES1_0; + *cpu_rev = 1.0; + break; + case 2: + omap_revision = TI8148_REV_ES2_0; + *cpu_rev = 2.0; + break; + case 3: + /* FALLTHROUGH */ + default: + omap_revision = TI8148_REV_ES2_1; + *cpu_rev = 2.1; + break; + } + break; default: /* Unknown default to latest silicon rev as default */ omap_revision = OMAP3630_REV_ES1_2; @@ -429,6 +449,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev) cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505; } else if (cpu_is_ti816x()) { cpu_name = TI816X; + } else if (cpu_is_ti814x()) { + cpu_name = TI814X; } else if (omap3_has_iva() omap3_has_sgx()) { /* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */ cpu_name = OMAP3430/3530; diff --git a/arch/arm/mach-omap2/opp2xxx.h b/arch/arm/mach-omap2/opp2xxx.h index 8affc66..8fae534 100644 --- a/arch/arm/mach-omap2/opp2xxx.h +++ b/arch/arm/mach-omap2/opp2xxx.h @@ -51,7 +51,7 @@ struct prcm_config { unsigned long cm_clksel2_pll; /* dpllx1 or x2 out */ unsigned long cm_clksel_mdm;/* modem dividers 2430 only */ unsigned long base_sdrc_rfr;/* base refresh timing for a set */ - unsigned char flags; + unsigned short flags; }; diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h b/arch/arm/plat-omap/include/plat/clkdev_omap.h index 387a963..3c50ec8 100644 --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h @@ -40,6 +40,7 @@ struct omap_clk { #define CK_443X(1 11) #define CK_TI816X (1 12) #define CK_446X(1 13) +#define CK_TI814X (1 14) #define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS) diff --git a/arch/arm/plat-omap/include/plat/clock.h
[PATCH v2 3/3] TI814X: Create board support and enable build for TI8148 EVM
This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. Signed-off-by: Hemant Pedanekar hema...@ti.com --- arch/arm/mach-omap2/Kconfig |5 +++ arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-ti8148evm.c| 51 ++ arch/arm/plat-omap/include/plat/uncompress.h |3 ++ 4 files changed, 60 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-ti8148evm.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index a3b9227..cc4f213 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -316,6 +316,11 @@ config MACH_TI8168EVM depends on SOC_OMAPTI81XX default y +config MACH_TI8148EVM + bool TI8148 Evaluation Module + depends on SOC_OMAPTI81XX + default y + config MACH_OMAP_4430SDP bool OMAP 4430 SDP board default y diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 46a3497..597a2b6 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -242,6 +242,7 @@ obj-$(CONFIG_MACH_CRANEBOARD) += board-am3517crane.o obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o obj-$(CONFIG_MACH_TI8168EVM) += board-ti8168evm.o +obj-$(CONFIG_MACH_TI8148EVM) += board-ti8148evm.o # Platform specific device init code diff --git a/arch/arm/mach-omap2/board-ti8148evm.c b/arch/arm/mach-omap2/board-ti8148evm.c new file mode 100644 index 000..355c766 --- /dev/null +++ b/arch/arm/mach-omap2/board-ti8148evm.c @@ -0,0 +1,51 @@ +/* + * Code for TI8148 EVM. + * + * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/ + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation version 2. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ +#include linux/kernel.h +#include linux/init.h + +#include mach/hardware.h +#include asm/mach-types.h +#include asm/mach/arch.h +#include asm/mach/map.h + +#include plat/irqs.h +#include plat/board.h +#include plat/common.h + +static struct omap_board_config_kernel ti8148_evm_config[] __initdata = { +}; + +static void __init ti8148_evm_init(void) +{ + omap_serial_init(); + omap_board_config = ti8148_evm_config; + omap_board_config_size = ARRAY_SIZE(ti8148_evm_config); +} + +static void __init ti8148_evm_map_io(void) +{ + omap2_set_globals_ti81xx(); + omapti81xx_map_common_io(); +} + +MACHINE_START(TI8148EVM, ti8148evm) + /* Maintainer: Texas Instruments */ + .atag_offset= 0x100, + .map_io = ti8148_evm_map_io, + .init_early = ti81xx_init_early, + .init_irq = ti81xx_init_irq, + .timer = omap3_timer, + .init_machine = ti8148_evm_init, +MACHINE_END diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h index 40336ad..8d052e7 100644 --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -175,6 +175,9 @@ static inline void __arch_decomp_setup(unsigned long arch_id) /* TI8168 base boards using UART3 */ DEBUG_LL_TI81XX(3, ti8168evm); + /* TI8148 base boards using UART1 */ + DEBUG_LL_TI81XX(1, ti8148evm); + } while (0); } -- 1.7.3.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
Staging tree for AM335x platforms
Tony, I'm looking at creating a public repository to hold patches not yet in shape for inclusion in linux-omap (if not personally, then someone at TI that meets the below charter). I know there can be concern that this becomes a distraction if we start pulling in community patches. It seems it needs to be coupled with reworking systems for acceptance upstream, but we'd like for there to be something where community members can generate patches against while we are in the process of cleaning up the underlying platform bits. Do you have any recommendations or guidelines that should be followed regarding anything about such a public repository? Recommendations and guidelines can include, but not be limited to, where the repository should live, where patches and pull requests should be submitted, what types of patches should be accepted and what state they should be in, when should it be rebased, who is suitable to maintain this repository and what should be used for managing patch status (ie. patchwork and which patchwork). If this doesn't sound useful to you, then please feel free to shut me down on this. The goal is to help and it is understood that contributions to the infrastructure (dev tree, pwr mgmt, etc.) are required to be productive. Regards, Jason -- 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: omap_device cleanup for v3.2
Tony Lindgren t...@atomide.com writes: * Kevin Hilman khil...@ti.com [110915 16:23]: Kevin Hilman khil...@ti.com writes: Please pull this omap_device cleanup series for v3.2. This sets the groundwork for Benoit's DT infrastructure work. Turns out this series has a dependency on a patch[1] in Russell's for-next branch. Russell, any chance of picking this patch into your devel-stable so we have a fixed point to merge with? Or maybe Kevin can add it to his series instead? Sure. Russell, if you're OK with dropping it from your for-next, I'll just add it to my series where the dependencies are. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 49/57] video: irq: Remove IRQF_DISABLED
On Wed, Sep 21, 2011 at 05:28:50PM +0800, Yong Zhang wrote: Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com --- drivers/video/msm/mddi.c |2 +- drivers/video/msm/mdp.c |2 +- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: Staging tree for AM335x platforms
Hi, * Jason Kridner jkrid...@beagleboard.org [110921 10:56]: Tony, I'm looking at creating a public repository to hold patches not yet in shape for inclusion in linux-omap (if not personally, then someone at TI that meets the below charter). I know there can be concern that this becomes a distraction if we start pulling in community patches. It seems it needs to be coupled with reworking systems for acceptance upstream, but we'd like for there to be something where community members can generate patches against while we are in the process of cleaning up the underlying platform bits. OK cool. Do you have any recommendations or guidelines that should be followed regarding anything about such a public repository? Recommendations and guidelines can include, but not be limited to, where the repository should live, where patches and pull requests should be submitted, what types of patches should be accepted and what state they should be in, when should it be rebased, who is suitable to maintain this repository and what should be used for managing patch status (ie. patchwork and which patchwork). Well in general the thing to watch out for is once you create a tree it becomes a complete mess in about three months. Or else it just becomes a graveyard of unmergeable patches :) So keeping that in mind, ideally your tree would be just a daily merge of various driver developers branches. And then try to set up things where the responsibility of merging code upstream is on the drivers developers. Trying to merge other people's patches upstream is not scalable. Other than that, you should be able to base it on some recent mainline tag and pick in some queued up patches as needed. If this doesn't sound useful to you, then please feel free to shut me down on this. The goal is to help and it is understood that contributions to the infrastructure (dev tree, pwr mgmt, etc.) are required to be productive. That totally sounds usable to me :) Assuming you can figure out some way to address the comments above. For helping with contributions, I can think of a few places where help is badly needed: 1. Remove dependencies in mainline kernel that block merging Maybe you can isolate some issues in mainline kernel that cause you problems merging your patches upstream? If so, whatever is needed should be done to patch away those dependencies. At least PM patches fit into this category.. 2. Merge all am335x/beagle clone board-*.c files together This would help a lot when we start converting drivers to use device tree as it reduces the number of board-*.c files 3. Help with device tree conversion of device drivers Which drivers do most am335x and beagle clones use? Maybe you can help converting those drivers to use device tree? Sure some drivers depend on regulator framework conversion and the device tree omap_device glue layer, but there are already patches being posted for those 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 v2 1/3] TI81XX: Prepare for addition of TI814X support
* Hemant Pedanekar hema...@ti.com [110921 10:05]: --- a/arch/arm/mach-omap2/board-ti8168evm.c +++ b/arch/arm/mach-omap2/board-ti8168evm.c @@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void) static void __init ti8168_evm_map_io(void) { - omap2_set_globals_ti816x(); - omapti816x_map_common_io(); + omap2_set_globals_ti81xx(); + omapti81xx_map_common_io(); } MACHINE_START(TI8168EVM, ti8168evm) /* Maintainer: Texas Instruments */ .atag_offset= 0x100, .map_io = ti8168_evm_map_io, - .init_early = ti816x_init_early, - .init_irq = ti816x_init_irq, + .init_early = ti81xx_init_early, + .init_irq = ti81xx_init_irq, .timer = omap3_timer, .init_machine = ti8168_evm_init, MACHINE_END Looks like you still need a minor rebase on the current cleanup branch as the ti8668_evm_map_io is no longer needed. The cleanup branch already has Paul's CHIP_IS removal, so that should be trivial. Ideally the rename patch would be separate without any functional changes, maybe you can move the changes and additions to the next patch? 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 v2 3/3] TI814X: Create board support and enable build for TI8148 EVM
* Hemant Pedanekar hema...@ti.com [110921 10:05]: + +static struct omap_board_config_kernel ti8148_evm_config[] __initdata = { +}; + +static void __init ti8148_evm_init(void) +{ + omap_serial_init(); + omap_board_config = ti8148_evm_config; + omap_board_config_size = ARRAY_SIZE(ti8148_evm_config); +} + +static void __init ti8148_evm_map_io(void) +{ + omap2_set_globals_ti81xx(); + omapti81xx_map_common_io(); +} Hmm I guess we still have board specific map_io in board-ti8668evm.c also. Those would be better replaced with ti81xx_map_io in mach-omap2/common.c. Care to take a look at that? +MACHINE_START(TI8148EVM, ti8148evm) + /* Maintainer: Texas Instruments */ + .atag_offset= 0x100, + .map_io = ti8148_evm_map_io, + .init_early = ti81xx_init_early, + .init_irq = ti81xx_init_irq, + .timer = omap3_timer, + .init_machine = ti8148_evm_init, +MACHINE_END Please add this all to board-ti8168evm.c instead of adding a new board-*.c file. With the upcoming device tree conversion most of these will disappear anyways. 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 v2 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
Cousson, Benoit b-cous...@ti.com writes: On 9/17/2011 6:13 PM, Grant Likely wrote: On Fri, Sep 16, 2011 at 04:43:19PM +0200, Benoit Cousson wrote: [...] +} + +static int _omap_device_notifier_call(struct notifier_block *nb, + unsigned long event, void *dev) Nit: Why the preceding underscore? Generally that is only done for 'special' variants of public functions. ie. for a variant that expects a lock to already be held. Yeah, the convention in this file is not that strict, and it is used for internal static helper function as well. I'll let Kevin arbitrate that point :-) The convention in this file is the leading '_' is used for internal helper functions. I'd prefer to keep it that way, and if we decide to change the coding convention to match a coding convention elsewhere, we should do it all at the same time. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Staging tree for AM335x platforms
On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren t...@atomide.com wrote: Hi, * Jason Kridner jkrid...@beagleboard.org [110921 10:56]: Tony, I'm looking at creating a public repository to hold patches not yet in shape for inclusion in linux-omap (if not personally, then someone at TI that meets the below charter). I know there can be concern that this becomes a distraction if we start pulling in community patches. It seems it needs to be coupled with reworking systems for acceptance upstream, but we'd like for there to be something where community members can generate patches against while we are in the process of cleaning up the underlying platform bits. OK cool. Do you have any recommendations or guidelines that should be followed regarding anything about such a public repository? Recommendations and guidelines can include, but not be limited to, where the repository should live, where patches and pull requests should be submitted, what types of patches should be accepted and what state they should be in, when should it be rebased, who is suitable to maintain this repository and what should be used for managing patch status (ie. patchwork and which patchwork). Well in general the thing to watch out for is once you create a tree it becomes a complete mess in about three months. Or else it just becomes a graveyard of unmergeable patches :) I'm not going to advertise a tree here and on the beagle list until I'm confident I can stick with it a couple of years consistently. I like to keep some labels on old stuff, but I would commit to having it rebased frequently and tested in an automated fashion. So keeping that in mind, ideally your tree would be just a daily merge of various driver developers branches. And then try to set up things where the responsibility of merging code upstream is on the drivers developers. Trying to merge other people's patches upstream is not scalable. Understood. I'd be looking for contributors to show some commitment or drop their patches. I'm sure there will be a certain amount of fire-and-forget patches coming from people that I'll want to try to push for them, but I'll try to shed the cruft frequently. Other than that, you should be able to base it on some recent mainline tag and pick in some queued up patches as needed. If this doesn't sound useful to you, then please feel free to shut me down on this. The goal is to help and it is understood that contributions to the infrastructure (dev tree, pwr mgmt, etc.) are required to be productive. That totally sounds usable to me :) Assuming you can figure out some way to address the comments above. For helping with contributions, I can think of a few places where help is badly needed: 1. Remove dependencies in mainline kernel that block merging Maybe you can isolate some issues in mainline kernel that cause you problems merging your patches upstream? If so, whatever is needed should be done to patch away those dependencies. At least PM patches fit into this category.. Makes sense. 2. Merge all am335x/beagle clone board-*.c files together This would help a lot when we start converting drivers to use device tree as it reduces the number of board-*.c files Sounds like a good task and something I can tackle. I got some push-back on this from internal developers, but I think I can start merging some of it myself and send some code to ask advice on how to make it most maintainable. 3. Help with device tree conversion of device drivers Which drivers do most am335x and beagle clones use? Maybe you can help converting those drivers to use device tree? USB, GPIO, I2C and SPI are most critical from my perspective. I need to figure out which of those already have some owners pushing them ahead. Sure some drivers depend on regulator framework conversion and the device tree omap_device glue layer, but there are already patches being posted for those Great. I guess it makes sense for this tree to include those patches and hopefully the thrash when they change won't be unbearable. I won't know until I start doing 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: [GIT PULL] OMAP: omap_device cleanup for v3.2
* Kevin Hilman khil...@ti.com [110915 16:23]: Kevin Hilman khil...@ti.com writes: Please pull this omap_device cleanup series for v3.2. This sets the groundwork for Benoit's DT infrastructure work. Turns out this series has a dependency on a patch[1] in Russell's for-next branch. Russell, any chance of picking this patch into your devel-stable so we have a fixed point to merge with? Or maybe Kevin can add it to his series instead? Tony [1] commit 456f69c544d4298e921dc0c606492cdbaa60b34b Author: Kevin Hilman khil...@deeprootsystems.com Date: Tue Sep 6 21:04:10 2011 +0100 ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointer Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Kevin Hilman khil...@ti.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/3] TI81XX: Prepare for addition of TI814X support
Tony Lindgren wrote on Thursday, September 22, 2011 2:11 AM: * Hemant Pedanekar hema...@ti.com [110921 10:05]: --- a/arch/arm/mach-omap2/board-ti8168evm.c +++ b/arch/arm/mach-omap2/board-ti8168evm.c @@ -37,16 +37,16 @@ static void __init ti8168_evm_init(void) static void __init ti8168_evm_map_io(void) { -omap2_set_globals_ti816x(); -omapti816x_map_common_io(); +omap2_set_globals_ti81xx(); +omapti81xx_map_common_io(); } MACHINE_START(TI8168EVM, ti8168evm) /* Maintainer: Texas Instruments */ .atag_offset= 0x100, .map_io = ti8168_evm_map_io, -.init_early = ti816x_init_early, -.init_irq = ti816x_init_irq, +.init_early = ti81xx_init_early, +.init_irq = ti81xx_init_irq, .timer = omap3_timer, .init_machine = ti8168_evm_init, MACHINE_END Looks like you still need a minor rebase on the current cleanup branch as the ti8668_evm_map_io is no longer needed. The cleanup branch already has Paul's CHIP_IS removal, so that should be trivial. Tony, Can you please clarify? Do we not need ti8168_evm_map_io() for global data initianlization and io init? Or, as you mentioned in comment on 3/3 of the series, do you mean to rename this with ti81xx and move to common.c? Ideally the rename patch would be separate without any functional changes, maybe you can move the changes and additions to the next patch? Tony If the above understanding is correct, then I will just have to rename+move ti8168_evm_map_io() so the change can still be in this patch, right? Or are You referring to any other part which should not be in this patch? Thanks. Hemant-- 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 3/3] TI814X: Create board support and enable build for TI8148 EVM
Tony Lindgren wrote on Thursday, September 22, 2011 2:18 AM: * Hemant Pedanekar hema...@ti.com [110921 10:05]: + +static struct omap_board_config_kernel ti8148_evm_config[] __initdata = { +}; + +static void __init ti8148_evm_init(void) +{ +omap_serial_init(); +omap_board_config = ti8148_evm_config; +omap_board_config_size = ARRAY_SIZE(ti8148_evm_config); +} + +static void __init ti8148_evm_map_io(void) +{ +omap2_set_globals_ti81xx(); +omapti81xx_map_common_io(); +} Hmm I guess we still have board specific map_io in board-ti8668evm.c also. Those would be better replaced with ti81xx_map_io in mach-omap2/common.c. Care to take a look at that? Yes, you are right. I will do that. +MACHINE_START(TI8148EVM, ti8148evm) +/* Maintainer: Texas Instruments */ +.atag_offset= 0x100, +.map_io = ti8148_evm_map_io, +.init_early = ti81xx_init_early, +.init_irq = ti81xx_init_irq, +.timer = omap3_timer, +.init_machine = ti8148_evm_init, +MACHINE_END Please add this all to board-ti8168evm.c instead of adding a new board-*.c file. With the upcoming device tree conversion most of these will disappear anyways. Ok, I will do that. Thanks. Hemant Regards, Tony Hemant-- 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 v16 10/12] OMAP: dmtimer: extend spinlock in request functions
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]: The request functions now verify the success of omap_dm_timer_prepare() call after a timer is acquired. If *_prepare() fails then we have to release the timer. In order to avoid race condition during this time, include *_prepare() within lock. This I've folded into patch 5. 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: [GIT PULL] omap cleanup part1 for v3.2 merge window
* Arnd Bergmann a...@arndb.de [110920 23:34]: On Tuesday 20 September 2011 15:33:12 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [110920 14:12]: On Tuesday 20 September 2011, Arnd Bergmann wrote: One more thing: my randconfig tests are running now and have spit out a new error after merging lost of stuff today: Good to hear you got arndconfig running :) Do you think we could also add support for something like this: $ echo CONFIG_ARCH_OMAP=y .config $ make randconfig or $ make --force=CONFIG_ARCH_OMAP randconfig Where randconfig would keep the forced CONFIG_ARCH_OMAP static while randomly selecting the others? This would allow targeted randconfig for each patch more or less.. The mechanism I use is setting KCONFIG_ALLCONFIG= to a file that has the options I want to have set to a specific value. If you don't do that, randconfig will take the default option for each 'choice' statement, which means we build for the ARCH_VERSATILE platform. See the script I'm using at the end of this mail. It should be easy for you to pick out the parts you need. Thanks will take a look at that for sure. 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 v16 00/12] OMAP: dmtimer: adaptation to platform_driver
Hi Tarun, * Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]: Adaptation of dmtimer code to platform driver using omap_device and omap_hwmod abstraction. It also include pm-runtime and off-mode support. I've applied these into dmtimer branch with some changes to simplify things further. I've also merged it into linux-omap master branch for further testing. I'll reply to your patches with the changes I've done. Care give the dmtimer branch a try and see if I've missed something? 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 v16 08/12] OMAP: dmtimer: do remaining initialization in probe
* Tarun Kanti DebBarma tarun.ka...@ti.com [110920 03:57]: @@ -514,10 +514,23 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev) timer-irq = irq-start; timer-pdev = pdev; - /* Skip pm_runtime_enable for OMAP1 */ - if (!pdata-needs_manual_reset) { - pm_runtime_enable(pdev-dev); - pm_runtime_irq_safe(pdev-dev); +/* + * sys_timer_reserved is not defined for OMAP1. + * Use the macro to avoid compilation error on OMAP1. + */ +#if defined(CONFIG_ARCH_OMAP2PLUS) + pm_runtime_enable(pdev-dev); + pm_runtime_irq_safe(pdev-dev); + /* Mark clocksource and clockevent timers as reserved */ + if ((sys_timer_reserved (pdev-id - 1)) 0x1) + timer-reserved = 1; +#endif + + if (!timer-reserved) { + pm_runtime_get_sync(pdev-dev); + __omap_dm_timer_init_regs(timer); + timer-tidr = __raw_readl(timer-io_base); + pm_runtime_put(pdev-dev); } /* add the timer element to the list */ This all should not be necessary. We can pass the reserved flag in pdata. Let's replace this one with the patch below. Regards, Tony From: Tony Lindgren t...@atomide.com Date: Wed, 21 Sep 2011 16:38:51 -0700 Subject: [PATCH] ARM: OMAP: dmtimer: skip reserved timers Pass the reserved flag in pdata and use it. We can now make sys_timer_reserved static to mach-omap2/timer.c. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 9c2f588..f1e3ec1 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -69,7 +69,7 @@ /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */ #define MAX_GPTIMER_ID 12 -u32 sys_timer_reserved; +static u32 sys_timer_reserved; /* Clockevent code */ @@ -463,6 +463,10 @@ static int __init omap_timer_init(struct omap_hwmod *oh, void *unused) pdata-set_timer_src = omap2_dm_timer_set_src; pdata-timer_ip_version = oh-class-rev; + /* Mark clocksource and clockevent timers as reserved */ + if ((sys_timer_reserved (id - 1)) 0x1) + pdata-reserved = 1; + od = omap_device_build(name, id, oh, pdata, sizeof(*pdata), omap2_dmtimer_latency, ARRAY_SIZE(omap2_dmtimer_latency), diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index ac904c2..c8df3c3 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -509,6 +509,7 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev) timer-id = pdev-id; timer-irq = irq-start; + timer-reserved = pdata-reserved; timer-pdev = pdev; /* Skip pm_runtime_enable for OMAP1 */ @@ -517,6 +518,12 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev) pm_runtime_irq_safe(pdev-dev); } + if (!timer-reserved) { + pm_runtime_get_sync(pdev-dev); + __omap_dm_timer_init_regs(timer); + pm_runtime_put(pdev-dev); + } + /* add the timer element to the list */ spin_lock_irqsave(dm_timer_lock, flags); list_add_tail(timer-node, omap_timer_list); diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h index 4e3a326..29764c3 100644 --- a/arch/arm/plat-omap/include/plat/dmtimer.h +++ b/arch/arm/plat-omap/include/plat/dmtimer.h @@ -77,6 +77,7 @@ struct dmtimer_platform_data { int (*set_timer_src)(struct platform_device *pdev, int source); int timer_ip_version; u32 needs_manual_reset:1; + bool reserved; }; struct omap_dm_timer *omap_dm_timer_request(void); @@ -248,7 +249,6 @@ struct omap_dm_timer { struct list_head node; }; -extern u32 sys_timer_reserved; int omap_dm_timer_prepare(struct omap_dm_timer *timer); static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, -- 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