Re: [GIT PULL] omap cleanup part1 for v3.2 merge window

2011-09-21 Thread Arnd Bergmann
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

2011-09-21 Thread Ming Lei
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

2011-09-21 Thread Paul Walmsley
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

2011-09-21 Thread Hiremath, Vaibhav

 -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

2011-09-21 Thread Paul Walmsley
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

2011-09-21 Thread Laurent Pinchart
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

2011-09-21 Thread Paul Walmsley
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

2011-09-21 Thread Yong Zhang
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

2011-09-21 Thread Yong Zhang
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

2011-09-21 Thread Arnd Bergmann
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

2011-09-21 Thread Hiremath, Vaibhav

 -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

2011-09-21 Thread Guennadi Liakhovetski
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

2011-09-21 Thread Archit Taneja

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

2011-09-21 Thread Archit Taneja

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

2011-09-21 Thread Govindraj.R
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.

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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.

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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.

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Govindraj.R
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

2011-09-21 Thread Hiremath, Vaibhav
 -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

2011-09-21 Thread Tony Lindgren
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

2011-09-21 Thread Arnd Bergmann
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Greg KH
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

2011-09-21 Thread Mark Brown
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Santosh Shilimkar
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

2011-09-21 Thread Linus Walleij
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

2011-09-21 Thread Ohad Ben-Cohen
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

2011-09-21 Thread Ohad Ben-Cohen
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Ohad Ben-Cohen
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

2011-09-21 Thread Jean Pihet
. 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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Arnd Bergmann
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread jean . pihet
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

2011-09-21 Thread Jean Pihet
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

2011-09-21 Thread Kevin Hilman
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

2011-09-21 Thread Kevin Hilman
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

2011-09-21 Thread Hemant Pedanekar
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

2011-09-21 Thread Hemant Pedanekar
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

2011-09-21 Thread Hemant Pedanekar
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

2011-09-21 Thread Hemant Pedanekar
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

2011-09-21 Thread Jason Kridner
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

2011-09-21 Thread Kevin Hilman
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

2011-09-21 Thread David Brown
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

2011-09-21 Thread Tony Lindgren
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Kevin Hilman
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

2011-09-21 Thread Jason Kridner
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Pedanekar, Hemant
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

2011-09-21 Thread Pedanekar, Hemant
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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
* 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

2011-09-21 Thread Tony Lindgren
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

2011-09-21 Thread Tony Lindgren
* 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


  1   2   >