Updating the gitignore to ignore include/asm-arm/mach-types.h

[venkat]

Hi  All,

Found that include/asm-arm/mach-types.h was generating after 
compilation which needs to be ignored by git.  Attached patch simply add 
this file to gitignore.



Regards,
Venkat.
From c1ac3148d1352716216dc020a584a0085bd3667b Mon Sep 17 00:00:00 2001
From: Venkat Raju venkat.r...@embinux.com
Date: Tue, 14 Jul 2009 10:10:30 +0530
Subject: [PATCH] Updating the gitignore to ignore include/asm-arm/mach-types.h

This file was genarating after compilation and was showing as
untracked file.

Signed-off-by: Venkat Raju venkat.r...@embinux.com
---
 .gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 51bd99d..d4928fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,6 +43,7 @@ Module.symvers
 #
 include/asm
 include/asm-*/asm-offsets.h
+include/asm-arm/mach-types.h
 include/config
 include/linux/autoconf.h
 include/linux/compile.h
-- 
1.5.3.3

RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Phil Carmody]

On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
 Thanks for the patch, it only has indentation problems, this is the 
 checkpatch output:
 
 WARNING: suspect code indent for conditional statements (8, 12)
 #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((src) == NULL) ||  \
 
 WARNING: line over 80 characters
 #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
 +   unlikely(copy_from_user(dest, src, (elements) * 
 sizeof(*(dest) { \
 
 WARNING: suspect code indent for conditional statements (8, 12)
 #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((dest) == NULL) || \
 
 WARNING: line over 80 characters
 #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
 +   unlikely(copy_to_user(dest, src, (elements) * 
 sizeof(*(src) { \
 
 total: 0 errors, 4 warnings, 48 lines checked
 
 Could you please fix that warning please?

I suspect the only way to fix those warnings would either introduce
other warnings, or \
would \
lead \
to \
utterly \
unread- \
able \
code.

If you check how and why the original TI-originated version of the code
does not follow the linux coding standards, the difficulties we would
have making a warning-free patch of it should be apparent.

Phil

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Menon, Nishanth]

Phil,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Phil Carmody
 Sent: Tuesday, July 14, 2009 6:03 AM
 
 On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
  Thanks for the patch, it only has indentation problems, this is the
 checkpatch output:
 
  WARNING: suspect code indent for conditional statements (8, 12)
  #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
  +   if (DSP_SUCCEEDED(status)) {\
  +   if (unlikely((src) == NULL) ||  \
 
  WARNING: line over 80 characters
  #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
  +   unlikely(copy_from_user(dest, src, (elements) *
 sizeof(*(dest) { \
 
  WARNING: suspect code indent for conditional statements (8, 12)
  #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
  +   if (DSP_SUCCEEDED(status)) {\
  +   if (unlikely((dest) == NULL) ||
 \
 
  WARNING: line over 80 characters
  #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
  +   unlikely(copy_to_user(dest, src, (elements) *
 sizeof(*(src) { \
 
  total: 0 errors, 4 warnings, 48 lines checked
 
  Could you please fix that warning please?
 
 I suspect the only way to fix those warnings would either introduce
 other warnings, or \
Gentle query: Have we already tried this or is it just a suspicion?


   would \
   lead \
   to \
   utterly \
   unread- \
   able \
   code.
 
 If you check how and why the original TI-originated version of the code
 does not follow the linux coding standards, the difficulties we would
 have making a warning-free patch of it should be apparent.

Past is past. The idea was not to introduce anymore warning code.

Regards,
Nishanth Menon

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP: OHCI: hc_driver's stop method should call ohci_stop

[Gadiyar, Anand]

From: Anand Gadiyar gadi...@ti.com

OMAP: OHCI: hc_driver's stop method should call ohci_stop

Without this, the ohci-omap driver will not cleanup the debugfs
nodes when the driver is unloaded. So the next insmod will fail,
if CONFIG_DEBUG_FS and CONFIG_USB_DEBUG are both selected.

Reported-by: vikram pandita vikram.pand...@ti.com
Cc: David Brownell dbrown...@users.sourceforge.net
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
Not tested. I don't have any hardware that uses this driver.

 drivers/usb/host/ohci-omap.c |1 +
 1 files changed, 1 insertion(+)

Index: linux-2.6/drivers/usb/host/ohci-omap.c
===
--- linux-2.6.orig/drivers/usb/host/ohci-omap.c
+++ linux-2.6/drivers/usb/host/ohci-omap.c
@@ -282,6 +282,7 @@ static int ohci_omap_init(struct usb_hcd
 static void ohci_omap_stop(struct usb_hcd *hcd)
 {
dev_dbg(hcd-self.controller, stopping USB Controller\n);
+   ohci_stop(hcd);
omap_ohci_clock_power(0);
 }
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Ameya Palande]

ext Menon, Nishanth wrote:
 Phil,
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Phil Carmody
 Sent: Tuesday, July 14, 2009 6:03 AM

 On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
 Thanks for the patch, it only has indentation problems, this is the
 checkpatch output:
 WARNING: suspect code indent for conditional statements (8, 12)
 #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((src) == NULL) ||  \

 WARNING: line over 80 characters
 #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
 +   unlikely(copy_from_user(dest, src, (elements) *
 sizeof(*(dest) { \
 WARNING: suspect code indent for conditional statements (8, 12)
 #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((dest) == NULL) ||
 \
 WARNING: line over 80 characters
 #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
 +   unlikely(copy_to_user(dest, src, (elements) *
 sizeof(*(src) { \
 total: 0 errors, 4 warnings, 48 lines checked

 Could you please fix that warning please?
 I suspect the only way to fix those warnings would either introduce
 other warnings, or \
 Gentle query: Have we already tried this or is it just a suspicion?
 
 
  would \
  lead \
  to \
  utterly \
  unread- \
  able \
  code.

 If you check how and why the original TI-originated version of the code
 does not follow the linux coding standards, the difficulties we would
 have making a warning-free patch of it should be apparent.
 
 Past is past. The idea was not to introduce anymore warning code.

I agree but if you want to stick to this, then I don't think we can get a
readable macro. And I personally prefer readability over warnings generated by
checkpatch.pl script.

Cheers,
Ameya.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Phil Carmody]

On Tue, 2009-07-14 at 13:05 +0200, ext Menon, Nishanth wrote:
 Phil,
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Phil Carmody
  Sent: Tuesday, July 14, 2009 6:03 AM
  
  On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
   Thanks for the patch, it only has indentation problems, this is the
  checkpatch output:
  
   WARNING: suspect code indent for conditional statements (8, 12)
   #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
   +   if (DSP_SUCCEEDED(status)) {\
   +   if (unlikely((src) == NULL) ||  \
  
   WARNING: line over 80 characters
   #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
   +   unlikely(copy_from_user(dest, src, (elements) *
  sizeof(*(dest) { \
  
   WARNING: suspect code indent for conditional statements (8, 12)
   #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
   +   if (DSP_SUCCEEDED(status)) {\
   +   if (unlikely((dest) == NULL) ||
  \
  
   WARNING: line over 80 characters
   #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
   +   unlikely(copy_to_user(dest, src, (elements) *
  sizeof(*(src) { \
  
   total: 0 errors, 4 warnings, 48 lines checked
  
   Could you please fix that warning please?
  
  I suspect the only way to fix those warnings would either introduce
  other warnings, or \
 Gentle query: Have we already tried this or is it just a suspicion?

Being an Englishman, I use various forms of irony more than others do;
that particular form's called litotes. It indeed is not a suspicion -
I tried about 4 or 5 variations, none of which were both readable and
warning-free. In the end I decided that whatever was closest to the
original would be safest.

  would \
  lead \
  to \
  utterly \
  unread- \
  able \
  code.
  
  If you check how and why the original TI-originated version of the code
  does not follow the linux coding standards, the difficulties we would
  have making a warning-free patch of it should be apparent.
 
 Past is past. The idea was not to introduce anymore warning code.

The TI code would trigger the following 4 warnings:
WARNING: suspect code indent for conditional statements (4, 12)
WARNING: line over 80 characters
WARNING: suspect code indent for conditional statements (4, 12)
WARNING: line over 80 characters
4 warnings isn't more than 4 warnings, it's no change - and as I mention
above, in the absence of an easy fix, that was deliberate.

Phil

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PM: off mode

[Roger Quadros]

Hi Kevin,

 Off mode does not seem to work on RX51 on latest PM branch. I get a reboot if 
I set enable_off_mode and sleep_while_idle and I wait for timeout.


 Does it work on other platforms?

regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Hiroshi DOYU]

From: Carmody Phil.2 (EXT-Ixonos/Helsinki) ext-phil.2.carm...@nokia.com
Subject: RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else
Date: Tue, 14 Jul 2009 13:20:30 +0200

 On Tue, 2009-07-14 at 13:05 +0200, ext Menon, Nishanth wrote:
  Phil,
   -Original Message-
   From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
   ow...@vger.kernel.org] On Behalf Of Phil Carmody
   Sent: Tuesday, July 14, 2009 6:03 AM
   
   On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
Thanks for the patch, it only has indentation problems, this is the
   checkpatch output:
   
WARNING: suspect code indent for conditional statements (8, 12)
#34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
+   if (DSP_SUCCEEDED(status)) {\
+   if (unlikely((src) == NULL) ||  \
   
WARNING: line over 80 characters
#36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
+   unlikely(copy_from_user(dest, src, (elements) *
   sizeof(*(dest) { \
   
WARNING: suspect code indent for conditional statements (8, 12)
#46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
+   if (DSP_SUCCEEDED(status)) {\
+   if (unlikely((dest) == NULL) ||
   \
   
WARNING: line over 80 characters
#48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
+   unlikely(copy_to_user(dest, src, (elements) *
   sizeof(*(src) { \
   
total: 0 errors, 4 warnings, 48 lines checked
   
Could you please fix that warning please?
   
   I suspect the only way to fix those warnings would either introduce
   other warnings, or \
  Gentle query: Have we already tried this or is it just a suspicion?
 
 Being an Englishman, I use various forms of irony more than others do;
 that particular form's called litotes. It indeed is not a suspicion -
 I tried about 4 or 5 variations, none of which were both readable and
 warning-free. In the end I decided that whatever was closest to the
 original would be safest.
 
 would \
 lead \
 to \
 utterly \
 unread- \
 able \
 code.
   
   If you check how and why the original TI-originated version of the code
   does not follow the linux coding standards, the difficulties we would
   have making a warning-free patch of it should be apparent.
  
  Past is past. The idea was not to introduce anymore warning code.
 
 The TI code would trigger the following 4 warnings:
 WARNING: suspect code indent for conditional statements (4, 12)
 WARNING: line over 80 characters
 WARNING: suspect code indent for conditional statements (4, 12)
 WARNING: line over 80 characters
 4 warnings isn't more than 4 warnings, it's no change - and as I mention
 above, in the absence of an easy fix, that was deliberate.

I am not sure if these copy_from_user() wrapping are practically
useful or not. It may be enough just to use kernel API as is. But if
there are some reason to requires strict parameter checkings or
debugging feature support for these family here, introducing inline
functions for them, instead of macro, may be another option?

For example,

Modified drivers/dsp/bridge/pmgr/wcd.c
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 86812c6..c8b26c0 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -146,16 +146,23 @@
 #define MAX_BUFS   64
 
 /* Following two macros should ideally have do{}while(0) */
+static inline void cp_fm_usr(void *to, const void __user *from,
+DSP_STATUS *err, unsigned long n)
+{
+   if (DSP_FAILED(err))
+   return;
 
-#define cp_fm_usr(dest, src, status, elements)\
-if (DSP_SUCCEEDED(status)) {\
-   if (unlikely(src == NULL) ||\
-   unlikely(copy_from_user(dest, src, elements * 
sizeof(*(dest) { \
-   GT_1trace(WCD_debugMask, GT_7CLASS, \
-   copy_from_user failed, src=0x%x\n, src);  \
-   status = DSP_EPOINTER ; \
-   } \
-}
+   if (unlikely(!from)) {
+   *err = DSP_EPOINTER ;
+   return;
+   }
+
+   if (unlikely(copy_from_user(to, from, n * sizeof(*(to) {
+   GT_1trace(WCD_debugMask, GT_7CLASS,
+ %s failed, from=0x%x\n, src, __func__);
+   *err = DSP_EPOINTER ;
+   }
+}
 
 #define cp_to_usr(dest, src, status, elements)\
 if (DSP_SUCCEEDED(status)) {\
@@ -525,7 +532,7 @@ u32 MGRWRAP_RegisterObject(union Trapped_Args *args)
char *pszPathName = NULL;
DSP_STATUS 

Re: PM: off mode

[Roger Quadros]

Roger Quadros wrote:

Hi Kevin,

 Off mode does not seem to work on RX51 on latest PM branch. I get a 
reboot if I set enable_off_mode and sleep_while_idle and I wait for 
timeout.


 Does it work on other platforms?

regards,
-roger



It works with the attached config though.

-roger
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-omap1
# Tue Jul 14 15:56:21 2009
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUPS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_CLK=y
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=cfq
CONFIG_FREEZER=y

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_LOKI is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_DAVINCI is not set
CONFIG_ARCH_OMAP=y
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_W90X900 is not set

#
# TI OMAP Implementations
#
CONFIG_ARCH_OMAP_OTG=y
# CONFIG_ARCH_OMAP1 is not set
# CONFIG_ARCH_OMAP2 is not set
CONFIG_ARCH_OMAP3=y
# CONFIG_ARCH_OMAP4 is not set

#
# OMAP Feature Selections
#
# CONFIG_OMAP_DEBUG_POWERDOMAIN is not set
# 

[PATCH 1/4] ARM: OMAP: Rename twl4030* driver files to enable re-use

[balajitk]

From: Santosh Shilimkar santosh.shilim...@ti.com

The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030
for OMAP3. The common modules like RTC, Regulator creates opportunity
to re-use the most of the code from twl4030.

This patch renames few common drivers twl4030* files to twl* to enable
the code re-use.

Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-2430sdp.c|2 +-
 arch/arm/mach-omap2/board-3430sdp.c|2 +-
 arch/arm/mach-omap2/board-ldp.c|2 +-
 arch/arm/mach-omap2/board-omap3beagle.c|2 +-
 arch/arm/mach-omap2/board-omap3pandora.c   |2 +-
 arch/arm/mach-omap2/board-overo.c  |2 +-
 drivers/gpio/twl4030-gpio.c|2 +-
 drivers/mfd/Makefile   |2 +-
 drivers/mfd/{twl4030-core.c = twl-core.c} |8 +++-
 drivers/mfd/twl4030-irq.c  |2 +-
 drivers/regulator/Makefile |2 +-
 .../{twl4030-regulator.c = twl-regulator.c}   |6 +++---
 drivers/rtc/Makefile   |2 +-
 drivers/rtc/{rtc-twl4030.c = rtc-twl.c}   |2 +-
 drivers/usb/otg/twl4030-usb.c  |2 +-
 include/linux/i2c/{twl4030.h = twl.h} |5 -
 sound/soc/codecs/twl4030.c |2 +-
 17 files changed, 24 insertions(+), 23 deletions(-)
 rename drivers/mfd/{twl4030-core.c = twl-core.c} (99%)
 rename drivers/regulator/{twl4030-regulator.c = twl-regulator.c} (99%)
 rename drivers/rtc/{rtc-twl4030.c = rtc-twl.c} (99%)
 rename include/linux/i2c/{twl4030.h = twl.h} (98%)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 9c3fdcd..7f5aac5 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -19,7 +19,7 @@
 #include linux/mtd/mtd.h
 #include linux/mtd/partitions.h
 #include linux/delay.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 #include linux/err.h
 #include linux/clk.h
 #include linux/io.h
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 496a90e..fa6645e 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -19,7 +19,7 @@
 #include linux/input.h
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 #include linux/regulator/machine.h
 #include linux/io.h
 #include linux/gpio.h
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index d8bc0a7..cf8244a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -23,7 +23,7 @@
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
 #include linux/regulator/machine.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 #include linux/io.h
 #include linux/smsc911x.h
 
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 991ac9c..455f65d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -29,7 +29,7 @@
 #include linux/mtd/nand.h
 
 #include linux/regulator/machine.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 
 #include mach/hardware.h
 #include asm/mach-types.h
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
index e32aa23..47b5ee4 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -24,7 +24,7 @@
 #include linux/spi/spi.h
 #include linux/spi/ads7846.h
 #include linux/regulator/machine.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 #include linux/leds.h
 #include linux/input.h
 #include linux/gpio_keys.h
diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index dff5528..744ff80 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -26,7 +26,7 @@
 #include linux/io.h
 #include linux/kernel.h
 #include linux/platform_device.h
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 #include linux/regulator/machine.h
 
 #include linux/mtd/mtd.h
diff --git a/drivers/gpio/twl4030-gpio.c b/drivers/gpio/twl4030-gpio.c
index afad147..8446399 100644
--- a/drivers/gpio/twl4030-gpio.c
+++ b/drivers/gpio/twl4030-gpio.c
@@ -34,7 +34,7 @@
 #include linux/platform_device.h
 #include linux/slab.h
 
-#include linux/i2c/twl4030.h
+#include linux/i2c/twl.h
 
 
 /*
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 6f8a9a1..4e9d513 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_MFD_WM8350_I2C)  += wm8350-i2c.o
 obj-$(CONFIG_TPS65010) += tps65010.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 

Re: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Phil Carmody]

On Tue, 2009-07-14 at 14:30 +0200, Doyu Hiroshi (Nokia-D/Helsinki)
wrote:
 From: Carmody Phil.2 (EXT-Ixonos/Helsinki) ext-phil.2.carm...@nokia.com
 Subject: RE: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an 
 if/else
 Date: Tue, 14 Jul 2009 13:20:30 +0200
 
  On Tue, 2009-07-14 at 13:05 +0200, ext Menon, Nishanth wrote:
   Phil,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phil Carmody
Sent: Tuesday, July 14, 2009 6:03 AM

On Fri, 2009-07-10 at 01:51 +0200, ext Guzman Lugo, Fernando wrote:
 Thanks for the patch, it only has indentation problems, this is the
checkpatch output:

 WARNING: suspect code indent for conditional statements (8, 12)
 #34: FILE: drivers/dsp/bridge/pmgr/wcd.c:152:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((src) == NULL) ||  \

 WARNING: line over 80 characters
 #36: FILE: drivers/dsp/bridge/pmgr/wcd.c:154:
 +   unlikely(copy_from_user(dest, src, (elements) *
sizeof(*(dest) { \

 WARNING: suspect code indent for conditional statements (8, 12)
 #46: FILE: drivers/dsp/bridge/pmgr/wcd.c:164:
 +   if (DSP_SUCCEEDED(status)) {\
 +   if (unlikely((dest) == NULL) ||
\

 WARNING: line over 80 characters
 #48: FILE: drivers/dsp/bridge/pmgr/wcd.c:166:
 +   unlikely(copy_to_user(dest, src, (elements) *
sizeof(*(src) { \

 total: 0 errors, 4 warnings, 48 lines checked

 Could you please fix that warning please?

I suspect the only way to fix those warnings would either introduce
other warnings, or \
   Gentle query: Have we already tried this or is it just a suspicion?
  
  Being an Englishman, I use various forms of irony more than others do;
  that particular form's called litotes. It indeed is not a suspicion -
  I tried about 4 or 5 variations, none of which were both readable and
  warning-free. In the end I decided that whatever was closest to the
  original would be safest.
  
would \
lead \
to \
utterly \
unread- \
able \
code.

If you check how and why the original TI-originated version of the code
does not follow the linux coding standards, the difficulties we would
have making a warning-free patch of it should be apparent.
   
   Past is past. The idea was not to introduce anymore warning code.
  
  The TI code would trigger the following 4 warnings:
  WARNING: suspect code indent for conditional statements (4, 12)
  WARNING: line over 80 characters
  WARNING: suspect code indent for conditional statements (4, 12)
  WARNING: line over 80 characters
  4 warnings isn't more than 4 warnings, it's no change - and as I mention
  above, in the absence of an easy fix, that was deliberate.
 
 I am not sure if these copy_from_user() wrapping are practically
 useful or not. It may be enough just to use kernel API as is. But if
 there are some reason to requires strict parameter checkings or
 debugging feature support for these family here, introducing inline
 functions for them, instead of macro, may be another option?

I did mention that possibility to Ameya. In the 21st century, I think we
should be able to trust the compiler to generate identical code from
inline functions as functional macros. (Are we allowed to use 'restrict'
pointers?)

 For example,
 
   Modified drivers/dsp/bridge/pmgr/wcd.c
 diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
 index 86812c6..c8b26c0 100644
 --- a/drivers/dsp/bridge/pmgr/wcd.c
 +++ b/drivers/dsp/bridge/pmgr/wcd.c
 @@ -146,16 +146,23 @@
  #define MAX_BUFS 64
  
  /* Following two macros should ideally have do{}while(0) */
 +static inline void cp_fm_usr(void *to, const void __user *from,
 +  DSP_STATUS *err, unsigned long n)
 +{
 + if (DSP_FAILED(err))

*err

 + return;
  
 -#define cp_fm_usr(dest, src, status, elements)\
 -if (DSP_SUCCEEDED(status)) {\
 - if (unlikely(src == NULL) ||\
 - unlikely(copy_from_user(dest, src, elements * 
 sizeof(*(dest) { \
 - GT_1trace(WCD_debugMask, GT_7CLASS, \
 - copy_from_user failed, src=0x%x\n, src);  \
 - status = DSP_EPOINTER ; \
 - } \
 -}
 + if (unlikely(!from)) {
 + *err = DSP_EPOINTER ;
 + return;
 + }
 +
 + if 

[PATCH 2/4] ARM: OMAP: Rename all twl4030_i2c*.

[balajitk]

From: Balaji T K balaj...@ti.com

 This patch renames function names like twl4030_i2c_write_u8,
 twl4030_i2c_read_u8 to twl_i2c_write_u8, twl_i2c_read_u8.
 I2C address for modules(MADC, Battery Charger, Audio, RTC)
 have changed between 4030 and 6030. Base address of these module register also
 changed. Thus twl4030_map will be different for twl4030 and twl6030.

Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-2430sdp.c  |4 +-
 arch/arm/mach-omap2/board-3430sdp.c  |   12 +-
 arch/arm/mach-omap2/board-ldp.c  |   10 +-
 arch/arm/mach-omap2/board-omap3beagle.c  |4 +-
 arch/arm/mach-omap2/board-omap3pandora.c |8 +-
 arch/arm/mach-omap2/board-overo.c|6 +-
 drivers/gpio/twl4030-gpio.c  |   24 +++---
 drivers/mfd/twl-core.c   |  159 -
 drivers/mfd/twl4030-irq.c|   18 ++--
 drivers/regulator/twl-regulator.c|8 +-
 drivers/rtc/rtc-twl.c|   14 ++--
 drivers/usb/otg/twl4030-usb.c|   40 
 include/linux/i2c/twl.h  |   73 ++
 sound/soc/codecs/twl4030.c   |   16 ++--
 14 files changed, 223 insertions(+), 173 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 7f5aac5..fa34798 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -156,13 +156,13 @@ static struct omap_board_config_kernel sdp2430_config[] = 
{
 };
 
 
-static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
+static struct twl_gpio_platform_data sdp2430_gpio_data = {
.gpio_base  = OMAP_MAX_GPIO_LINES,
.irq_base   = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
 };
 
-static struct twl4030_platform_data sdp2430_twldata = {
+static struct twl_platform_data sdp2430_twldata = {
.irq_base   = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
 
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index fa6645e..85193d7 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -88,7 +88,7 @@ static int sdp3430_keymap[] = {
0
 };
 
-static struct twl4030_keypad_data sdp3430_kp_data = {
+static struct twl_keypad_data sdp3430_kp_data = {
.rows   = 5,
.cols   = 6,
.keymap = sdp3430_keymap,
@@ -198,7 +198,7 @@ static int sdp3430_batt_table[] = {
 4040,   3910,   3790,   3670,   3550
 };
 
-static struct twl4030_bci_platform_data sdp3430_bci_data = {
+static struct twl_bci_platform_data sdp3430_bci_data = {
.battery_tmp_tbl= sdp3430_batt_table,
.tblsize= ARRAY_SIZE(sdp3430_batt_table),
 };
@@ -260,7 +260,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
return 0;
 }
 
-static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
+static struct twl_gpio_platform_data sdp3430_gpio_data = {
.gpio_base  = OMAP_MAX_GPIO_LINES,
.irq_base   = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
@@ -269,11 +269,11 @@ static struct twl4030_gpio_platform_data 
sdp3430_gpio_data = {
.setup  = sdp3430_twl_gpio_setup,
 };
 
-static struct twl4030_usb_data sdp3430_usb_data = {
+static struct twl_usb_data sdp3430_usb_data = {
.usb_mode   = T2_USB_MODE_ULPI,
 };
 
-static struct twl4030_madc_platform_data sdp3430_madc_data = {
+static struct twl_madc_platform_data sdp3430_madc_data = {
.irq_line   = 1,
 };
 
@@ -409,7 +409,7 @@ static struct regulator_init_data sdp3430_vpll2 = {
.consumer_supplies  = sdp3430_vdvi_supply,
 };
 
-static struct twl4030_platform_data sdp3430_twldata = {
+static struct twl_platform_data sdp3430_twldata = {
.irq_base   = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
 
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index cf8244a..eb91056 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -101,7 +101,7 @@ static int ldp_twl4030_keymap[] = {
0
 };
 
-static struct twl4030_keypad_data ldp_kp_twl4030_data = {
+static struct twl_keypad_data ldp_kp_twl4030_data = {
.rows   = 6,
.cols   = 6,
.keymap = ldp_twl4030_keymap,
@@ -294,17 +294,17 @@ static struct omap_board_config_kernel ldp_config[] 
__initdata = {
{ OMAP_TAG_LCD, ldp_lcd_config },
 };
 
-static struct twl4030_usb_data ldp_usb_data = {
+static struct twl_usb_data ldp_usb_data = {
.usb_mode   = T2_USB_MODE_ULPI,
 };
 
-static struct twl4030_gpio_platform_data ldp_gpio_data = {
+static struct twl_gpio_platform_data ldp_gpio_data = {
.gpio_base  = 

[PATCH 3/4] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it generic rtc

[balajitk]

From: Balaji T K balaj...@ti.com

 This patch renames all twl4030_ functions to twl_ so that RTC driver can be
 shared between Triton and Phoenix.  Register addresses which have changed will
 be selected with COMPILATION FLAG

Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Nayak Rajendra rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/mfd/twl-core.c |2 +-
 drivers/rtc/rtc-twl.c  |  124 
 2 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 7cd1b01..95d92db 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -528,7 +528,7 @@ add_children(struct twl_platform_data *pdata, unsigned long 
features)
 * Eventually, Linux might become more aware of such
 * HW security concerns, and least privilege.
 */
-   child = add_child(RTC_SUB_CHIP_ID, twl4030_rtc,
+   child = add_child(RTC_SUB_CHIP_ID, twl_rtc,
NULL, 0,
true, pdata-irq_base + RTC_INTR_OFFSET, 0);
if (IS_ERR(child))
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 6119712..630acb7 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -88,13 +88,13 @@
 /*
  * Supports 1 byte read from TWL4030 RTC register.
  */
-static int twl4030_rtc_read_u8(u8 *data, u8 reg)
+static int twl_rtc_read_u8(u8 *data, u8 reg)
 {
int ret;
 
-   ret = twl_i2c_read_u8(TWL4030_MODULE_RTC, data, reg);
+   ret = twl_i2c_read_u8(TWL_MODULE_RTC, data, reg);
if (ret  0)
-   pr_err(twl4030_rtc: Could not read TWL4030
+   pr_err(twl_rtc: Could not read TWL4030
   register %X - error %d\n, reg, ret);
return ret;
 }
@@ -102,13 +102,13 @@ static int twl4030_rtc_read_u8(u8 *data, u8 reg)
 /*
  * Supports 1 byte write to TWL4030 RTC registers.
  */
-static int twl4030_rtc_write_u8(u8 data, u8 reg)
+static int twl_rtc_write_u8(u8 data, u8 reg)
 {
int ret;
 
-   ret = twl_i2c_write_u8(TWL4030_MODULE_RTC, data, reg);
+   ret = twl_i2c_write_u8(TWL_MODULE_RTC, data, reg);
if (ret  0)
-   pr_err(twl4030_rtc: Could not write TWL4030
+   pr_err(twl_rtc: Could not write TWL4030
   register %X - error %d\n, reg, ret);
return ret;
 }
@@ -129,7 +129,7 @@ static int set_rtc_irq_bit(unsigned char bit)
 
val = rtc_irq_bits | bit;
val = ~BIT_RTC_INTERRUPTS_REG_EVERY_M;
-   ret = twl4030_rtc_write_u8(val, REG_RTC_INTERRUPTS_REG);
+   ret = twl_rtc_write_u8(val, REG_RTC_INTERRUPTS_REG);
if (ret == 0)
rtc_irq_bits = val;
 
@@ -145,14 +145,14 @@ static int mask_rtc_irq_bit(unsigned char bit)
int ret;
 
val = rtc_irq_bits  ~bit;
-   ret = twl4030_rtc_write_u8(val, REG_RTC_INTERRUPTS_REG);
+   ret = twl_rtc_write_u8(val, REG_RTC_INTERRUPTS_REG);
if (ret == 0)
rtc_irq_bits = val;
 
return ret;
 }
 
-static int twl4030_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
+static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
 {
int ret;
 
@@ -164,7 +164,7 @@ static int twl4030_rtc_alarm_irq_enable(struct device *dev, 
unsigned enabled)
return ret;
 }
 
-static int twl4030_rtc_update_irq_enable(struct device *dev, unsigned enabled)
+static int twl_rtc_update_irq_enable(struct device *dev, unsigned enabled)
 {
int ret;
 
@@ -185,23 +185,23 @@ static int twl4030_rtc_update_irq_enable(struct device 
*dev, unsigned enabled)
  *  - Months are 1..12 vs Linux 0-11
  *  - Years are 0..99 vs Linux 1900..N (we assume 21st century)
  */
-static int twl4030_rtc_read_time(struct device *dev, struct rtc_time *tm)
+static int twl_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
unsigned char rtc_data[ALL_TIME_REGS + 1];
int ret;
u8 save_control;
 
-   ret = twl4030_rtc_read_u8(save_control, REG_RTC_CTRL_REG);
+   ret = twl_rtc_read_u8(save_control, REG_RTC_CTRL_REG);
if (ret  0)
return ret;
 
save_control |= BIT_RTC_CTRL_REG_GET_TIME_M;
 
-   ret = twl4030_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
+   ret = twl_rtc_write_u8(save_control, REG_RTC_CTRL_REG);
if (ret  0)
return ret;
 
-   ret = twl_i2c_read(TWL4030_MODULE_RTC, rtc_data,
+   ret = twl_i2c_read(TWL_MODULE_RTC, rtc_data,
   REG_SECONDS_REG, ALL_TIME_REGS);
 
if (ret  0) {
@@ -219,7 +219,7 @@ static int twl4030_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
return ret;
 }
 
-static int twl4030_rtc_set_time(struct device *dev, struct rtc_time *tm)
+static int twl_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
unsigned char save_control;

[PATCH 4/4] ARM: OMAP: Rename twl4030_ to twl_ in twl-regulator.c to make it generic reg

[balajitk]

From: Rajendra Nayak rna...@ti.com

 This patch renames all twl4030_ functions to twl so that regulator driver
 can be reused by Triton - TWL4030 and Phoenix - TWL6030.

Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 drivers/mfd/twl-core.c|3 +-
 drivers/regulator/twl-regulator.c |  191 +++--
 2 files changed, 100 insertions(+), 94 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 95d92db..f40768b 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -124,6 +124,7 @@
 #define KEYPAD_SUB_CHIP_ID SUB_CHIP_ID2
 #define BCI_SUB_CHIP_ID SUB_CHIP_ID3
 #define RTC_SUB_CHIP_ID SUB_CHIP_ID3
+#define REG_SUB_CHIP_ID SUB_CHIP_ID3
 
 /* Last - for index max*/
 #define TWL4030_MODULE_LASTTWL4030_MODULE_SECURED_REG
@@ -463,7 +464,7 @@ add_regulator_linked(int num, struct regulator_init_data 
*pdata,
}
 
/* NOTE:  we currently ignore regulator IRQs, e.g. for short circuits */
-   return add_numbered_child(3, twl4030_reg, num,
+   return add_numbered_child(REG_SUB_CHIP_ID, twl_reg, num,
pdata, sizeof(*pdata), false, 0, 0);
 }
 
diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index 68c941d..d01aa4e 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1,5 +1,5 @@
 /*
- * twl4030-regulator.c -- support regulators in twl4030 family chips
+ * twl-regulator.c -- support regulators in twl4030/twl6030 family chips
  *
  * Copyright (C) 2008 David Brownell
  *
@@ -19,7 +19,7 @@
 
 
 /*
- * The TWL4030/TW5030/TPS659x0 family chips include power management, a
+ * The TWL4030/TW5030/TPS659x0/TWL6030 family chips include power management, a
  * USB OTG transceiver, an RTC, ADC, PWM, and lots more.  Some versions
  * include an audio codec, battery charger, and more voltage regulators.
  * These chips are often used in OMAP-based systems.
@@ -33,7 +33,7 @@ struct twlreg_info {
/* start of regulator's PM_RECEIVER control register bank */
u8  base;
 
-   /* twl4030 resource ID, for resource control state machine */
+   /* twl resource ID, for resource control state machine */
u8  id;
 
/* voltage in mV = table[VSEL]; table_len must be a power-of-two */
@@ -59,20 +59,20 @@ struct twlreg_info {
 
 
 static inline int
-twl4030reg_read(struct twlreg_info *info, unsigned offset)
+twlreg_read(struct twlreg_info *info, unsigned offset)
 {
u8 value;
int status;
 
-   status = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
+   status = twl_i2c_read_u8(TWL_MODULE_PM_RECEIVER,
value, info-base + offset);
return (status  0) ? status : value;
 }
 
 static inline int
-twl4030reg_write(struct twlreg_info *info, unsigned offset, u8 value)
+twlreg_write(struct twlreg_info *info, unsigned offset, u8 value)
 {
-   return twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+   return twl_i2c_write_u8(TWL_MODULE_PM_RECEIVER,
value, info-base + offset);
 }
 
@@ -80,9 +80,9 @@ twl4030reg_write(struct twlreg_info *info, unsigned offset, 
u8 value)
 
 /* generic power resource operations, which work on all regulators */
 
-static int twl4030reg_grp(struct regulator_dev *rdev)
+static int twlreg_grp(struct regulator_dev *rdev)
 {
-   return twl4030reg_read(rdev_get_drvdata(rdev), VREG_GRP);
+   return twlreg_read(rdev_get_drvdata(rdev), VREG_GRP);
 }
 
 /*
@@ -94,9 +94,9 @@ static int twl4030reg_grp(struct regulator_dev *rdev)
 #define P2_GRP BIT(6)  /* secondary processor, modem, etc */
 #define P1_GRP BIT(5)  /* CPU/Linux */
 
-static int twl4030reg_is_enabled(struct regulator_dev *rdev)
+static int twlreg_is_enabled(struct regulator_dev *rdev)
 {
-   int state = twl4030reg_grp(rdev);
+   int state = twlreg_grp(rdev);
 
if (state  0)
return state;
@@ -104,35 +104,35 @@ static int twl4030reg_is_enabled(struct regulator_dev 
*rdev)
return (state  P1_GRP) != 0;
 }
 
-static int twl4030reg_enable(struct regulator_dev *rdev)
+static int twlreg_enable(struct regulator_dev *rdev)
 {
struct twlreg_info  *info = rdev_get_drvdata(rdev);
int grp;
 
-   grp = twl4030reg_read(info, VREG_GRP);
+   grp = twlreg_read(info, VREG_GRP);
if (grp  0)
return grp;
 
grp |= P1_GRP;
-   return twl4030reg_write(info, VREG_GRP, grp);
+   return twlreg_write(info, VREG_GRP, grp);
 }
 
-static int twl4030reg_disable(struct regulator_dev *rdev)
+static int twlreg_disable(struct regulator_dev *rdev)
 {
struct twlreg_info  *info = rdev_get_drvdata(rdev);
int grp;
 
-   grp = twl4030reg_read(info, VREG_GRP);

[PATCH 0/4] TWL patch series

[Krishnamoorthy, Balaji T]

The upcoming TWL6030 is companion chip for OMAP4 like the current TWL4030
for OMAP3. The common modules like RTC, Regulator creates opportunity
to re-use the most of the code from twl4030.

Summary of Major difference between Triton and Phoenix chips are:
-GPIO, Keypad is not present in Phoenix
-I2C Chips addresses of modules like RTC, BCI, ADC, USB, PMC 
Master/Slave 
 have changed.  Base address of these module register is also 
changed.
-PIH and SIH, module interrupt status registers will be replaced by 
PIH 
 (INT_STS_A, INT_STS_B and INT_STS_C) and module interrupt status 
registers
-MADC to GPADC in Phoenix, 17 channels supported
 GPADC in Phoenix supports Realtime, Asynchronous SW request.
-RTC register offsets have changed. Addition/removal of LDO/SMPS 
Voltage 
 Regulators

These patches are generated against mainline 2.6.31-rc1 and validated on OMAP 
3430 SDP for RTC driver and regulator drivers.

[PATCH 1/4] ARM: OMAP: Rename twl4030* driver files to enable re-use
[PATCH 2/4] ARM: OMAP: Rename all twl4030_i2c*.
[PATCH 3/4] ARM: OMAP: Rename twl4030_ in rtc-twl.c to make it 
generic twl rtc
[PATCH 4/4] Rename twl4030_ to twl_ in twl-regulator.c to make it 
generic twl reg

Below files needs updates/investigation for the possible re-use:
drivers/gpio/twl4030-gpio.c
drivers/usb/otg/twl4030-usb.c
drivers/input/misc/twl4030-pwrbutton.c
arch/arm/mach-omap2/board-rx51-peripherals.c
arch/arm/mach-omap2/board-omap3evm.c

Please provide your feedback on this patch series.

Thanks !!
Balaji T K--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How to turn off LED backlight drivers for LG Philips 4.3 LCD display when system suspends

[Elvis Dowson]

Hi,
	I was wondering if someone could give me some pointers on what I  
should modify in order to turn off the LED backlight drivers on my LG  
Philips 4.3 LCD display.


This display turns bright white when there is not signal input, and I  
am using it with android-2.6.29 kernel version.


So, when the system tries to suspend, the LED backlight drivers for  
the LCD panel are still active.


Best regards,

Elvis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Problems configuring OMAP35x ISP driver

[Zach LeRoy]

Hello Sergio,

I spoke with you earlier about using the ISP and omap34xxcam drivers with a 
micron mt9d111 SOC sensor.  I have since been able to take pictures, but the 
sensor data is not making it through the ISP data-path correctly.  I know the 
problem is in the ISP data-path because I am configuring the sensor the exact 
same way as I have been on my working PXA system.  I am expecting 4:2:2 packed 
YUV data, but all of the U and V data is no more than 2 bits where it should be 
8.  I know the ISP has a lot of capabilities, but all I want to use it for is 
grabbing 8-bit data from my sensor and putting it in a buffer untouched using 
the CCDC interface (and of course clocking and timing).  What are the key steps 
to take to get this type of configuration?  

Other Questions:

Is there any processing done on YUV data in the ISP driver by default that I am 
missing?
Has any one else experienced similar problems while adding new sensor support?

Any help here would be greatly appreciated.

Thank you,

Zach LeRoy
--
To unsubscribe from this list: send the line unsubscribe 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: PM: off mode

[Kevin Hilman]

Roger Quadros ext-roger.quad...@nokia.com writes:

 Hi Kevin,

  Off mode does not seem to work on RX51 on latest PM branch. I get a
 reboot if I set enable_off_mode and sleep_while_idle and I wait for
 timeout.

  Does it work on other platforms?


Yes, I tested on SDP, omap3evm, Beagle, Overo and RX51.

On RX51, I'm using omap3_pm_defconfig with the debug UART changed to
UART3 and things work fine here.

I using rootfs from latest fiasco image, and it drops me into an early
shell because /sbin/preinit fails in various ways. Note that I'm using
an S2.0 GP board.  Note also that I modified /sbin/preinit to launch
another getty on ttyS2 so I get a shell since newer kernels ignore the
ATAGs passed by nolo.

Below is a console log of my boot so you can see what is going on.
Because /sbin/preinit enables off-mode and sleep_while_idle, I just
let it boot and it seems to work.

Kevin




40V


NOLO X-Loader (v1.4.1, Mar 25 2009)
Secondary image size 94388
Booting secondary
[   0.001] Nokia OMAP Loader v1.4.1 (Mar 25 2009) running on Nokia N00 S2.0 
(RX-51)
[   0.011] I2C v3.12
[   0.016] System DMA v4.0
[   0.020] OneNAND device ID 0040, version ID 0121 (256 MiB, 66 MHz)
[   0.054]   OneNAND blocks unlocked in 28034 us
[   0.059]   Flash id: ec4021
[   0.073] Partition table successfully read
[   0.081] Forcing power key boot reason (RD flag set)
[   0.086] Reset reason: pwr_key
[   0.089] McSPI v2.1
[   0.092] LP5523 found at I2C bus 2, address 0x32
[   0.099] SMB138C: Not loading driver (version reg. 0x4a)
[   0.104] BQ24150 (rev. 2) found on I2C bus 1, address 0x6b
[   0.110] SSI version 1.0
[   0.116] Battery voltage 3.668 V, BSI: 56
[   0.122] Disabling charging (no battery present)
[   0.128] Initializing LCD panel
[   0.131]   Detecting LCD panel moscow
[   0.135] Panel ID: 298b5c
[   0.138]   Detected LCD panel: l4f00311
[   0.142] DISPC: version 3.0
[   0.147]   LCD pixel clock 19200 kHz
[   0.178]   Logo drawn in 5 ms (11700 kB/s)
[   0.286] Initializing USB
[   0.290]   USB host detected
[   0.293]   Entering USB loop
[   0.345] USB suspend signaling detected
[   0.497] USB reset received
[   0.569] SETUP: RD STD DEVICEGET_DESCRIPTOR DEVICE (value 00, index 
, length 64 bytes)
[   0.583] USB reset received
[   0.653] SETUP: WR STD DEVICESET_ADDRESSvalue 002d index  
length 
[   0.680] SETUP: RD STD DEVICEGET_DESCRIPTOR DEVICE (value 00, index 
, length 18 bytes)
[   0.689] SETUP: RD STD DEVICEGET_DESCRIPTOR CONFIGURATION (value 00, 
index , length 9 bytes)
[   0.700] SETUP: RD STD DEVICEGET_DESCRIPTOR CONFIGURATION (value 00, 
index , length 94 bytes)
[   0.710] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 00, index 
, length 255 bytes)
[   0.720] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 02, index 
0409, length 255 bytes)
[   0.730] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 01, index 
0409, length 255 bytes)
[   0.741] SETUP: WR STD DEVICESET_CONFIGURATION  value 0001 index  
length 
[   0.749] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 03, index 
0409, length 255 bytes)
[   0.760] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 04, index 
0409, length 255 bytes)
[   0.774] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 04, index 
0409, length 255 bytes)
[   0.787] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 04, index 
0409, length 255 bytes)
[   0.801] SETUP: WR STD INTERFACE SET_INTERFACE  value 0001 index 0002 
length 
[   0.809] Flashing interface selected
[   0.813] SETUP: RD STD DEVICEGET_DESCRIPTOR STRING (value 04, index 
0409, length 255 bytes)
[   0.823] SETUP: RD VND DEVICEreq 01 value  index  length 0004
[   0.830] Flashing mode entered
[   0.833] SETUP: RD VND DEVICEreq 01 value  index  length 0004
[   0.840] SETUP: RD VND DEVICEreq 04 value  index  length 0200
[   0.848] SETUP: RD VND DEVICEreq 03 value  index  length 0004
[   0.856] SETUP: WR VND DEVICEreq 12 value  index  length 0012
[   0.864] SETUP: RD VND DEVICEreq 14 value  index  length 0200
[   0.872] SETUP: WR VND DEVICEreq 42 value  index  length 001b
[   0.879] Receiving kernel (length 1822976)
[   0.941] Image successfully received
[   1.042] SETUP: WR VND DEVICEreq 82 value  index  length 0092
[   1.050] SETUP: WR STD INTERFACE SET_INTERFACE  value  index 0002 
length 
[   1.100] Boot requested (normal mode)
Kernel command line: init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs 
rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw console=ttyMTD,log 
console=ttyS2,115200
[   1.120] Serial console disabled
Uncompressing 
Linux...
 done, booting the kernel.
Linux version 

AW: Problems configuring OMAP35x ISP driver

[Jesko Schwarzer]

Hello Zach,

unfortunately I cannot help you, but maybe you can tell me what driver you
use? Where I can find it?

Thanks in advance
/Jesko

-Ursprüngliche Nachricht-
Von: linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] Im Auftrag von Zach LeRoy
Gesendet: Dienstag, 14. Juli 2009 18:49
An: Aguirre Rodriguez, Sergio
Cc: linux-media; linux-omap
Betreff: Problems configuring OMAP35x ISP driver

Hello Sergio,

I spoke with you earlier about using the ISP and omap34xxcam drivers with a
micron mt9d111 SOC sensor.  I have since been able to take pictures, but the
sensor data is not making it through the ISP data-path correctly.  I know
the problem is in the ISP data-path because I am configuring the sensor the
exact same way as I have been on my working PXA system.  I am expecting
4:2:2 packed YUV data, but all of the U and V data is no more than 2 bits
where it should be 8.  I know the ISP has a lot of capabilities, but all I
want to use it for is grabbing 8-bit data from my sensor and putting it in a
buffer untouched using the CCDC interface (and of course clocking and
timing).  What are the key steps to take to get this type of configuration?


Other Questions:

Is there any processing done on YUV data in the ISP driver by default that I
am missing?
Has any one else experienced similar problems while adding new sensor
support?

Any help here would be greatly appreciated.

Thank you,

Zach LeRoy
--
To unsubscribe from this list: send the line unsubscribe linux-media 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

Stable PM release for Overo

[Elvis Dowson]

Hi Kevin,

On Jul 14, 2009, at 8:58 PM, Kevin Hilman wrote:


Yes, I tested on SDP, omap3evm, Beagle, Overo and RX51.


Would you happen to have a stable PM release that works with the  
Overo, for linux-omap3-2.6.29 ? I still don't have a stable pm version  
working, get problems with it trying to suspend, when a USB device is  
connected, etc.


Best regards,

Elvis

--
To unsubscribe from this list: send the line unsubscribe 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: Stable PM release for Overo

[Kevin Hilman]

Elvis Dowson elvis.dow...@mac.com writes:

 Hi Kevin,

 On Jul 14, 2009, at 8:58 PM, Kevin Hilman wrote:

 Yes, I tested on SDP, omap3evm, Beagle, Overo and RX51.

 Would you happen to have a stable PM release that works with the
 Overo, for linux-omap3-2.6.29?  

I've only tested the current PM branch (2.6.30 based) on Overo since I
just recieved hardware, and I have no plans to test/support pm-2.6.29
on new platforms.

In the initial announcment of the new PM branch, I mentioned I tested
on Overo, but that Overo support in linux-omap master needs some
updates and some testing before the PM branch will be very usable.

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: Problems configuring OMAP35x ISP driver

[Eino-Ville Talvala]

Zach,

We've gotten a Aptina MT9P031 driver working with the latest ISP 
patchset, both with YUV and RAW data.
I don't know what the problem might be with YUYV data - we get useful 
YUYV data without any changes to the ISP defaults.
However, to request RAW data, that simply uses the CCDC and bypasses all 
the processing in the ISP, request the pixelformat of 
V4L2_PIX_FMT_SGRBG10.  This will give you two bytes per pixel, at least 
in our case (although we have a 12-bit sensor cut down to 10 bits), so 
be prepared to throw out every other byte.


Hope this helps,

Eino-Ville (Eddy) Talvala
Computer Graphics Lab
Stanford University

On 7/14/2009 9:49 AM, Zach LeRoy wrote:

Hello Sergio,

I spoke with you earlier about using the ISP and omap34xxcam drivers with a 
micron mt9d111 SOC sensor.  I have since been able to take pictures, but the 
sensor data is not making it through the ISP data-path correctly.  I know the 
problem is in the ISP data-path because I am configuring the sensor the exact 
same way as I have been on my working PXA system.  I am expecting 4:2:2 packed 
YUV data, but all of the U and V data is no more than 2 bits where it should be 
8.  I know the ISP has a lot of capabilities, but all I want to use it for is 
grabbing 8-bit data from my sensor and putting it in a buffer untouched using 
the CCDC interface (and of course clocking and timing).  What are the key steps 
to take to get this type of configuration?

Other Questions:

Is there any processing done on YUV data in the ISP driver by default that I am 
missing?
Has any one else experienced similar problems while adding new sensor support?

Any help here would be greatly appreciated.

Thank you,

Zach LeRoy
--
To unsubscribe from this list: send the line unsubscribe 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: Stable PM release for Overo

[Elvis Dowson]

Hi Kevin,
			So, what would you recommend that I do. I need DSS2 and a stable  
working PM with android.


Do you recommend that I rebase my development efforts on the linux- 
omap-2.6 master branch or on your pm branch, in which case does your  
pm branch incorporate all of tomi's dss2 patches?


If you can guide me on this one, what I shall do, is try to port all  
the android 2.6.29 kernel sources to either v2.6.30 or v2.6.31.


I'm going to have to put in a huge effort to do this, so might as well  
do it with a branch that you recommend.


Best regards,

Elvis

On Jul 14, 2009, at 9:28 PM, Kevin Hilman wrote:





I've only tested the current PM branch (2.6.30 based) on Overo since I
just recieved hardware, and I have no plans to test/support pm-2.6.29
on new platforms.

In the initial announcment of the new PM branch, I mentioned I tested
on Overo, but that Overo support in linux-omap master needs some
updates and some testing before the PM branch will be very usable.


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bitsperlong.h missing in asm-arm?

[Eino-Ville Talvala]

Hi,

I'm not at all familiar with the way the asm-* include directories are 
handled, but with the current linux-omap tree, I'm getting a user-space 
compilation error with the CodeSourcery 2009q1 release:


In file included from 
/CodeSourcery/arm-gcc-2009q1/bin/../arm-none-linux-gnueabi/libc/usr/include/asm/types.h:
linux-omap-2.6/include/asm-generic/int-ll64.h:11:29: error: 
asm/bitsperlong.h: No such file or directory


It doesn't look like just a CodeSourcery issue, since the missing 
reference is actually in asm-generic/int-ll64.h.


Am I doing something incorrect, or is something missing in 
include/asm-arm  ?


Thanks,

Eddy Talvala
Computer Graphics Lab
Stanford University


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] OMAP3: PM: move context-loss counting into OMAP PM

[Madhusudhan]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Kevin Hilman
 Sent: Wednesday, July 08, 2009 1:34 PM
 To: linux-omap@vger.kernel.org
 Cc: Rajendra Nayak; Peter 'p2' De Schrijver
 Subject: [PATCH] OMAP3: PM: move context-loss counting into OMAP PM
 
 From: Rajendra Nayak rna...@ti.com
 
 Drop get_last_off_on_transaction_id() and move functionality
 into OMAP PM layer.
 
 For SRF, use omapdev** to get powerdomain state counte
 for NOOP, use an increasing counter to ensure context is always restord.
 
 **NOTE: in future PM branch, this omapdev functinality will be replaced
 by omap_hwmod.  Thus, context loss counting will only exist
 for modules with omap_hwmod implementations.
 
 Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
 ---
 Applies to current PM branch and pm-2.6.29
 
  arch/arm/mach-omap2/pm.c  |   16 
  arch/arm/plat-omap/omap-pm-noop.c |7 ++-
  arch/arm/plat-omap/omap-pm-srf.c  |   11 +++
  3 files changed, 17 insertions(+), 17 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
 index 1192e01..fec7d00 100644
 --- a/arch/arm/mach-omap2/pm.c
 +++ b/arch/arm/mach-omap2/pm.c
 @@ -31,7 +31,6 @@
  #include asm/atomic.h
 
  #include mach/powerdomain.h
 -#include mach/omapdev.h
  #include mach/resource.h
  #include mach/omap34xx.h
 
 @@ -221,21 +220,6 @@ void omap2_allow_sleep(void)
   BUG_ON(i  0);
  }
 
 -unsigned get_last_off_on_transaction_id(struct device *dev)
 -{
 - struct platform_device *pdev = to_platform_device(dev);
 - struct omapdev *odev = omapdev_find_pdev(pdev);
 - struct powerdomain *pwrdm;
 -
 - if (odev) {
 - pwrdm = omapdev_get_pwrdm(odev);
 - if (pwrdm)
 - return pwrdm-state_counter[0];
 - }
 -
 - return 0;
 -}
 -
  static int __init omap_pm_init(void)
  {
   int error = -1;
 diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-
 pm-noop.c
 index 4ba261a..07b208b 100644
 --- a/arch/arm/plat-omap/omap-pm-noop.c
 +++ b/arch/arm/plat-omap/omap-pm-noop.c
 @@ -277,6 +277,8 @@ unsigned long omap_pm_cpu_get_freq(void)
 
  int omap_pm_get_dev_context_loss_count(struct device *dev)
  {
 + static u32 counter = 0;
 +
   if (!dev) {
   WARN_ON(1);
   return -EINVAL;
 @@ -290,7 +292,10 @@ int omap_pm_get_dev_context_loss_count(struct device
 *dev)
* off counter.
*/
 
 - return 0;
 + /* For the noop case, we cannot know the off counter, so
 +  * return an increasing counter which will ensure that
 +  * context is always restored. */
 + return counter++;
  }
 
  /*
 diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-
 pm-srf.c
 index 226662d..cac08e4 100644
 --- a/arch/arm/plat-omap/omap-pm-srf.c
 +++ b/arch/arm/plat-omap/omap-pm-srf.c
 @@ -276,6 +276,10 @@ EXPORT_SYMBOL(omap_pm_cpu_get_freq);
 
  int omap_pm_get_dev_context_loss_count(struct device *dev)
  {
 + struct platform_device *pdev;
 + struct omapdev *odev;
 + struct powerdomain *pwrdm;
 +
   if (!dev) {
   WARN_ON(1);
   return -EINVAL;
 @@ -288,7 +292,14 @@ int omap_pm_get_dev_context_loss_count(struct device
 *dev)
* Map the device to the powerdomain.  Return the powerdomain
* off counter.
*/
 + pdev = to_platform_device(dev);
 + odev = omapdev_find_pdev(pdev);
 
 + if (odev) {
 + pwrdm = omapdev_get_pwrdm(odev);
 + if (pwrdm)
 + return pwrdm-state_counter[0];
The state_counter is unsigned and the return type of this fn does not match.
How is the overflow handled for state_counter? Once the OFF mode count
increases to 65535 there could be a overflow here.
 + }
   return 0;
  }
 
 --
 1.6.3.3
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

How to checkout v2.6.31-rc3 using git

[Elvis Dowson]

Hi,
	How should my git command look like if I were to try to check out  
v2.6.31-rc3 from the linux-omap-2.6 repository? I don't see a head for  
v2.6.31 , and the master branch is 2 weeks old at v2.6.31-rc1.


Best regards,

Elvis

--
To unsubscribe from this list: send the line unsubscribe 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: How to checkout v2.6.31-rc3 using git

[Pandita, Vikram]

Elvis
-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Elvis
Dowson
Sent: Tuesday, July 14, 2009 2:44 PM
To: Linux OMAP Users
Subject: How to checkout v2.6.31-rc3 using git

Hi,
   How should my git command look like if I were to try to check out
v2.6.31-rc3 from the linux-omap-2.6 repository? I don't see a head for
v2.6.31 , and the master branch is 2 weeks old at v2.6.31-rc1.

L-O seems to be still on v2.6.31-rc1
Use: $git tag -l 

Looks like tony has not synce'd up with rc2/3 yet.

If you need the new rc, then you could use kernel.org git.
Not sure what is your use case.


Best regards,

Elvis

--
To unsubscribe from this list: send the line unsubscribe 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: How to checkout v2.6.31-rc3 using git

[Elvis Dowson]

Hi Vikram,
Thanks for the reply.

On Jul 14, 2009, at 11:49 PM, Pandita, Vikram wrote:





L-O seems to be still on v2.6.31-rc1
Use: $git tag -l

Looks like tony has not synce'd up with rc2/3 yet.

If you need the new rc, then you could use kernel.org git.
Not sure what is your use case.


I'm trying to port android kernel sources to v2.6.31, to better take  
advantage of power management support for the gumstix overo. I've  
managed to complete the port of android-2.6.29, but power management  
is not very stable with v2.6.29.


Best regards,

Elvis

--
To unsubscribe from this list: send the line unsubscribe 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: How to checkout v2.6.31-rc3 using git

[Pandita, Vikram]

-Original Message-
From: Elvis Dowson [mailto:elvis.dow...@mac.com]
Sent: Tuesday, July 14, 2009 2:57 PM
To: Pandita, Vikram
Cc: Linux OMAP Users
Subject: Re: How to checkout v2.6.31-rc3 using git

Hi Vikram,
   Thanks for the reply.

On Jul 14, 2009, at 11:49 PM, Pandita, Vikram wrote:



 L-O seems to be still on v2.6.31-rc1
 Use: $git tag -l

 Looks like tony has not synce'd up with rc2/3 yet.

 If you need the new rc, then you could use kernel.org git.
 Not sure what is your use case.

I'm trying to port android kernel sources to v2.6.31, to better take
advantage of power management support for the gumstix overo. I've
managed to complete the port of android-2.6.29, but power management
is not very stable with v2.6.29.

If your requirement is a good PM, then the best place is kevin's pm branch I 
guess.

http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary
head: pm 



Best regards,

Elvis


--
To unsubscribe from this list: send the line unsubscribe 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: How to checkout v2.6.31-rc3 using git

[Elvis Dowson]

Hi Vikram,

On Jul 15, 2009, at 12:03 AM, Pandita, Vikram wrote:



If your requirement is a good PM, then the best place is kevin's pm  
branch I guess.


http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary
head: pm


I want to also incorporate tomi's DSS2 patches, so what I was thinking  
was continuing off the linux-omap-2.6 master branch, starting with  
rc1, and then pull the delta patches off Kevin and Tomi's git  
repositories, and incorporating them as delta patches into my  
openembedded recipe for the overo.


This way, I can maintain the same structure that the overo recipe  
uses, and pull off the latest delta patches for DSS2 and PM.


What do you think?

Best regards,

Elvis

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else

[Hiroshi DOYU]

From: Carmody Phil.2 (EXT-Ixonos/Helsinki) ext-phil.2.carm...@nokia.com
Subject: Re: [PATCH 1/4] DSPBRIDGE: Fix macros that break when inside an if/else
Date: Tue, 14 Jul 2009 15:17:25 +0200

[...]
  I am not sure if these copy_from_user() wrapping are practically
  useful or not. It may be enough just to use kernel API as is. But if
  there are some reason to requires strict parameter checkings or
  debugging feature support for these family here, introducing inline
  functions for them, instead of macro, may be another option?
 
 I did mention that possibility to Ameya. In the 21st century, I think we
 should be able to trust the compiler to generate identical code from
 inline functions as functional macros. (Are we allowed to use 'restrict'
 pointers?)

I tried to create the attached patch.


0001-DSPBRIDGE-fix-macros-that-break-when-inside-an-if-e.patch
Description: Binary data

Re: Problems configuring OMAP35x ISP driver

[John Sarman]

Eddy and anyone who may be able to help,
  I am currently working on an Omnivision OV5620 and have used the
ov3640 driver as a starting point.  I have the June 18( latest ? )
code from the gitorious git repo.  I have thouroughly tested my i2c
driver setup using a 500 Mhz oscilloscope and have configured the
sensor to 640 x 480.  The only mode this supports is RAW
V4L2_PIX_FMT_SGRBG10 and I have that as the only available format.  So
far so good.  Sensor powers, configures etc, etc.  However when I run
the sensor I get ISPCTRL: HS_VS_IRQ 6ISPCTRL: OVF_IRQ 6ISPCTRL:
To test this I used the example code provided with v4l2 documentation.
 I have attached a complete log with all my added printk's set up as a
poor mans stacktrace.

Stuck trying to determine where to go from here, I feel like I am so
close to getting an image.

Thanks,
John Sarman

v4l2_open
omap34xx: Opening device
isp_get
ISPCTRL: isp_get: old 0
isp_enable_clocks
isp_restore_ctx
isp_restore_context
isp_restore_context
iommu_restore_ctx
ISPHIST:  Restoring context
isp_restore_context
ISPH3A:  Restoring context
isp_restore_context
isp_restore_context
ISPRESZ: Restoring context
isp_restore_context
ISPCTRL: isp_get: new 1
omap34xxcam_slave_power_set
OV5620: ioctl_s_power
isp_set_xclk
isp_reg_and_or
ISPCTRL: isp_set_xclk(): cam_xclka set to 2400 Hz
BOARD_OVERO_CAMERA: Switching Power to 1
OV5620: POWER ON
isp_configure_interface
isp_buf_init
OV5620: Sensor Detected, calling configure
ov5620:configure
omap34xxcam_slave_power_set
OV5620: ioctl_s_power
BOARD_OVERO_CAMERA: Switching Power to 2
OV5620: POWER STANDBY
isp_set_xclk
isp_reg_and_or
ISPCTRL: isp_set_xclk(): cam_xclka set to 0 Hz
OV5620: ioctl_g_fmt_cap
omap34xxcam_s_pix_parm
omap34xxcam_try_pix_parm
omap34xxcam_try_pix_parm fps = 1
OV5620: ioctl_enum_fmt_cap
OV5620: ioctl_enum_fmt_cap index 0 type 1
video4linux video0: trying fmt 30314142 (0)
OV5620: ioctl_enum_framesizes
isp_try_fmt_cap
isp_try_pipeline
video4linux video0: this w 640  h 480   fmt 30314142- w 640h 480   
 fmt
30314142wanted w 640h 480fmt 30314142
video4linux video0: renegotiate: w 640  h 480   w 1073741823h 1073741823
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 60
the demoninator is 0
video4linux video0: best_pix_in: w 640  h 480   fmt 30314142ival 1/60
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 30
video4linux video0: closer fps: fps 29   fps 59
video4linux video0: best_pix_in: w 640  h 480   fmt 30314142ival 1/30
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 7
video4linux video0: closer fps: fps 6fps 29
video4linux video0: best_pix_in: w 640  h 480   fmt 30314142ival 2/15
OV5620: ioctl_enum_frameintervals
OV5620: ioctl_enum_framesizes
isp_try_fmt_cap
isp_try_pipeline
video4linux video0: this w 1280 h 960   fmt 30314142- w 1280   h 960   
fmt 30314142wanted w 640h 480fmt 30314142
video4linux video0: size diff bigger: w 1280h 960   w 640   h 480
OV5620: ioctl_enum_framesizes
OV5620: ioctl_enum_fmt_cap
OV5620: ioctl_enum_fmt_cap index 1 type 1
video4linux video0: w 640, h 480, fmt 30314142 - w 640, h 480
video4linux video0: Wanted w 640, h 480, fmt 30314142
omap34xxcam_s_pix_parm 1 0
isp_s_fmt_cap
isp_s_pipeline
isp_release_resources
isp_try_pipeline
isp_reg_or
isp_reg_or
isp_reg_and_or
isp_reg_and_or
isp_reg_and
isp_print_status
ISPCTRL: ###ISP_CTRL=0x29c140
ISPCTRL: ###ISP_TCTRL_CTRL=0x0
ISPCTRL: ###ISP_SYSCONFIG=0x2000
ISPCTRL: ###ISP_SYSSTATUS=0x1
ISPCTRL: ###ISP_IRQ0ENABLE=0x0
ISPCTRL: ###ISP_IRQ0STATUS=0x8000
isp_reg_and
isp_reg_and
isp_reg_and
omap34xxcam_s_pix_parm 2 0
OV5620: ioctl_g_fmt_cap
OV5620: ioctl_s_fmt_cap
OV5620: ioctl_try_fmt_cap
OV5620: ioctl_try_fmt_cap WIDTH = 640
OV5620: ioctl_try_fmt_cap HEIGHT = 480
omap34xxcam_s_pix_parm 3 0
OV5620: ioctl_s_parm
OV5620 desired_fps = 7
omap34xxcam_s_pix_parm 4 0
omap34xx: Opened device
video_do_ioctl
omap34xxcam_vidioc_querycap
video_do_ioctl
omap34xxcam_cropcap
OV5620: ioctl_g_fmt_cap
video_do_ioctl
omap34xxcam_vidioc_s_crop
isp_s_crop
video_do_ioctl
omap34xxcam_vidioc_s_fmt_vid_cap
omap34xxcam_s_pix_parm
omap34xxcam_try_pix_parm
omap34xxcam_try_pix_parm fps = 1
OV5620: ioctl_enum_fmt_cap
OV5620: ioctl_enum_fmt_cap index 0 type 1
video4linux video0: trying fmt 30314142 (0)
OV5620: ioctl_enum_framesizes
isp_try_fmt_cap
isp_try_pipeline
video4linux video0: this w 640  h 480   fmt 30314142- w 640h 480   
 fmt
56595559wanted w 640h 480fmt 56595559
video4linux video0: renegotiate: w 640  h 480   w 1073741823h 1073741823
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 60
the demoninator is 0
video4linux video0: best_pix_in: w 640  h 480   fmt 30314142ival 1/60
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 30
video4linux video0: closer fps: fps 29   fps 59
video4linux video0: best_pix_in: w 640  h 480   fmt 30314142ival 1/30
OV5620: ioctl_enum_frameintervals
video4linux video0: fps 7
video4linux 

[PATCH 0/3] [OMAP:I2C] Small bug fixes and errata 1.153

[Sonasath, Moiz]

This patch includes the following:
- Bug in reading the RXSTAT/TXSTAT values from I2C_BUFFSTAT
- In case of a NACK|ARDY|AL interrupts return from the ISR
- OMAP3430 silicon errata 1.153

Signed-off-by: Moiz Sonasathm-sonas...@ti.com 
Signed-off-by: Vikram panditavikram.pand...@ti.com

Moiz Sonasath (3):
  [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the
I2C_BUFFSTAT register
  [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR
  [OMAP:I2C]OMAP3430 Silicon Errata 1.153

 drivers/i2c/busses/i2c-omap.c |   42 +---
 1 files changed, 34 insertions(+), 8 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register

[Sonasath, Moiz]

Fix bug in reading the I2C_BUFFSTAT register for getting byte count on RX/TX 
interrupt.

On Interrupt: I2C_STAT[RDR],
read 'RXSTAT' from I2C_BUFFSTAT[8-13]
On Interrupt: I2C_STAT[XDR]
read 'TXSTAT' from I2C_BUFFSTAT[0-5]

Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Jagadeesh Pakaravoorj-pakarav...@ti.com
Signed-off-by: Vikram anditavikram.pand...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..d280acf 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -692,9 +692,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (dev-fifo_size) {
if (stat  OMAP_I2C_STAT_RRDY)
num_bytes = dev-fifo_size;
-   else
-   num_bytes = omap_i2c_read_reg(dev,
-   OMAP_I2C_BUFSTAT_REG);
+   else/* read RXSTAT on RDR interrupt */
+   num_bytes = (omap_i2c_read_reg(dev,
+   OMAP_I2C_BUFSTAT_REG)
+8)  0x3F;
}
while (num_bytes) {
num_bytes--;
@@ -731,9 +732,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
if (dev-fifo_size) {
if (stat  OMAP_I2C_STAT_XRDY)
num_bytes = dev-fifo_size;
-   else
-   num_bytes = omap_i2c_read_reg(dev,
-   OMAP_I2C_BUFSTAT_REG);
+   else/* read TXSTAT on XDR interrupt */
+   num_bytes = (omap_i2c_read_reg(dev,
+   OMAP_I2C_BUFSTAT_REG))
+0x3F;
}
while (num_bytes) {
num_bytes--;
-- 
1.5.6.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR

[Sonasath, Moiz]

In case of a NACK or ARDY or AL interrupt, complete the request.
There is no need to service the RRDY/RDR or XRDY/XDR interrupts.

Refer TRM SWPU114: Figure 18-31.I2C Master Transmitter Mode, Interrupt Method,
in F/S and HS Modes

http://focus.ti.com/pdfs/wtbu/SWPU114T_PrelimFinalEPDF_06_25_2009.pdf

Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram Panditavikram.pand...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d280acf..05b5e4c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -685,8 +685,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
err |= OMAP_I2C_STAT_AL;
}
if (stat  (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
-   OMAP_I2C_STAT_AL))
+   OMAP_I2C_STAT_AL)) {
omap_i2c_complete_cmd(dev, err);
+   return IRQ_HANDLED;
+   }
if (stat  (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
if (dev-fifo_size) {
-- 
1.5.6.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153

[Sonasath, Moiz]

When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.

Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.

Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram Panditavikram.pand...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   24 +++-
 1 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 05b5e4c..8deaf87 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
 
+   err = 0;
+complete:
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
 
-   err = 0;
if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
data to send\n);
break;
}
+
+   /*
+* OMAP3430 Errata 1.153: When an XRDY/XDR
+* is hit, wait for XUDF before writing data
+* to DATA_REG. Otherwise some data bytes can
+* be lost while transferring them from the
+* memory to the I2C interface.
+*/
+
+   if (cpu_is_omap34xx()) {
+   while (!(stat  
OMAP_I2C_STAT_XUDF)) {
+   if (stat  
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+   
omap_i2c_ack_stat(dev, stat  (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
+   err |= 
OMAP_I2C_STAT_XUDF;
+   goto complete;
+   }
+   cpu_relax();
+   stat = 
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+   }
+   }
+
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
omap_i2c_ack_stat(dev,
-- 
1.5.6.3

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: How to checkout v2.6.31-rc3 using git

[Pandita, Vikram]

-Original Message-
From: Elvis Dowson [mailto:elvis.dow...@mac.com]
Sent: Tuesday, July 14, 2009 3:08 PM
To: Pandita, Vikram
Cc: Linux OMAP Users
Subject: Re: How to checkout v2.6.31-rc3 using git

Hi Vikram,

On Jul 15, 2009, at 12:03 AM, Pandita, Vikram wrote:


 If your requirement is a good PM, then the best place is kevin's pm
 branch I guess.

 http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summary
 head: pm

I want to also incorporate tomi's DSS2 patches, so what I was thinking
was continuing off the linux-omap-2.6 master branch, starting with
rc1, and then pull the delta patches off Kevin and Tomi's git
repositories, and incorporating them as delta patches into my
openembedded recipe for the overo.

This way, I can maintain the same structure that the overo recipe
uses, and pull off the latest delta patches for DSS2 and PM.

What do you think?

All this is already available and integrated on android public git tree.
This had DSS2 and PM.

http://android.git.kernel.org/?p=kernel/omap.git;a=summary
Head: android-omap-2.6.29
Validated on Zoom2.


Best regards,

Elvis


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP3: PM: move context-loss counting into OMAP PM

[Kevin Hilman]

Madhusudhan madhu...@ti.com writes:

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Kevin Hilman
 Sent: Wednesday, July 08, 2009 1:34 PM
 To: linux-omap@vger.kernel.org
 Cc: Rajendra Nayak; Peter 'p2' De Schrijver
 Subject: [PATCH] OMAP3: PM: move context-loss counting into OMAP PM
 
 From: Rajendra Nayak rna...@ti.com
 
 Drop get_last_off_on_transaction_id() and move functionality
 into OMAP PM layer.
 
 For SRF, use omapdev** to get powerdomain state counte
 for NOOP, use an increasing counter to ensure context is always restord.
 
 **NOTE: in future PM branch, this omapdev functinality will be replaced
 by omap_hwmod.  Thus, context loss counting will only exist
 for modules with omap_hwmod implementations.
 
 Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
 Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
 ---
 Applies to current PM branch and pm-2.6.29
 
  arch/arm/mach-omap2/pm.c  |   16 
  arch/arm/plat-omap/omap-pm-noop.c |7 ++-
  arch/arm/plat-omap/omap-pm-srf.c  |   11 +++
  3 files changed, 17 insertions(+), 17 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
 index 1192e01..fec7d00 100644
 --- a/arch/arm/mach-omap2/pm.c
 +++ b/arch/arm/mach-omap2/pm.c
 @@ -31,7 +31,6 @@
  #include asm/atomic.h
 
  #include mach/powerdomain.h
 -#include mach/omapdev.h
  #include mach/resource.h
  #include mach/omap34xx.h
 
 @@ -221,21 +220,6 @@ void omap2_allow_sleep(void)
  BUG_ON(i  0);
  }
 
 -unsigned get_last_off_on_transaction_id(struct device *dev)
 -{
 -struct platform_device *pdev = to_platform_device(dev);
 -struct omapdev *odev = omapdev_find_pdev(pdev);
 -struct powerdomain *pwrdm;
 -
 -if (odev) {
 -pwrdm = omapdev_get_pwrdm(odev);
 -if (pwrdm)
 -return pwrdm-state_counter[0];
 -}
 -
 -return 0;
 -}
 -
  static int __init omap_pm_init(void)
  {
  int error = -1;
 diff --git a/arch/arm/plat-omap/omap-pm-noop.c b/arch/arm/plat-omap/omap-
 pm-noop.c
 index 4ba261a..07b208b 100644
 --- a/arch/arm/plat-omap/omap-pm-noop.c
 +++ b/arch/arm/plat-omap/omap-pm-noop.c
 @@ -277,6 +277,8 @@ unsigned long omap_pm_cpu_get_freq(void)
 
  int omap_pm_get_dev_context_loss_count(struct device *dev)
  {
 +static u32 counter = 0;
 +
  if (!dev) {
  WARN_ON(1);
  return -EINVAL;
 @@ -290,7 +292,10 @@ int omap_pm_get_dev_context_loss_count(struct device
 *dev)
   * off counter.
   */
 
 -return 0;
 +/* For the noop case, we cannot know the off counter, so
 + * return an increasing counter which will ensure that
 + * context is always restored. */
 +return counter++;
  }
 
  /*
 diff --git a/arch/arm/plat-omap/omap-pm-srf.c b/arch/arm/plat-omap/omap-
 pm-srf.c
 index 226662d..cac08e4 100644
 --- a/arch/arm/plat-omap/omap-pm-srf.c
 +++ b/arch/arm/plat-omap/omap-pm-srf.c
 @@ -276,6 +276,10 @@ EXPORT_SYMBOL(omap_pm_cpu_get_freq);
 
  int omap_pm_get_dev_context_loss_count(struct device *dev)
  {
 +struct platform_device *pdev;
 +struct omapdev *odev;
 +struct powerdomain *pwrdm;
 +
  if (!dev) {
  WARN_ON(1);
  return -EINVAL;
 @@ -288,7 +292,14 @@ int omap_pm_get_dev_context_loss_count(struct device
 *dev)
   * Map the device to the powerdomain.  Return the powerdomain
   * off counter.
   */
 +pdev = to_platform_device(dev);
 +odev = omapdev_find_pdev(pdev);
 
 +if (odev) {
 +pwrdm = omapdev_get_pwrdm(odev);
 +if (pwrdm)
 +return pwrdm-state_counter[0];
 The state_counter is unsigned and the return type of this fn does not match.

Good catch.

 How is the overflow handled for state_counter? Once the OFF mode count
 increases to 65535 there could be a overflow here.

And overflow doesn't matter.  Drivers should simply be checking for
current state != previous state.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/3] [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR

[Menon, Nishanth]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
 Sent: Tuesday, July 14, 2009 4:20 PM
 To: linux-omap@vger.kernel.org
 Cc: Kamat, Nishant; Paul Walmsley
 Subject: [PATCH 2/3] [OMAP:I2C]In case of a NACK|ARDY|AL return from the
 ISR
 
 
 In case of a NACK or ARDY or AL interrupt, complete the request.
 There is no need to service the RRDY/RDR or XRDY/XDR interrupts.
 
 Refer TRM SWPU114: Figure 18-31.I2C Master Transmitter Mode, Interrupt
 Method,
 in F/S and HS Modes
 
 http://focus.ti.com/pdfs/wtbu/SWPU114T_PrelimFinalEPDF_06_25_2009.pdf
 
 Signed-off-by: Moiz Sonasathm-sonas...@ti.com
 Signed-off-by: Vikram Panditavikram.pand...@ti.com
 ---
  drivers/i2c/busses/i2c-omap.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index d280acf..05b5e4c 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -685,8 +685,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
   err |= OMAP_I2C_STAT_AL;
   }
   if (stat  (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
 - OMAP_I2C_STAT_AL))
 + OMAP_I2C_STAT_AL)) {
   omap_i2c_complete_cmd(dev, err);
 + return IRQ_HANDLED;
 + }
What is the status of IRQ_STAT register? Who will clear that if we return 
immediately from ISR? Isr will be reinvoked and we'd handle the same anyways..

I think this conflicts with [1]

Regards,
Nishanth Menon

Ref:
[1] http://patchwork.kernel.org/patch/32332/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register

[Menon, Nishanth]

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Sonasath, Moiz
 Sent: Tuesday, July 14, 2009 4:18 PM
 To: linux-omap@vger.kernel.org
 Cc: Kamat, Nishant; Paul Walmsley
 Subject: [PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values
 from the I2C_BUFFSTAT register
 
 
 Fix bug in reading the I2C_BUFFSTAT register for getting byte count on
 RX/TX interrupt.
 
 On Interrupt: I2C_STAT[RDR],
   read 'RXSTAT' from I2C_BUFFSTAT[8-13]
 On Interrupt: I2C_STAT[XDR]
   read 'TXSTAT' from I2C_BUFFSTAT[0-5]
 
 Signed-off-by: Moiz Sonasathm-sonas...@ti.com
 Signed-off-by: Jagadeesh Pakaravoorj-pakarav...@ti.com
 Signed-off-by: Vikram anditavikram.pand...@ti.com
 ---
  drivers/i2c/busses/i2c-omap.c |   14 --
  1 files changed, 8 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index ad8d201..d280acf 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -692,9 +692,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
   if (dev-fifo_size) {
   if (stat  OMAP_I2C_STAT_RRDY)
   num_bytes = dev-fifo_size;
 - else
 - num_bytes = omap_i2c_read_reg(dev,
 - OMAP_I2C_BUFSTAT_REG);
 + else/* read RXSTAT on RDR interrupt */
 + num_bytes = (omap_i2c_read_reg(dev,
 + OMAP_I2C_BUFSTAT_REG)
 +  8)  0x3F;
   }
   while (num_bytes) {
   num_bytes--;
 @@ -731,9 +732,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
   if (dev-fifo_size) {
   if (stat  OMAP_I2C_STAT_XRDY)
   num_bytes = dev-fifo_size;
 - else
 - num_bytes = omap_i2c_read_reg(dev,
 - OMAP_I2C_BUFSTAT_REG);
 + else/* read TXSTAT on XDR interrupt */
 + num_bytes = (omap_i2c_read_reg(dev,
 + OMAP_I2C_BUFSTAT_REG))
Minor - Remove that extra ().. ^^
 +  0x3F;
   }
   while (num_bytes) {
   num_bytes--;
Acked-by: Nishanth Menon n...@ti.com

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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 3/3] [OMAP:I2C]OMAP3430 Silicon Errata 1.153

[Nishanth Menon]

Sonasath, Moiz wrote:

When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.

Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.

Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram Panditavikram.pand...@ti.com
---
 drivers/i2c/busses/i2c-omap.c |   24 +++-
 1 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 05b5e4c..8deaf87 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -672,9 +672,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
break;
}
 
+		err = 0;

+complete:

cant we rename this label?

omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
 
-		err = 0;

if (stat  OMAP_I2C_STAT_NACK) {
err |= OMAP_I2C_STAT_NACK;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -764,6 +765,27 @@ omap_i2c_isr(int this_irq, void *dev_id)
data to send\n);
break;
}
+
+   /*
+* OMAP3430 Errata 1.153: When an XRDY/XDR
+* is hit, wait for XUDF before writing data
+* to DATA_REG. Otherwise some data bytes can
+* be lost while transferring them from the
+* memory to the I2C interface.
+*/
+
+   if (cpu_is_omap34xx()) {
+   while (!(stat  
OMAP_I2C_STAT_XUDF)) {
+   if (stat  
(OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+   
omap_i2c_ack_stat(dev, stat  (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
generic comment - code nesting is getting overwhelming - we may like to 
refactor the isr function at a later date I think..

+   err |= 
OMAP_I2C_STAT_XUDF;

why set the err if we wantedly force this to happen?

+   goto complete;



+   }
+   cpu_relax();
+   stat = 
omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+   }
this is an infinite while loop + it tries to handle error cases - 
essentially do another isr routine inside itself.



How about:
Apply [1] and the following?
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ad8d201..e3f21af 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -728,6 +728,12 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
if (stat  (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
+   if (cpu_is_omap34xx() 
+   !(stat  OMAP_I2C_STAT_XUDF)){
+   cpu_relax();
+   continue;
+   }
+
if (dev-fifo_size) {
if (stat  OMAP_I2C_STAT_XRDY)
num_bytes = dev-fifo_size;


Regards,
Nishanth Menon
Ref:
[1] http://patchwork.kernel.org/patch/32332/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Is DSS2 incorporated into linux-omap-2.6 master branch?

[Elvis Dowson]

Hi Tomi,
			Have the DSS2 patches been incorporated into the linux-omap-2.6  
master branch? i.e. v2.6.31-rc1?


Best regards,

Elvis Dowson

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] DSPBRIDGE: enable smart/autoidle for mailbox sysconfig

[Hiroshi DOYU]

From: Hiroshi DOYU hiroshi.d...@nokia.com

Reported-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
 drivers/dsp/bridge/hw/hw_mbox.c |4 +++-
 drivers/dsp/bridge/hw/hw_mbox.h |5 +
 drivers/dsp/bridge/wmd/io_sm.c  |1 +
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index ee79032..5a87597 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -33,7 +33,9 @@
 /* width in bits of MBOX Id */
 #define HW_MBOX_ID_WIDTH  2
 
-struct MAILBOX_CONTEXT mboxsetting = {0x4, 0x1, 0x1};
+static struct MAILBOX_CONTEXT mboxsetting = {
+   .sysconfig = 2  3 | 1, /* SMART/AUTO-IDLE */
+};
 
 /* Saves the mailbox context */
 HW_STATUS HW_MBOX_saveSettings(void __iomem *baseAddress)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.h b/drivers/dsp/bridge/hw/hw_mbox.h
index ad1a89c..8a5f6bd 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.h
+++ b/drivers/dsp/bridge/hw/hw_mbox.h
@@ -320,4 +320,9 @@ extern HW_STATUS HW_MBOX_saveSettings(void __iomem 
*baseAddres);
 */
 extern HW_STATUS HW_MBOX_restoreSettings(void __iomem *baseAddres);
 
+static inline void HW_MBOX_initSettings(void __iomem *baseAddres)
+{
+   HW_MBOX_restoreSettings(baseAddres);
+}
+
 #endif  /* __MBOX_H */
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 39c34f7..d8ae1f1 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -282,6 +282,7 @@ DSP_STATUS WMD_IO_Create(OUT struct IO_MGR **phIOMgr,
pIOMgr-fSharedIRQ = pMgrAttrs-fShared;
IO_DisableInterrupt(hWmdContext);
if (devType == DSP_UNIT) {
+   HW_MBOX_initSettings(hostRes.dwMboxBase);
/* Plug the channel ISR:. */
if ((request_irq(INT_MAIL_MPU_IRQ, IO_ISR, 0,
DspBridge\tmailbox, (void *)pIOMgr)) == 0)
-- 
1.6.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html