RE: [OMAP 1710] Mainline Broken

2010-12-17 Thread DebBarma, Tarun Kanti
 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Thursday, December 16, 2010 10:39 PM
 To: Belisko Marek
 Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
 Subject: Re: [OMAP 1710] Mainline Broken
 
 Belisko Marek marek.beli...@gmail.com writes:
 
  Hi,
 
  On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti
  tarun.ka...@ti.com wrote:
  Did anyone observe this? I am using omap_generic_1710_defconfig
 
  [...]
  input: omap-keypad as /devices/platform/omap-keypad/input/input0
  TCP cubic registered
  NET: Registered protocol family 17
  Registering the dns_resolver key type
  eth0: link up
  IP-Config: Complete:
      device=eth0, addr=172.24.191.106, mask=255.255.252.0,
 gw=172.24.188.1,
      host=myomap, domain=, nis-domain=(none),
      bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath=
  VFS: Mounted root (nfs filesystem) on device 0:10.
  Freeing init memory: 128K
  Kernel panic - not syncing: Attempted to kill init!
 
  Seems your userspace is broken. Try add user_debug=31 to command line
  to see what exactly happens.
 
 Looks like you're mounting an NFS rootfs.  Was it compiled for armv5?
 My hunch would be you're trying to run an armv6/armv7 userspace on the
 1710 which is armv5.
 
 To get more debugging, ensure these are enabled in your defconfig:
 
 CONFIG_DEBUG_BUGVERBOSE=y
 CONFIG_DEBUG_USER=y
 CONFIG_DEBUG_ERRORS=y
 
 and in addition to cmdline suggested by Marek, add user_debug=0xf
 
 This will give verbose output for userspace exceptions as well and
 possibly confirm my hunch.
 
 Kevin

I checked .config and it shows: CONFIG_CPU_32v5=y

With regard to additional log here they are!!

[...]
[1] init: obsolete system call .
Code: e08f1001 e1a0c000 e3a0702d ef00 (e3700a01)
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[...]

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


RE: [PATCH v4 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros from omap_vout

2010-12-17 Thread Hiremath, Vaibhav
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Taneja, Archit
 Sent: Friday, December 17, 2010 12:13 PM
 To: linux-me...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org; Taneja, Archit
 Subject: [PATCH v4 1/2] OMAP_VOUT: CLEANUP: Move some functions and macros
 from omap_vout
 
 Move some inline functions from omap_vout.c to omap_voutdef.h and
 independent
 functions like omap_vout_alloc_buffer/omap_vout_free_buffer to
 omap_voutlib.c.
 
[Hiremath, Vaibhav] Thanks, Archit.

Tested-By Vaibhav Hiremath hvaib...@ti.com
Acked-By Vaibhav Hiremath hvaib...@ti.com


Thanks,
Vaibhav

 Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c|  109 --
 -
  drivers/media/video/omap/omap_voutdef.h |   62 +
  drivers/media/video/omap/omap_voutlib.c |   44 
  drivers/media/video/omap/omap_voutlib.h |2 +
  4 files changed, 108 insertions(+), 109 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 15f8793..e1df01c 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -35,17 +35,14 @@
  #include linux/sched.h
  #include linux/types.h
  #include linux/platform_device.h
 -#include linux/dma-mapping.h
  #include linux/irq.h
  #include linux/videodev2.h
 -#include linux/slab.h
 
  #include media/videobuf-dma-contig.h
  #include media/v4l2-device.h
  #include media/v4l2-ioctl.h
 
  #include plat/dma.h
 -#include plat/vram.h
  #include plat/vrfb.h
  #include plat/display.h
 
 @@ -56,7 +53,6 @@ MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
  MODULE_LICENSE(GPL);
 
 -
  /* Driver Configuration macros */
  #define VOUT_NAMEomap_vout
 
 @@ -65,31 +61,6 @@ enum omap_vout_channels {
   OMAP_VIDEO2,
  };
 
 -enum dma_channel_state {
 - DMA_CHAN_NOT_ALLOTED,
 - DMA_CHAN_ALLOTED,
 -};
 -
 -#define QQVGA_WIDTH  160
 -#define QQVGA_HEIGHT 120
 -
 -/* Max Resolution supported by the driver */
 -#define VID_MAX_WIDTH1280/* Largest width */
 -#define VID_MAX_HEIGHT   720 /* Largest height */
 -
 -/* Mimimum requirement is 2x2 for DSS */
 -#define VID_MIN_WIDTH2
 -#define VID_MIN_HEIGHT   2
 -
 -/* 2048 x 2048 is max res supported by OMAP display controller */
 -#define MAX_PIXELS_PER_LINE 2048
 -
 -#define VRFB_TX_TIMEOUT 1000
 -#define VRFB_NUM_BUFS4
 -
 -/* Max buffer size tobe allocated during init */
 -#define OMAP_VOUT_MAX_BUF_SIZE (VID_MAX_WIDTH*VID_MAX_HEIGHT*4)
 -
  static struct videobuf_queue_ops video_vbq_ops;
  /* Variables configurable through module params*/
  static u32 video1_numbuffers = 3;
 @@ -172,49 +143,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
  #define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))
 
  /*
 - * Allocate buffers
 - */
 -static unsigned long omap_vout_alloc_buffer(u32 buf_size, u32 *phys_addr)
 -{
 - u32 order, size;
 - unsigned long virt_addr, addr;
 -
 - size = PAGE_ALIGN(buf_size);
 - order = get_order(size);
 - virt_addr = __get_free_pages(GFP_KERNEL | GFP_DMA, order);
 - addr = virt_addr;
 -
 - if (virt_addr) {
 - while (size  0) {
 - SetPageReserved(virt_to_page(addr));
 - addr += PAGE_SIZE;
 - size -= PAGE_SIZE;
 - }
 - }
 - *phys_addr = (u32) virt_to_phys((void *) virt_addr);
 - return virt_addr;
 -}
 -
 -/*
 - * Free buffers
 - */
 -static void omap_vout_free_buffer(unsigned long virtaddr, u32 buf_size)
 -{
 - u32 order, size;
 - unsigned long addr = virtaddr;
 -
 - size = PAGE_ALIGN(buf_size);
 - order = get_order(size);
 -
 - while (size  0) {
 - ClearPageReserved(virt_to_page(addr));
 - addr += PAGE_SIZE;
 - size -= PAGE_SIZE;
 - }
 - free_pages((unsigned long) virtaddr, order);
 -}
 -
 -/*
   * Function for allocating video buffers
   */
  static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
 @@ -369,43 +297,6 @@ static void omap_vout_release_vrfb(struct
 omap_vout_device *vout)
  }
 
  /*
 - * Return true if rotation is 90 or 270
 - */
 -static inline int rotate_90_or_270(const struct omap_vout_device *vout)
 -{
 - return (vout-rotation == dss_rotation_90_degree ||
 - vout-rotation == dss_rotation_270_degree);
 -}
 -
 -/*
 - * Return true if rotation is enabled
 - */
 -static inline int rotation_enabled(const struct omap_vout_device *vout)
 -{
 - return vout-rotation || vout-mirror;
 -}
 -
 -/*
 - * Reverse the rotation degree if mirroring is enabled
 - */
 -static inline int calc_rotation(const struct omap_vout_device *vout)
 -{
 - if 

RE: [PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related API's

2010-12-17 Thread Hiremath, Vaibhav

 -Original Message-
 From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
 ow...@vger.kernel.org] On Behalf Of Taneja, Archit
 Sent: Friday, December 17, 2010 12:13 PM
 To: linux-me...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org; Taneja, Archit
 Subject: [PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related
 API's

[Hiremath, Vaibhav] [Hiremath, Vaibhav] Thanks, Archit.

Tested-By Vaibhav Hiremath hvaib...@ti.com
Acked-By Vaibhav Hiremath hvaib...@ti.com

I will merge to my Arago repository and give pull request to Mauro.

Thanks,
Vaibhav

 Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related
 API's,
 making OMAP_VOUT driver independent from VRFB. This is required for OMAP4
 DSS,
 since OMAP4 doesn't have VRFB block.

 Added new enum vout_rotation_type and rotation_type member to
 omapvideo_info,
 this is initialized based on the arch type in omap_vout_probe. The
 rotation_type
 var is now used to choose between vrfb and non-vrfb calls.

 Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/Kconfig  |2 +-
  drivers/media/video/omap/Makefile |1 +
  drivers/media/video/omap/omap_vout.c  |  457 ++--
 -
  drivers/media/video/omap/omap_vout_vrfb.c |  390 
  drivers/media/video/omap/omap_vout_vrfb.h |   40 +++
  drivers/media/video/omap/omap_voutdef.h   |   16 +
  6 files changed, 532 insertions(+), 374 deletions(-)
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c
  create mode 100644 drivers/media/video/omap/omap_vout_vrfb.h

 diff --git a/drivers/media/video/omap/Kconfig
 b/drivers/media/video/omap/Kconfig
 index e63233f..5f8abea 100644
 --- a/drivers/media/video/omap/Kconfig
 +++ b/drivers/media/video/omap/Kconfig
 @@ -5,7 +5,7 @@ config VIDEO_OMAP2_VOUT
   select VIDEOBUF_DMA_CONTIG
   select OMAP2_DSS
   select OMAP2_VRAM
 - select OMAP2_VRFB
 + select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
   default n
   ---help---
 V4L2 Display driver support for OMAP2/3 based boards.
 diff --git a/drivers/media/video/omap/Makefile
 b/drivers/media/video/omap/Makefile
 index b287880..bc47569 100644
 --- a/drivers/media/video/omap/Makefile
 +++ b/drivers/media/video/omap/Makefile
 @@ -5,3 +5,4 @@
  # OMAP2/3 Display driver
  omap-vout-y := omap_vout.o omap_voutlib.o
  obj-$(CONFIG_VIDEO_OMAP2_VOUT) += omap-vout.o
 +obj-$(CONFIG_OMAP2_VRFB) += omap_vout_vrfb.o
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index e1df01c..e6c0fde 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -42,12 +42,9 @@
  #include media/v4l2-device.h
  #include media/v4l2-ioctl.h

 -#include plat/dma.h
 -#include plat/vrfb.h
 -#include plat/display.h
 -
  #include omap_voutlib.h
  #include omap_voutdef.h
 +#include omap_vout_vrfb.h

  MODULE_AUTHOR(Texas Instruments);
  MODULE_DESCRIPTION(OMAP Video for Linux Video out driver);
 @@ -143,41 +140,6 @@ const static struct v4l2_fmtdesc omap_formats[] = {
  #define NUM_OUTPUT_FORMATS (ARRAY_SIZE(omap_formats))

  /*
 - * Function for allocating video buffers
 - */
 -static int omap_vout_allocate_vrfb_buffers(struct omap_vout_device *vout,
 - unsigned int *count, int startindex)
 -{
 - int i, j;
 -
 - for (i = 0; i  *count; i++) {
 - if (!vout-smsshado_virt_addr[i]) {
 - vout-smsshado_virt_addr[i] =
 - omap_vout_alloc_buffer(vout-smsshado_size,
 - vout-smsshado_phy_addr[i]);
 - }
 - if (!vout-smsshado_virt_addr[i]  startindex != -1) {
 - if (V4L2_MEMORY_MMAP == vout-memory  i = startindex)
 - break;
 - }
 - if (!vout-smsshado_virt_addr[i]) {
 - for (j = 0; j  i; j++) {
 - omap_vout_free_buffer(
 - vout-smsshado_virt_addr[j],
 - vout-smsshado_size);
 - vout-smsshado_virt_addr[j] = 0;
 - vout-smsshado_phy_addr[j] = 0;
 - }
 - *count = 0;
 - return -ENOMEM;
 - }
 - memset((void *) vout-smsshado_virt_addr[i], 0,
 - vout-smsshado_size);
 - }
 - return 0;
 -}
 -
 -/*
   * Try format
   */
  static int omap_vout_try_format(struct v4l2_pix_format *pix)
 @@ -270,36 +232,9 @@ static u32 omap_vout_uservirt_to_phys(u32 virtp)
  }

  /*
 - * Wakes up the application once the DMA transfer to VRFB space is
 completed.
 - */
 -static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void
 *data)
 -{
 - struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) 

[PATCH 0/7 v5] OMAP3: clean up ASM sleep code

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

This patch only contains clean-ups and cosmetic changes,
no functional change.

Clean-up of the ASM sleep code, for better readability and
easier maintenance.

Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2

Jean Pihet (7):
  OMAP2+: use global values for the SRAM PA addresses
  OMAP3: remove hardcoded values from the ASM sleep code
  OMAP3: re-organize the ASM sleep code
  OMAP3: rework of the ASM sleep code execution paths
  OMAP3: add comments for low power code errata
  OMAP3: ASM sleep code format rework
  OMAP3: remove unused code from the ASM sleep code

 arch/arm/mach-omap2/control.c  |9 +-
 arch/arm/mach-omap2/control.h  |2 +
 arch/arm/mach-omap2/pm.h   |1 -
 arch/arm/mach-omap2/pm34xx.c   |4 +-
 arch/arm/mach-omap2/sdrc.h |1 -
 arch/arm/mach-omap2/sleep34xx.S|  724 +---
 arch/arm/plat-omap/include/plat/sram.h |   11 +
 arch/arm/plat-omap/sram.c  |7 +-
 8 files changed, 413 insertions(+), 346 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 3/7] OMAP3: remove hardcoded values from the ASM sleep code

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

Using macros from existing include files for registers addresses.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Based on original patch from Vishwa.

Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Vishwanath BS vishwanath...@ti.com
---
 arch/arm/mach-omap2/control.h   |2 ++
 arch/arm/mach-omap2/sleep34xx.S |   29 ++---
 2 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index d7911c5..72efefb 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -274,6 +274,8 @@
 #define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860)
 #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910)
 #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C
+#define OMAP343X_SCRATCHPAD_REGADDR(reg)   OMAP2_L4_IO_ADDRESS(\
+   OMAP343X_SCRATCHPAD + reg)
 
 /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */
 #define AM35XX_USBOTG_VBUSP_CLK_SHIFT   0
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 406cd2a..8e9f38f 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -34,20 +34,27 @@
 #include sdrc.h
 #include control.h
 
-#define SDRC_SCRATCHPAD_SEM_V  0xfa00291c
-
-#define PM_PREPWSTST_CORE_P0x48306AE8
+/*
+ * Registers access definitions
+ */
+#define SDRC_SCRATCHPAD_SEM_OFFS   0xc
+#define SDRC_SCRATCHPAD_SEM_V  OMAP343X_SCRATCHPAD_REGADDR\
+   (SDRC_SCRATCHPAD_SEM_OFFS)
+#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD +\
+   OMAP3430_PM_PREPWSTST
 #define PM_PWSTCTRL_MPU_P  OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL
 #define CM_IDLEST1_CORE_V  OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
 #define CM_IDLEST_CKGEN_V  OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
-#define SRAM_BASE_P0x4020
-#define CONTROL_STAT   0x480022F0
-#define CONTROL_MEM_RTA_CTRL   (OMAP343X_CTRL_BASE\
-   + OMAP36XX_CONTROL_MEM_RTA_CTRL)
-#define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is
-  * available */
-#define SCRATCHPAD_BASE_P  (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\
-   + SCRATCHPAD_MEM_OFFS)
+#define SRAM_BASE_POMAP3_SRAM_PA
+#define CONTROL_STAT   OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS
+#define CONTROL_MEM_RTA_CTRL   (OMAP343X_CTRL_BASE +\
+   OMAP36XX_CONTROL_MEM_RTA_CTRL)
+
+/* Move this as correct place is available */
+#define SCRATCHPAD_MEM_OFFS0x310
+#define SCRATCHPAD_BASE_P  (OMAP343X_CTRL_BASE +\
+   OMAP343X_CONTROL_MEM_WKUP +\
+   SCRATCHPAD_MEM_OFFS)
 #define SDRC_POWER_V   OMAP34XX_SDRC_REGADDR(SDRC_POWER)
 #define SDRC_SYSCONFIG_P   (OMAP343X_SDRC_BASE + SDRC_SYSCONFIG)
 #define SDRC_MR_0_P(OMAP343X_SDRC_BASE + SDRC_MR_0)
-- 
1.7.1

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


[PATCH 4/7] OMAP3: re-organize the ASM sleep code

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

Organize the code in the following sections:
- register access macros,
- API functions,
- internal functions.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/sleep34xx.S |  114 +--
 1 files changed, 61 insertions(+), 53 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 8e9f38f..beeb682 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -79,6 +79,7 @@ ENTRY(get_restore_pointer)
 ldmfd   sp!, {pc} @ restore regs and return
 ENTRY(get_restore_pointer_sz)
 .word   . - get_restore_pointer
+
.text
 /* Function call to get the restore pointer for 3630 resume from OFF */
 ENTRY(get_omap3630_restore_pointer)
@@ -89,9 +90,18 @@ ENTRY(get_omap3630_restore_pointer_sz)
 .word   . - get_omap3630_restore_pointer
 
.text
+/* Function call to get the restore pointer for ES3 to resume from OFF */
+ENTRY(get_es3_restore_pointer)
+   stmfd   sp!, {lr}   @ save registers on stack
+   adr r0, restore_es3
+   ldmfd   sp!, {pc}   @ restore regs and return
+ENTRY(get_es3_restore_pointer_sz)
+   .word   . - get_es3_restore_pointer
+
+   .text
 /*
  * L2 cache needs to be toggled for stable OFF mode functionality on 3630.
- * This function sets up a fflag that will allow for this toggling to take
+ * This function sets up a flag that will allow for this toggling to take
  * place on 3630. Hopefully some version in the future maynot need this
  */
 ENTRY(enable_omap3630_toggle_l2_on_restore)
@@ -101,58 +111,6 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
str r1, l2dis_3630
 ldmfd   sp!, {pc} @ restore regs and return
 
-   .text
-/* Function call to get the restore pointer for for ES3 to resume from OFF */
-ENTRY(get_es3_restore_pointer)
-   stmfd   sp!, {lr}   @ save registers on stack
-   adr r0, restore_es3
-   ldmfd   sp!, {pc}   @ restore regs and return
-ENTRY(get_es3_restore_pointer_sz)
-   .word   . - get_es3_restore_pointer
-
-ENTRY(es3_sdrc_fix)
-   ldr r4, sdrc_syscfg @ get config addr
-   ldr r5, [r4]@ get value
-   tst r5, #0x100  @ is part access blocked
-   it  eq
-   biceq   r5, r5, #0x100  @ clear bit if set
-   str r5, [r4]@ write back change
-   ldr r4, sdrc_mr_0   @ get config addr
-   ldr r5, [r4]@ get value
-   str r5, [r4]@ write back change
-   ldr r4, sdrc_emr2_0 @ get config addr
-   ldr r5, [r4]@ get value
-   str r5, [r4]@ write back change
-   ldr r4, sdrc_manual_0   @ get config addr
-   mov r5, #0x2@ autorefresh command
-   str r5, [r4]@ kick off refreshes
-   ldr r4, sdrc_mr_1   @ get config addr
-   ldr r5, [r4]@ get value
-   str r5, [r4]@ write back change
-   ldr r4, sdrc_emr2_1 @ get config addr
-   ldr r5, [r4]@ get value
-   str r5, [r4]@ write back change
-   ldr r4, sdrc_manual_1   @ get config addr
-   mov r5, #0x2@ autorefresh command
-   str r5, [r4]@ kick off refreshes
-   bx  lr
-sdrc_syscfg:
-   .word   SDRC_SYSCONFIG_P
-sdrc_mr_0:
-   .word   SDRC_MR_0_P
-sdrc_emr2_0:
-   .word   SDRC_EMR2_0_P
-sdrc_manual_0:
-   .word   SDRC_MANUAL_0_P
-sdrc_mr_1:
-   .word   SDRC_MR_1_P
-sdrc_emr2_1:
-   .word   SDRC_EMR2_1_P
-sdrc_manual_1:
-   .word   SDRC_MANUAL_1_P
-ENTRY(es3_sdrc_fix_sz)
-   .word   . - es3_sdrc_fix
-
 /* Function to call rom code to save secure ram context */
 ENTRY(save_secure_ram_context)
stmfd   sp!, {r1-r12, lr}   @ save registers on stack
@@ -577,6 +535,56 @@ skip_l2_inval:
/* restore regs and return */
ldmfd   sp!, {r0-r12, pc}
 
+
+/*
+ * Internal functions
+ */
+
+   .text
+ENTRY(es3_sdrc_fix)
+   ldr r4, sdrc_syscfg @ get config addr
+   ldr r5, [r4]@ get value
+   tst r5, #0x100  @ is part access blocked
+   it  eq
+   biceq   r5, r5, #0x100  @ clear bit if set
+   str r5, [r4]@ write back change
+   ldr r4, sdrc_mr_0   @ get config addr
+   ldr r5, [r4]@ get value
+   str r5, [r4]@ write back change
+   ldr r4, sdrc_emr2_0 @ get config addr
+   ldr r5, [r4]@ get value
+   str r5, [r4]@ write back change
+   

[PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

- Reworked and simplified the execution paths for better
  readability and to avoid duplication of code,
- Added comments on the entry and exit points and the interaction
  with the ROM code for OFF mode restore,
- Reworked the existing comments for better readability.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/control.c   |9 +-
 arch/arm/mach-omap2/sleep34xx.S |  313 +++
 2 files changed, 191 insertions(+), 131 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 728f268..f4b19ed 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -239,7 +239,14 @@ void omap3_save_scratchpad_contents(void)
struct omap3_scratchpad_prcm_block prcm_block_contents;
struct omap3_scratchpad_sdrc_block sdrc_block_contents;
 
-   /* Populate the Scratchpad contents */
+   /*
+* Populate the Scratchpad contents
+*
+* The get_*restore_pointer functions are used to provide a
+* physical restore address where the ROM code jumps while waking
+* up from MPU OFF/OSWR state.
+* The restore pointer is stored into the scratchpad.
+*/
scratchpad_contents.boot_config_ptr = 0x0;
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index beeb682..12061fd 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -71,6 +71,13 @@
  * API functions
  */
 
+/*
+ * The get_*restore_pointer functions are used to provide a
+ * physical restore address where the ROM code jumps while waking
+ * up from MPU OFF/OSWR state.
+ * The restore pointer is stored into the scratchpad.
+ */
+
.text
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
@@ -102,7 +109,7 @@ ENTRY(get_es3_restore_pointer_sz)
 /*
  * L2 cache needs to be toggled for stable OFF mode functionality on 3630.
  * This function sets up a flag that will allow for this toggling to take
- * place on 3630. Hopefully some version in the future maynot need this
+ * place on 3630. Hopefully some version in the future may not need this.
  */
 ENTRY(enable_omap3630_toggle_l2_on_restore)
 stmfd   sp!, {lr} @ save registers on stack
@@ -144,34 +151,158 @@ ENTRY(save_secure_ram_context_sz)
.word   . - save_secure_ram_context
 
 /*
+ * ==
+ * == Idle entry point ==
+ * ==
+ */
+
+/*
  * Forces OMAP into idle state
  *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if needed
+ * and executes the WFI instruction
  *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *  wakes up it continues execution at the point it went to sleep.
+ * Notes:
+ * - this code gets copied to internal SRAM at boot.
+ * - when the OMAP wakes up it continues at different execution points
+ *   depending on the low power mode (non-OFF vs OFF modes),
+ *   cf. 'Resume path for xxx mode' comments.
  */
 ENTRY(omap34xx_cpu_suspend)
stmfd   sp!, {r0-r12, lr}   @ save registers on stack
 
-   /* r0 contains restore pointer in sdram */
-   /* r1 contains information about saving context */
-   ldr r4, sdrc_power  @ read the SDRC_POWER register
-   ldr r5, [r4]@ read the contents of SDRC_POWER
-   orr r5, r5, #0x40   @ enable self refresh on idle req
-   str r5, [r4]@ write back to SDRC_POWER register
+   /*
+* r0 contains restore pointer in sdram
+* r1 contains information about saving context:
+*   0 - No context lost
+*   1 - Only L1 and logic lost
+*   2 - Only L2 lost
+*   3 - Both L1 and L2 lost
+*/
 
+   /* Save context only if required */
cmp r1, #0x0
-   /* If context save is required, do that and execute wfi */
-   bne save_context_wfi
+   beq omap3_do_wfi
+
+save_context_wfi:
+   mov r8, r0  @ Store SDRAM address in r8
+   mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
+   mov r4, #0x1@ Number of parameters for restore call
+   stmia   r8!, {r4-r5}@ Push parameters for restore call
+   mrc p15, 1, r5, c9, c0, 2   @ Read L2 AUX ctrl register
+   stmia   r8!, {r4-r5}@ Push parameters for restore call
+
+/* Check what that target sleep state is from r1 */
+   cmp r1, #0x2@ Only L2 lost, no need to save context
+   beq clean_caches
+
+l1_logic_lost:
+   /* Store 

[PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.

The macros are now defined at a centralized place, for
easier maintenance.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/sdrc.h |1 -
 arch/arm/mach-omap2/sleep34xx.S|1 +
 arch/arm/plat-omap/include/plat/sram.h |   11 +++
 arch/arm/plat-omap/sram.c  |7 ++-
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
index 68f57bb..b3f8379 100644
--- a/arch/arm/mach-omap2/sdrc.h
+++ b/arch/arm/mach-omap2/sdrc.h
@@ -74,5 +74,4 @@ static inline u32 sms_read_reg(u16 reg)
  */
 #define SDRC_MPURATE_LOOPS 96
 
-
 #endif
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 2191576..406cd2a 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -26,6 +26,7 @@
  */
 #include linux/linkage.h
 #include asm/assembler.h
+#include plat/sram.h
 #include mach/io.h
 
 #include cm.h
diff --git a/arch/arm/plat-omap/include/plat/sram.h 
b/arch/arm/plat-omap/include/plat/sram.h
index 5905100..9967d5e 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -11,6 +11,7 @@
 #ifndef __ARCH_ARM_OMAP_SRAM_H
 #define __ARCH_ARM_OMAP_SRAM_H
 
+#ifndef __ASSEMBLY__
 extern void * omap_sram_push(void * start, unsigned long size);
 extern void omap_sram_reprogram_clock(u32 dpllctl, u32 ckctl);
 
@@ -74,4 +75,14 @@ extern void omap_push_sram_idle(void);
 static inline void omap_push_sram_idle(void) {}
 #endif /* CONFIG_PM */
 
+#endif /* __ASSEMBLY__ */
+
+/*
+ * OMAP2+: define the SRAM PA addresses.
+ * Used by the SRAM management code and the idle sleep code.
+ */
+#define OMAP2_SRAM_PA  0x4020
+#define OMAP3_SRAM_PA   0x4020
+#define OMAP4_SRAM_PA  0x4030
+
 #endif
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 819ea0c..1a686c8 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -41,15 +41,12 @@
 
 #define OMAP1_SRAM_PA  0x2000
 #define OMAP1_SRAM_VA  VMALLOC_END
-#define OMAP2_SRAM_PA  0x4020
-#define OMAP2_SRAM_PUB_PA  0x4020f800
+#define OMAP2_SRAM_PUB_PA  (OMAP2_SRAM_PA + 0xf800)
 #define OMAP2_SRAM_VA  0xfe40
 #define OMAP2_SRAM_PUB_VA  (OMAP2_SRAM_VA + 0x800)
-#define OMAP3_SRAM_PA   0x4020
 #define OMAP3_SRAM_VA   0xfe40
-#define OMAP3_SRAM_PUB_PA   0x40208000
+#define OMAP3_SRAM_PUB_PA   (OMAP3_SRAM_PA + 0x8000)
 #define OMAP3_SRAM_PUB_VA   (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_PA  0x4030
 #define OMAP4_SRAM_VA  0xfe40
 #define OMAP4_SRAM_PUB_PA  (OMAP4_SRAM_PA + 0x4000)
 #define OMAP4_SRAM_PUB_VA  (OMAP4_SRAM_VA + 0x4000)
-- 
1.7.1

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


[PATCH 6/7] OMAP3: add comments for low power code errata

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

Errata covered:
- 1.157  1.185
- i443
- i581

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/pm34xx.c|4 ++--
 arch/arm/mach-omap2/sleep34xx.S |   11 +++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index adc0917..267f015 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -148,7 +148,7 @@ static void omap3_core_save_context(void)
 
/*
 * Force write last pad into memory, as this can fail in some
-* cases according to erratas 1.157, 1.185
+* cases according to errata 1.157, 1.185
 */
omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
OMAP343X_CONTROL_MEM_WKUP + 0x2a0);
@@ -446,7 +446,7 @@ void omap_sram_idle(void)
/*
* On EMU/HS devices ROM code restores a SRDC value
* from scratchpad which has automatic self refresh on timeout
-   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
+   * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443.
* Hence store/restore the SDRC_POWER register here.
*/
if (omap_rev() = OMAP3430_REV_ES3_0 
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 12061fd..8e5004a 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -592,6 +592,7 @@ usettbr0:
  * Internal functions
  */
 
+/* This function implements the erratum ID i443 WA, applies to 34xx = ES3.0 */
.text
 ENTRY(es3_sdrc_fix)
ldr r4, sdrc_syscfg @ get config addr
@@ -637,6 +638,16 @@ sdrc_manual_1:
 ENTRY(es3_sdrc_fix_sz)
.word   . - es3_sdrc_fix
 
+/*
+ * This function implements the erratum ID i581 WA:
+ *  SDRC state restore before accessing the SDRAM
+ *
+ * Only used at return from non-OFF mode. For OFF
+ * mode the ROM code configures the SDRC and
+ * the DPLL before calling the restore code directly
+ * from DDR.
+ */
+
 /* Make sure SDRC accesses are ok */
 wait_sdrc_ok:
 
-- 
1.7.1

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


[PATCH 7/7] OMAP3: ASM sleep code format rework

2010-12-17 Thread jean . pihet
From: Jean Pihet j-pi...@ti.com

Cosmetic fixes to the code:
- white spaces and tabs,
- alignement,
- comments rephrase and typos,
- multi-line comments

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/sleep34xx.S |  226 +--
 1 files changed, 122 insertions(+), 104 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 8e5004a..6376427 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -1,6 +1,10 @@
 /*
  * linux/arch/arm/mach-omap2/sleep.S
  *
+ * (C) Copyright 2010
+ * Texas Instruments
+ * Jean Pihet j-pi...@ti.com
+ *
  * (C) Copyright 2007
  * Texas Instruments
  * Karthik Dasu karthik...@ti.com
@@ -81,20 +85,20 @@
.text
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
adr r0, restore
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 ENTRY(get_restore_pointer_sz)
-.word   . - get_restore_pointer
+   .word   . - get_restore_pointer
 
.text
 /* Function call to get the restore pointer for 3630 resume from OFF */
 ENTRY(get_omap3630_restore_pointer)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
adr r0, restore_3630
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 ENTRY(get_omap3630_restore_pointer_sz)
-.word   . - get_omap3630_restore_pointer
+   .word   . - get_omap3630_restore_pointer
 
.text
 /* Function call to get the restore pointer for ES3 to resume from OFF */
@@ -112,16 +116,16 @@ ENTRY(get_es3_restore_pointer_sz)
  * place on 3630. Hopefully some version in the future may not need this.
  */
 ENTRY(enable_omap3630_toggle_l2_on_restore)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
/* Setup so that we will disable and enable l2 */
mov r1, #0x1
str r1, l2dis_3630
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 
+   .text
 /* Function to call rom code to save secure ram context */
 ENTRY(save_secure_ram_context)
stmfd   sp!, {r1-r12, lr}   @ save registers on stack
-
adr r3, api_params  @ r3 points to parameters
str r0, [r3,#0x4]   @ r0 has sdram address
ldr r12, high_mask
@@ -150,6 +154,7 @@ api_params:
 ENTRY(save_secure_ram_context_sz)
.word   . - save_secure_ram_context
 
+
 /*
  * ==
  * == Idle entry point ==
@@ -163,13 +168,14 @@ ENTRY(save_secure_ram_context_sz)
  * and executes the WFI instruction
  *
  * Notes:
- * - this code gets copied to internal SRAM at boot.
+ * - this code gets copied to internal SRAM at boot and after wake-up
+ *   from OFF mode
  * - when the OMAP wakes up it continues at different execution points
  *   depending on the low power mode (non-OFF vs OFF modes),
  *   cf. 'Resume path for xxx mode' comments.
  */
 ENTRY(omap34xx_cpu_suspend)
-   stmfd   sp!, {r0-r12, lr}   @ save registers on stack
+   stmfd   sp!, {r0-r12, lr}   @ save registers on stack
 
/*
 * r0 contains restore pointer in sdram
@@ -276,9 +282,9 @@ clean_l2:
 *  - should be faster and will change with kernel
 *  - 'might' have to copy address, load and jump to it
 */
-   ldr r1, kernel_flush
-   mov lr, pc
-   bx  r1
+   ldr r1, kernel_flush
+   mov lr, pc
+   bx  r1
 
 omap3_do_wfi:
ldr r4, sdrc_power  @ read the SDRC_POWER register
@@ -371,18 +377,18 @@ restore_3630:
/* Fall thru to common code for the remaining logic */
 
 restore:
-/*
+   /*
 * Check what was the reason for mpu reset and store the reason in r9:
 *  0 - No context lost
- *  1 - Only L1 and logic lost
- *  2 - Only L2 lost - In this case, we wont be here
- *  3 - Both L1 and L2 lost
+*  1 - Only L1 and logic lost
+*  2 - Only L2 lost - In this case, we wont be here
+*  3 - Both L1 and L2 lost
 */
-   ldr r1, pm_pwstctrl_mpu
+   ldr r1, pm_pwstctrl_mpu
ldr r2, [r1]
-   and r2, r2, #0x3
-   cmp r2, #0x0@ Check if target power state was OFF or RET
-moveq   r9, #0x3@ MPU OFF = L1 and L2 lost
+   and r2, r2, #0x3
+   cmp r2, #0x0@ Check if target power state was OFF or RET
+   moveq   r9, #0x3@ MPU OFF = L1 and L2 

Re: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths

2010-12-17 Thread Jean Pihet
On Fri, Dec 17, 2010 at 6:04 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Thursday, December 16, 2010 11:21 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths

 From: Jean Pihet j-pi...@ti.com

 - Reworked and simplified the execution paths for better
   readability and to avoid duplication of code,
 - Added comments on the entry and exit points and the interaction
   with the ROM code for OFF mode restore,
 - Reworked the existing comments for better readability.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com
 ---
  arch/arm/mach-omap2/control.c   |   10 +-
  arch/arm/mach-omap2/sleep34xx.S |  309
 ++
 
  2 files changed, 188 insertions(+), 131 deletions(-)

 diff --git a/arch/arm/mach-omap2/control.c
 b/arch/arm/mach-omap2/control.c
 index 728f268..5cb7276 100644
 --- a/arch/arm/mach-omap2/control.c
 +++ b/arch/arm/mach-omap2/control.c
 @@ -239,7 +239,15 @@ void omap3_save_scratchpad_contents(void)
       struct omap3_scratchpad_prcm_block prcm_block_contents;
       struct omap3_scratchpad_sdrc_block sdrc_block_contents;

 -     /* Populate the Scratchpad contents */
 +     /*
 +      * Populate the Scratchpad contents
 +      *
 +      * The get_*restore_pointer functions are used to get the resume
 +      *  function pointer to be called by the ROM code when back from
 WFI
 +      *  in OFF mode.
 Align your text here.
 +      * The restore pointer is stored into the scratchpad for later
 access
 +      *  by the ROM code.
 The text needs to be reworked a bit.

 The get_*restore_pointer functions are used to provide a physical
 restore
 address where ROM code jumps while waking up from MPU OFF/OSWR state.
 The restore pointer is stored into the scratchpad

That sounds better. Fixed.


 +      */
       scratchpad_contents.boot_config_ptr = 0x0;
       if (cpu_is_omap3630())
               scratchpad_contents.public_restore_ptr =
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 426af02..55ddd5a 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -70,6 +70,11 @@
   * API functions
   */

 +/*
 + * The get_*restore_pointer functions are returning the resume
 + *  function pointer to be called by the ROM code when back from WFI
 + *  in OFF mode.
 Ditto
 The get_*restore_pointer functions are used to provide a physical
 restore
 address where ROM code jumps while waking up from MPU OFF/OSWR state.
 The restore pointer is stored into the scratchpad
Idem


 + */
       .text
  /* Function call to get the restore pointer for resume from OFF */
  ENTRY(get_restore_pointer)
 @@ -101,7 +106,7 @@ ENTRY(get_es3_restore_pointer_sz)
  /*
   * L2 cache needs to be toggled for stable OFF mode functionality on
 3630.
   * This function sets up a flag that will allow for this toggling to
 take
 - * place on 3630. Hopefully some version in the future maynot need this
 + * place on 3630. Hopefully some version in the future maynot need
 this.
 'maynot' . may not
Fixed

   */
  ENTRY(enable_omap3630_toggle_l2_on_restore)
          stmfd   sp!, {lr}     @ save registers on stack
 @@ -143,34 +148,156 @@ ENTRY(save_secure_ram_context_sz)
       .word   . - save_secure_ram_context

  /*
 + * ==
 + * == Idle entry point ==
 + * ==
 + */
 +
 +/*
   * Forces OMAP into idle state
   *
 - * omap34xx_suspend() - This bit of code just executes the WFI
 - * for normal idles.
 + * omap34xx_suspend() - This bit of code saves the CPU context if
 needed
 + * and executes the WFI instruction
   *
 - * Note: This code get's copied to internal SRAM at boot. When the OMAP
 - *    wakes up it continues execution at the point it went to sleep.
 + * Notes:
 + * - this code gets copied to internal SRAM at boot.
 + * - when the OMAP wakes up it continues at different execution points
 + *   depending on the low power mode (non-OFF vs OFF modes),
 + *   cf. 'Resume path for xxx mode' comments.
   */
  ENTRY(omap34xx_cpu_suspend)
       stmfd   sp!, {r0-r12, lr}               @ save registers on stack

 -     /* r0 contains restore pointer in sdram */
 -     /* r1 contains information about saving context */
 -     ldr     r4, sdrc_power          @ read the SDRC_POWER register
 -     ldr     r5, [r4]                @ read the contents of SDRC_POWER
 -     orr     r5, r5, #0x40           @ enable self refresh on idle req
 -     str     r5, [r4]                @ write back to SDRC_POWER
 register
 +     /*
 +      * r0 contains restore pointer in sdram
 +      * r1 contains information about saving context:
 

Re: [PATCH 7/7] OMAP3: ASM sleep code format rework

2010-12-17 Thread Jean Pihet
On Fri, Dec 17, 2010 at 6:09 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Thursday, December 16, 2010 11:21 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 7/7] OMAP3: ASM sleep code format rework

 From: Jean Pihet j-pi...@ti.com

 Cosmetic fixes to the code:
 - white spaces and tabs,
 - alignement,
 - comments rephrase and typos,
 - multi-line comments

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com
 ---
  arch/arm/mach-omap2/sleep34xx.S |  221
 +-
 -
  1 files changed, 118 insertions(+), 103 deletions(-)

 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 207f6e9..9c1c57e 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -1,6 +1,10 @@
  /*
   * linux/arch/arm/mach-omap2/sleep.S
   *
 + * (C) Copyright 2010
 + * Texas Instruments
 + * Jean Pihet j-pi...@ti.com
 + *
   * (C) Copyright 2007
   * Texas Instruments
   * Karthik Dasu karthik...@ti.com
 @@ -78,20 +82,20 @@
       .text
  /* Function call to get the restore pointer for resume from OFF */
  ENTRY(get_restore_pointer)
 -        stmfd   sp!, {lr}     @ save registers on stack
 +     stmfd   sp!, {lr}       @ save registers on stack
       adr     r0, restore
 -        ldmfd   sp!, {pc}     @ restore regs and return
 +     ldmfd   sp!, {pc}       @ restore regs and return
  ENTRY(get_restore_pointer_sz)
 -        .word   . - get_restore_pointer
 +     .word   . - get_restore_pointer

       .text
  /* Function call to get the restore pointer for 3630 resume from OFF */
  ENTRY(get_omap3630_restore_pointer)
 -        stmfd   sp!, {lr}     @ save registers on stack
 +     stmfd   sp!, {lr}       @ save registers on stack
       adr     r0, restore_3630
 -        ldmfd   sp!, {pc}     @ restore regs and return
 +     ldmfd   sp!, {pc}       @ restore regs and return
  ENTRY(get_omap3630_restore_pointer_sz)
 -        .word   . - get_omap3630_restore_pointer
 +     .word   . - get_omap3630_restore_pointer

       .text
  /* Function call to get the restore pointer for ES3 to resume from OFF
 */
 @@ -109,16 +113,16 @@ ENTRY(get_es3_restore_pointer_sz)
   * place on 3630. Hopefully some version in the future maynot need
 this.
   */
  ENTRY(enable_omap3630_toggle_l2_on_restore)
 -        stmfd   sp!, {lr}     @ save registers on stack
 +     stmfd   sp!, {lr}       @ save registers on stack
       /* Setup so that we will disable and enable l2 */
       mov     r1, #0x1
       str     r1, l2dis_3630
 -        ldmfd   sp!, {pc}     @ restore regs and return
 +     ldmfd   sp!, {pc}       @ restore regs and return

 +     .text
  /* Function to call rom code to save secure ram context */
  ENTRY(save_secure_ram_context)
       stmfd   sp!, {r1-r12, lr}       @ save registers on stack
 -
       adr     r3, api_params          @ r3 points to parameters
       str     r0, [r3,#0x4]           @ r0 has sdram address
       ldr     r12, high_mask
 @@ -147,6 +151,7 @@ api_params:
  ENTRY(save_secure_ram_context_sz)
       .word   . - save_secure_ram_context

 +
  /*
   * ==
   * == Idle entry point ==
 @@ -160,13 +165,14 @@ ENTRY(save_secure_ram_context_sz)
   * and executes the WFI instruction
   *
   * Notes:
 - * - this code gets copied to internal SRAM at boot.
 + * - this code gets copied to internal SRAM at boot and after wake-up
 + *   from OFF mode
   * - when the OMAP wakes up it continues at different execution points
   *   depending on the low power mode (non-OFF vs OFF modes),
   *   cf. 'Resume path for xxx mode' comments.
   */
  ENTRY(omap34xx_cpu_suspend)
 -     stmfd   sp!, {r0-r12, lr}               @ save registers on stack
 +     stmfd   sp!, {r0-r12, lr}       @ save registers on stack

       /*
        * r0 contains restore pointer in sdram
 @@ -271,9 +277,9 @@ clean_l2:
        *  - should be faster and will change with kernel
        *  - 'might' have to copy address, load and jump to it
        */
 -     ldr r1, kernel_flush
 -     mov lr, pc
 -     bx  r1
 +     ldr     r1, kernel_flush
 +     mov     lr, pc
 +     bx      r1

  omap3_do_wfi:
       ldr     r4, sdrc_power          @ read the SDRC_POWER register
 @@ -366,18 +372,18 @@ restore_3630:
       /* Fall thru to common code for the remaining logic */

  restore:
 -        /*
 +     /*
        * Check what was the reason for mpu reset and store the reason in
 r9:
        *  0 - No context lost
 -         *  1 - Only L1 and logic lost
 -         *  2 - Only L2 lost - In this case, we wont be here
 -         *  3 - Both L1 and L2 lost
 +      *  1 - Only L1 and logic lost
 +      *  2 - Only L2 lost - In this case, 

Re: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code

2010-12-17 Thread Jean Pihet
Hi Santosh, Kevin,

On Fri, Dec 17, 2010 at 6:05 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 Jean,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Thursday, December 16, 2010 11:21 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code

 From: Jean Pihet j-pi...@ti.com

 This patch only contains clean-ups and cosmetic changes,
 no functional change.

 Clean-up of the ASM sleep code, for better readability and
 easier maintenance.

 Applies on top of Nishant's latest idle path errata fixes step 2,
 cf. http://marc.info/?l=linux-omapm=129139584919242w=2

 Thanks for cleanup. Have few minor comments on these patches.

Thanks for the review.
I fixed the issues and reposted the series as '[PATCH 0/7 v5] OMAP3:
clean up ASM sleep code'.

Regards,
Jean


 Jean Pihet (7):
   OMAP2+: use global values for the SRAM PA addresses
   OMAP3: remove hardcoded values from the ASM sleep code
   OMAP3: re-organize the ASM sleep code
   OMAP3: rework of the ASM sleep code execution paths
   OMAP3: add comments for low power code errata
   OMAP3: ASM sleep code format rework
   OMAP3: remove unused code from the ASM sleep code

  arch/arm/mach-omap2/control.c   |   10 +-
  arch/arm/mach-omap2/control.h   |    2 +
  arch/arm/mach-omap2/pm.h        |    1 -
  arch/arm/mach-omap2/pm34xx.c    |    4 +-
  arch/arm/mach-omap2/sdrc.h      |    7 +
  arch/arm/mach-omap2/sleep34xx.S |  714
 +-
 -
  arch/arm/plat-omap/sram.c       |    7 +-
  7 files changed, 401 insertions(+), 344 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
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


RE: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: Jean Pihet [mailto:jean.pi...@newoldbits.com]
 Sent: Friday, December 17, 2010 3:48 PM
 To: Santosh Shilimkar; khil...@deeprootsystems.com
 Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Jean
 Pihet-XID
 Subject: Re: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code

 Hi Santosh, Kevin,

 On Fri, Dec 17, 2010 at 6:05 AM, Santosh Shilimkar
 santosh.shilim...@ti.com wrote:
  Jean,
 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
  Sent: Thursday, December 16, 2010 11:21 PM
  To: linux-omap@vger.kernel.org
  Cc: khil...@deeprootsystems.com;
linux-arm-ker...@lists.infradead.org;
  Jean Pihet
  Subject: [PATCH 0/7 v4] OMAP3: clean up ASM sleep code
 
  From: Jean Pihet j-pi...@ti.com
 
  This patch only contains clean-ups and cosmetic changes,
  no functional change.
 
  Clean-up of the ASM sleep code, for better readability and
  easier maintenance.
 
  Applies on top of Nishant's latest idle path errata fixes step 2,
  cf. http://marc.info/?l=linux-omapm=129139584919242w=2
 
  Thanks for cleanup. Have few minor comments on these patches.

 Thanks for the review.
 I fixed the issues and reposted the series as '[PATCH 0/7 v5] OMAP3:
 clean up ASM sleep code'.

Thanks. I checked it. Will ack your patches
--
To unsubscribe from this list: send the line unsubscribe 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/7] OMAP3: remove unused code from the ASM sleep code

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 1/7] OMAP3: remove unused code from the ASM sleep code

 From: Jean Pihet j-pi...@ti.com

 Remove unused code:
 - macros,
 - variables,
 - unused semaphore locking API. This API shall be added back
   when needed,
 - infinite loops for debug.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/pm.h|1 -
  arch/arm/mach-omap2/sleep34xx.S |   58
--
 -
  2 files changed, 6 insertions(+), 53 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
 index aff39d0..e458b2a 100644
 --- a/arch/arm/mach-omap2/pm.h
 +++ b/arch/arm/mach-omap2/pm.h
 @@ -80,7 +80,6 @@ extern void save_secure_ram_context(u32 *addr);
  extern void omap3_save_scratchpad_contents(void);

  extern unsigned int omap24xx_idle_loop_suspend_sz;
 -extern unsigned int omap34xx_suspend_sz;
  extern unsigned int save_secure_ram_context_sz;
  extern unsigned int omap24xx_cpu_suspend_sz;
  extern unsigned int omap34xx_cpu_suspend_sz;
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index d2eda01..2191576 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -35,11 +35,7 @@

  #define SDRC_SCRATCHPAD_SEM_V0xfa00291c

 -#define PM_PREPWSTST_CORE_V  OMAP34XX_PRM_REGADDR(CORE_MOD, \
 - OMAP3430_PM_PREPWSTST)
  #define PM_PREPWSTST_CORE_P  0x48306AE8
 -#define PM_PREPWSTST_MPU_V   OMAP34XX_PRM_REGADDR(MPU_MOD, \
 - OMAP3430_PM_PREPWSTST)
  #define PM_PWSTCTRL_MPU_POMAP3430_PRM_BASE + MPU_MOD +
 OMAP2_PM_PWSTCTRL
  #define CM_IDLEST1_CORE_VOMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
  #define CM_IDLEST_CKGEN_VOMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
 @@ -62,36 +58,10 @@
  #define SDRC_DLLA_STATUS_V   OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
  #define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)

 -.text
 -/* Function to acquire the semaphore in scratchpad */
 -ENTRY(lock_scratchpad_sem)
 - stmfd   sp!, {lr}   @ save registers on stack
 -wait_sem:
 - mov r0,#1
 - ldr r1, sdrc_scratchpad_sem
 -wait_loop:
 - ldr r2, [r1]@ load the lock value
 - cmp r2, r0  @ is the lock free ?
 - beq wait_loop   @ not free...
 - swp r2, r0, [r1]@ semaphore free so lock it and proceed
 - cmp r2, r0  @ did we succeed ?
 - beq wait_sem@ no - try again
 - ldmfd   sp!, {pc}   @ restore regs and return
 -sdrc_scratchpad_sem:
 -.word SDRC_SCRATCHPAD_SEM_V
 -ENTRY(lock_scratchpad_sem_sz)
 -.word   . - lock_scratchpad_sem
 -
 -.text
 -/* Function to release the scratchpad semaphore */
 -ENTRY(unlock_scratchpad_sem)
 - stmfd   sp!, {lr}   @ save registers on stack
 - ldr r3, sdrc_scratchpad_sem
 - mov r2,#0
 - str r2,[r3]
 - ldmfd   sp!, {pc}   @ restore regs and return
 -ENTRY(unlock_scratchpad_sem_sz)
 -.word   . - unlock_scratchpad_sem
 +
 +/*
 + * API functions
 + */

   .text
  /* Function call to get the restore pointer for resume from OFF */
 @@ -178,8 +148,7 @@ ENTRY(es3_sdrc_fix_sz)
  /* Function to call rom code to save secure ram context */
  ENTRY(save_secure_ram_context)
   stmfd   sp!, {r1-r12, lr}   @ save registers on stack
 -save_secure_ram_debug:
 - /* b save_secure_ram_debug */   @ enable to debug save code
 +
   adr r3, api_params  @ r3 points to parameters
   str r0, [r3,#0x4]   @ r0 has sdram address
   ldr r12, high_mask
 @@ -219,8 +188,7 @@ ENTRY(save_secure_ram_context_sz)
   */
  ENTRY(omap34xx_cpu_suspend)
   stmfd   sp!, {r0-r12, lr}   @ save registers on stack
 -loop:
 - /*b loop*/  @Enable to debug by stepping through code
 +
   /* r0 contains restore pointer in sdram */
   /* r1 contains information about saving context */
   ldr r4, sdrc_power  @ read the SDRC_POWER register
 @@ -252,7 +220,6 @@ loop:

   ldmfd   sp!, {r0-r12, pc}   @ restore regs and return
  restore_es3:
 - /*b restore_es3*/   @ Enable to debug restore code
   ldr r5, pm_prepwstst_core_p
   ldr r4, [r5]
   and r4, r4, #0x3
 @@ -272,7 +239,6 @@ copy_to_sram:
   b   restore

  restore_3630:
 - /*b restore_es3630*/@ Enable to debug restore code
   ldr r1, pm_prepwstst_core_p
   ldr r2, [r1]
  

RE: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses

 From: Jean Pihet j-pi...@ti.com

 The SRAM PA addresses are locally defined and used at
 different places, i.e. SRAM management code and idle sleep code.

 The macros are now defined at a centralized place, for
 easier maintenance.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/sdrc.h |1 -
  arch/arm/mach-omap2/sleep34xx.S|1 +
  arch/arm/plat-omap/include/plat/sram.h |   11 +++
  arch/arm/plat-omap/sram.c  |7 ++-
  4 files changed, 14 insertions(+), 6 deletions(-)

 diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
 index 68f57bb..b3f8379 100644
 --- a/arch/arm/mach-omap2/sdrc.h
 +++ b/arch/arm/mach-omap2/sdrc.h
 @@ -74,5 +74,4 @@ static inline u32 sms_read_reg(u16 reg)
   */
  #define SDRC_MPURATE_LOOPS   96

 -
  #endif
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 2191576..406cd2a 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -26,6 +26,7 @@
   */
  #include linux/linkage.h
  #include asm/assembler.h
 +#include plat/sram.h
  #include mach/io.h

  #include cm.h
 diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-
 omap/include/plat/sram.h
 index 5905100..9967d5e 100644
 --- a/arch/arm/plat-omap/include/plat/sram.h
 +++ b/arch/arm/plat-omap/include/plat/sram.h
 @@ -11,6 +11,7 @@
  #ifndef __ARCH_ARM_OMAP_SRAM_H
  #define __ARCH_ARM_OMAP_SRAM_H

 +#ifndef __ASSEMBLY__
  extern void * omap_sram_push(void * start, unsigned long size);
  extern void omap_sram_reprogram_clock(u32 dpllctl, u32 ckctl);

 @@ -74,4 +75,14 @@ extern void omap_push_sram_idle(void);
  static inline void omap_push_sram_idle(void) {}
  #endif /* CONFIG_PM */

 +#endif /* __ASSEMBLY__ */
 +
 +/*
 + * OMAP2+: define the SRAM PA addresses.
 + * Used by the SRAM management code and the idle sleep code.
 + */
 +#define OMAP2_SRAM_PA0x4020
 +#define OMAP3_SRAM_PA   0x4020
 +#define OMAP4_SRAM_PA0x4030
 +
  #endif
 diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
 index 819ea0c..1a686c8 100644
 --- a/arch/arm/plat-omap/sram.c
 +++ b/arch/arm/plat-omap/sram.c
 @@ -41,15 +41,12 @@

  #define OMAP1_SRAM_PA0x2000
  #define OMAP1_SRAM_VAVMALLOC_END
 -#define OMAP2_SRAM_PA0x4020
 -#define OMAP2_SRAM_PUB_PA0x4020f800
 +#define OMAP2_SRAM_PUB_PA(OMAP2_SRAM_PA + 0xf800)
  #define OMAP2_SRAM_VA0xfe40
  #define OMAP2_SRAM_PUB_VA(OMAP2_SRAM_VA + 0x800)
 -#define OMAP3_SRAM_PA   0x4020
  #define OMAP3_SRAM_VA   0xfe40
 -#define OMAP3_SRAM_PUB_PA   0x40208000
 +#define OMAP3_SRAM_PUB_PA   (OMAP3_SRAM_PA + 0x8000)
  #define OMAP3_SRAM_PUB_VA   (OMAP3_SRAM_VA + 0x8000)
 -#define OMAP4_SRAM_PA0x4030
  #define OMAP4_SRAM_VA0xfe40
  #define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
  #define OMAP4_SRAM_PUB_VA(OMAP4_SRAM_VA + 0x4000)
 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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/7] OMAP3: remove hardcoded values from the ASM sleep code

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet; Vishwanath BS
 Subject: [PATCH 3/7] OMAP3: remove hardcoded values from the ASM sleep
 code

 From: Jean Pihet j-pi...@ti.com

 Using macros from existing include files for registers addresses.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Based on original patch from Vishwa.

 Signed-off-by: Jean Pihet j-pi...@ti.com
 Cc: Vishwanath BS vishwanath...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/control.h   |2 ++
  arch/arm/mach-omap2/sleep34xx.S |   29 ++---
  2 files changed, 20 insertions(+), 11 deletions(-)

 diff --git a/arch/arm/mach-omap2/control.h
b/arch/arm/mach-omap2/control.h
 index d7911c5..72efefb 100644
 --- a/arch/arm/mach-omap2/control.h
 +++ b/arch/arm/mach-omap2/control.h
 @@ -274,6 +274,8 @@
  #define OMAP343X_SCRATCHPAD_ROM  (OMAP343X_CTRL_BASE +
0x860)
  #define OMAP343X_SCRATCHPAD  (OMAP343X_CTRL_BASE + 0x910)
  #define OMAP343X_SCRATCHPAD_ROM_OFFSET   0x19C
 +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\
 + OMAP343X_SCRATCHPAD + reg)

  /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */
  #define AM35XX_USBOTG_VBUSP_CLK_SHIFT   0
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 406cd2a..8e9f38f 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -34,20 +34,27 @@
  #include sdrc.h
  #include control.h

 -#define SDRC_SCRATCHPAD_SEM_V0xfa00291c
 -
 -#define PM_PREPWSTST_CORE_P  0x48306AE8
 +/*
 + * Registers access definitions
 + */
 +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc
 +#define SDRC_SCRATCHPAD_SEM_VOMAP343X_SCRATCHPAD_REGADDR\
 + (SDRC_SCRATCHPAD_SEM_OFFS)
 +#define PM_PREPWSTST_CORE_P  OMAP3430_PRM_BASE + CORE_MOD +\
 + OMAP3430_PM_PREPWSTST
  #define PM_PWSTCTRL_MPU_POMAP3430_PRM_BASE + MPU_MOD +
 OMAP2_PM_PWSTCTRL
  #define CM_IDLEST1_CORE_VOMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1)
  #define CM_IDLEST_CKGEN_VOMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST)
 -#define SRAM_BASE_P  0x4020
 -#define CONTROL_STAT 0x480022F0
 -#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE\
 - + OMAP36XX_CONTROL_MEM_RTA_CTRL)
 -#define SCRATCHPAD_MEM_OFFS  0x310 /* Move this as correct place is
 -* available */
 -#define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE +
 OMAP343X_CONTROL_MEM_WKUP\
 - + SCRATCHPAD_MEM_OFFS)
 +#define SRAM_BASE_P  OMAP3_SRAM_PA
 +#define CONTROL_STAT OMAP343X_CTRL_BASE +
OMAP343X_CONTROL_STATUS
 +#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE +\
 + OMAP36XX_CONTROL_MEM_RTA_CTRL)
 +
 +/* Move this as correct place is available */
 +#define SCRATCHPAD_MEM_OFFS  0x310
 +#define SCRATCHPAD_BASE_P(OMAP343X_CTRL_BASE +\
 + OMAP343X_CONTROL_MEM_WKUP +\
 + SCRATCHPAD_MEM_OFFS)
  #define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER)
  #define SDRC_SYSCONFIG_P (OMAP343X_SDRC_BASE + SDRC_SYSCONFIG)
  #define SDRC_MR_0_P  (OMAP343X_SDRC_BASE + SDRC_MR_0)
 --
 1.7.1

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


RE: [PATCH 4/7] OMAP3: re-organize the ASM sleep code

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 4/7] OMAP3: re-organize the ASM sleep code

 From: Jean Pihet j-pi...@ti.com

 Organize the code in the following sections:
 - register access macros,
 - API functions,
 - internal functions.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/sleep34xx.S |  114
+-
 -
  1 files changed, 61 insertions(+), 53 deletions(-)

 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 8e9f38f..beeb682 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -79,6 +79,7 @@ ENTRY(get_restore_pointer)
  ldmfd   sp!, {pc} @ restore regs and return
  ENTRY(get_restore_pointer_sz)
  .word   . - get_restore_pointer
 +
   .text
  /* Function call to get the restore pointer for 3630 resume from OFF */
  ENTRY(get_omap3630_restore_pointer)
 @@ -89,9 +90,18 @@ ENTRY(get_omap3630_restore_pointer_sz)
  .word   . - get_omap3630_restore_pointer

   .text
 +/* Function call to get the restore pointer for ES3 to resume from OFF
*/
 +ENTRY(get_es3_restore_pointer)
 + stmfd   sp!, {lr}   @ save registers on stack
 + adr r0, restore_es3
 + ldmfd   sp!, {pc}   @ restore regs and return
 +ENTRY(get_es3_restore_pointer_sz)
 + .word   . - get_es3_restore_pointer
 +
 + .text
  /*
   * L2 cache needs to be toggled for stable OFF mode functionality on
3630.
 - * This function sets up a fflag that will allow for this toggling to
 take
 + * This function sets up a flag that will allow for this toggling to
take
   * place on 3630. Hopefully some version in the future maynot need this
   */
  ENTRY(enable_omap3630_toggle_l2_on_restore)
 @@ -101,58 +111,6 @@ ENTRY(enable_omap3630_toggle_l2_on_restore)
   str r1, l2dis_3630
  ldmfd   sp!, {pc} @ restore regs and return

 - .text
 -/* Function call to get the restore pointer for for ES3 to resume from
 OFF */
 -ENTRY(get_es3_restore_pointer)
 - stmfd   sp!, {lr}   @ save registers on stack
 - adr r0, restore_es3
 - ldmfd   sp!, {pc}   @ restore regs and return
 -ENTRY(get_es3_restore_pointer_sz)
 - .word   . - get_es3_restore_pointer
 -
 -ENTRY(es3_sdrc_fix)
 - ldr r4, sdrc_syscfg @ get config addr
 - ldr r5, [r4]@ get value
 - tst r5, #0x100  @ is part access blocked
 - it  eq
 - biceq   r5, r5, #0x100  @ clear bit if set
 - str r5, [r4]@ write back change
 - ldr r4, sdrc_mr_0   @ get config addr
 - ldr r5, [r4]@ get value
 - str r5, [r4]@ write back change
 - ldr r4, sdrc_emr2_0 @ get config addr
 - ldr r5, [r4]@ get value
 - str r5, [r4]@ write back change
 - ldr r4, sdrc_manual_0   @ get config addr
 - mov r5, #0x2@ autorefresh command
 - str r5, [r4]@ kick off refreshes
 - ldr r4, sdrc_mr_1   @ get config addr
 - ldr r5, [r4]@ get value
 - str r5, [r4]@ write back change
 - ldr r4, sdrc_emr2_1 @ get config addr
 - ldr r5, [r4]@ get value
 - str r5, [r4]@ write back change
 - ldr r4, sdrc_manual_1   @ get config addr
 - mov r5, #0x2@ autorefresh command
 - str r5, [r4]@ kick off refreshes
 - bx  lr
 -sdrc_syscfg:
 - .word   SDRC_SYSCONFIG_P
 -sdrc_mr_0:
 - .word   SDRC_MR_0_P
 -sdrc_emr2_0:
 - .word   SDRC_EMR2_0_P
 -sdrc_manual_0:
 - .word   SDRC_MANUAL_0_P
 -sdrc_mr_1:
 - .word   SDRC_MR_1_P
 -sdrc_emr2_1:
 - .word   SDRC_EMR2_1_P
 -sdrc_manual_1:
 - .word   SDRC_MANUAL_1_P
 -ENTRY(es3_sdrc_fix_sz)
 - .word   . - es3_sdrc_fix
 -
  /* Function to call rom code to save secure ram context */
  ENTRY(save_secure_ram_context)
   stmfd   sp!, {r1-r12, lr}   @ save registers on stack
 @@ -577,6 +535,56 @@ skip_l2_inval:
   /* restore regs and return */
   ldmfd   sp!, {r0-r12, pc}

 +
 +/*
 + * Internal functions
 + */
 +
 + .text
 +ENTRY(es3_sdrc_fix)
 + ldr r4, sdrc_syscfg @ get config addr
 + ldr r5, [r4]@ get value
 + tst r5, #0x100  @ is part access blocked
 + it  eq
 + biceq   r5, r5, #0x100

RE: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths

 From: Jean Pihet j-pi...@ti.com

 - Reworked and simplified the execution paths for better
   readability and to avoid duplication of code,
 - Added comments on the entry and exit points and the interaction
   with the ROM code for OFF mode restore,
 - Reworked the existing comments for better readability.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/control.c   |9 +-
  arch/arm/mach-omap2/sleep34xx.S |  313
+++---
 -
  2 files changed, 191 insertions(+), 131 deletions(-)

 diff --git a/arch/arm/mach-omap2/control.c
b/arch/arm/mach-omap2/control.c
 index 728f268..f4b19ed 100644
 --- a/arch/arm/mach-omap2/control.c
 +++ b/arch/arm/mach-omap2/control.c
 @@ -239,7 +239,14 @@ void omap3_save_scratchpad_contents(void)
   struct omap3_scratchpad_prcm_block prcm_block_contents;
   struct omap3_scratchpad_sdrc_block sdrc_block_contents;

 - /* Populate the Scratchpad contents */
 + /*
 +  * Populate the Scratchpad contents
 +  *
 +  * The get_*restore_pointer functions are used to provide a
 +  * physical restore address where the ROM code jumps while waking
 +  * up from MPU OFF/OSWR state.
 +  * The restore pointer is stored into the scratchpad.
 +  */
   scratchpad_contents.boot_config_ptr = 0x0;
   if (cpu_is_omap3630())
   scratchpad_contents.public_restore_ptr =
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index beeb682..12061fd 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -71,6 +71,13 @@
   * API functions
   */

 +/*
 + * The get_*restore_pointer functions are used to provide a
 + * physical restore address where the ROM code jumps while waking
 + * up from MPU OFF/OSWR state.
 + * The restore pointer is stored into the scratchpad.
 + */
 +
   .text
  /* Function call to get the restore pointer for resume from OFF */
  ENTRY(get_restore_pointer)
 @@ -102,7 +109,7 @@ ENTRY(get_es3_restore_pointer_sz)
  /*
   * L2 cache needs to be toggled for stable OFF mode functionality on
3630.
   * This function sets up a flag that will allow for this toggling to
take
 - * place on 3630. Hopefully some version in the future maynot need this
 + * place on 3630. Hopefully some version in the future may not need
this.
   */
  ENTRY(enable_omap3630_toggle_l2_on_restore)
  stmfd   sp!, {lr} @ save registers on stack
 @@ -144,34 +151,158 @@ ENTRY(save_secure_ram_context_sz)
   .word   . - save_secure_ram_context

  /*
 + * ==
 + * == Idle entry point ==
 + * ==
 + */
 +
 +/*
   * Forces OMAP into idle state
   *
 - * omap34xx_suspend() - This bit of code just executes the WFI
 - * for normal idles.
 + * omap34xx_suspend() - This bit of code saves the CPU context if
needed
 + * and executes the WFI instruction
   *
 - * Note: This code get's copied to internal SRAM at boot. When the OMAP
 - *wakes up it continues execution at the point it went to sleep.
 + * Notes:
 + * - this code gets copied to internal SRAM at boot.
 + * - when the OMAP wakes up it continues at different execution points
 + *   depending on the low power mode (non-OFF vs OFF modes),
 + *   cf. 'Resume path for xxx mode' comments.
   */
  ENTRY(omap34xx_cpu_suspend)
   stmfd   sp!, {r0-r12, lr}   @ save registers on stack

 - /* r0 contains restore pointer in sdram */
 - /* r1 contains information about saving context */
 - ldr r4, sdrc_power  @ read the SDRC_POWER register
 - ldr r5, [r4]@ read the contents of SDRC_POWER
 - orr r5, r5, #0x40   @ enable self refresh on idle req
 - str r5, [r4]@ write back to SDRC_POWER
register
 + /*
 +  * r0 contains restore pointer in sdram
 +  * r1 contains information about saving context:
 +  *   0 - No context lost
 +  *   1 - Only L1 and logic lost
 +  *   2 - Only L2 lost
 +  *   3 - Both L1 and L2 lost
 +  */

 + /* Save context only if required */
   cmp r1, #0x0
 - /* If context save is required, do that and execute wfi */
 - bne save_context_wfi
 + beq omap3_do_wfi
 +
 +save_context_wfi:
 + mov r8, r0  @ Store SDRAM address in r8
 + mrc p15, 0, r5, c1, c0, 1   @ Read Auxiliary Control Register
 + mov r4, #0x1

RE: [PATCH 6/7] OMAP3: add comments for low power code errata

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 6/7] OMAP3: add comments for low power code errata

 From: Jean Pihet j-pi...@ti.com

 Errata covered:
 - 1.157  1.185
 - i443
 - i581

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/pm34xx.c|4 ++--
  arch/arm/mach-omap2/sleep34xx.S |   11 +++
  2 files changed, 13 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
 index adc0917..267f015 100644
 --- a/arch/arm/mach-omap2/pm34xx.c
 +++ b/arch/arm/mach-omap2/pm34xx.c
 @@ -148,7 +148,7 @@ static void omap3_core_save_context(void)

   /*
* Force write last pad into memory, as this can fail in some
 -  * cases according to erratas 1.157, 1.185
 +  * cases according to errata 1.157, 1.185
*/
   omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
   OMAP343X_CONTROL_MEM_WKUP + 0x2a0);
 @@ -446,7 +446,7 @@ void omap_sram_idle(void)
   /*
   * On EMU/HS devices ROM code restores a SRDC value
   * from scratchpad which has automatic self refresh on timeout
 - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
 + * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443.
   * Hence store/restore the SDRC_POWER register here.
   */
   if (omap_rev() = OMAP3430_REV_ES3_0 
 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 12061fd..8e5004a 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -592,6 +592,7 @@ usettbr0:
   * Internal functions
   */

 +/* This function implements the erratum ID i443 WA, applies to 34xx =
 ES3.0 */
   .text
  ENTRY(es3_sdrc_fix)
   ldr r4, sdrc_syscfg @ get config addr
 @@ -637,6 +638,16 @@ sdrc_manual_1:
  ENTRY(es3_sdrc_fix_sz)
   .word   . - es3_sdrc_fix

 +/*
 + * This function implements the erratum ID i581 WA:
 + *  SDRC state restore before accessing the SDRAM
 + *
 + * Only used at return from non-OFF mode. For OFF
 + * mode the ROM code configures the SDRC and
 + * the DPLL before calling the restore code directly
 + * from DDR.
 + */
 +
  /* Make sure SDRC accesses are ok */
  wait_sdrc_ok:

 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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 7/7] OMAP3: ASM sleep code format rework

2010-12-17 Thread Santosh Shilimkar
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com
 Sent: Friday, December 17, 2010 3:38 PM
 To: linux-omap@vger.kernel.org
 Cc: khil...@deeprootsystems.com; linux-arm-ker...@lists.infradead.org;
 Jean Pihet
 Subject: [PATCH 7/7] OMAP3: ASM sleep code format rework

 From: Jean Pihet j-pi...@ti.com

 Cosmetic fixes to the code:
 - white spaces and tabs,
 - alignement,
 - comments rephrase and typos,
 - multi-line comments

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com

 ---
  arch/arm/mach-omap2/sleep34xx.S |  226
+-
 -
  1 files changed, 122 insertions(+), 104 deletions(-)

 diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-
 omap2/sleep34xx.S
 index 8e5004a..6376427 100644
 --- a/arch/arm/mach-omap2/sleep34xx.S
 +++ b/arch/arm/mach-omap2/sleep34xx.S
 @@ -1,6 +1,10 @@
  /*
   * linux/arch/arm/mach-omap2/sleep.S
   *
 + * (C) Copyright 2010
 + * Texas Instruments
 + * Jean Pihet j-pi...@ti.com
 + *
   * (C) Copyright 2007
   * Texas Instruments
   * Karthik Dasu karthik...@ti.com
 @@ -81,20 +85,20 @@
   .text
  /* Function call to get the restore pointer for resume from OFF */
  ENTRY(get_restore_pointer)
 -stmfd   sp!, {lr} @ save registers on stack
 + stmfd   sp!, {lr}   @ save registers on stack
   adr r0, restore
 -ldmfd   sp!, {pc} @ restore regs and return
 + ldmfd   sp!, {pc}   @ restore regs and return
  ENTRY(get_restore_pointer_sz)
 -.word   . - get_restore_pointer
 + .word   . - get_restore_pointer

   .text
  /* Function call to get the restore pointer for 3630 resume from OFF */
  ENTRY(get_omap3630_restore_pointer)
 -stmfd   sp!, {lr} @ save registers on stack
 + stmfd   sp!, {lr}   @ save registers on stack
   adr r0, restore_3630
 -ldmfd   sp!, {pc} @ restore regs and return
 + ldmfd   sp!, {pc}   @ restore regs and return
  ENTRY(get_omap3630_restore_pointer_sz)
 -.word   . - get_omap3630_restore_pointer
 + .word   . - get_omap3630_restore_pointer

   .text
  /* Function call to get the restore pointer for ES3 to resume from OFF
*/
 @@ -112,16 +116,16 @@ ENTRY(get_es3_restore_pointer_sz)
   * place on 3630. Hopefully some version in the future may not need
this.
   */
  ENTRY(enable_omap3630_toggle_l2_on_restore)
 -stmfd   sp!, {lr} @ save registers on stack
 + stmfd   sp!, {lr}   @ save registers on stack
   /* Setup so that we will disable and enable l2 */
   mov r1, #0x1
   str r1, l2dis_3630
 -ldmfd   sp!, {pc} @ restore regs and return
 + ldmfd   sp!, {pc}   @ restore regs and return

 + .text
  /* Function to call rom code to save secure ram context */
  ENTRY(save_secure_ram_context)
   stmfd   sp!, {r1-r12, lr}   @ save registers on stack
 -
   adr r3, api_params  @ r3 points to parameters
   str r0, [r3,#0x4]   @ r0 has sdram address
   ldr r12, high_mask
 @@ -150,6 +154,7 @@ api_params:
  ENTRY(save_secure_ram_context_sz)
   .word   . - save_secure_ram_context

 +
  /*
   * ==
   * == Idle entry point ==
 @@ -163,13 +168,14 @@ ENTRY(save_secure_ram_context_sz)
   * and executes the WFI instruction
   *
   * Notes:
 - * - this code gets copied to internal SRAM at boot.
 + * - this code gets copied to internal SRAM at boot and after wake-up
 + *   from OFF mode
   * - when the OMAP wakes up it continues at different execution points
   *   depending on the low power mode (non-OFF vs OFF modes),
   *   cf. 'Resume path for xxx mode' comments.
   */
  ENTRY(omap34xx_cpu_suspend)
 - stmfd   sp!, {r0-r12, lr}   @ save registers on stack
 + stmfd   sp!, {r0-r12, lr}   @ save registers on stack

   /*
* r0 contains restore pointer in sdram
 @@ -276,9 +282,9 @@ clean_l2:
*  - should be faster and will change with kernel
*  - 'might' have to copy address, load and jump to it
*/
 - ldr r1, kernel_flush
 - mov lr, pc
 - bx  r1
 + ldr r1, kernel_flush
 + mov lr, pc
 + bx  r1

  omap3_do_wfi:
   ldr r4, sdrc_power  @ read the SDRC_POWER register
 @@ -371,18 +377,18 @@ restore_3630:
   /* Fall thru to common code for the remaining logic */

  restore:
 -/*
 + /*
* Check what was the reason for mpu reset and store the reason in
 r9:
*  0 - No context lost
 - *  1 - Only L1 and logic lost
 - *  2 - Only L2 lost - In this case, we wont be here
 - *  3 - Both L1 and L2 lost
 +  *  1 - Only L1 and logic lost
 +  *  2 - Only L2 lost - In this case, we wont be here
 +  *  3 - Both 

Re: twl4030_usb porting advice

2010-12-17 Thread Tomasz Mloduchowski

On 12/17/10 10:11, Felipe Balbi wrote:

Hi,

On Fri, Dec 17, 2010 at 07:23:43AM +, Tomasz Mloduchowski wrote:

I'm quoting a snippet below for commenting.


[ 1.639892] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.646759] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
[ 1.646881] ehci-omap ehci-omap.0: failed to get ehci port1 regulator


This is alarming. Please add this patch to get the error code:

This is also alarming... Let's increase the timeout just for a debugging
purpose:

I've applied both patches. The new kernel log in its entirety resides
here:
http://pastie.org/1384896


Unfortunately seems like pastie.org is down:

503 Service Unavailable
No server is available to handle this request.


And the line of interest is
[ 2.085449] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
-- 0

Unfortunately, I don't understand what an error code of '0' might mean
here, but it surely does something.


That's funny, 0 means success, not sure why that branch is being
called.

I'll wait a bit until pastie is back, but if you could append to your
reply the output of dmesg | grep -i ehci I'd be glad.


I really appreciate your help, this sort of a bug that really stunned me.

I've noticed that the variable storing the error code is set to NULL 
right before printing it out :(, so I corrected this mistake.


[2.065216] ehci-omap ehci-omap.0: failed to get ehci port1 regulator 
-- -19


I also switched to pastebin, with the new, more meaningful dmesg:
http://pastebin.com/86kfLT2G

Cheers,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe 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: prcm: switch to a chained IRQ handler mechanism

2010-12-17 Thread Thomas Petazzoni
From: Thomas Petazzoni t-petazz...@ti.com

Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC being used.

arch/arm/mach-omap2/prcm.c implements the chained interrupt mechanism
itself, with individual PRCM events for OMAP3 and OMAP4 being
described in arch/arm/mach-omap2/prcm3xxx.c and
arch/arm/mach-omap2/prcm4xxx.c respectively. At initialization time,
the set of PRCM events is filtered against the SoC on which we are
running, keeping only the ones that are actually useful. All the logic
is written to be generic with regard to OMAP3/OMAP4, even though OMAP3
has single PRCM event registers and OMAP4 has two PRCM event
registers.

The wakeup and I/O PRCM events are now handled as two separate
interrupts, and their handler is registered with IRQF_NO_SUSPEND,
otherwise the IRQ gets disabled during suspend, which prevents resume.

Patch tested on OMAP3 BeagleBoard, with a suspend/resume cycle to both
retention and off mode. No test done on OMAP4.

Signed-off-by: Thomas Petazzoni t-petazz...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
---
 arch/arm/mach-omap2/Makefile   |4 +
 arch/arm/mach-omap2/pm34xx.c   |  104 ++
 arch/arm/mach-omap2/pm44xx.c   |8 ++
 arch/arm/mach-omap2/prcm.c |  186 
 arch/arm/mach-omap2/prcm3xxx.c |  117 
 arch/arm/mach-omap2/prcm4xxx.c |  146 +
 arch/arm/plat-omap/include/plat/irqs.h |9 ++-
 arch/arm/plat-omap/include/plat/prcm.h |   45 
 8 files changed, 548 insertions(+), 71 deletions(-)
 create mode 100644 arch/arm/mach-omap2/prcm3xxx.c
 create mode 100644 arch/arm/mach-omap2/prcm4xxx.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 7805545..a227f4d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -36,6 +36,10 @@ AFLAGS_sram242x.o:=-Wa,-march=armv6
 AFLAGS_sram243x.o  :=-Wa,-march=armv6
 AFLAGS_sram34xx.o  :=-Wa,-march=armv7-a
 
+# PRCM
+obj-$(CONFIG_ARCH_OMAP3)+= prcm3xxx.o
+obj-$(CONFIG_ARCH_OMAP4)+= prcm4xxx.o
+
 # Pin multiplexing
 obj-$(CONFIG_ARCH_OMAP2420)+= mux2420.o
 obj-$(CONFIG_ARCH_OMAP2430)+= mux2430.o
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1c716c8..ec1b7f6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -236,7 +236,7 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs)
return c;
 }
 
-static int _prcm_int_handle_wakeup(void)
+static irqreturn_t _prcm_int_handle_wakeup(int irq, void *unused)
 {
int c;
 
@@ -248,64 +248,10 @@ static int _prcm_int_handle_wakeup(void)
c += prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
}
 
-   return c;
-}
-
-/*
- * PRCM Interrupt Handler
- *
- * The PRM_IRQSTATUS_MPU register indicates if there are any pending
- * interrupts from the PRCM for the MPU. These bits must be cleared in
- * order to clear the PRCM interrupt. The PRCM interrupt handler is
- * implemented to simply clear the PRM_IRQSTATUS_MPU in order to clear
- * the PRCM interrupt. Please note that bit 0 of the PRM_IRQSTATUS_MPU
- * register indicates that a wake-up event is pending for the MPU and
- * this bit can only be cleared if the all the wake-up events latched
- * in the various PM_WKST_x registers have been cleared. The interrupt
- * handler is implemented using a do-while loop so that if a wake-up
- * event occurred during the processing of the prcm interrupt handler
- * (setting a bit in the corresponding PM_WKST_x register and thus
- * preventing us from clearing bit 0 of the PRM_IRQSTATUS_MPU register)
- * this would be handled.
- */
-static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
-{
-   u32 irqenable_mpu, irqstatus_mpu;
-   int c = 0;
-
-   irqenable_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQENABLE_MPU_OFFSET);
-   irqstatus_mpu = omap2_prm_read_mod_reg(OCP_MOD,
-OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
-   irqstatus_mpu = irqenable_mpu;
-
-   do {
-   if (irqstatus_mpu  (OMAP3430_WKUP_ST_MASK |
-OMAP3430_IO_ST_MASK)) {
-   c = _prcm_int_handle_wakeup();
-
-   /*
-* Is the MPU PRCM interrupt handler racing with the
-* IVA2 PRCM interrupt handler ?
-*/
-   WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup 
-

RE: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support

2010-12-17 Thread Gopinath, Thara


-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, December 17, 2010 7:01 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy,
Vishwanath; Sawant, Anand; Menon, Nishanth
Subject: Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver
support

Hi Thara,

Thara Gopinath th...@ti.com writes:

 This patch series introduces smartreflex and voltage driver support
 for OMAP3430 and OMAP3630. SmartReflex modules do adaptive voltage
 control for real-time voltage adjustments.


[...]

 This patch series has been tested on OMAP3430 SDP with
omap2plus_defconfig
 with the following menuconfig options enabled.

Any testing on 3630?

 System type - TI OMAP Implementations - Smartreflex Support
 System type - TI OMAP Implementations -
 Class 3 mode of Smartreflex Implementation

 Major Changes in v5

 - Rebased to k.org 2.6.37-rc3
 - Rebased to Nishant Menon's latest opp patches
 - Voltage pmic info structure extended to include a
 vast set of PMIC dependent parameters.
 - Smartreflex software n-target values support
 removed from the kernel. Instead n-target
 values are exposed as debugfs entries which can
 be written into by the user if needed.
 - Introduced a new file arch/arm/mach-omap2/omap_twl.c
 for specifying OMAP and TWL related info for
 the voltage layer.
 - Remove default enabling of smartreflex autocompensation
 during boot on OMAP3430 ES3.1 chips. Instead
 an API is provided that can be called from
 board files in case autocompensation needs
 to be enabled during boot up itself.
 - Other review comments on v4



This series is looking good.  I have a couple minor comments on specific
patches.
Hello Kevin,

Thanks for the review!


Also, it needs (hopefully only) one more rebase/repost.

First, a few things have changed at the PRCM API level that need to be
updated.  I have a untested patch (below) that should fix this for you,
that you'll need to split and apply to the OMAP3 and OMAP4 voltage
driver patches.

You have forgotten to attach the patch! Can you please share it.


To test with those changes, you can rebase onto my pm-core branch, which
contains not only the PRCM API changes, but also Nishanth's latest OPP
branch, and several other clock, hwmod, PM core changes queued for
2.6.38

Second, please also Cc the linux-arm-kernel mailing list, so if/when we
merge this into linux-omap, it doesn't need a last minute repost.

I will CC linux-arm when I am posting the next version

Regards
Thaa
--
To unsubscribe from this list: send the line unsubscribe 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 11/40] ARM: omap: update clock source registration

2010-12-17 Thread Russell King - ARM Linux
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants.  Switch over to using this new interface.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/mach-omap1/time.c   |6 +-
 arch/arm/mach-omap2/timer-gp.c   |5 +
 arch/arm/plat-omap/counter_32k.c |6 +-
 3 files changed, 3 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 1be6a21..abb34ff 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -208,7 +208,6 @@ static struct clocksource clocksource_mpu = {
.rating = 300,
.read   = mpu_read,
.mask   = CLOCKSOURCE_MASK(32),
-   .shift  = 24,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
@@ -217,13 +216,10 @@ static void __init omap_init_clocksource(unsigned long 
rate)
static char err[] __initdata = KERN_ERR
%s: can't register clocksource!\n;
 
-   clocksource_mpu.mult
-   = clocksource_khz2mult(rate/1000, clocksource_mpu.shift);
-
setup_irq(INT_TIMER2, omap_mpu_timer2_irq);
omap_mpu_timer_start(1, ~0, 1);
 
-   if (clocksource_register(clocksource_mpu))
+   if (clocksource_register_hz(clocksource_mpu, rate))
printk(err, clocksource_mpu.name);
 }
 
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e13c29e..a7816db 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -195,7 +195,6 @@ static struct clocksource clocksource_gpt = {
.rating = 300,
.read   = clocksource_read_cycles,
.mask   = CLOCKSOURCE_MASK(32),
-   .shift  = 24,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
@@ -220,9 +219,7 @@ static void __init omap2_gp_clocksource_init(void)
 
omap_dm_timer_set_load_start(gpt, 1, 0);
 
-   clocksource_gpt.mult =
-   clocksource_khz2mult(tick_rate/1000, clocksource_gpt.shift);
-   if (clocksource_register(clocksource_gpt))
+   if (clocksource_register_hz(clocksource_gpt, tick_rate))
printk(err2, clocksource_gpt.name);
 }
 #endif
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 155fe43..8f149f5 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -102,7 +102,6 @@ static struct clocksource clocksource_32k = {
.rating = 250,
.read   = omap_32k_read_dummy,
.mask   = CLOCKSOURCE_MASK(32),
-   .shift  = 10,
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
@@ -167,12 +166,9 @@ static int __init omap_init_clocksource_32k(void)
if (sync_32k_ick)
clk_enable(sync_32k_ick);
 
-   clocksource_32k.mult = clocksource_hz2mult(32768,
-   clocksource_32k.shift);
-
offset_32k = clocksource_32k.read(clocksource_32k);
 
-   if (clocksource_register(clocksource_32k))
+   if (clocksource_register_hz(clocksource_32k, 32768))
printk(err, clocksource_32k.name);
}
return 0;
-- 
1.6.2.5

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


[PATCH 26/40] ARM: ensure all sched_clock() implementations are notrace marked

2010-12-17 Thread Russell King - ARM Linux
ftrace requires sched_clock() to be notrace.  Ensure that all
implementations are so marked.  Also make sure that they include
linux/sched.h

Also ensure OMAP clocksource read functions are marked notrace as
they're used for sched_clock() too.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/mach-ixp4xx/common.c |2 +-
 arch/arm/mach-mmp/time.c  |2 +-
 arch/arm/mach-pxa/time.c  |2 +-
 arch/arm/mach-sa1100/generic.c|2 +-
 arch/arm/mach-tegra/timer.c   |3 ++-
 arch/arm/mach-u300/timer.c|1 +
 arch/arm/plat-iop/time.c  |3 ++-
 arch/arm/plat-nomadik/timer.c |1 +
 arch/arm/plat-omap/counter_32k.c  |   15 ---
 arch/arm/plat-orion/time.c|2 +-
 arch/arm/plat-versatile/sched-clock.c |2 +-
 11 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index 82fc003..e0b91d8 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -424,7 +424,7 @@ static void __init ixp4xx_clocksource_init(void)
 /*
  * sched_clock()
  */
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
cycle_t cyc = ixp4xx_get_cycles(NULL);
struct clocksource *cs = clocksource_ixp4xx;
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index 0c0ab09..a2ea33d 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -75,7 +75,7 @@ static inline uint32_t timer_read(void)
return __raw_readl(TIMERS_VIRT_BASE + TMR_CVWR(0));
 }
 
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
unsigned long long v = cnt32_to_63(timer_read());
return (v * tcr2ns_scale)  TCR2NS_SCALE_FACTOR;
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index caf92c0..b8d9dff 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -51,7 +51,7 @@ static void __init set_oscr2ns_scale(unsigned long oscr_rate)
oscr2ns_scale++;
 }
 
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
unsigned long long v = cnt32_to_63(OSCR);
return (v * oscr2ns_scale)  OSCR2NS_SCALE_FACTOR;
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 3c1fcd6..33b4969 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -119,7 +119,7 @@ unsigned int sa11x0_getspeed(unsigned int cpu)
  *
  *  ( * 1E9 / 3686400 = * 78125 / 288)
  */
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
unsigned long long v = cnt32_to_63(OSCR);
 
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index b49f2f5..c52bd84 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -18,6 +18,7 @@
  */
 
 #include linux/init.h
+#include linux/sched.h
 #include linux/time.h
 #include linux/interrupt.h
 #include linux/irq.h
@@ -110,7 +111,7 @@ static struct clocksource tegra_clocksource = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
return cnt32_to_63(timer_readl(TIMERUS_CNTR_1US)) * 1000;
 }
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index 377ff7f..6c68fe7 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -9,6 +9,7 @@
  * Author: Linus Walleij linus.wall...@stericsson.com
  */
 #include linux/interrupt.h
+#include linux/sched.h
 #include linux/time.h
 #include linux/timex.h
 #include linux/clockchips.h
diff --git a/arch/arm/plat-iop/time.c b/arch/arm/plat-iop/time.c
index cd6d54f..0c6da54 100644
--- a/arch/arm/plat-iop/time.c
+++ b/arch/arm/plat-iop/time.c
@@ -17,6 +17,7 @@
 #include linux/interrupt.h
 #include linux/time.h
 #include linux/init.h
+#include linux/sched.h
 #include linux/timex.h
 #include linux/io.h
 #include linux/clocksource.h
@@ -52,7 +53,7 @@ static struct clocksource iop_clocksource = {
 /*
  * IOP sched_clock() implementation via its clocksource.
  */
-unsigned long long sched_clock(void)
+unsigned long long notrace sched_clock(void)
 {
cycle_t cyc = iop_clocksource_read(NULL);
struct clocksource *cs = iop_clocksource;
diff --git a/arch/arm/plat-nomadik/timer.c b/arch/arm/plat-nomadik/timer.c
index b0bd6df..c3b8a22 100644
--- a/arch/arm/plat-nomadik/timer.c
+++ b/arch/arm/plat-nomadik/timer.c
@@ -19,6 +19,7 @@
 #include linux/err.h
 #include linux/cnt32_to_63.h
 #include linux/timer.h
+#include linux/sched.h
 #include asm/mach/time.h
 
 #include plat/mtu.h
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 8f149f5..aed301b 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -16,6 +16,7 @@
 #include linux/init.h
 #include linux/clk.h
 #include 

[PATCH 37/40] ARM: omap: convert sched_clock() to use new infrastructure

2010-12-17 Thread Russell King - ARM Linux
Convert omap to use the new sched_clock() infrastructure for extending
32bit counters to full 64-bit nanoseconds.

Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
 arch/arm/Kconfig |1 +
 arch/arm/plat-omap/counter_32k.c |   24 ++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 58e2fe3..726279f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -839,6 +839,7 @@ config ARCH_OMAP
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
select GENERIC_CLOCKEVENTS
+   select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
help
  Support for TI's OMAP platform (OMAP1/2/3/4).
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index aed301b..1b558ef 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -18,6 +18,8 @@
 #include linux/io.h
 #include linux/sched.h
 
+#include asm/sched_clock.h
+
 #include plat/common.h
 #include plat/board.h
 
@@ -110,10 +112,25 @@ static struct clocksource clocksource_32k = {
  * Returns current time from boot in nsecs. It's OK for this to wrap
  * around for now, as it's just a relative time stamp.
  */
+static DEFINE_CLOCK_DATA(cd);
+
+/*
+ * Constants generated by clocks_calc_mult_shift(m, s, 32768, NSEC_PER_SEC, 
60).
+ * This gives a resolution of about 30us and a wrap period of about 36hrs.
+ */
+#define SC_MULT40u
+#define SC_SHIFT   17
+
 unsigned long long notrace sched_clock(void)
 {
-   return clocksource_cyc2ns(clocksource_32k.read(clocksource_32k),
- clocksource_32k.mult, clocksource_32k.shift);
+   u32 cyc = clocksource_32k.read(clocksource_32k);
+   return cyc_to_fixed_sched_clock(cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
+}
+
+static void notrace omap_update_sched_clock(void)
+{
+   u32 cyc = clocksource_32k.read(clocksource_32k);
+   update_sched_clock(cd, cyc, (u32)~0);
 }
 
 /**
@@ -171,6 +188,9 @@ static int __init omap_init_clocksource_32k(void)
 
if (clocksource_register_hz(clocksource_32k, 32768))
printk(err, clocksource_32k.name);
+
+   init_fixed_sched_clock(cd, omap_update_sched_clock, 32,
+  32768, SC_MULT, SC_SHIFT);
}
return 0;
 }
-- 
1.6.2.5

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


Re: [PATCH 2/2] arm: mach-omap2: Kconfig: devkit8000 should select needed options

2010-12-17 Thread Aaro Koskinen

Hi,

On Wed, 15 Dec 2010, Tony Lindgren wrote:

* Aaro Koskinen aaro.koski...@nokia.com [101215 04:48]:

It's not possible to compile a kernel for this board without I2C,
MFD_SUPPORT and TWL4030_CORE, so those should be selected. This will
prevent build errors when trying out different configurations.


This one I'm not so convinced about. We should be able to compile
support for each board and enable and disable these kind of options
just fine if CONFIG_ARCH_OMAP2PLUS_TYPICAL is disabled.


So in this case we should move the stuff with special dependencies from
the board file into e.g. board-devkit8000-peripherals, which would be
a kernel module?

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


Re: twl4030_usb porting advice

2010-12-17 Thread Felipe Balbi

On Fri, Dec 17, 2010 at 11:14:50AM +, Tomasz Mloduchowski wrote:

I really appreciate your help, this sort of a bug that really stunned me.

I've noticed that the variable storing the error code is set to NULL 
right before printing it out :(, so I corrected this mistake.


[2.065216] ehci-omap ehci-omap.0: failed to get ehci port1 
regulator -- -19


Thanks for that :-)

Error -19 is -ENODEV, so it means there really isn't a regulator.

Maybe you can more debug to ehci_reset() function ?!?


I also switched to pastebin, with the new, more meaningful dmesg:
http://pastebin.com/86kfLT2G


I'll look at it and get back to you. But try to figure out exactly where
ehci decides to bounce the port to companion ohci and start adding
printks or dev_info to that. A good start is ehci_reset(), something
like below might help:

diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 6e25996..7fdaecf 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -330,7 +330,7 @@ dbg_port_buf (char *buf, unsigned len, const char *label, 
int port, u32 status)
 #define dbg_cmd(ehci, label, command) { \
char _buf [80]; \
dbg_command_buf (_buf, sizeof _buf, label, command); \
-   ehci_dbg (ehci, %s\n, _buf); \
+   ehci_info (ehci, %s\n, _buf); \
 }
 
 #define dbg_port(ehci, label, port, status) { \


a lot already.

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


Re: [Patch v4] AM35xx: Craneboard: Add USB EHCI support

2010-12-17 Thread Sergei Shtylyov

Hello.

On 16-12-2010 18:25, srin...@mistralsolutions.com wrote:


From: Srinath srin...@mistralsolutions.com



AM3517/05 Craneboard has one EHCI interface on board using port1.



GPIO35 is used as power enable.
GPIO38 is used as port1 PHY reset.



History:
http://marc.info/?l=linux-omapw=2r=1s=Craneboard%3A+Add+USB+EHCI+supportq=t



Signed-off-by: Srinath srin...@mistralsolutions.com
---
  arch/arm/mach-omap2/board-am3517crane.c |   53 +++
  1 files changed, 53 insertions(+), 0 deletions(-)



diff --git a/arch/arm/mach-omap2/board-am3517crane.c 
b/arch/arm/mach-omap2/board-am3517crane.c
index 8ba4047..1a80175 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c

[...]

@@ -51,10 +58,56 @@ static void __init am3517_crane_init_irq(void)

[...]

  static void __init am3517_crane_init(void)
  {
+   int ret;
+
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
+
+   /* Configure GPIO for EHCI port */
+   if (omap_mux_init_gpio(GPIO_USB_NRESET, OMAP_PIN_OUTPUT)) {
+   pr_err(Can not cofigure mux for GPIO_USB_NRESET %d\n,
+   GPIO_USB_NRESET);
+   return;
+   }
+
+   if (omap_mux_init_gpio(GPIO_USB_POWER, OMAP_PIN_OUTPUT)) {
+   pr_err(Can not cofigure mux for GPIO_USB_POWER %d\n,
+


   Empty line not needed here...


+   GPIO_USB_POWER);
+   return;
+   }
+
+   ret = gpio_request(GPIO_USB_POWER, usb_ehci_enable);
+   if (ret  0) {
+   pr_err(Cannot request GPIO %d\n, GPIO_USB_POWER);
+   return;
+   }
+
+   ret = gpio_direction_output(GPIO_USB_POWER, 1);
+   if (ret  0)
+   goto err;
+
+


   Too  many empty lines here...


+   usb_ehci_init(ehci_pdata);
+   return;
+
+err:


   There's no need for *goto* and label.


+   gpio_free(GPIO_USB_POWER);
+   pr_err(Unable to initialize EHCI power\n);
+   return;
  }


WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe 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: [OMAP 1710] Mainline Broken

2010-12-17 Thread Nishanth Menon

DebBarma, Tarun Kanti had written, on 12/17/2010 02:22 AM, the following:

-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, December 16, 2010 10:39 PM
To: Belisko Marek
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
Subject: Re: [OMAP 1710] Mainline Broken

Belisko Marek marek.beli...@gmail.com writes:


Hi,

On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:

Did anyone observe this? I am using omap_generic_1710_defconfig

[...]
input: omap-keypad as /devices/platform/omap-keypad/input/input0
TCP cubic registered
NET: Registered protocol family 17
Registering the dns_resolver key type
eth0: link up
IP-Config: Complete:
device=eth0, addr=172.24.191.106, mask=255.255.252.0,

gw=172.24.188.1,

host=myomap, domain=, nis-domain=(none),
bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath=
VFS: Mounted root (nfs filesystem) on device 0:10.
Freeing init memory: 128K
Kernel panic - not syncing: Attempted to kill init!

Seems your userspace is broken. Try add user_debug=31 to command line
to see what exactly happens.

Looks like you're mounting an NFS rootfs.  Was it compiled for armv5?
My hunch would be you're trying to run an armv6/armv7 userspace on the
1710 which is armv5.

To get more debugging, ensure these are enabled in your defconfig:

CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_ERRORS=y

and in addition to cmdline suggested by Marek, add user_debug=0xf

This will give verbose output for userspace exceptions as well and
possibly confirm my hunch.

Kevin


I checked .config and it shows: CONFIG_CPU_32v5=y

With regard to additional log here they are!!

[...]
[1] init: obsolete system call .
Code: e08f1001 e1a0c000 e3a0702d ef00 (e3700a01)
Kernel panic - not syncing: Attempted to kill init!
Backtrace:
[...]

I wonder if the age old
http://linux.omap.com/pub/documentation/Howto_build_Linux_on_H3.pdf
and
http://linux.omap.com/pub/filesystem/ might help?


--
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 0/7 v2] OMAP: McSPI: Hwmod adaptation + runtime conversion

2010-12-17 Thread Govindraj
On Thu, Dec 16, 2010 at 11:47 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Hi Govindraj,

 Raja, Govindraj govindraj.r...@ti.com writes:

 On Wed, Dec 15, 2010 at 9:42 PM, Kevin Hilman khil...@deeprootsystems.com
 wrote:

     Govindraj.R govindraj.r...@ti.com writes:

      Changes invloves:
      
      1) Addition of hwmod data for omap2/3/4.
      1) McSPI driver hwmod adaptation with cleanup of base address
         macros and using omap-device API's.
      2) Runtime Conversion of McSPI driver
     
      Changes from v1:
      ---
      1) Fixing patch 5/5 comments for hwmod+runtime
         Split the patch 5/5 to hwmod adaptation
         and then runtime conversion
         http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html
     
      Testing Updates:
      
      Was tested using data transfer test module available at:
      http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/
     test_code/
      utils/mcspi_modules/omap_mcspi_datatest.c;
      h=e42ec10c5c844abdde6a7175a268b379fbbdb655;
      hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3

     Can you summarize what this test does?

     On what platforms was this tested?

     How was it tested for OMAP1 and OMAP2?



 Using the above mentioned test module we had done some
 data transfer tests.
 Platforms used used where :
 1) OMAP2430 SDP.
 2) OMAP3 (ZOOM boards zoom2/3).
 3) OMAP4430 SDP [ Here even basic Ethernet functionality was checked which is
 over SPI interface]

 Can you describe a little more about the testing please?  What exactly
 does the data transfer test do?  Is it a loopback test?  Does it use
 on-board SPI peripherals?  If so, which ones, etc.


Yes its an loopback test based on SPI interface available from
development board expansion connector.

MISO --- MOSI [Loopback test]

So basically looking into the Board schematics we decide
which SPI interface is available on the board expansion connector
and use SPI interface available.

On zoom boards SPI3 was available on expansion connector
and same was used. On 4430SDP SPI2 interface was used.
On 2430SDP SPI2.

Also for testing, spi_board_info was populated in board file
and spi_register_board_info was done, here bus info was populated
based on spi bus available on the board. In spi_board_info structure
we initialize spi_bus and name as spitst and speed and chip-select
later once test module is loaded word-length, speed etc is modified
from proc interface available from the test module and data test
is done.

--
Thanks,
Govindraj.R


 We boot tested on 2420/n800.

 Coming to omap1,

 This driver[omap2_mcspi.c] is applicable only from omap2_plus
 for omap1 omap_uwire.c is the spi driver file.

 OK, thanks for clarification.

 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

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


[PATCH] OMAP3: clocks: Update clock domain name for mcspi fck

2010-12-17 Thread Govindraj.R
From: Charulatha V ch...@ti.com

Update clock3xxx_data for mcspi1-4 with appropriate clock domain name.

Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
This Patch is posted seperatley from v2_mcspi_hwmod
patch series based on comments from Paul.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39655.html

 arch/arm/mach-omap2/clock3xxx_data.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 0579604..9337355 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1558,6 +1558,7 @@ static struct clk mcspi4_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI4_SHIFT,
.recalc = followparent_recalc,
+   .clkdm_name = core_l4_clkdm,
 };

 static struct clk mcspi3_fck = {
@@ -1567,6 +1568,7 @@ static struct clk mcspi3_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI3_SHIFT,
.recalc = followparent_recalc,
+   .clkdm_name = core_l4_clkdm,
 };

 static struct clk mcspi2_fck = {
@@ -1576,6 +1578,7 @@ static struct clk mcspi2_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI2_SHIFT,
.recalc = followparent_recalc,
+   .clkdm_name = core_l4_clkdm,
 };

 static struct clk mcspi1_fck = {
@@ -1585,6 +1588,7 @@ static struct clk mcspi1_fck = {
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
.enable_bit = OMAP3430_EN_MCSPI1_SHIFT,
.recalc = followparent_recalc,
+   .clkdm_name = core_l4_clkdm,
 };

 static struct clk uart2_fck = {
-- 
1.7.1


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


Re: [PATCH 1/7] OMAP3: remove unused code from the ASM sleep code

2010-12-17 Thread Nishanth Menon
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the 
following:

From: Jean Pihet j-pi...@ti.com

Remove unused code:
- macros,
- variables,
- unused semaphore locking API. This API shall be added back
  when needed,
- infinite loops for debug.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com


Reviewed-by: Nishanth Menon n...@ti.com
Tested-by: Nishanth Menonn...@ti.com
Tested on:
SDP3630
SDP3430
Test script:
http://pastebin.mozilla.org/889933


--
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 2/7] OMAP2+: use global values for the SRAM PA addresses

2010-12-17 Thread Nishanth Menon
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the 
following:

From: Jean Pihet j-pi...@ti.com

The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.

The macros are now defined at a centralized place, for
easier maintenance.

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/sdrc.h |1 -
 arch/arm/mach-omap2/sleep34xx.S|1 +
 arch/arm/plat-omap/include/plat/sram.h |   11 +++
 arch/arm/plat-omap/sram.c  |7 ++-
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
index 68f57bb..b3f8379 100644
--- a/arch/arm/mach-omap2/sdrc.h
+++ b/arch/arm/mach-omap2/sdrc.h
@@ -74,5 +74,4 @@ static inline u32 sms_read_reg(u16 reg)
  */
 #define SDRC_MPURATE_LOOPS 96
 
-

spurious change.

[...]


diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 819ea0c..1a686c8 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -41,15 +41,12 @@
 
 #define OMAP1_SRAM_PA		0x2000

 #define OMAP1_SRAM_VA  VMALLOC_END
-#define OMAP2_SRAM_PA  0x4020
-#define OMAP2_SRAM_PUB_PA  0x4020f800
+#define OMAP2_SRAM_PUB_PA  (OMAP2_SRAM_PA + 0xf800)
 #define OMAP2_SRAM_VA  0xfe40
 #define OMAP2_SRAM_PUB_VA  (OMAP2_SRAM_VA + 0x800)
-#define OMAP3_SRAM_PA   0x4020
 #define OMAP3_SRAM_VA   0xfe40
-#define OMAP3_SRAM_PUB_PA   0x40208000
+#define OMAP3_SRAM_PUB_PA   (OMAP3_SRAM_PA + 0x8000)
Though not directly related to the patch, information sake: the PUB 
physical address on a GP device != public SRAM address on a HS/EMU 
device - in theory PPA can reconfigure how much is available for a 
HS/EMU device here.



 #define OMAP3_SRAM_PUB_VA   (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_PA  0x4030
 #define OMAP4_SRAM_VA  0xfe40
 #define OMAP4_SRAM_PUB_PA  (OMAP4_SRAM_PA + 0x4000)
 #define OMAP4_SRAM_PUB_VA  (OMAP4_SRAM_VA + 0x4000)


Tested-by: Nishanth Menonn...@ti.com
Tested on:
SDP3630
SDP3430
Test script:
http://pastebin.mozilla.org/889933

--
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 v1] OMAP: GPIO: Correct IP version message during boot

2010-12-17 Thread Varadarajan, Charulatha
Kevin,

On Thu, Dec 16, 2010 at 11:49, Kevin Hilman khil...@deeprootsystems.com wrote:
 Varadarajan, Charulatha ch...@ti.com writes:

 With the commit 9a748053f5f58a77cd71864f1d7b804175b0e47d whose subject is
 OMAP: GPIO: Make omap_gpio_show_rev bank specific (see [1]),
 the IP version information for all the banks are shown during bootup,
 but it does not show the bank number.

 Use dev_info instead of printk in omap_gpio_show_rev() so that the
 bank id is displayed along with the IP version

 [1] http://www.spinics.net/lists/arm-kernel/msg105872.html

 A related question, the commit above also changed the GPIO revision
 display from one-time to once per bank.  Do we need to know the GPIO HW
 revision for each bank, or can we assume it's the same for all banks?

The IP version is the same for all the gpio banks in all OMAP2+ CPUs.
But I am not sure about OMAP16xx.


 Kevin

 Signed-off-by: Varadarajan, Charulatha ch...@ti.com
 Acked-by: Felipe Balbi ba...@ti.com
 ---
  arch/arm/plat-omap/gpio.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
 index 8d493b9..47aeaeb 100644
 --- a/arch/arm/plat-omap/gpio.c
 +++ b/arch/arm/plat-omap/gpio.c
 @@ -1554,7 +1554,7 @@ static void __init omap_gpio_show_rev(struct gpio_bank 
 *bank)
       else
               return;

 -     printk(KERN_INFO OMAP GPIO hardware version %d.%d\n,
 +     dev_info(bank-dev, hardware version %d.%d\n,
               (rev  4)  0x0f, rev  0x0f);
  }

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


[PATCH v2]: OMAP: DSS2: Adding check_timings and set_timings for panel-taal

2010-12-17 Thread Janorkar, Mayuresh
Adding two APIs for panel-taal: check_timings and set_timings

These are required by omapfb in case we wish to set default mode through 
bootargs.
e.g.: omapfb.mode=lcd:640x480-16 (display device:width X height - bits per 
pixel)

omapfb_set_def_mode function in omapfb-main.c essentially needs these functions
otherwise it would return -EINVAL and default mode sent through bootargs
would be ignored.

Signed-off-by: Mayuresh Janorkar ma...@ti.com
---
 drivers/video/omap2/displays/panel-taal.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index e1c765d..0bb2c30 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -476,6 +476,31 @@ static void taal_get_timings(struct omap_dss_device 
*dssdev,
*timings = dssdev-panel.timings;
 }
 
+static void taal_set_timings(struct omap_dss_device *dssdev,
+   struct omap_video_timings *timings)
+{
+   /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+   dssdev-panel.timings.x_res = timings-x_res;
+   dssdev-panel.timings.y_res = timings-y_res;
+}
+
+static int taal_check_timings(struct omap_dss_device *dssdev,
+   struct omap_video_timings *timings)
+{
+   /*
+* TAAL panel's timing struct has only x_res and y_res
+* other timing parameters are not set
+*/
+   if (!timings || timings-x_res != dssdev-panel.timings.x_res ||
+   timings-y_res != dssdev-panel.timings.y_res)
+   return -EINVAL;
+
+   return 0;
+}
+
 static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
 {
@@ -1563,6 +1588,8 @@ static struct omap_dss_driver taal_driver = {
.memory_read= taal_memory_read,
 
.get_timings= taal_get_timings,
+   .set_timings= taal_set_timings,
+   .check_timings  = taal_check_timings,
 
.driver = {
.name   = taal,
-- 
1.7.0.4

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


Re: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses

2010-12-17 Thread Jean Pihet
Hi Nishant,

On Fri, Dec 17, 2010 at 2:34 PM, Nishanth Menon n...@ti.com wrote:
 jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the
 following:

 From: Jean Pihet j-pi...@ti.com

 The SRAM PA addresses are locally defined and used at
 different places, i.e. SRAM management code and idle sleep code.

 The macros are now defined at a centralized place, for
 easier maintenance.

 Tested on N900 and Beagleboard with full RET and OFF modes,
 using cpuidle and suspend.

 Signed-off-by: Jean Pihet j-pi...@ti.com
 ---
  arch/arm/mach-omap2/sdrc.h             |    1 -
  arch/arm/mach-omap2/sleep34xx.S        |    1 +
  arch/arm/plat-omap/include/plat/sram.h |   11 +++
  arch/arm/plat-omap/sram.c              |    7 ++-
  4 files changed, 14 insertions(+), 6 deletions(-)

 diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
 index 68f57bb..b3f8379 100644
 --- a/arch/arm/mach-omap2/sdrc.h
 +++ b/arch/arm/mach-omap2/sdrc.h
 @@ -74,5 +74,4 @@ static inline u32 sms_read_reg(u16 reg)
  */
  #define SDRC_MPURATE_LOOPS             96
  -

 spurious change.
Cosmetic change!


 [...]

 diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
 index 819ea0c..1a686c8 100644
 --- a/arch/arm/plat-omap/sram.c
 +++ b/arch/arm/plat-omap/sram.c
 @@ -41,15 +41,12 @@
  #define OMAP1_SRAM_PA         0x2000
  #define OMAP1_SRAM_VA          VMALLOC_END
 -#define OMAP2_SRAM_PA          0x4020
 -#define OMAP2_SRAM_PUB_PA      0x4020f800
 +#define OMAP2_SRAM_PUB_PA      (OMAP2_SRAM_PA + 0xf800)
  #define OMAP2_SRAM_VA          0xfe40
  #define OMAP2_SRAM_PUB_VA      (OMAP2_SRAM_VA + 0x800)
 -#define OMAP3_SRAM_PA           0x4020
  #define OMAP3_SRAM_VA           0xfe40
 -#define OMAP3_SRAM_PUB_PA       0x40208000
 +#define OMAP3_SRAM_PUB_PA       (OMAP3_SRAM_PA + 0x8000)

 Though not directly related to the patch, information sake: the PUB physical
 address on a GP device != public SRAM address on a HS/EMU device - in theory
 PPA can reconfigure how much is available for a HS/EMU device here.
Ok good to know.


  #define OMAP3_SRAM_PUB_VA       (OMAP3_SRAM_VA + 0x8000)
 -#define OMAP4_SRAM_PA          0x4030
  #define OMAP4_SRAM_VA          0xfe40
  #define OMAP4_SRAM_PUB_PA      (OMAP4_SRAM_PA + 0x4000)
  #define OMAP4_SRAM_PUB_VA      (OMAP4_SRAM_VA + 0x4000)

 Tested-by: Nishanth Menonn...@ti.com
 Tested on:
 SDP3630
 SDP3430
 Test script:
 http://pastebin.mozilla.org/889933
Nice test script btw


 --
 Regards,
 Nishanth Menon


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


Re: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses

2010-12-17 Thread Nishanth Menon

Jean Pihet had written, on 12/17/2010 08:59 AM, the following:


diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h
index 68f57bb..b3f8379 100644
--- a/arch/arm/mach-omap2/sdrc.h
+++ b/arch/arm/mach-omap2/sdrc.h
@@ -74,5 +74,4 @@ static inline u32 sms_read_reg(u16 reg)
 */
 #define SDRC_MPURATE_LOOPS 96
 -

spurious change.

Cosmetic change!

yep, does not belong to this patch :)


http://pastebin.mozilla.org/889933

Nice test script btw


you are welcome, hope it is useful.

--
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 5/7] OMAP3: rework of the ASM sleep code execution paths

2010-12-17 Thread Nishanth Menon
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the 
following:

From: Jean Pihet j-pi...@ti.com

- Reworked and simplified the execution paths for better
  readability and to avoid duplication of code,
is it possible to split this good rewrite into logical chunks for better 
and easier reviewability?


my suggestion clean each of the paths independently - like the code upto 
wfi.. and then we can clean up the resume path as well separately.



- Added comments on the entry and exit points and the interaction
  with the ROM code for OFF mode restore,
- Reworked the existing comments for better readability.
thanks for doing this, but, just my suggestion, looking at the amount of 
changes done in this patch - if you can keep one patch for functional 
change which is separate from cosmetic change (such as comment cleanup 
and addition), it makes a reviewer's life easier :)




Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/control.c   |9 +-
 arch/arm/mach-omap2/sleep34xx.S |  313 +++
 2 files changed, 191 insertions(+), 131 deletions(-)

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 728f268..f4b19ed 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -239,7 +239,14 @@ void omap3_save_scratchpad_contents(void)
struct omap3_scratchpad_prcm_block prcm_block_contents;
struct omap3_scratchpad_sdrc_block sdrc_block_contents;
 
-	/* Populate the Scratchpad contents */

+   /*
+* Populate the Scratchpad contents
+*
+* The get_*restore_pointer functions are used to provide a
+* physical restore address where the ROM code jumps while waking
+* up from MPU OFF/OSWR state.
Just curious: we dont have OSWR(open switch retention) in l-o unless I 
am mistaken.. we have cswr (closed switch retention).



+* The restore pointer is stored into the scratchpad.
+*/
scratchpad_contents.boot_config_ptr = 0x0;
if (cpu_is_omap3630())
scratchpad_contents.public_restore_ptr =
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index beeb682..12061fd 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -71,6 +71,13 @@
  * API functions
  */
 
+/*

+ * The get_*restore_pointer functions are used to provide a
+ * physical restore address where the ROM code jumps while waking
+ * up from MPU OFF/OSWR state.
+ * The restore pointer is stored into the scratchpad.
+ */
+

we need to cleanup comments such as those used below:


.text
 /* Function call to get the restore pointer for resume from OFF */


may be make it explicit what the difference for get_restore_pointer is etc..


 ENTRY(get_restore_pointer)
@@ -102,7 +109,7 @@ ENTRY(get_es3_restore_pointer_sz)
 /*
  * L2 cache needs to be toggled for stable OFF mode functionality on 3630.
  * This function sets up a flag that will allow for this toggling to take
- * place on 3630. Hopefully some version in the future maynot need this
+ * place on 3630. Hopefully some version in the future may not need this.
I think we should split the patch up for the comment cleanup - it is a 
little nuisance trying to review the actual functional change mixed with 
comment cleanups together..



  */
 ENTRY(enable_omap3630_toggle_l2_on_restore)
 stmfd   sp!, {lr} @ save registers on stack
@@ -144,34 +151,158 @@ ENTRY(save_secure_ram_context_sz)
.word   . - save_secure_ram_context
 
 /*

+ * ==
+ * == Idle entry point ==
+ * ==
+ */
+
+/*
  * Forces OMAP into idle state
  *
- * omap34xx_suspend() - This bit of code just executes the WFI
- * for normal idles.
+ * omap34xx_suspend() - This bit of code saves the CPU context if needed
+ * and executes the WFI instruction
since we are cleaning up, I might as well suggest - what condition do we 
save the CPU context might be worth mentioning. is this called during 
RET transition or OFF transition is not clear..

  *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *  wakes up it continues execution at the point it went to sleep.
+ * Notes:
+ * - this code gets copied to internal SRAM at boot.
+ * - when the OMAP wakes up it continues at different execution points
+ *   depending on the low power mode (non-OFF vs OFF modes),
+ *   cf. 'Resume path for xxx mode' comments.
Further, might as well help people and say that this is the call 
_omap_sram_idle actually takes ;)


Also might be a little indepth pseudo code overview of this complex code 
flow might help for code maintainers later on..


omap34xx_cpu_suspend
   |- if Context save not required - omap3_do_wfi - wfi
   \- if context save required: - save_context_wfi
  |

[PATCH v2 1/9] OMAP: DMA: Replace read/write macros with functions

2010-12-17 Thread G, Manjunath Kondaiah
Prepare DMA library to get converted into DMA driver using platform
device model and hwmod infrastucture(for omap2+, resource structures
for omap1)

The low level read/write macros are replaced with static inline
functions and register offsets are handled through static register
offset tables mapped through  enumeration constants.

These low level read/write functions along with static register offset
tables will be moved to respective mach-omap dma files in the later
patches of this series.

There are no functionality changes with these changes except change in
logic for handling 16bit registers of OMAP1.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/plat-omap/dma.c  |  517 -
 arch/arm/plat-omap/include/plat/dma.h |  151 ++
 2 files changed, 345 insertions(+), 323 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index a863f55..49a7cd4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -40,6 +40,96 @@
 
 #undef DEBUG
 
+static u16 reg_map_omap1[] = {
+   [GCR]   = 0x400,
+   [GSCR]  = 0x404,
+   [GRST1] = 0x408,
+   [HW_ID] = 0x442,
+   [PCH2_ID]   = 0x444,
+   [PCH0_ID]   = 0x446,
+   [PCH1_ID]   = 0x448,
+   [PCHG_ID]   = 0x44a,
+   [PCHD_ID]   = 0x44c,
+   [CAPS_0]= 0x44e,
+   [CAPS_1]= 0x452,
+   [CAPS_2]= 0x456,
+   [CAPS_3]= 0x458,
+   [CAPS_4]= 0x45a,
+   [PCH2_SR]   = 0x460,
+   [PCH0_SR]   = 0x480,
+   [PCH1_SR]   = 0x482,
+   [PCHD_SR]   = 0x4c0,
+
+   /* Common Registers */
+   [CSDP]  = 0x00,
+   [CCR]   = 0x02,
+   [CICR]  = 0x04,
+   [CSR]   = 0x06,
+   [CEN]   = 0x10,
+   [CFN]   = 0x12,
+   [CSFI]  = 0x14,
+   [CSEI]  = 0x16,
+   [CPC]   = 0x18, /* 15xx only */
+   [CSAC]  = 0x18,
+   [CDAC]  = 0x1a,
+   [CDEI]  = 0x1c,
+   [CDFI]  = 0x1e,
+   [CLNK_CTRL] = 0x28,
+
+   /* Channel specific register offsets */
+   [CSSA]  = 0x08,
+   [CDSA]  = 0x0c,
+   [COLOR] = 0x20,
+   [CCR2]  = 0x24,
+   [LCH_CTRL]  = 0x2a,
+};
+
+static u16 reg_map_omap2[] = {
+   [REVISION]  = 0x00,
+   [GCR]   = 0x78,
+   [IRQSTATUS_L0]  = 0x08,
+   [IRQSTATUS_L1]  = 0x0c,
+   [IRQSTATUS_L2]  = 0x10,
+   [IRQSTATUS_L3]  = 0x14,
+   [IRQENABLE_L0]  = 0x18,
+   [IRQENABLE_L1]  = 0x1c,
+   [IRQENABLE_L2]  = 0x20,
+   [IRQENABLE_L3]  = 0x24,
+   [SYSSTATUS] = 0x28,
+   [OCP_SYSCONFIG] = 0x2c,
+   [CAPS_0]= 0x64,
+   [CAPS_2]= 0x6c,
+   [CAPS_3]= 0x70,
+   [CAPS_4]= 0x74,
+
+   /* Common register offsets */
+   [CCR]   = 0x80,
+   [CLNK_CTRL] = 0x84,
+   [CICR]  = 0x88,
+   [CSR]   = 0x8c,
+   [CSDP]  = 0x90,
+   [CEN]   = 0x94,
+   [CFN]   = 0x98,
+   [CSEI]  = 0xa4,
+   [CSFI]  = 0xa8,
+   [CDEI]  = 0xac,
+   [CDFI]  = 0xb0,
+   [CSAC]  = 0xb4,
+   [CDAC]  = 0xb8,
+
+   /* Channel specific register offsets */
+   [CSSA]  = 0x9c,
+   [CDSA]  = 0xa0,
+   [CCEN]  = 0xbc,
+   [CCFN]  = 0xc0,
+   [COLOR] = 0xc4,
+
+   /* OMAP4 specific registers */
+   [CDP]   = 0xd0,
+   [CNDP]  = 0xd4,
+   [CCDN]  = 0xd8,
+};
+
 #ifndef CONFIG_ARCH_OMAP1
 enum { DMA_CH_ALLOC_DONE, DMA_CH_PARAMS_SET_DONE, DMA_CH_STARTED,
DMA_CH_QUEUED, DMA_CH_NOTSTARTED, DMA_CH_PAUSED, DMA_CH_LINK_ENABLED
@@ -138,6 +228,9 @@ static int omap_dma_reserve_channels;
 static spinlock_t dma_chan_lock;
 static struct omap_dma_lch *dma_chan;
 static void __iomem *omap_dma_base;
+static u16 *reg_map;
+static u8 dma_stride;
+static enum omap_reg_offsets dma_common_ch_start, dma_common_ch_end;
 
 static const u8 omap1_dma_irq[OMAP1_LOGICAL_DMA_CH_COUNT] = {
INT_DMA_CH0_6, INT_DMA_CH1_7, INT_DMA_CH2_8, INT_DMA_CH3,
@@ -154,23 +247,48 @@ static inline void omap_enable_channel_irq(int lch);
 #define REVISIT_24XX() printk(KERN_ERR FIXME: no %s on 24xx\n, \
__func__);
 
-#define dma_read(reg)  

[PATCH v2 2/9] OMAP: DMA: Introduce errata handling feature

2010-12-17 Thread G, Manjunath Kondaiah
Implement errata handling to use flags instead of cpu_is_* and
cpu_class_* in the code.

The errata flags are initialized at init time and during runtime we are
using the errata variable (via the IS_DMA_ERRATA macro) to execute the
required errata workaround.

Reused errata handling patch from: Peter Ujfalusi
peter.ujfal...@nokia.com
https://patchwork.kernel.org/patch/231191/

Changes to above patch:
1. Changes are done for converting all the existing errata work arounds
to use this feature.
2. Detailed description for each errata is added.
3. Fixed bug in SET_DMA_ERRATA macro
4. Bit shifting in macro definitions are replaced with BIT() macro

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/plat-omap/dma.c  |  152 ++---
 arch/arm/plat-omap/include/plat/dma.h |   12 +++
 2 files changed, 114 insertions(+), 50 deletions(-)

diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 49a7cd4..6f51bf3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -144,6 +144,7 @@ enum { DMA_CHAIN_STARTED, DMA_CHAIN_NOTSTARTED };
 #define OMAP_FUNC_MUX_ARM_BASE (0xfffe1000 + 0xec)
 
 static int enable_1510_mode;
+static u32 errata;
 
 static struct omap_dma_global_context_registers {
u32 dma_irqenable_l0;
@@ -1088,31 +1089,17 @@ void omap_start_dma(int lch)
 
cur_lch = next_lch;
} while (next_lch != -1);
-   } else if (cpu_is_omap242x() ||
-   (cpu_is_omap243x()   omap_type() = OMAP2430_REV_ES1_0)) {
-
-   /* Errata: Need to write lch even if not using chaining */
+   } else if (IS_DMA_ERRATA(DMA_ERRATA_PARALLEL_CHANNELS))
dma_write(lch, CLNK_CTRL, lch);
-   }
 
omap_enable_channel_irq(lch);
 
l = dma_read(CCR, lch);
 
-   /*
-* Errata: Inter Frame DMA buffering issue (All OMAP2420 and
-* OMAP2430ES1.0): DMA will wrongly buffer elements if packing and
-* bursting is enabled. This might result in data gets stalled in
-* FIFO at the end of the block.
-* Workaround: DMA channels must have BUFFERING_DISABLED bit set to
-* guarantee no data will stay in the DMA FIFO in case inter frame
-* buffering occurs.
-*/
-   if (cpu_is_omap2420() ||
-   (cpu_is_omap2430()  (omap_type() == OMAP2430_REV_ES1_0)))
-   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
-
+   if (IS_DMA_ERRATA(DMA_ERRATA_IFRAME_BUFFERING))
+   l |= OMAP_DMA_CCR_BUFFERING_DISABLE;
l |= OMAP_DMA_CCR_EN;
+
dma_write(l, CCR, lch);
 
dma_chan[lch].flags |= OMAP_DMA_ACTIVE;
@@ -1128,8 +1115,8 @@ void omap_stop_dma(int lch)
dma_write(0, CICR, lch);
 
l = dma_read(CCR, lch);
-   /* OMAP3 Errata i541: sDMA FIFO draining does not finish */
-   if (cpu_is_omap34xx()  (l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
+   if (IS_DMA_ERRATA(DMA_ERRATA_i541) 
+   (l  OMAP_DMA_CCR_SEL_SRC_DST_SYNC)) {
int i = 0;
u32 sys_cf;
 
@@ -1229,11 +1216,7 @@ dma_addr_t omap_get_dma_src_pos(int lch)
else
offset = dma_read(CSAC, lch);
 
-   /*
-* omap 3.2/3.3 erratum: sometimes 0 is returned if CSAC/CDAC is
-* read before the DMA controller finished disabling the channel.
-*/
-   if (!cpu_is_omap15xx()  offset == 0)
+   if (IS_DMA_ERRATA(DMA_ERRATA_3_3)  offset == 0)
offset = dma_read(CSAC, lch);
 
if (cpu_class_is_omap1())
@@ -1814,7 +1797,7 @@ int omap_stop_dma_chain_transfers(int chain_id)
 {
int *channels;
u32 l, i;
-   u32 sys_cf;
+   u32 sys_cf = 0;
 
/* Check for input params */
if (unlikely((chain_id  0 || chain_id = dma_lch_count))) {
@@ -1829,15 +1812,13 @@ int omap_stop_dma_chain_transfers(int chain_id)
}
channels = dma_linked_lch[chain_id].linked_dmach_q;
 
-   /*
-* DMA Errata:
-* Special programming model needed to disable DMA before end of block
-*/
-   sys_cf = dma_read(OCP_SYSCONFIG, 0);
-   l = sys_cf;
-   /* Middle mode reg set no Standby */
-   l = ~((1  12)|(1  13));
-   dma_write(l, OCP_SYSCONFIG, 0);
+   if (IS_DMA_ERRATA(DMA_ERRATA_i88)) {
+   sys_cf = dma_read(OCP_SYSCONFIG, 0);
+   l = sys_cf;
+   /* Middle mode reg set no Standby */
+   l = ~((1  12)|(1  13));
+   dma_write(l, OCP_SYSCONFIG, 0);
+   }
 
for (i = 0; i  dma_linked_lch[chain_id].no_of_lchs_linked; i++) {
 
@@ -1856,8 +1837,8 @@ int omap_stop_dma_chain_transfers(int chain_id)
/* Reset the Queue pointers */
OMAP_DMA_CHAIN_QINIT(chain_id);
 
-   /* Errata - put in the old value */
-   dma_write(sys_cf, 

[PATCH v2 5/9] OMAP3: hwmod data: add system DMA

2010-12-17 Thread G, Manjunath Kondaiah
Add OMAP3 DMA hwmod data

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   97 
 1 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 2687be1..d5acb63 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -52,6 +52,8 @@ static struct omap_hwmod omap3xxx_gpio4_hwmod;
 static struct omap_hwmod omap3xxx_gpio5_hwmod;
 static struct omap_hwmod omap3xxx_gpio6_hwmod;
 
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
+
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
.master = omap3xxx_l3_main_hwmod,
@@ -1090,6 +1092,98 @@ static struct omap_hwmod omap3xxx_gpio6_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
 };
 
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+   .master = omap3xxx_dma_system_hwmod,
+   .slave  = omap3xxx_l3_main_hwmod,
+   .clk= core_l3_ick,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+   omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+   .master = omap3xxx_l4_core_hwmod,
+   .slave  = omap3xxx_dma_system_hwmod,
+   .clk= core_l4_ick,
+   .addr   = omap3xxx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+   omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap3xxx_dma_hwmod_class,
+   .mpu_irqs   = omap3xxx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+   .main_clk   = core_l3_ick,
+   .prcm = {
+   .omap2 = {
+   .module_offs= CORE_MOD,
+   .prcm_reg_id= 1,
+   .module_bit = OMAP3430_ST_SDMA_SHIFT,
+   .idlest_reg_id  = 1,
+   .idlest_idle_bit= OMAP3430_ST_SDMA_SHIFT,
+   },
+   },
+   .slaves = omap3xxx_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+   .masters= omap3xxx_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@ -1113,6 +1207,9 @@ static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_gpio4_hwmod,
omap3xxx_gpio5_hwmod,
omap3xxx_gpio6_hwmod,
+
+   /* dma_system class*/
+   omap3xxx_dma_system_hwmod,
NULL,
 };
 
-- 
1.7.1

--
To 

[PATCH v2 4/9] OMAP2430: hwmod data: add system DMA

2010-12-17 Thread G, Manjunath Kondaiah
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   87 
 arch/arm/plat-omap/include/plat/dma.h  |1 +
 2 files changed, 88 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index f68409e..b52ba66 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -43,6 +43,7 @@ static struct omap_hwmod omap2430_gpio2_hwmod;
 static struct omap_hwmod omap2430_gpio3_hwmod;
 static struct omap_hwmod omap2430_gpio4_hwmod;
 static struct omap_hwmod omap2430_gpio5_hwmod;
+static struct omap_hwmod omap2430_dma_system_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -840,6 +841,89 @@ static struct omap_hwmod omap2430_gpio5_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
 };
 
+/* dma_system */
+static struct omap_hwmod_class_sysconfig omap2430_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap2430_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2430_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2430_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2430_dma_system__l3 = {
+   .master = omap2430_dma_system_hwmod,
+   .slave  = omap2430_l3_main_hwmod,
+   .clk= core_l3_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_masters[] = {
+   omap2430_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2430_l4_core__dma_system = {
+   .master = omap2430_l4_core_hwmod,
+   .slave  = omap2430_dma_system_hwmod,
+   .clk= sdma_ick,
+   .addr   = omap2430_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2430_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2430_dma_system_slaves[] = {
+   omap2430_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2430_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap2430_dma_hwmod_class,
+   .mpu_irqs   = omap2430_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2430_dma_system_irqs),
+   .main_clk   = core_l3_ck,
+   .slaves = omap2430_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2430_dma_system_slaves),
+   .masters= omap2430_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2430_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_l3_main_hwmod,
omap2430_l4_core_hwmod,
@@ -859,6 +943,9 @@ static __initdata struct omap_hwmod *omap2430_hwmods[] = {
omap2430_gpio3_hwmod,
omap2430_gpio4_hwmod,
omap2430_gpio5_hwmod,
+
+   /* dma_system class*/
+   omap2430_dma_system_hwmod,
NULL,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index c466566..4b51d2b 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -301,6 +301,7 @@
 #define RESERVE_CHANNELBIT(0x2)
 #define IS_CSSA_32 BIT(0x3)
 #define IS_CDSA_32 BIT(0x4)
+#define IS_RW_PRIORITY 

[PATCH v2 6/9] OMAP4: hwmod data: add system DMA

2010-12-17 Thread G, Manjunath Kondaiah
From: Benoit Cousson b-cous...@ti.com

Add OMAP4 DMA hwmod data

Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  101 
 1 files changed, 101 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d258936..50c00d6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -23,6 +23,7 @@
 #include plat/omap_hwmod.h
 #include plat/cpu.h
 #include plat/gpio.h
+#include plat/dma.h
 
 #include omap_hwmod_common_data.h
 
@@ -36,6 +37,7 @@
 #define OMAP44XX_DMA_REQ_START  1
 
 /* Backward references (IPs with Bus Master capability) */
+static struct omap_hwmod omap44xx_dma_system_hwmod;
 static struct omap_hwmod omap44xx_dmm_hwmod;
 static struct omap_hwmod omap44xx_emif_fw_hwmod;
 static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -216,6 +218,14 @@ static struct omap_hwmod_ocp_if 
omap44xx_l3_main_1__l3_main_2 = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* dma_system - l3_main_2 */
+static struct omap_hwmod_ocp_if omap44xx_dma_system__l3_main_2 = {
+   .master = omap44xx_dma_system_hwmod,
+   .slave  = omap44xx_l3_main_2_hwmod,
+   .clk= l3_div_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg - l3_main_2 */
 static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 = {
.master = omap44xx_l4_cfg_hwmod,
@@ -227,6 +237,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__l3_main_2 
= {
 /* l3_main_2 slave ports */
 static struct omap_hwmod_ocp_if *omap44xx_l3_main_2_slaves[] = {
omap44xx_l3_main_1__l3_main_2,
+   omap44xx_dma_system__l3_main_2,
omap44xx_l4_cfg__l3_main_2,
 };
 
@@ -1376,6 +1387,93 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio6_slaves),
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
 };
+
+/*
+ * 'dma' class
+ * dma controller for data exchange between memory to memory (i.e. internal or
+ * external memory) and gp peripherals to memory or memory to gp peripherals
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap44xx_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORITY,
+   .lch_count = 32,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap44xx_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 + OMAP44XX_IRQ_GIC_START },
+   { .name = 1, .irq = 13 + OMAP44XX_IRQ_GIC_START },
+   { .name = 2, .irq = 14 + OMAP44XX_IRQ_GIC_START },
+   { .name = 3, .irq = 15 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x4a056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_masters[] = {
+   omap44xx_dma_system__l3_main_2,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__dma_system = {
+   .master = omap44xx_l4_cfg_hwmod,
+   .slave  = omap44xx_dma_system_hwmod,
+   .clk= l4_div_ck,
+   .addr   = omap44xx_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap44xx_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dma_system_slaves[] = {
+   omap44xx_l4_cfg__dma_system,
+};
+
+static struct omap_hwmod omap44xx_dma_system_hwmod = {
+   .name   = dma_system,
+   .class  = omap44xx_dma_hwmod_class,
+   .mpu_irqs   = omap44xx_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap44xx_dma_system_irqs),
+   .main_clk   = l3_div_ck,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_reg = OMAP4430_CM_SDMA_SDMA_CLKCTRL,
+ 

[PATCH v2 7/9] OMAP1: DMA: Implement in platform device model

2010-12-17 Thread G, Manjunath Kondaiah
Implement OMAP1 DMA as platform device and add support for
registering through platform device layer using resource
structures.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap1/dma.c |  179 +
 1 files changed, 179 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dma.c

diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
new file mode 100644
index 000..120eff7
--- /dev/null
+++ b/arch/arm/mach-omap1/dma.c
@@ -0,0 +1,179 @@
+/*
+ * OMAP1/OMAP7xx - specific DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ *   - G, Manjunath Kondaiah manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/dma.h
+#include plat/tc.h
+#include plat/irqs.h
+
+#define OMAP1_DMA_BASE (0xfffed800)
+
+static struct resource res[] __initdata = {
+   [0] = {
+   .start  = OMAP1_DMA_BASE,
+   .end= OMAP1_DMA_BASE + SZ_2K - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .name   = 0,
+   .start  = INT_DMA_CH0_6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [2] = {
+   .name   = 1,
+   .start  = INT_DMA_CH1_7,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [3] = {
+   .name   = 2,
+   .start  = INT_DMA_CH2_8,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [4] = {
+   .name   = 3,
+   .start  = INT_DMA_CH3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [5] = {
+   .name   = 4,
+   .start  = INT_DMA_CH4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [6] = {
+   .name   = 5,
+   .start  = INT_DMA_CH5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [7] = {
+   .name   = 6,
+   .start  = INT_1610_DMA_CH6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   /* irq's for omap16xx and omap7xx */
+   [8] = {
+   .name   = 7,
+   .start  = INT_1610_DMA_CH7,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [9] = {
+   .name   = 8,
+   .start  = INT_1610_DMA_CH8,
+   .flags  = IORESOURCE_IRQ,
+   },
+   [10] = {
+   .name  = 9,
+   .start = INT_1610_DMA_CH9,
+   .flags = IORESOURCE_IRQ,
+   },
+   [11] = {
+   .name  = 10,
+   .start = INT_1610_DMA_CH10,
+   .flags = IORESOURCE_IRQ,
+   },
+   [12] = {
+   .name  = 11,
+   .start = INT_1610_DMA_CH11,
+   .flags = IORESOURCE_IRQ,
+   },
+   [13] = {
+   .name  = 12,
+   .start = INT_1610_DMA_CH12,
+   .flags = IORESOURCE_IRQ,
+   },
+   [14] = {
+   .name  = 13,
+   .start = INT_1610_DMA_CH13,
+   .flags = IORESOURCE_IRQ,
+   },
+   [15] = {
+   .name  = 14,
+   .start = INT_1610_DMA_CH14,
+   .flags = IORESOURCE_IRQ,
+   },
+   [16] = {
+   .name  = 15,
+   .start = INT_1610_DMA_CH15,
+   .flags = IORESOURCE_IRQ,
+   },
+   [17] = {
+   .name  = 16,
+   .start = INT_DMA_LCD,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
+static int __init omap1_system_dma_init(void)
+{
+   struct omap_system_dma_plat_info*p;
+   struct platform_device  *pdev;
+   int ret;
+
+   pdev = platform_device_alloc(omap_dma_system, 0);
+   if (!pdev) {
+   pr_err(%s: Unable to device alloc for dma\n,
+   __func__);
+   return -ENOMEM;
+   }
+
+   ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
+   if (ret) {
+   dev_err(pdev-dev, %s: Unable to add resources for %s%d\n,
+   __func__, pdev-name, pdev-id);
+   goto exit_device_del;
+  

[PATCH v2 8/9] OMAP2+: DMA: hwmod: Device registration

2010-12-17 Thread G, Manjunath Kondaiah
Prepare OMAP2+ DMA to use hwmod infrastructure so that DMA can register
as platform device.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Tested-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/dma.c |   74 +
 1 files changed, 74 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/dma.c

diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..2130059
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP2+ DMA driver
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun, Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   },
+};
+
+/* One time initializations */
+static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void 
*unused)
+{
+   struct omap_device  *od;
+   struct omap_system_dma_plat_info*p;
+   char*name = omap_dma_system;
+
+   p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+   if (!p) {
+   pr_err(%s: Unable to allocate pdata for %s:%s\n,
+   __func__, name, oh-name);
+   return -ENOMEM;
+   }
+
+   od = omap_device_build(name, 0, oh, p, sizeof(*p),
+   omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+   kfree(p);
+   if (IS_ERR(od)) {
+   pr_err(%s: Cant build omap_device for %s:%s.\n,
+   __func__, name, oh-name);
+   return IS_ERR(od);
+   }
+
+   return 0;
+}
+
+static int __init omap2_system_dma_init(void)
+{
+   return omap_hwmod_for_each_by_class(dma,
+   omap2_system_dma_init_dev, NULL);
+}
+arch_initcall(omap2_system_dma_init);
-- 
1.7.1

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


[PATCH v2 0/9] OMAP: DMA: hwmod and DMA as platform device

2010-12-17 Thread G, Manjunath Kondaiah
Detailed description and history of this patch series can be found at:
http://thread.gmane.org/gmane.linux.ports.arm.omap/47600

Changes from v1 to v2:
1. The OMAP1 irq fixes patchby kevin:
https://patchwork.kernel.org/patch/412021/
is folded into this series and added kevin s.o.b

2. The 2420 and 2430 clock clock entries are corrected as per paul's
suggestion at:
http://article.gmane.org/gmane.linux.ports.arm.omap/48441
http://article.gmane.org/gmane.linux.ports.arm.omap/48442

3. Added Tested-by and Acked-by to all the applicable patches
(except 3/9 and 4/9 due to paul's comments)

The diff between v1 and v2 series is posted for reference at:
http://pastebin.com/EG46DeK6

Testing:
Build: 
omap1_defconfig : Success
omap2plus_defconfig: Success

Boot:
OMAP4430SDP: Success
OMAP2430SDP: Success
N800(OMAP2420) : Success 
Note: Image for N800 is created from n8x0_defconfig derived from the commit: 
d31f59f31d602e8c3a34ce1f20d1e8fcfe50dd59
and it is customized to reduce the image size. Thanks to Tony and paul
for providing the commit and other info related to N800 boot.
boot log at: http://pastebin.com/0y91Vvkf

Unit testing:
All the memory to memory test cases are passing on SDP2430 and complete
test log can be accessed at:
http://pastebin.com/1ALGuE8z

Note: The remaining omap2+ boards are not tested with this series since
changes done in this series are no way related to other omap2+ boards. 
The OMAP1(OSK5912) boot and other relevant tests are executed by kevin 
with the fixes https://patchwork.kernel.org/patch/412021/
The above patch is folded into 7/9 in this patch series which needs review.

Benoit Cousson (1):
  OMAP4: hwmod data: add system DMA

G, Manjunath Kondaiah (8):
  OMAP: DMA: Replace read/write macros with functions
  OMAP: DMA: Introduce errata handling feature
  OMAP2420: hwmod data: add system DMA
  OMAP2430: hwmod data: add system DMA
  OMAP3: hwmod data: add system DMA
  OMAP1: DMA: Implement in platform device model
  OMAP2+: DMA: hwmod: Device registration
  OMAP: DMA: Convert DMA library into platform driver

 arch/arm/mach-omap1/Makefile   |2 +-
 arch/arm/mach-omap1/dma.c  |  390 
 arch/arm/mach-omap2/Makefile   |2 +-
 arch/arm/mach-omap2/dma.c  |  297 
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   87 
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   87 
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   97 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  101 
 arch/arm/plat-omap/dma.c   |  697 
 arch/arm/plat-omap/include/plat/dma.h  |  232 --
 10 files changed, 1452 insertions(+), 540 deletions(-)
 create mode 100644 arch/arm/mach-omap1/dma.c
 create mode 100644 arch/arm/mach-omap2/dma.c

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


[PATCH v2 3/9] OMAP2420: hwmod data: add system DMA

2010-12-17 Thread G, Manjunath Kondaiah
Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.

Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   87 
 arch/arm/plat-omap/include/plat/dma.h  |   11 
 2 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index d953425..eb02fec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -42,6 +42,7 @@ static struct omap_hwmod omap2420_gpio1_hwmod;
 static struct omap_hwmod omap2420_gpio2_hwmod;
 static struct omap_hwmod omap2420_gpio3_hwmod;
 static struct omap_hwmod omap2420_gpio4_hwmod;
+static struct omap_hwmod omap2420_dma_system_hwmod;
 
 /* L3 - L4_CORE interface */
 static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -779,6 +780,89 @@ static struct omap_hwmod omap2420_gpio4_hwmod = {
.omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
 };
 
+/* system dma */
+static struct omap_hwmod_class_sysconfig omap2420_dma_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x002c,
+   .syss_offs  = 0x0028,
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_dma_hwmod_class = {
+   .name = dma,
+   .sysc = omap2420_dma_sysc,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+   .dev_caps  = RESERVE_CHANNEL | DMA_LINKED_LCH | GLOBAL_PRIORITY |
+   IS_CSSA_32 | IS_CDSA_32,
+   .lch_count = 32,
+};
+
+static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
+   { .name = 0, .irq = 12 }, /* INT_24XX_SDMA_IRQ0 */
+   { .name = 1, .irq = 13 }, /* INT_24XX_SDMA_IRQ1 */
+   { .name = 2, .irq = 14 }, /* INT_24XX_SDMA_IRQ2 */
+   { .name = 3, .irq = 15 }, /* INT_24XX_SDMA_IRQ3 */
+};
+
+static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
+   {
+   .pa_start   = 0x48056000,
+   .pa_end = 0x4a0560ff,
+   .flags  = ADDR_TYPE_RT
+   },
+};
+
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap2420_dma_system__l3 = {
+   .master = omap2420_dma_system_hwmod,
+   .slave  = omap2420_l3_main_hwmod,
+   .clk= core_l3_ck,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_masters[] = {
+   omap2420_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap2420_l4_core__dma_system = {
+   .master = omap2420_l4_core_hwmod,
+   .slave  = omap2420_dma_system_hwmod,
+   .clk= sdma_ick,
+   .addr   = omap2420_dma_system_addrs,
+   .addr_cnt   = ARRAY_SIZE(omap2420_dma_system_addrs),
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap2420_dma_system_slaves[] = {
+   omap2420_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap2420_dma_system_hwmod = {
+   .name   = dma,
+   .class  = omap2420_dma_hwmod_class,
+   .mpu_irqs   = omap2420_dma_system_irqs,
+   .mpu_irqs_cnt   = ARRAY_SIZE(omap2420_dma_system_irqs),
+   .main_clk   = core_l3_ck,
+   .slaves = omap2420_dma_system_slaves,
+   .slaves_cnt = ARRAY_SIZE(omap2420_dma_system_slaves),
+   .masters= omap2420_dma_system_masters,
+   .masters_cnt= ARRAY_SIZE(omap2420_dma_system_masters),
+   .dev_attr   = dma_dev_attr,
+   .omap_chip  = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+   .flags  = HWMOD_NO_IDLEST,
+};
+
 static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -797,6 +881,9 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_gpio2_hwmod,
omap2420_gpio3_hwmod,
omap2420_gpio4_hwmod,
+
+   /* dma_system class*/
+   omap2420_dma_system_hwmod,
NULL,
 };
 
diff --git a/arch/arm/plat-omap/include/plat/dma.h 
b/arch/arm/plat-omap/include/plat/dma.h
index 2378399..c466566 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -295,6 +295,13 @@
 #define DMA_ERRATA_3_3 BIT(0x5)
 #define DMA_ROMCODE_BUGBIT(0x6)
 
+/* Attributes for OMAP DMA Contrller */
+#define DMA_LINKED_LCH

Re: [PATCH 6/7] OMAP3: add comments for low power code errata

2010-12-17 Thread Nishanth Menon
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the 
following:

From: Jean Pihet j-pi...@ti.com

Errata covered:
- 1.157  1.185
- i443
- i581

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/pm34xx.c|4 ++--
 arch/arm/mach-omap2/sleep34xx.S |   11 +++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index adc0917..267f015 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -148,7 +148,7 @@ static void omap3_core_save_context(void)
 
 	/*

 * Force write last pad into memory, as this can fail in some
-* cases according to erratas 1.157, 1.185
+* cases according to errata 1.157, 1.185
a better cleanup might to actually use PM_ERRATUM macros to enable 
disable this code on a need basis.

 */
omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
OMAP343X_CONTROL_MEM_WKUP + 0x2a0);
@@ -446,7 +446,7 @@ void omap_sram_idle(void)
/*
* On EMU/HS devices ROM code restores a SRDC value
* from scratchpad which has automatic self refresh on timeout
-   * of AUTO_CNT = 1 enabled. This takes care of errata 1.142.
+   * of AUTO_CNT = 1 enabled. This takes care of erratum ID i443.

same here.

* Hence store/restore the SDRC_POWER register here.
*/
if (omap_rev() = OMAP3430_REV_ES3_0 
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 12061fd..8e5004a 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -592,6 +592,7 @@ usettbr0:
  * Internal functions
  */
 
+/* This function implements the erratum ID i443 WA, applies to 34xx = ES3.0 */

.text
 ENTRY(es3_sdrc_fix)
ldr r4, sdrc_syscfg @ get config addr
@@ -637,6 +638,16 @@ sdrc_manual_1:
 ENTRY(es3_sdrc_fix_sz)
.word   . - es3_sdrc_fix
 
+/*

+ * This function implements the erratum ID i581 WA:
+ *  SDRC state restore before accessing the SDRAM
+ *
+ * Only used at return from non-OFF mode. For OFF
+ * mode the ROM code configures the SDRC and
+ * the DPLL before calling the restore code directly
+ * from DDR.
+ */
+
 /* Make sure SDRC accesses are ok */
 wait_sdrc_ok:

Tested-by: Nishanth Menon n...@ti.com
Tested on:
SDP3630
SDP3430
Test script:
http://pastebin.mozilla.org/889933

--
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 7/7] OMAP3: ASM sleep code format rework

2010-12-17 Thread Nishanth Menon


jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the 
following:

From: Jean Pihet j-pi...@ti.com
Thanks for doing this, could you pull in the other cosmetic changes from 
patches 1-6 here as well?


Also, please run checkpatch.pl --strict:
ERROR: trailing whitespace
#426: FILE: arch/arm/mach-omap2/sleep34xx.S:590:
+^I * The caches and prediction are not enabled here, they $

total: 1 errors, 0 warnings, 0 checks, 447 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile
Also reported by git am:
linux-2.6/.git/rebase-apply/patch:355: trailing whitespace.
 * The caches and prediction are not enabled here, they
warning: 1 line adds whitespace errors.



Cosmetic fixes to the code:
- white spaces and tabs,
- alignement,
- comments rephrase and typos,
- multi-line comments

Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.

Signed-off-by: Jean Pihet j-pi...@ti.com
---
 arch/arm/mach-omap2/sleep34xx.S |  226 +--
 1 files changed, 122 insertions(+), 104 deletions(-)

diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 8e5004a..6376427 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -1,6 +1,10 @@
 /*
  * linux/arch/arm/mach-omap2/sleep.S

if you are cleaning things up, you might as well throw this out.

  *
+ * (C) Copyright 2010
+ * Texas Instruments
if you do use this, please follow the requirements that have been 
standardized in side TI now:

Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/


+ * Jean Pihet j-pi...@ti.com
+ *
umm.. will leave it for Kevin to comment. the series was a cleanup I 
agree, functionally there is much contribution from lot of other folks 
as well.. personally, since all contributions are maintained in git 
history anyways.. I dont usually bother about touching the original 
copyrights - but that is just me



  * (C) Copyright 2007
  * Texas Instruments
  * Karthik Dasu karthik...@ti.com
@@ -81,20 +85,20 @@
.text
 /* Function call to get the restore pointer for resume from OFF */
 ENTRY(get_restore_pointer)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
adr r0, restore
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 ENTRY(get_restore_pointer_sz)
-.word   . - get_restore_pointer
+   .word   . - get_restore_pointer
 
 	.text

 /* Function call to get the restore pointer for 3630 resume from OFF */
 ENTRY(get_omap3630_restore_pointer)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
adr r0, restore_3630
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 ENTRY(get_omap3630_restore_pointer_sz)
-.word   . - get_omap3630_restore_pointer
+   .word   . - get_omap3630_restore_pointer
 
 	.text

 /* Function call to get the restore pointer for ES3 to resume from OFF */
@@ -112,16 +116,16 @@ ENTRY(get_es3_restore_pointer_sz)
  * place on 3630. Hopefully some version in the future may not need this.
  */
 ENTRY(enable_omap3630_toggle_l2_on_restore)
-stmfd   sp!, {lr} @ save registers on stack
+   stmfd   sp!, {lr}   @ save registers on stack
/* Setup so that we will disable and enable l2 */
mov r1, #0x1
str r1, l2dis_3630
-ldmfd   sp!, {pc} @ restore regs and return
+   ldmfd   sp!, {pc}   @ restore regs and return
 
+	.text

 /* Function to call rom code to save secure ram context */
 ENTRY(save_secure_ram_context)
stmfd   sp!, {r1-r12, lr}   @ save registers on stack
-
adr r3, api_params  @ r3 points to parameters
str r0, [r3,#0x4]   @ r0 has sdram address
ldr r12, high_mask
@@ -150,6 +154,7 @@ api_params:
 ENTRY(save_secure_ram_context_sz)
.word   . - save_secure_ram_context
 
+

IMHO, spurious - just need one EOL, not 2.


 /*
  * ==
  * == Idle entry point ==
@@ -163,13 +168,14 @@ ENTRY(save_secure_ram_context_sz)
  * and executes the WFI instruction
  *
  * Notes:
- * - this code gets copied to internal SRAM at boot.
+ * - this code gets copied to internal SRAM at boot and after wake-up
+ *   from OFF mode
  * - when the OMAP wakes up it continues at different execution points
  *   depending on the low power mode (non-OFF vs OFF modes),
  *   cf. 'Resume path for xxx mode' comments.
  */
 ENTRY(omap34xx_cpu_suspend)
-   stmfd   sp!, {r0-r12, lr}   @ save registers on stack
+   stmfd   sp!, {r0-r12, lr}   @ save registers on stack
 
 	/*

 * r0 contains restore pointer in sdram
@@ -276,9 +282,9 @@ clean_l2:
 *  - should be 

Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling

2010-12-17 Thread Cousson, Benoit

Hi Omar,

On 12/16/2010 3:11 PM, Ramirez Luna, Omar wrote:

Hi,

On Thu, Dec 16, 2010 at 2:28 AM, Varadarajan, Charulathach...@ti.com  wrote:

On Thu, Dec 16, 2010 at 12:17, Omar Ramirez Lunaomar.rami...@ti.com  wrote:

Use runtime pm APIs to enable/disable mailbox clocks and
to configure SYSC register.

Based on the patch sent by Felipe Contreras:
https://patchwork.kernel.org/patch/101662/

Signed-off-by: Omar Ramirez Lunaomar.rami...@ti.com
---
  arch/arm/mach-omap2/mailbox.c |   27 +--
  1 files changed, 5 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 40ddeca..f5f72ba 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -14,6 +14,7 @@
  #includelinux/err.h
  #includelinux/platform_device.h
  #includelinux/io.h
+#includelinux/pm_runtime.h
  #includeplat/mailbox.h
  #includemach/irqs.h

@@ -34,12 +35,8 @@
  #define MAILBOX_IRQ_NOTFULL(m) (1  (2 * (m) + 1))

  /* SYSCONFIG: register bit definition */
-#define AUTOIDLE   (1  0)
  #define SOFTRESET  (1  1)
-#define SMARTIDLE  (2  3)
  #define OMAP4_SOFTRESET(1  0)
-#define OMAP4_NOIDLE   (1  2)
-#define OMAP4_SMARTIDLE(2  2)

  /* SYSSTATUS: register bit definition */
  #define RESETDONE  (1  0)


Is this still required?


Yes, mailbox uses the softreset every time it is requested (and that
it has no current users at the time), it does it before configuring
sysc, as opossed to what this patch does (where clk is enabled, sysc
configured, and then softreset), but no harm was seen with this
sequence.

AFAIK, enabling/disabling hwmod handles prm reset but not softreset
bit, that's why I left it there.


In fact both are handled now. hardreset is managed for IVA, DSP and IPU, 
and softreset for most the other IPs.
The only slight difference, is that softreset for the moment is just 
done once at setup time. The idea being that we do not know the state 
the bootloader configured IP, so we reset it by default.


I thought I did it for every enable from disable state, but in fact this 
is not the case, because AFAIK there is not use-case for that yet.


Why do you have to softreset the mailbox? That sounds like some old HW 
bugs from the past that we solve using the softreset.


Could you elaborate on that use case? If there is a need, I'd rather 
update the hwmod core than letting you playing directly with the 
sysconfig. At least we can expose the API we did for that purpose but 
didn't merge due to the lack of any strong need.


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


Re: [PATCH] OMAP4: Pandaboard: Fixing MMC card detect gpio line

2010-12-17 Thread Menon, Nishanth
On Wed, Dec 8, 2010 at 10:49, David Anders x0132...@ti.com wrote:
 On 12/07/2010 06:13 AM, Murthy, Raghuveer wrote:

 The .gpio_cd member of omap2_hsmmc_info is not initialized. This
 will default to zero. On Pandaboard this interferes with gpio line
 assigned for powering TFP410 DVI chip.

 This fix was missed out in the previous commit bf56f0a6668cd, from
 Nishanth Menon

 Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
 Signed-off-by: Raghuveer Murthyraghuveer.mur...@ti.com
 Acked-by: Nishanth Menonn...@ti.com


 Tested-by: David Anders x0132...@ti.com
Tony,
this is a regression introduced in my commit for .37-rc1. any chance
of this making to one of 37 rc cycles? I can re-post this patch
including l-a if that is the path you'd like.

Regards,
Nishanth Menon



 ---
  arch/arm/mach-omap2/board-omap4panda.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-omap4panda.c
 b/arch/arm/mach-omap2/board-omap4panda.c
 index ad6b5cc..0ccc24f 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -142,6 +142,7 @@ static struct omap2_hsmmc_info mmc[] = {
                .mmc            = 1,
                .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
                .gpio_wp        = -EINVAL,
 +               .gpio_cd        = -EINVAL,
        },
        {}      /* Terminator */
  };


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

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


Re: [PATCH v2] OMAP4: Pandaboard: Add omap_reserve functionality

2010-12-17 Thread Menon, Nishanth
Tony,

2010/12/8 Marek Vasut marek.va...@gmail.com:
 On Wednesday 08 December 2010 08:10:47 Raghuveer Murthy wrote:
 This patch adds omap_reserve functionality to board-omap4panda.c.
 Helps in the reserving boot time memory in SDRAM, used here for
 framebuffer allocation.

 This patch is in similar lines to commit id 71ee7dad9b6991, from
 Russell king

 Russell King ... it's a surname, not a title :-D

 btw. CCing linux-arm-kernel, as that's a proper mailing list.

Gentle ping on this patch - should this be reposted for the -next
cycle inclusion?

Regards,
Nishanth Menon


 Cheers

 Cc: Russell King rmk+ker...@arm.linux.org.uk
 Cc: linux-...@lists.arm.linux.org.uk
 Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com
 ---
  arch/arm/mach-omap2/board-omap4panda.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-omap4panda.c
 b/arch/arm/mach-omap2/board-omap4panda.c index da24745..0ccc24f 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
       /* Maintainer: David Anders - Texas Instruments Inc */
       .boot_params    = 0x8100,
       .map_io         = omap4_panda_map_io,
 +     .reserve        = omap_reserve,
       .init_irq       = omap4_panda_init_irq,
       .init_machine   = omap4_panda_init,
       .timer          = omap_timer,
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


Re: [PATCH] OMAP4: Pandaboard: Fixing MMC card detect gpio line

2010-12-17 Thread Tony Lindgren
* Menon, Nishanth n...@ti.com [101217 09:50]:
 On Wed, Dec 8, 2010 at 10:49, David Anders x0132...@ti.com wrote:
  On 12/07/2010 06:13 AM, Murthy, Raghuveer wrote:
 
  The .gpio_cd member of omap2_hsmmc_info is not initialized. This
  will default to zero. On Pandaboard this interferes with gpio line
  assigned for powering TFP410 DVI chip.
 
  This fix was missed out in the previous commit bf56f0a6668cd, from
  Nishanth Menon
 
  Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
  Signed-off-by: Raghuveer Murthyraghuveer.mur...@ti.com
  Acked-by: Nishanth Menonn...@ti.com
 
 
  Tested-by: David Anders x0132...@ti.com
 Tony,
 this is a regression introduced in my commit for .37-rc1. any chance
 of this making to one of 37 rc cycles? I can re-post this patch
 including l-a if that is the path you'd like.

Yes please, and also explain what exactly this breaks.

If it just breaks MMC card detect with some DVI chip driver that's
not merged yet, then this would be in the it never worked before.

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


Re: [PATCH] OMAP4: Pandaboard: Fixing MMC card detect gpio line

2010-12-17 Thread Nishanth Menon

Tony Lindgren had written, on 12/17/2010 12:02 PM, the following:

* Menon, Nishanth n...@ti.com [101217 09:50]:

On Wed, Dec 8, 2010 at 10:49, David Anders x0132...@ti.com wrote:

On 12/07/2010 06:13 AM, Murthy, Raghuveer wrote:

The .gpio_cd member of omap2_hsmmc_info is not initialized. This
will default to zero. On Pandaboard this interferes with gpio line
assigned for powering TFP410 DVI chip.

This fix was missed out in the previous commit bf56f0a6668cd, from
Nishanth Menon

Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Signed-off-by: Raghuveer Murthyraghuveer.mur...@ti.com
Acked-by: Nishanth Menonn...@ti.com


Tested-by: David Anders x0132...@ti.com

Tony,
this is a regression introduced in my commit for .37-rc1. any chance
of this making to one of 37 rc cycles? I can re-post this patch
including l-a if that is the path you'd like.


Yes please, and also explain what exactly this breaks.

If it just breaks MMC card detect with some DVI chip driver that's
not merged yet, then this would be in the it never worked before.
The regression is card detect ends up refering to a valid GPIO - yeah 
as a result the upcoming DVI driver is broken without this patch. given 
that commit bf56f0a6668cd was intended to fix cd, it did not do it 
cleanly - hence my claim of regression. DVI in opinion is just a symptom 
of the wiring of GPIO0 on the board.


ok with considering this a regression?

--
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 v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling

2010-12-17 Thread Ramirez Luna, Omar
On Fri, Dec 17, 2010 at 10:28 AM, Cousson, Benoit b-cous...@ti.com wrote:
  /* SYSCONFIG: register bit definition */
 -#define AUTOIDLE       (1  0)
  #define SOFTRESET      (1  1)
 -#define SMARTIDLE      (2  3)
  #define OMAP4_SOFTRESET        (1  0)
 -#define OMAP4_NOIDLE   (1  2)
 -#define OMAP4_SMARTIDLE        (2  2)

  /* SYSSTATUS: register bit definition */
  #define RESETDONE      (1  0)

 Is this still required?

 Yes, mailbox uses the softreset every time it is requested (and that
 it has no current users at the time), it does it before configuring
 sysc, as opossed to what this patch does (where clk is enabled, sysc
 configured, and then softreset), but no harm was seen with this
 sequence.

 AFAIK, enabling/disabling hwmod handles prm reset but not softreset
 bit, that's why I left it there.

 In fact both are handled now. hardreset is managed for IVA, DSP and IPU, and
 softreset for most the other IPs.
 The only slight difference, is that softreset for the moment is just done
 once at setup time. The idea being that we do not know the state the
 bootloader configured IP, so we reset it by default.

Yes, I noticed that softreset was handled on setup only.

 I thought I did it for every enable from disable state, but in fact this is
 not the case, because AFAIK there is not use-case for that yet.

 Why do you have to softreset the mailbox? That sounds like some old HW bugs
 from the past that we solve using the softreset.

It is adviced in the TRM that before initialization of the module, you
should do a softreset and set sysc register, I found this explanation
too (with git blame):

omap: mailbox: Execute softreset at startup

The softreset at startup is introduced as TRM describes and also some
register bit definitions are added instead of magic number

But mailbox doesn't execute this on init, but on every first user
request, it doesn't sound like there was a bug solved with this.

Also related (these were the quickest I could check):

- The DSI protocol engine can be reset by software. This reset can be
done for debug purposes or after a protocol error.
- UART needs it too, but in this case it was executed one time at
init, so hwmod was the perfect match to remove it.

 Could you elaborate on that use case? If there is a need, I'd rather update
 the hwmod core than letting you playing directly with the sysconfig. At
 least we can expose the API we did for that purpose but didn't merge due to
 the lack of any strong need.

I also thought of this, but then driver would need:

pm_runtime_get_sync()// to enable the clock
pdata-device_reset() // to set the softreset
pm_runtime_put_sync()// to disable the clock
pm_runtime_get_sync()// to enable again and reconfigure sysc lost
with softreset

If needed I think softreset should be handled in the device enable
path rather than a new API.

Regards,

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


[PATCH 3/3] omap: rx51: Add supplies and data for codec b part of TLV320AIC34

2010-12-17 Thread Jarkko Nikula
Upcoming ASoC core and tlv320aic3x changes makes possible to take b part of
TLV320AIC34 into use on RX51/N900. Prepare to this by adding virtual supplies
and platform data for b part of the codec.

Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 6114e47..ca8cecd 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -343,6 +343,8 @@ static struct regulator_consumer_supply 
rx51_vmmc2_supplies[] = {
/* tlv320aic3x analog supplies */
REGULATOR_SUPPLY(AVDD, 2-0018),
REGULATOR_SUPPLY(DRVDD, 2-0018),
+   REGULATOR_SUPPLY(AVDD, 2-0019),
+   REGULATOR_SUPPLY(DRVDD, 2-0019),
/* tpa6130a2 */
REGULATOR_SUPPLY(Vdd, 2-0060),
/* Keep vmmc as last item. It is not iterated for newer boards */
@@ -353,6 +355,8 @@ static struct regulator_consumer_supply rx51_vio_supplies[] 
= {
/* tlv320aic3x digital supplies */
REGULATOR_SUPPLY(IOVDD, 2-0018),
REGULATOR_SUPPLY(DVDD, 2-0018),
+   REGULATOR_SUPPLY(IOVDD, 2-0019),
+   REGULATOR_SUPPLY(DVDD, 2-0019),
 };
 
 #if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
@@ -743,11 +747,19 @@ static struct aic3x_pdata rx51_aic3x_data = {
.gpio_reset = 60,
 };
 
+static struct aic3x_pdata rx51_aic3x_data2 = {
+   .gpio_reset = 60,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
{
I2C_BOARD_INFO(tlv320aic3x, 0x18),
.platform_data = rx51_aic3x_data,
},
+   {
+   I2C_BOARD_INFO(tlv320aic3x, 0x19),
+   .platform_data = rx51_aic3x_data2,
+   },
 #if defined(CONFIG_SENSORS_TSL2563) || defined(CONFIG_SENSORS_TSL2563_MODULE)
{
I2C_BOARD_INFO(tsl2563, 0x29),
-- 
1.7.2.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: rx51: Remove extra tlv320aic3x.h inclusion

2010-12-17 Thread Jarkko Nikula
Remove second tlv320aic3x.h inclusion that came along the commit f0fba2a
ASoC: multi-component - ASoC Multi-Component Support.

Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Liam Girdwood l...@slimlogic.co.uk
---
Clearly for 2.6.38 as harmless issue.
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index cde6847..6114e47 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -23,7 +23,6 @@
 #include linux/gpio.h
 #include linux/gpio_keys.h
 #include linux/mmc/host.h
-#include sound/tlv320aic3x.h
 
 #include plat/mcspi.h
 #include plat/board.h
-- 
1.7.2.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] OMAP: Fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4

2010-12-17 Thread Jon Hunter
From: Jon Hunter jon-hun...@ti.com

J-Type DPLLs have additional configuration parameters that need to
be programmed when setting the multipler and divider for the DPLL.
These parameters being the sigma delta divider (SD_DIV) for the DPLL
and the digital controlled oscillator (DCO) to be used by the DPLL.

The current code is implemented specifically to configure the
OMAP3630 PER J-Type DPLL. The OMAP4430 USB DPLL is also a J-Type DPLL
and so this code needs to be updated to work for both OMAP3 and OMAP4
devices and any other future devices that have J-TYPE DPLLs.

For the OMAP3630 PER DPLL both the SD_DIV and DCO paramenters are
used but for the OMAP4430 USB DPLL only the SD_DIV field is used.
The current implementation will only program the SD_DIV and DCO
fields if the DPLL has both and hence this does not work for
OMAP4430.

In order to make the code more generic add two new fields to the
dpll_data structure for the SD_DIV field and DCO field bit-masks
and only program these fields if the masks are defined for a specific
DPLL. This simplifies the code and allows us to remove the flag
DPLL_NO_DCO_SEL.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clock.h |1 -
 arch/arm/mach-omap2/clock3xxx_data.c|2 +
 arch/arm/mach-omap2/clock44xx_data.c|3 +-
 arch/arm/mach-omap2/dpll3xxx.c  |   53 +++---
 arch/arm/plat-omap/include/plat/clock.h |5 ++-
 5 files changed, 40 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index a535c7a..896584e 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -49,7 +49,6 @@
 
 /* DPLL Type and DCO Selection Flags */
 #define DPLL_J_TYPE0x1
-#define DPLL_NO_DCO_SEL0x2
 
 int omap2_clk_enable(struct clk *clk);
 void omap2_clk_disable(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 0579604..461b1ca 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -602,6 +602,8 @@ static struct dpll_data dpll4_dd_3630 __initdata = {
.autoidle_mask  = OMAP3430_AUTO_PERIPH_DPLL_MASK,
.idlest_reg = OMAP_CM_REGADDR(PLL_MOD, CM_IDLEST),
.idlest_mask= OMAP3430_ST_PERIPH_CLK_MASK,
+   .dco_mask   = OMAP3630_PERIPH_DPLL_DCO_SEL_MASK,
+   .sddiv_mask = OMAP3630_PERIPH_DPLL_SD_DIV_MASK,
.max_multiplier = OMAP3630_MAX_JTYPE_DPLL_MULT,
.min_divider= 1,
.max_divider= OMAP3_MAX_DPLL_DIV,
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index bfcd19f..cef179e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -913,7 +913,7 @@ static struct clk usb_hs_clk_div_ck = {
 static struct dpll_data dpll_usb_dd = {
.mult_div1_reg  = OMAP4430_CM_CLKSEL_DPLL_USB,
.clk_bypass = usb_hs_clk_div_ck,
-   .flags  = DPLL_J_TYPE | DPLL_NO_DCO_SEL,
+   .flags  = DPLL_J_TYPE,
.clk_ref= sys_clkin_ck,
.control_reg= OMAP4430_CM_CLKMODE_DPLL_USB,
.modes  = (1  DPLL_LOW_POWER_BYPASS) | (1  DPLL_LOCKED),
@@ -924,6 +924,7 @@ static struct dpll_data dpll_usb_dd = {
.enable_mask= OMAP4430_DPLL_EN_MASK,
.autoidle_mask  = OMAP4430_AUTO_DPLL_MODE_MASK,
.idlest_mask= OMAP4430_ST_DPLL_CLK_MASK,
+   .sddiv_mask = OMAP4430_DPLL_SD_DIV_MASK,
.max_multiplier = OMAP4430_MAX_DPLL_MULT,
.max_divider= OMAP4430_MAX_DPLL_DIV,
.min_divider= 1,
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index ed8d330..48df8e4 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -225,23 +225,18 @@ static int _omap3_noncore_dpll_stop(struct clk *clk)
 }
 
 /**
- * lookup_dco_sddiv -  Set j-type DPLL4 compensation variables
+ * lookup_dco - Lookup DCO used by j-type DPLL
  * @clk: pointer to a DPLL struct clk
  * @dco: digital control oscillator selector
- * @sd_div: target sigma-delta divider
  * @m: DPLL multiplier to set
  * @n: DPLL divider to set
  *
  * See 36xx TRM section 3.5.3.3.3.2 Type B DPLL (Low-Jitter)
  *
- * XXX This code is not needed for 3430/AM35xx; can it be optimized
- * out in non-multi-OMAP builds for those chips?
  */
-static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 m,
-u8 n)
+static inline void lookup_dco(struct clk *clk, u8 *dco, u16 m, u8 n)
 {
-   unsigned long fint, clkinp, sd; /* watch out for overflow */
-   int mod1, mod2;
+   unsigned long fint, clkinp; /* watch out for overflow */
 
clkinp = clk-parent-rate;
fint = (clkinp / n) * m;
@@ -250,6 +245,25 @@ static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 
*sd_div, u16 m,
*dco = 2;
else
*dco 

Re: [OMAP 1710] Mainline Broken

2010-12-17 Thread Kevin Hilman
DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

 -Original Message-
 From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
 Sent: Thursday, December 16, 2010 10:39 PM
 To: Belisko Marek
 Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org
 Subject: Re: [OMAP 1710] Mainline Broken
 
 Belisko Marek marek.beli...@gmail.com writes:
 
  Hi,
 
  On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti
  tarun.ka...@ti.com wrote:
  Did anyone observe this? I am using omap_generic_1710_defconfig
 
  [...]
  input: omap-keypad as /devices/platform/omap-keypad/input/input0
  TCP cubic registered
  NET: Registered protocol family 17
  Registering the dns_resolver key type
  eth0: link up
  IP-Config: Complete:
      device=eth0, addr=172.24.191.106, mask=255.255.252.0,
 gw=172.24.188.1,
      host=myomap, domain=, nis-domain=(none),
      bootserver=172.24.191.66, rootserver=172.24.191.66, rootpath=
  VFS: Mounted root (nfs filesystem) on device 0:10.
  Freeing init memory: 128K
  Kernel panic - not syncing: Attempted to kill init!
 
  Seems your userspace is broken. Try add user_debug=31 to command line
  to see what exactly happens.
 
 Looks like you're mounting an NFS rootfs.  Was it compiled for armv5?
 My hunch would be you're trying to run an armv6/armv7 userspace on the
 1710 which is armv5.
 
 To get more debugging, ensure these are enabled in your defconfig:
 
 CONFIG_DEBUG_BUGVERBOSE=y
 CONFIG_DEBUG_USER=y
 CONFIG_DEBUG_ERRORS=y
 
 and in addition to cmdline suggested by Marek, add user_debug=0xf
 
 This will give verbose output for userspace exceptions as well and
 possibly confirm my hunch.
 
 Kevin

 I checked .config and it shows: CONFIG_CPU_32v5=y

This is a kernel config option.  I was asking about your userspace.
Your kernel is obviously booting fine, but it crashes as soon as
userspace starts.

Is your *userspace* compiled for armv5?  I'm guessing not.

Kevin

 With regard to additional log here they are!!

 [...]
 [1] init: obsolete system call .
 Code: e08f1001 e1a0c000 e3a0702d ef00 (e3700a01)
 Kernel panic - not syncing: Attempted to kill init!
 Backtrace:
 [...]
--
To unsubscribe from this list: send the line unsubscribe 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] Keyboard: omap-keypad: use matrix_keypad.h

2010-12-17 Thread Janusz Krzysztofik
Most keypad drivers make use of the linux/input/matrix_keypad.h 
defined macros, structures and inline functions.

Convert omap-keypad driver to use those as well, as suggested by a 
compile time warning, hardcoded into the OMAP palt/keypad.h.

Created against linux-2.6.37-rc5.
Tested on Amstrad Delta.
Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to 
board-h4.

Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---

 arch/arm/mach-omap1/board-ams-delta.c|  128 +++
 arch/arm/mach-omap1/board-fsample.c  |   65 ---
 arch/arm/mach-omap1/board-h2.c   |   69 
 arch/arm/mach-omap1/board-h3.c   |   69 
 arch/arm/mach-omap1/board-htcherald.c|   90 +++--
 arch/arm/mach-omap1/board-innovator.c|   19 ++--
 arch/arm/mach-omap1/board-nokia770.c |   27 +++---
 arch/arm/mach-omap1/board-osk.c  |   19 ++--
 arch/arm/mach-omap1/board-palmte.c   |   24 +++--
 arch/arm/mach-omap1/board-palmtt.c   |   26 +++---
 arch/arm/mach-omap1/board-palmz71.c  |   26 +++---
 arch/arm/mach-omap1/board-perseus2.c |   65 ---
 arch/arm/mach-omap1/board-sx1.c  |   55 +++--
 arch/arm/mach-omap2/board-h4.c   |   59 +++---
 arch/arm/plat-omap/include/plat/keypad.h |   31 ---
 drivers/input/keyboard/omap-keypad.c |   36 
 include/linux/input/matrix_keypad.h  |2
 17 files changed, 429 insertions(+), 381 deletions(-)

--- linux-2.6.37-rc5/arch/arm/plat-omap/include/plat/keypad.h.orig  
2010-12-09 23:07:38.0 +0100
+++ linux-2.6.37-rc5/arch/arm/plat-omap/include/plat/keypad.h   2010-12-16 
21:11:46.0 +0100
@@ -10,13 +10,15 @@
 #ifndef ASMARM_ARCH_KEYPAD_H
 #define ASMARM_ARCH_KEYPAD_H
 
-#warning: Please update the board to use matrix_keypad.h instead
+#ifndef CONFIG_ARCH_OMAP1
+#warning Please update the board to use matrix-keypad driver
+#endif
+#include linux/input/matrix_keypad.h
 
 struct omap_kp_platform_data {
int rows;
int cols;
-   int *keymap;
-   unsigned int keymapsize;
+   const struct matrix_keymap_data *keymap_data;
unsigned int rep:1;
unsigned long delay;
unsigned int dbounce:1;
@@ -28,18 +30,21 @@ struct omap_kp_platform_data {
 /* Group (0..3) -- when multiple keys are pressed, only the
  * keys pressed in the same group are considered as pressed. This is
  * in order to workaround certain crappy HW designs that produce ghost
- * keypresses. */
-#define GROUP_0(0  16)
-#define GROUP_1(1  16)
-#define GROUP_2(2  16)
-#define GROUP_3(3  16)
+ * keypresses. Two free bits, not used by neither row/col nor keynum,
+ * must be available for use as group bits. The below GROUP_SHIFT
+ * macro definition is based on some prior knowledge of the
+ * matrix_keypad defined KEY() macro internals.
+ */
+#define GROUP_SHIFT14
+#define GROUP_0(0  GROUP_SHIFT)
+#define GROUP_1(1  GROUP_SHIFT)
+#define GROUP_2(2  GROUP_SHIFT)
+#define GROUP_3(3  GROUP_SHIFT)
 #define GROUP_MASK GROUP_3
+#if KEY_MAX  GROUP_MASK
+#error Group bits in conflict with keynum bits
+#endif
 
-#define KEY_PERSISTENT 0x0080
-#define KEYNUM_MASK0x00EF
-#define KEY(col, row, val) (((col)  28) | ((row)  24) | (val))
-#define PERSISTENT_KEY(col, row) (((col)  28) | ((row)  24) | \
-   KEY_PERSISTENT)
 
 #endif
 
--- linux-2.6.37-rc5/include/linux/input/matrix_keypad.h.orig   2010-12-09 
23:09:05.0 +0100
+++ linux-2.6.37-rc5/include/linux/input/matrix_keypad.h2010-12-17 
03:13:28.0 +0100
@@ -9,7 +9,7 @@
 
 #define KEY(row, col, val) row)  (MATRIX_MAX_ROWS - 1))  24) |\
 (((col)  (MATRIX_MAX_COLS - 1))  16) |\
-(val  0x))
+((val)  0x))
 
 #define KEY_ROW(k) (((k)  24)  0xff)
 #define KEY_COL(k) (((k)  16)  0xff)
--- linux-2.6.37-rc5/drivers/input/keyboard/omap-keypad.c.orig  2010-12-09 
23:08:09.0 +0100
+++ linux-2.6.37-rc5/drivers/input/keyboard/omap-keypad.c   2010-12-16 
21:04:07.0 +0100
@@ -65,7 +65,6 @@ struct omap_kp {
 
 static DECLARE_TASKLET_DISABLED(kp_tasklet, omap_kp_tasklet, 0);
 
-static int *keymap;
 static unsigned int *row_gpios;
 static unsigned int *col_gpios;
 
@@ -162,20 +161,11 @@ static void omap_kp_scan_keypad(struct o
}
 }
 
-static inline int omap_kp_find_key(int col, int row)
-{
-   int i, key;
-
-   key = KEY(col, row, 0);
-   for (i = 0; keymap[i] != 0; i++)
-   if ((keymap[i]  0xff00) == key)
-   return keymap[i]  0x00ff;
-   return -1;
-}
-
 static void omap_kp_tasklet(unsigned long data)
 {

Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2

2010-12-17 Thread Kevin Hilman
Nishanth Menon n...@ti.com writes:

 Kevin Hilman had written, on 12/16/2010 12:57 PM, the following:
 Nishanth Menon n...@ti.com writes:

 Nishanth Menon had written, on 12/15/2010 06:05 PM, the following:
 Kevin Hilman had written, on 12/15/2010 05:47 PM, the following:

 I agree that this additional check in sram_idle should be removed, but
 as long as I handle it in omap3_pm_off_mode_enable where the next
 states are configured, is'nt that enough or am I missing something?
 Setting the next states only sets the default states, but CPUidle
 changes them.

 Looking closer at omap3_pm_off_mode_enable() though, it already calls
 into CPUidle and disables the valid bit for any states that have
 *either* MPU or core off.You'll probably just need to extend this
 approach to disable only CORE off state(s).
 Thx. it is clear now. let me see how to clean this up.
 k. Does the attached look any better now :)? 

 Yes, but, I still don't quite like it.  Basically, I'm not crazy about
 the errata knowledge being centralized in pm34xx.c.   How about this:

 Move the Errata handling core code (pm_errata_* PM_ERRATTA_*) to pm.[ch]
 as a single patch.  Then both pm34xx.c and cpuidle34xx.c would be free
 to use it.

 This would allow CPUidle handle the errata itself in the 'update_states'
 function.  Or even better, if CPUidle core can check this errata, it
 should probably just never register C7 in the first place, because it is
 *never* a valid C-state.

 Make sense?
 hmm.. IMHO at the problems themselves:
 a) cpuidle_params_table - this needs to become dynamically generated
 if you'd like cpuidle to not know about the existance of the invalid
 states at all(C7 has to disappear from it's radar - but extending it
 to a generic solution where an inbetween C state might be disabled as
 well)

 b) extending the problem further - cpu idle state latencies by
 themselves might vary between boards(PMIC variances causing delta in
 voltage setup times as an example).. I suppose we have some way to
 plug that data in as well? but irrelevant to this discussion. or maybe
 some board would like to have a customized additional c state which is
 not really practical for other platforms for what ever reasons..

 c) if cpuidle where to get pm errata info, it is nice thing to do,
 but, dont you think it is an overkill atm for just one errata?

 d) omap_init_power_states may need some cleanups as well.. too many =
 assignments IMHO..

 e) On the topic of argument that the states controlled by
 enable_off_mode is dynamic, though even though enable_off_mode is a
 variable, it is in debugfs - not really a dynamic variant in a
 product.. with that in mind, we may want to have off OR not have off
 mode in a product board file and folks would probably call
 omap3_pm_off_mode_enable or set the variable and set it to 1. That
 makes it even more crazy IMHO.

 f) Finally, where do we detect the erratas? it is more handy to have
 them in one place - pm34xx.c was chosen to make it independent of
 silicon type - pm44xx.c might endup having different set with it's own
 requirements - so not all together convinced it should be in
 pm.[ch]. I have tried to restrict the detection and usage purely to
 the file that needs it - pm34xx.c

 I think I agree to your overall thought that C state by itself
 should'nt have been registered, but would'nt it be better to do the
 cpuidle cleanups in a different context?

If you want to do all those cleanups, feel free.  They all are valid.

However, your patch targets an isolated problem, and I'm OK with an
isolated fix.

All I was suggesting is moving the PM errata detection/macros etc. into
pm.h, and doing somthing simple (below) in CPUidle.

Kevin

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 81b0a90..92873b4 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -452,6 +452,15 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C7].core_state = PWRDM_POWER_OFF;
omap3_power_states[OMAP3_STATE_C7].flags = CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_CHECK_BM;
+
+   /*
+* Erratum i583: implementation for ES rev  Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+   if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+   omap3_power_states[OMAP3_STATE_C7].valid = 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 0/7 v5] OMAP3: clean up ASM sleep code

2010-12-17 Thread Kevin Hilman
Hi Jean,

jean.pi...@newoldbits.com writes:

 From: Jean Pihet j-pi...@ti.com

 This patch only contains clean-ups and cosmetic changes,
 no functional change.

 Clean-up of the ASM sleep code, for better readability and
 easier maintenance.

 Applies on top of Nishant's latest idle path errata fixes step 2,
 cf. http://marc.info/?l=linux-omapm=129139584919242w=2

Can you do one more spin of this series in order to collect the
reviewed-by/tested-by tags posted, and address some of Nishanth's
comments.  Since we are reaching a merge window deadline, I'll leave it
to your discretion to decide which of Nishanth's suggestions to address
now and which to address later.

Kevin

 Jean Pihet (7):
   OMAP2+: use global values for the SRAM PA addresses
   OMAP3: remove hardcoded values from the ASM sleep code
   OMAP3: re-organize the ASM sleep code
   OMAP3: rework of the ASM sleep code execution paths
   OMAP3: add comments for low power code errata
   OMAP3: ASM sleep code format rework
   OMAP3: remove unused code from the ASM sleep code

  arch/arm/mach-omap2/control.c  |9 +-
  arch/arm/mach-omap2/control.h  |2 +
  arch/arm/mach-omap2/pm.h   |1 -
  arch/arm/mach-omap2/pm34xx.c   |4 +-
  arch/arm/mach-omap2/sdrc.h |1 -
  arch/arm/mach-omap2/sleep34xx.S|  724 
 +---
  arch/arm/plat-omap/include/plat/sram.h |   11 +
  arch/arm/plat-omap/sram.c  |7 +-
  8 files changed, 413 insertions(+), 346 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/7 v5] OMAP3: clean up ASM sleep code

2010-12-17 Thread Jean Pihet
Hi Kevin,

On Sat, Dec 18, 2010 at 12:02 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Hi Jean,

 jean.pi...@newoldbits.com writes:

 From: Jean Pihet j-pi...@ti.com

 This patch only contains clean-ups and cosmetic changes,
 no functional change.

 Clean-up of the ASM sleep code, for better readability and
 easier maintenance.

 Applies on top of Nishant's latest idle path errata fixes step 2,
 cf. http://marc.info/?l=linux-omapm=129139584919242w=2

 Can you do one more spin of this series in order to collect the
 reviewed-by/tested-by tags posted, and address some of Nishanth's
 comments.  Since we are reaching a merge window deadline, I'll leave it
 to your discretion to decide which of Nishanth's suggestions to address
 now and which to address later.
Sure I will post a new version tomorrow.
This will include some fixes after Nishant's comments. The rest can be
done later after we agree on the future changes.

Thanks,
Jean


 Kevin

 Jean Pihet (7):
   OMAP2+: use global values for the SRAM PA addresses
   OMAP3: remove hardcoded values from the ASM sleep code
   OMAP3: re-organize the ASM sleep code
   OMAP3: rework of the ASM sleep code execution paths
   OMAP3: add comments for low power code errata
   OMAP3: ASM sleep code format rework
   OMAP3: remove unused code from the ASM sleep code

  arch/arm/mach-omap2/control.c          |    9 +-
  arch/arm/mach-omap2/control.h          |    2 +
  arch/arm/mach-omap2/pm.h               |    1 -
  arch/arm/mach-omap2/pm34xx.c           |    4 +-
  arch/arm/mach-omap2/sdrc.h             |    1 -
  arch/arm/mach-omap2/sleep34xx.S        |  724 
 +---
  arch/arm/plat-omap/include/plat/sram.h |   11 +
  arch/arm/plat-omap/sram.c              |    7 +-
  8 files changed, 413 insertions(+), 346 deletions(-)

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


Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if ES1.2

2010-12-17 Thread Nishanth Menon

Kevin Hilman had written, on 12/17/2010 04:54 PM, the following:

Nishanth Menon n...@ti.com writes:


Kevin Hilman had written, on 12/16/2010 12:57 PM, the following:

Nishanth Menon n...@ti.com writes:


Nishanth Menon had written, on 12/15/2010 06:05 PM, the following:

Kevin Hilman had written, on 12/15/2010 05:47 PM, the following:


I agree that this additional check in sram_idle should be removed, but
as long as I handle it in omap3_pm_off_mode_enable where the next
states are configured, is'nt that enough or am I missing something?

Setting the next states only sets the default states, but CPUidle
changes them.

Looking closer at omap3_pm_off_mode_enable() though, it already calls
into CPUidle and disables the valid bit for any states that have
*either* MPU or core off.You'll probably just need to extend this
approach to disable only CORE off state(s).

Thx. it is clear now. let me see how to clean this up.
k. Does the attached look any better now :)? 

Yes, but, I still don't quite like it.  Basically, I'm not crazy about
the errata knowledge being centralized in pm34xx.c.   How about this:

Move the Errata handling core code (pm_errata_* PM_ERRATTA_*) to pm.[ch]
as a single patch.  Then both pm34xx.c and cpuidle34xx.c would be free
to use it.
This would allow CPUidle handle the errata itself in the 'update_states'
function.  Or even better, if CPUidle core can check this errata, it
should probably just never register C7 in the first place, because it is
*never* a valid C-state.

Make sense?

hmm.. IMHO at the problems themselves:
a) cpuidle_params_table - this needs to become dynamically generated
if you'd like cpuidle to not know about the existance of the invalid
states at all(C7 has to disappear from it's radar - but extending it
to a generic solution where an inbetween C state might be disabled as
well)

b) extending the problem further - cpu idle state latencies by
themselves might vary between boards(PMIC variances causing delta in
voltage setup times as an example).. I suppose we have some way to
plug that data in as well? but irrelevant to this discussion. or maybe
some board would like to have a customized additional c state which is
not really practical for other platforms for what ever reasons..

c) if cpuidle where to get pm errata info, it is nice thing to do,
but, dont you think it is an overkill atm for just one errata?

d) omap_init_power_states may need some cleanups as well.. too many =
assignments IMHO..

e) On the topic of argument that the states controlled by
enable_off_mode is dynamic, though even though enable_off_mode is a
variable, it is in debugfs - not really a dynamic variant in a
product.. with that in mind, we may want to have off OR not have off
mode in a product board file and folks would probably call
omap3_pm_off_mode_enable or set the variable and set it to 1. That
makes it even more crazy IMHO.

f) Finally, where do we detect the erratas? it is more handy to have
them in one place - pm34xx.c was chosen to make it independent of
silicon type - pm44xx.c might endup having different set with it's own
requirements - so not all together convinced it should be in
pm.[ch]. I have tried to restrict the detection and usage purely to
the file that needs it - pm34xx.c

I think I agree to your overall thought that C state by itself
should'nt have been registered, but would'nt it be better to do the
cpuidle cleanups in a different context?


If you want to do all those cleanups, feel free.  They all are valid.

However, your patch targets an isolated problem, and I'm OK with an
isolated fix.

All I was suggesting is moving the PM errata detection/macros etc. into
pm.h, and doing somthing simple (below) in CPUidle.

Kevin

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 81b0a90..92873b4 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -452,6 +452,15 @@ void omap_init_power_states(void)
omap3_power_states[OMAP3_STATE_C7].core_state = PWRDM_POWER_OFF;
omap3_power_states[OMAP3_STATE_C7].flags = CPUIDLE_FLAG_TIME_VALID |
CPUIDLE_FLAG_CHECK_BM;
+
+   /*
+* Erratum i583: implementation for ES rev  Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+   if (IS_PM34XX_ERRATUM(SDRC_WAKEUP_ERRATUM_i583)
+   omap3_power_states[OMAP3_STATE_C7].valid = 0;
+	
 }
 


Look at the following sequence:
a) omap_init_power_states is called at init 
omap3_power_states[OMAP3_STATE_C7].valid = 0
lets say we make cpuidle_params_table[OMAP3_STATE_C7].valid = 0 as well 
here.


b) user enables enable_off_mode
omap3_pm_off_mode_enable(pm34xx.c) - calls omap3_cpuidle_update_states
for (i = OMAP3_STATE_C1; i  OMAP3_MAX_STATES; i++) {
struct omap3_processor_cx *cx = omap3_power_states[i];

if (enable_off_mode) {

cx-valid = 

Re: [PATCH 0/7 v5] OMAP3: clean up ASM sleep code

2010-12-17 Thread Nishanth Menon

Jean Pihet had written, on 12/17/2010 05:07 PM, the following:

Hi Kevin,

On Sat, Dec 18, 2010 at 12:02 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:

Hi Jean,

jean.pi...@newoldbits.com writes:


From: Jean Pihet j-pi...@ti.com

This patch only contains clean-ups and cosmetic changes,
no functional change.

Clean-up of the ASM sleep code, for better readability and
easier maintenance.

Applies on top of Nishant's latest idle path errata fixes step 2,
cf. http://marc.info/?l=linux-omapm=129139584919242w=2

Can you do one more spin of this series in order to collect the
reviewed-by/tested-by tags posted, and address some of Nishanth's
comments.  Since we are reaching a merge window deadline, I'll leave it
to your discretion to decide which of Nishanth's suggestions to address
now and which to address later.

Sure I will post a new version tomorrow.
This will include some fixes after Nishant's comments. The rest can be
done later after we agree on the future changes.

Sounds good to me as well.. the minor cleanups should be easy to do..
will help with testing tomorrow on the new series if there are any 
functional changes. I will post out my revamped series as well 2morrow.



--
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] MTD: NAND: ams-delta: drop omap_read/write, use ioremap

2010-12-17 Thread Tony Lindgren
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [101215 06:44]:
 There is a common requirement for not using OMAP specific omap_readw() / 
 omap_writew() function calls in drivers/, but replace them with 
 readw() / writew() on ioremap()ped addresses passed from arch/ instead.
 
 The patch implements this idea for the Amstrad Delta NAND driver. To be 
 able to use the modified driver, the board file is updated with the 
 platform device I/O resource declaration, which is passed from there.
 
 Created and tested against linux-2.6.37-rc5, on top of recent patch 
 'MTD: NAND: ams-delta: convert to platform driver'.

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


Re: [PATCH 1/7] omap3630: nand: fix device size to work in polled mode

2010-12-17 Thread Tony Lindgren
* Sukumar Ghorai s-gho...@ti.com [101126 07:25]:
 zoom3 and 3630-sdp having the x16 nand device.
 This patch configure gpmc as x16 and select the currect function in driver
 for polled mode (without prefetch enable) transfer.
 
 Signed-off-by: Sukumar Ghorai s-gho...@ti.com
 ---
  arch/arm/mach-omap2/board-flash.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-flash.c 
 b/arch/arm/mach-omap2/board-flash.c
 index fd38c05..001c605 100644
 --- a/arch/arm/mach-omap2/board-flash.c
 +++ b/arch/arm/mach-omap2/board-flash.c
 @@ -145,6 +145,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, 
 u8 nr_parts, u8 cs)
   board_nand_data.parts   = nand_parts;
   board_nand_data.nr_parts= nr_parts;
  
 + if (cpu_is_omap3630())
 + board_nand_data.devsize = 1;
 +
   gpmc_nand_init(board_nand_data);
  }
  #else

I guess this is board specific for the size, not omap specific?

Regards,

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


Re: [PATCH 2/7] omap3: nand: configurable transfer type per board

2010-12-17 Thread Tony Lindgren
* Sukumar Ghorai s-gho...@ti.com [101126 07:25]:
 nand transfer type (sDMA, Polled, prefetch) can be select from board file,
 enabling all transfer type in driver, by default.
 
 this helps in multi-omap build and to select different transfer type for
 different board.
 
 Signed-off-by: Sukumar Ghorai s-gho...@ti.com
 ---
  arch/arm/plat-omap/include/plat/nand.h |7 +++
  drivers/mtd/nand/Kconfig   |   17 --
  drivers/mtd/nand/omap2.c   |   92 +++
  3 files changed, 40 insertions(+), 76 deletions(-)
 
 diff --git a/arch/arm/plat-omap/include/plat/nand.h 
 b/arch/arm/plat-omap/include/plat/nand.h
 index 6562cd0..78c0bdb 100644
 --- a/arch/arm/plat-omap/include/plat/nand.h
 +++ b/arch/arm/plat-omap/include/plat/nand.h
 @@ -10,6 +10,12 @@
  
  #include linux/mtd/partitions.h
  
 +enum nand_io {
 + NAND_OMAP_PREFETCH_POLLED = 0,  /* prefetch polled mode, default */
 + NAND_OMAP_POLLED,   /* polled mode, without prefetch */
 + NAND_OMAP_PREFETCH_DMA  /* prefetch enabled sDMA mode */
 +};
 +
  struct omap_nand_platform_data {
   unsigned intoptions;
   int cs;
 @@ -20,6 +26,7 @@ struct omap_nand_platform_data {
   int (*nand_setup)(void);
   int (*dev_ready)(struct omap_nand_platform_data *);
   int dma_channel;
 + enum nand_ioxfer_type;
   unsigned long   phys_base;
   int devsize;
  };

So maybe the devsize in patch 1/7 should be handled with this too?

Regards,

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


Re: [PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc

2010-12-17 Thread Tony Lindgren
* Sukumar Ghorai s-gho...@ti.com [101126 07:25]:
 add support the irq mode in GPMC.
 gpmc_init() function move after omap_init_irq() as it has dependecy on irq.
 
 Signed-off-by: Sukumar Ghorai s-gho...@ti.com
 ---
  arch/arm/mach-omap2/board-2430sdp.c|1 +
  arch/arm/mach-omap2/board-3430sdp.c|1 +
  arch/arm/mach-omap2/board-3630sdp.c|1 +
  arch/arm/mach-omap2/board-4430sdp.c|2 +
  arch/arm/mach-omap2/board-am3517evm.c  |2 +
  arch/arm/mach-omap2/board-apollon.c|1 +
  arch/arm/mach-omap2/board-cm-t35.c |1 +
  arch/arm/mach-omap2/board-devkit8000.c |1 +
  arch/arm/mach-omap2/board-generic.c|2 +
  arch/arm/mach-omap2/board-h4.c |1 +
  arch/arm/mach-omap2/board-igep0020.c   |1 +
  arch/arm/mach-omap2/board-ldp.c|1 +
  arch/arm/mach-omap2/board-n8x0.c   |2 +
  arch/arm/mach-omap2/board-omap3beagle.c|1 +
  arch/arm/mach-omap2/board-omap3evm.c   |2 +
  arch/arm/mach-omap2/board-omap3pandora.c   |2 +
  arch/arm/mach-omap2/board-omap3stalker.c   |1 +
  arch/arm/mach-omap2/board-omap3touchbook.c |1 +
  arch/arm/mach-omap2/board-omap4panda.c |2 +
  arch/arm/mach-omap2/board-overo.c  |1 +
  arch/arm/mach-omap2/board-rx51.c   |1 +
  arch/arm/mach-omap2/board-zoom2.c  |2 +
  arch/arm/mach-omap2/board-zoom3.c  |2 +
  arch/arm/mach-omap2/gpmc.c |   39 ++-
  arch/arm/mach-omap2/io.c   |2 -
  arch/arm/plat-omap/include/plat/gpmc.h |4 +++
  arch/arm/plat-omap/include/plat/irqs.h |9 +-
  27 files changed, 81 insertions(+), 5 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
 b/arch/arm/mach-omap2/board-2430sdp.c
 index b527f8d..11c89dc 100644
 --- a/arch/arm/mach-omap2/board-2430sdp.c
 +++ b/arch/arm/mach-omap2/board-2430sdp.c
 @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void)
   omap_board_config_size = ARRAY_SIZE(sdp2430_config);
   omap2_init_common_hw(NULL, NULL);
   omap_init_irq();
 + gpmc_init();
   omap_gpio_init();
  }
  
 diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
 b/arch/arm/mach-omap2/board-3430sdp.c
 index 4e3742c..a040165 100644
 --- a/arch/arm/mach-omap2/board-3430sdp.c
 +++ b/arch/arm/mach-omap2/board-3430sdp.c
 @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
   omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
   omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
   omap_init_irq();
 + gpmc_init();
   omap_gpio_init();
  }
...

The gpmc init should be done with subsys_initcall instead.

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


Re: [PATCH v6 0/12] dmtimer adaptation to platform_driver

2010-12-17 Thread Tony Lindgren
* Tarun Kanti DebBarma tarun.ka...@ti.com [101214 09:03]:
 dmtimer adaptation to platform_driver.
 
 This patch series is adaptation of dmtimer code to platform driver
 using omap_device and omap_hwmod abstraction.
 
 Tested on following platforms:
 OMAP4430, OMAP3430, OMAP3630, OMAP2430
 OMAP2420, OMAP1710(in-progress)

Looks like this we need to wait on for 2.6.39 merge window to
get all the needed testing done.

With the pending GPIO and DMA changes we are already struggling
to have them tested properly and I'm not planning on merging any more
intrusive code for this merge window after the we get the DMA
changes in hopefully today.

Regards,

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


Re: [PATCH 2/2] arm: mach-omap2: Kconfig: devkit8000 should select needed options

2010-12-17 Thread Tony Lindgren
* Aaro Koskinen aaro.koski...@nokia.com [101217 04:41]:
 Hi,
 
 On Wed, 15 Dec 2010, Tony Lindgren wrote:
 * Aaro Koskinen aaro.koski...@nokia.com [101215 04:48]:
 It's not possible to compile a kernel for this board without I2C,
 MFD_SUPPORT and TWL4030_CORE, so those should be selected. This will
 prevent build errors when trying out different configurations.
 
 This one I'm not so convinced about. We should be able to compile
 support for each board and enable and disable these kind of options
 just fine if CONFIG_ARCH_OMAP2PLUS_TYPICAL is disabled.
 
 So in this case we should move the stuff with special dependencies from
 the board file into e.g. board-devkit8000-peripherals, which would be
 a kernel module?

Or how about just have them in ifdef CONFIG_I2C_OMAP and TWL4030_CORE
in the board-devkit8000.c file?

Regards,

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


Re: [PATCH 1/3] omap: rx51: Remove __initdata from rx51_tpa6130a2_data

2010-12-17 Thread Tony Lindgren
* Jarkko Nikula jhnik...@gmail.com [101217 11:16]:
 If the TPA6130 is compiled as module the id and power_gpio values are
 arbitrary at module probing time since the rx51_tpa6130a2_data was marked as
 __initdata.
 
 Signed-off-by: Jarkko Nikula jhnik...@gmail.com
 ---
 For 2.6.38 as the TPA6130 is not used in 2.6.37.
 ---
  arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
 b/arch/arm/mach-omap2/board-rx51-peripherals.c
 index 126b724..cde6847 100644
 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
 +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
 @@ -719,7 +719,7 @@ static struct twl4030_platform_data rx51_twldata 
 __initdata = {
   .vio= rx51_vio,
  };
  
 -static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
 +static struct tpa6130a2_platform_data rx51_tpa6130a2_data = {
   .id = TPA6130A2,
   .power_gpio = 98,
  };

How about __initdata_or_module instead of __initdata?

Regards,

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


Re: [RFC PATCHv4 2/7] HSI: omap_ssi: Introducing OMAP SSI driver

2010-12-17 Thread Tony Lindgren
* Carlos Chinea carlos.chi...@nokia.com [101214 02:13]:
 Introduces the OMAP SSI driver in the kernel.
 
 The Synchronous Serial Interface (SSI) is a legacy version
 of HSI. As in the case of HSI, it is mainly used to connect
 Application engines (APE) with cellular modem engines (CMT)
 in cellular handsets.
 
 It provides a multichannel, full-duplex, multi-core communication
 with no reference clock. The OMAP SSI block is capable of reaching
 speeds of 110 Mbit/s.
...

 +static int __init ssi_init(void)
 +{
 + return platform_device_register(ssi_pdev);
 +}
 +subsys_initcall(ssi_init);

Is this safe to do for all omaps2+ machines?

Regards,

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


Re: [PATCH 1/2] Added video data to support tvout on rx51

2010-12-17 Thread Tony Lindgren
* Srikar ext-srikar.1.bhavanaray...@nokia.com [101125 07:43]:
 To support tvout on rx51,added Intilization data,
 tvout as display device and enabled venc through gpio
 on rx51

Only taking the first one, looks like the second one
has some pending comments.

Regards,

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


Re: [PATCH] OMAP3: add comments for erratas i540 and i478 workarounds

2010-12-17 Thread Tony Lindgren
* Jean Pihet jean.pi...@newoldbits.com [101117 09:44]:
 From: Jean Pihet jean.pi...@newoldbits.com
 
 Add comments and IDs for the following erratas:
 - i540: MPU cannot exit from Standby,
 - i478: Unexpected Cold-Reset is generated when device is coming
back from OFF mode

Applying thanks.

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


Re: [PATCH v3 0/4] Introduce hardware spinlock framework

2010-12-17 Thread Tony Lindgren
* Ohad Ben-Cohen o...@wizery.com [101216 13:34]:
 On Thu, Dec 16, 2010 at 11:08 PM, Greg KH g...@kroah.com wrote:
   I've seen a lot of discussion about this, are all of the review comments
   now addressed?
 
  Yes, all comments were addressed in this v3 iteration, and this thread
  has been idle for about 10 days.
 
  That's because we are all busy with other things :(
 
 Oh sure, my intention was only positive (to demonstrate that there are
 no outstanding comments), sorry if it sounded differently than
 intended.
 
  Sorry, I really don't have the time at the moment to review this code,
  nor does it seem to affect areas that I maintain, so I don't understand
  what you are looking for from me.
 
 Sorry for the noise - I contacted you because you maintain the driver
 core, in the hope you could suggest where this can go through.
 
 Tony, Andrew, can you please have a look ?
 
 Any comment or suggestion is appreciated.

Looks sane to me from omap point of view and it seems the locks
are now all timeout based:

Acked-by: Tony Lindgren t...@atomide.com

Regards,

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


[PATCH 1/3] OMAP2+: powerdomain: add API to get context loss count

2010-12-17 Thread Kevin Hilman
Add new powerdomain API

u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)

for checking how many times the powerdomain has lost context.  The
loss count is the sum sum of the powerdomain off-mode counter, the
logic off counter and the per-bank memory off counter.

Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/powerdomain.c |   26 ++
 arch/arm/mach-omap2/powerdomain.h |1 +
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c 
b/arch/arm/mach-omap2/powerdomain.c
index 06ef60e..b147a82 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -909,3 +909,29 @@ int pwrdm_post_transition(void)
pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
 }
+
+/**
+ * pwrdm_get_context_loss_count - get powerdomain's context loss count
+ * @pwrdm: struct powerdomain * to wait for
+ *
+ * Context loss count is a sum of powerdomain off-mode counter,
+ * the logic off counter and the per-bank memory off counter.
+ */
+u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+{
+   int i, count;
+
+   if (!pwrdm)
+   return -EINVAL;
+
+   count = pwrdm-state_counter[PWRDM_POWER_OFF];
+   count += pwrdm-ret_logic_off_counter;
+
+   for (i = 0; i  pwrdm-banks; i++)
+   count += pwrdm-ret_mem_off_counter[i];
+
+   pr_debug(powerdomain: %s: context loss count = %u\n,
+pwrdm-name, count);
+
+   return count;
+}
diff --git a/arch/arm/mach-omap2/powerdomain.h 
b/arch/arm/mach-omap2/powerdomain.h
index 35b5b48..c66431e 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -211,6 +211,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
 int pwrdm_pre_transition(void);
 int pwrdm_post_transition(void);
 int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
+u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
 
 extern void omap2xxx_powerdomains_init(void);
 extern void omap3xxx_powerdomains_init(void);
-- 
1.7.2.1

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


[PATCH 3/3] OMAP: PM noop: implement context loss count for non-omap_devices

2010-12-17 Thread Kevin Hilman
For devices which have not (yet) been converted to use omap_device,
implement the context loss counter using the brutal method as
originally proposed by Paul Walmsley[1].

The dummy context loss counter is incremented every time it is
checked, but only when off-mode is enabled.  When off-mode is
disabled, the dummy counter stops incrementing.

Tested on 36xx/Zoom3 using MMC driver, which is currently the
only in-tree user of this API.

This patch should be reverted after all devices are converted to using
omap_device.

[1] http://marc.info/?l=linux-omapm=12917626626w=2

Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/pm-debug.c|5 
 arch/arm/plat-omap/include/plat/omap-pm.h |2 +
 arch/arm/plat-omap/omap-pm-noop.c |   38 +++-
 3 files changed, 43 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index e535082..125f565 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -32,6 +32,7 @@
 #include powerdomain.h
 #include clockdomain.h
 #include plat/dmtimer.h
+#include plat/omap-pm.h
 
 #include cm2xxx_3xxx.h
 #include prm2xxx_3xxx.h
@@ -581,6 +582,10 @@ static int option_set(void *data, u64 val)
*option = val;
 
if (option == enable_off_mode) {
+   if (val)
+   omap_pm_enable_off_mode();
+   else
+   omap_pm_disable_off_mode();
if (cpu_is_omap34xx())
omap3_pm_off_mode_enable(val);
}
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h 
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 2f0bee8..6242b25 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -372,5 +372,7 @@ unsigned long omap_pm_cpu_get_freq(void);
  */
 u32 omap_pm_get_dev_context_loss_count(struct device *dev);
 
+void omap_pm_enable_off_mode(void);
+void omap_pm_disable_off_mode(void);
 
 #endif
diff --git a/arch/arm/plat-omap/omap-pm-noop.c 
b/arch/arm/plat-omap/omap-pm-noop.c
index f7d1307..12b2bfe 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -30,6 +30,9 @@ struct omap_opp *dsp_opps;
 struct omap_opp *mpu_opps;
 struct omap_opp *l3_opps;
 
+static bool off_mode_enabled;
+static u32 dummy_context_loss_counter;
+
 /*
  * Device-driver-originated constraints (via board-*.c files)
  */
@@ -284,10 +287,31 @@ unsigned long omap_pm_cpu_get_freq(void)
return 0;
 }
 
+/**
+ * omap_pm_enable_off_mode - notify OMAP PM that off-mode is enabled
+ *
+ * Intended for use only by OMAP PM core code to notify this layer
+ * that off mode has been enabled.
+ */
+void omap_pm_enable_off_mode(void)
+{
+   off_mode_enabled = true;
+}
+
+/**
+ * omap_pm_disable_off_mode - notify OMAP PM that off-mode is disabled
+ *
+ * Intended for use only by OMAP PM core code to notify this layer
+ * that off mode has been disabled.
+ */
+void omap_pm_disable_off_mode(void)
+{
+   off_mode_enabled = false;
+}
+
 /*
  * Device context loss tracking
  */
-
 u32 omap_pm_get_dev_context_loss_count(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
@@ -296,7 +320,17 @@ u32 omap_pm_get_dev_context_loss_count(struct device *dev)
if (WARN_ON(!dev))
return 0;
 
-   count = omap_device_get_context_loss_count(pdev);
+   if (dev-parent == omap_device_parent) {
+   count = omap_device_get_context_loss_count(pdev);
+   } else {
+   WARN_ONCE(off_mode_enabled, using dummy context loss counter, 
+ device %s should be converted to omap_device.,
+ __func__, dev_name(dev));
+   if (off_mode_enabled)
+   dummy_context_loss_counter++;
+   count = dummy_context_loss_counter;
+   }
+
pr_debug(OMAP PM: context loss count for dev %s = %d\n,
 dev_name(dev), count);
 
-- 
1.7.2.1

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


[PATCH 2/3] OMAP: PM: implement context loss count APIs

2010-12-17 Thread Kevin Hilman
Implement OMAP PM layer omap_pm_get_dev_context_loss_count() API by
creating similar APIs at the omap_device and omap_hwmod levels.  The
omap_hwmod level call is the layer with access to the powerdomain
core, so it is the place where the powerdomain is queried to get the
context loss count.

The new APIs return an unsigned value that can wrap as the
context-loss count grows.  However, the wrapping is not important as
the role of this function is to determine context loss by checking for
any difference in subsequent calls to this function.

Note that these APIs at each level can return zero when no context
loss is detected, or on errors.  This is to avoid returning error
codes which could potentially be mistaken for large context loss
counters.

NOTE: only works for devices which have been converted to use
  omap_device/omap_hwmod.

Longer term, we could possibly remove this API from the OMAP PM layer,
and instead directly use the omap_device level API.

Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
 arch/arm/mach-omap2/omap_hwmod.c  |   22 +++
 arch/arm/plat-omap/include/plat/omap-pm.h |4 +-
 arch/arm/plat-omap/include/plat/omap_device.h |1 +
 arch/arm/plat-omap/include/plat/omap_hwmod.h  |1 +
 arch/arm/plat-omap/omap-pm-noop.c |   23 +--
 arch/arm/plat-omap/omap_device.c  |   28 +
 6 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 81c1097..08da0f3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2220,3 +2220,25 @@ ohsps_unlock:
 
return ret;
 }
+
+/**
+ * omap_hwmod_get_context_loss_count - get lost context count
+ * @oh: struct omap_hwmod *
+ *
+ * Query the powerdomain of of @oh to get the context loss
+ * count for this device.
+ *
+ * Returns the context loss count of the powerdomain assocated with @oh
+ * upon success, or zero if no powerdomain exists for @oh.
+ */
+u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
+{
+   struct powerdomain *pwrdm;
+   int ret = 0;
+
+   pwrdm = omap_hwmod_get_pwrdm(oh);
+   if (pwrdm)
+   ret = pwrdm_get_context_loss_count(pwrdm);
+
+   return ret;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h 
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 9870b4f..2f0bee8 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -368,9 +368,9 @@ unsigned long omap_pm_cpu_get_freq(void);
  * driver must restore device context.   If the number of context losses
  * exceeds the maximum positive integer, the function will wrap to 0 and
  * continue counting.  Returns the number of context losses for this device,
- * or -EINVAL upon error.
+ * or zero upon error.
  */
-int omap_pm_get_dev_context_loss_count(struct device *dev);
+u32 omap_pm_get_dev_context_loss_count(struct device *dev);
 
 
 #endif
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..e4c349f 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -107,6 +107,7 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);
 int omap_device_align_pm_lat(struct platform_device *pdev,
 u32 new_wakeup_lat_limit);
 struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
+u32 omap_device_get_context_loss_count(struct platform_device *pdev);
 
 /* Other */
 
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 62bdb23..3fdb574 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -568,6 +568,7 @@ int omap_hwmod_for_each_by_class(const char *classname,
 void *user);
 
 int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state);
+u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
 
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/plat-omap/omap-pm-noop.c 
b/arch/arm/plat-omap/omap-pm-noop.c
index 7578366..f7d1307 100644
--- a/arch/arm/plat-omap/omap-pm-noop.c
+++ b/arch/arm/plat-omap/omap-pm-noop.c
@@ -20,9 +20,11 @@
 #include linux/init.h
 #include linux/cpufreq.h
 #include linux/device.h
+#include linux/platform_device.h
 
 /* Interface documentation is in mach/omap-pm.h */
 #include plat/omap-pm.h
+#include plat/omap_device.h
 
 struct omap_opp *dsp_opps;
 struct omap_opp *mpu_opps;
@@ -286,22 +288,19 @@ unsigned long omap_pm_cpu_get_freq(void)
  * Device context loss tracking
  */
 
-int omap_pm_get_dev_context_loss_count(struct device *dev)
+u32 omap_pm_get_dev_context_loss_count(struct device *dev)
 {
-   if (!dev) {
-   WARN_ON(1);

[APPLIED] [PATCH] OMAP: kill all section mismatch warning for

2010-12-17 Thread Tony Lindgren
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: devel-cleanup

Initial commit ID (Likely to change): 1a6b59232bbaf612265e364c9e06ba1d15bbe7e0

PatchWorks
http://patchwork.kernel.org/patch/389482/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=1a6b59232bbaf612265e364c9e06ba1d15bbe7e0


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


Re: [PATCH] OMAP: kill all section mismatch warning for omap2plus_defconfig

2010-12-17 Thread Tony Lindgren
* Bryan Wu bryan...@canonical.com [101207 18:31]:
 This patch will kill following section mismatch warnings:
...

 --- a/arch/arm/mach-omap2/board-2430sdp.c
 +++ b/arch/arm/mach-omap2/board-2430sdp.c
 @@ -135,7 +135,7 @@ static inline void board_smc91x_init(void)
  
  #endif
  
 -static struct omap_board_config_kernel sdp2430_config[] = {
 +static struct omap_board_config_kernel sdp2430_config[] __initdata = {
   {OMAP_TAG_LCD, sdp2430_lcd_config},
  };
  

Thanks merging this. Note that the OMAP_TAG_LCD stuff should be
replaced with just platform_data.

Regards,

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


[APPLIED] [PATCH] OMAP4: enable smc instruction in new assembler versions

2010-12-17 Thread Tony Lindgren
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.

Branch in linux-omap: devel-cleanup

Initial commit ID (Likely to change): fe297dde5ae8f8bf67d3a87759289a99b48ecb2c

PatchWorks
http://patchwork.kernel.org/patch/369681/

Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=fe297dde5ae8f8bf67d3a87759289a99b48ecb2c


--
To unsubscribe from this list: send the line unsubscribe 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] OMAP4: enable smc instruction in new assembler versions

2010-12-17 Thread Tony Lindgren
* John Rigby john.ri...@linaro.org [101130 21:49]:
 New assemblers need -march=armv7-a+sec on command line or
 .arch_extension sec inline to enable use of the smc instruction.
 
 This patch uses as-instr to check the latter to conditionally
 enable the former in AFLAGS for files that use smc.
 
 Checked on both old and new binutils to verify that it does
 not break old versions.

Thanks applying.

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


Re: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor

2010-12-17 Thread Tony Lindgren
* Hemanth V heman...@ti.com [101212 22:08]:
 - Original Message - From: Hemanth V heman...@ti.com
 To: linux-omap@vger.kernel.org
 Sent: Thursday, December 02, 2010 12:59 PM
 Subject: [PATCH 1/3] omap4: Add platform changes for Ambient Light sensor
 
 
 From 10f5f9f918e197f4052ac66b4e4cfb4b72646878 Mon Sep 17 00:00:00 2001
 From: Hemanth V heman...@ti.com
 Date: Wed, 1 Dec 2010 16:28:51 +0530
 Subject: [PATCH] omap4: Add platform changes for Ambient Light sensor
 
 Register BH1780GLI Ambient light sensor, which is an I2C device
 for 4430SDP board.
 
 Tony, would you be pulling these patches for the next merge window.

Yes taking the first two, will ack the third as the header is not
in the mainline kernel.

Regards,

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


Re: [RESEND] [PATCH 3/3] omap4: Platform changes for CMA3000 Accelerometer driver

2010-12-17 Thread Tony Lindgren
* Hemanth V heman...@ti.com [101201 23:34]:
 Pl ignore the earlier patch, which seems to have rebasing issues.
 
 Thanks
 Hemanth
 
 From 42cb400c1bd3878977bc8fd416c9c39f81bed674 Mon Sep 17 00:00:00 2001
 From: Hemanth V heman...@ti.com
 Date: Thu, 2 Dec 2010 12:44:19 +0530
 Subject: [PATCH] omap4: Platform changes for CMA3000 Accelerometer driver
 
 Update 4430 SDP board file with platform data for accelerometer driver
 
 Signed-off-by: Hemanth V heman...@ti.com
 ---
 CMA3000 Driver is queued up for 2.6.38 merge window
 
  arch/arm/mach-omap2/board-4430sdp.c |   30 ++
  1 files changed, 30 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index ea56c30..6bda335 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -24,6 +24,8 @@
  #include linux/regulator/machine.h
  #include linux/leds.h
  #include linux/leds_pwm.h
 +#include linux/input/cma3000.h
 +#include linux/interrupt.h
 
  #include mach/hardware.h
  #include mach/omap4-common.h

This you should send via the input list along with the cma3000
driver:

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


Re: [PATCH] omap: remove dead wdt code in plat-omap/devices.c

2010-12-17 Thread Tony Lindgren
* Anand Gadiyar gadi...@ti.com [101203 09:17]:
 Commit f2ce62312650 (OMAP: WDT: Split OMAP1 and OMAP2PLUS device
 registration) removed omap_init_wdt and related structures from
 plat-omap/devices.c. However a subsequent commit or merge
 seems to have reintroduced these by accident. The caller of
 omap_init_wdt was also removed by that commit, and this did
 not get restored. So we have the following build warning now:
 
   CC  arch/arm/plat-omap/devices.o
 arch/arm/plat-omap/devices.c:252: warning: 'omap_init_wdt' defined but not 
 used
 
 Fix this by removing this dead code.
 
 Signed-off-by: Anand Gadiyar gadi...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 ---
 Couldn't figure out which commit reintroduced this code - git blame
 only points to the original commits that added the code years ago.
 
 I suspect it's the DSP bridge commits that got merged via staging.
 
 If someone can debug this mystery for me, that'd be nice.

Thanks applying. Looks like it was added back by mismerge in
e4c5bf8e3dca827a1b3a6fac494eae8c74b7e1e7 (Merge 'staging-next'
into Linus's tree).

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


Re: [PATCH v2 resend] OMAP4: Pandaboard: Add omap_reserve functionality

2010-12-17 Thread Tony Lindgren
* Raghuveer Murthy raghuveer.mur...@ti.com [101207 23:31]:
 This patch adds omap_reserve functionality to board-omap4panda.c.
 Helps in the reserving boot time memory in SDRAM, used here for
 framebuffer allocation.
 
 This patch is in similar lines to commit id 71ee7dad9b6991, from
 Russell king
 
 Cc: Russell King rmk+ker...@arm.linux.org.uk
 Cc: linux-arm-ker...@lists.infradead.org
 Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com
 ---
  arch/arm/mach-omap2/board-omap4panda.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
 b/arch/arm/mach-omap2/board-omap4panda.c
 index da24745..0ccc24f 100644
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
   /* Maintainer: David Anders - Texas Instruments Inc */
   .boot_params= 0x8100,
   .map_io = omap4_panda_map_io,
 + .reserve= omap_reserve,
   .init_irq   = omap4_panda_init_irq,
   .init_machine   = omap4_panda_init,
   .timer  = omap_timer,

Thanks applying.

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


[PATCH 0/6] Misc omap board patches for v2.6.38 merge window

2010-12-17 Thread Tony Lindgren
Hi,

The following set contains some patches for the v2.6.38 merge window.

Regards,

Tony

---

Hemanth V (2):
  omap4: Add platform changes for Ambient Light sensor
  omap4: Add platform changes for PWM LED

Laurent Pinchart (2):
  omap3: igepv2: Don't call gpio_set_value right aftergpio_direction_output
  omap3: igepv2: LED gpio-led:green:d1 is active low

Raghuveer Murthy (1):
  OMAP4: Pandaboard: Add omap_reserve functionality

Tony Lindgren (1):
  omap1: Fix innovator FPGA init for multi-omap


 arch/arm/mach-omap1/board-innovator.c  |7 ++-
 arch/arm/mach-omap1/fpga.c |   10 ++
 arch/arm/mach-omap2/board-4430sdp.c|   27 +++
 arch/arm/mach-omap2/board-igep0020.c   |   21 +
 arch/arm/mach-omap2/board-omap4panda.c |1 +
 arch/arm/plat-omap/include/plat/fpga.h |4 
 6 files changed, 45 insertions(+), 25 deletions(-)

-- 
Signature
--
To unsubscribe from this list: send the line unsubscribe 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/6] omap1: Fix innovator FPGA init for multi-omap

2010-12-17 Thread Tony Lindgren
No need to call this early from init_irq. Also recent changes
initialize GPIO now later, so calling gpio_request from init_irq
will make it fail.

While at it, also remove the unnecessary EXPORT_SYMBOL.

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap1/board-innovator.c  |7 ++-
 arch/arm/mach-omap1/fpga.c |   10 ++
 arch/arm/plat-omap/include/plat/fpga.h |4 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap1/board-innovator.c 
b/arch/arm/mach-omap1/board-innovator.c
index a051acd..8d59b07 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -290,11 +290,6 @@ static void __init innovator_init_irq(void)
 {
omap1_init_common_hw();
omap_init_irq();
-#ifdef CONFIG_ARCH_OMAP15XX
-   if (cpu_is_omap1510()) {
-   omap1510_fpga_init_irq();
-   }
-#endif
 }
 
 #ifdef CONFIG_ARCH_OMAP15XX
@@ -385,6 +380,8 @@ static struct omap_board_config_kernel innovator_config[] = 
{
 
 static void __init innovator_init(void)
 {
+   if (cpu_is_omap1510())
+   omap1510_fpga_init_irq();
innovator_init_smc91x();
 
 #ifdef CONFIG_ARCH_OMAP15XX
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index 5cfce16..8780e75 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -143,7 +143,7 @@ static struct irq_chip omap_fpga_irq = {
  */
 void omap1510_fpga_init_irq(void)
 {
-   int i;
+   int i, res;
 
__raw_writeb(0, OMAP1510_FPGA_IMR_LO);
__raw_writeb(0, OMAP1510_FPGA_IMR_HI);
@@ -177,10 +177,12 @@ void omap1510_fpga_init_irq(void)
 * NOTE: For general GPIO/MPUIO access and interrupts, please see
 * gpio.[ch]
 */
-   gpio_request(13, FPGA irq);
+   res = gpio_request(13, FPGA irq);
+   if (res) {
+   pr_err(%s failed to get gpio\n, __func__);
+   return;
+   }
gpio_direction_input(13);
set_irq_type(gpio_to_irq(13), IRQ_TYPE_EDGE_RISING);
set_irq_chained_handler(OMAP1510_INT_FPGA, innovator_fpga_IRQ_demux);
 }
-
-EXPORT_SYMBOL(omap1510_fpga_init_irq);
diff --git a/arch/arm/plat-omap/include/plat/fpga.h 
b/arch/arm/plat-omap/include/plat/fpga.h
index f1864a6..ae39bcb 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -19,11 +19,7 @@
 #ifndef __ASM_ARCH_OMAP_FPGA_H
 #define __ASM_ARCH_OMAP_FPGA_H
 
-#if defined(CONFIG_MACH_OMAP_INNOVATOR)  defined(CONFIG_ARCH_OMAP15XX)
 extern void omap1510_fpga_init_irq(void);
-#else
-#define omap1510_fpga_init_irq()   (0)
-#endif
 
 #define fpga_read(reg) __raw_readb(reg)
 #define fpga_write(val, reg)   __raw_writeb(val, reg)

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


[PATCH 2/6] OMAP4: Pandaboard: Add omap_reserve functionality

2010-12-17 Thread Tony Lindgren
From: Raghuveer Murthy raghuveer.mur...@ti.com

This patch adds omap_reserve functionality to board-omap4panda.c.
Helps in the reserving boot time memory in SDRAM, used here for
framebuffer allocation.

This patch is in similar lines to commit id 71ee7dad9b6991, from
Russell king

Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-omap4panda.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 38f942b..9f49e23 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -407,6 +407,7 @@ MACHINE_START(OMAP4_PANDA, OMAP4 Panda board)
/* Maintainer: David Anders - Texas Instruments Inc */
.boot_params= 0x8100,
.map_io = omap4_panda_map_io,
+   .reserve= omap_reserve,
.init_irq   = omap4_panda_init_irq,
.init_machine   = omap4_panda_init,
.timer  = omap_timer,

--
To unsubscribe from this list: send the line unsubscribe 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/6] omap3: igepv2: Don't call gpio_set_value right aftergpio_direction_output

2010-12-17 Thread Tony Lindgren
From: Laurent Pinchart laurent.pinch...@ideasonboard.com

gpio_direction_output() has a value argument, there's no need to call
gpio_set_value() explicitly right after.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |   20 
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 3bee9a1..77e2db7 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -377,24 +377,21 @@ static void __init igep2_leds_init(void)
 static inline void igep2_leds_init(void)
 {
if ((gpio_request(IGEP2_GPIO_LED0_RED, gpio-led:red:d0) == 0) 
-   (gpio_direction_output(IGEP2_GPIO_LED0_RED, 1) == 0)) {
+   (gpio_direction_output(IGEP2_GPIO_LED0_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_RED, 0);
-   gpio_set_value(IGEP2_GPIO_LED0_RED, 0);
-   } else
+   else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_RED\n);
 
if ((gpio_request(IGEP2_GPIO_LED0_GREEN, gpio-led:green:d0) == 0) 
-   (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 1) == 0)) {
+   (gpio_direction_output(IGEP2_GPIO_LED0_GREEN, 0) == 0))
gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
-   gpio_set_value(IGEP2_GPIO_LED0_GREEN, 0);
-   } else
+   else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED0_GREEN\n);
 
if ((gpio_request(IGEP2_GPIO_LED1_RED, gpio-led:red:d1) == 0) 
-   (gpio_direction_output(IGEP2_GPIO_LED1_RED, 1) == 0)) {
+   (gpio_direction_output(IGEP2_GPIO_LED1_RED, 0) == 0))
gpio_export(IGEP2_GPIO_LED1_RED, 0);
-   gpio_set_value(IGEP2_GPIO_LED1_RED, 0);
-   } else
+   else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_RED\n);
 
 }
@@ -426,10 +423,9 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
 #if !defined(CONFIG_LEDS_GPIO)  !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
-(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0)) {
+(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
-   gpio_set_value(gpio + TWL4030_GPIO_MAX + 1, 0);
-   } else
+   else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);
 #else
igep2_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;

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


[PATCH 5/6] omap4: Add platform changes for Ambient Light sensor

2010-12-17 Thread Tony Lindgren
From: Hemanth V heman...@ti.com

Register BH1780GLI Ambient light sensor, which is an I2C device
for 4430SDP board.

Signed-off-by: Hemanth V heman...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-4430sdp.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 8842ec5..66f8943 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -464,6 +464,9 @@ static struct i2c_board_info __initdata 
sdp4430_i2c_3_boardinfo[] = {
{
I2C_BOARD_INFO(tmp105, 0x48),
},
+   {
+   I2C_BOARD_INFO(bh1780, 0x29),
+   },
 };
 static struct i2c_board_info __initdata sdp4430_i2c_4_boardinfo[] = {
{

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


[PATCH 6/6] omap4: Add platform changes for PWM LED

2010-12-17 Thread Tony Lindgren
From: Hemanth V heman...@ti.com

Register TWL6030 PWM, which is used as charging LED

Signed-off-by: Hemanth V heman...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-4430sdp.c |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 66f8943..33b1f73 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -23,6 +23,7 @@
 #include linux/gpio_keys.h
 #include linux/regulator/machine.h
 #include linux/leds.h
+#include linux/leds_pwm.h
 
 #include mach/hardware.h
 #include mach/omap4-common.h
@@ -97,6 +98,28 @@ static struct gpio_led_platform_data sdp4430_led_data = {
.num_leds   = ARRAY_SIZE(sdp4430_gpio_leds),
 };
 
+static struct led_pwm sdp4430_pwm_leds[] = {
+   {
+   .name   = omap4:green:chrg,
+   .pwm_id = 1,
+   .max_brightness = 255,
+   .pwm_period_ns  = 7812500,
+   },
+};
+
+static struct led_pwm_platform_data sdp4430_pwm_data = {
+   .num_leds   = ARRAY_SIZE(sdp4430_pwm_leds),
+   .leds   = sdp4430_pwm_leds,
+};
+
+static struct platform_device sdp4430_leds_pwm = {
+   .name   = leds_pwm,
+   .id = -1,
+   .dev= {
+   .platform_data = sdp4430_pwm_data,
+   },
+};
+
 static int omap_prox_activate(struct device *dev)
 {
gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
@@ -204,6 +227,7 @@ static struct platform_device *sdp4430_devices[] __initdata 
= {
sdp4430_lcd_device,
sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
+   sdp4430_leds_pwm,
 };
 
 static struct omap_lcd_config sdp4430_lcd_config __initdata = {

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


[PATCH 4/6] omap3: igepv2: LED gpio-led:green:d1 is active low

2010-12-17 Thread Tony Lindgren
From: Laurent Pinchart laurent.pinch...@ideasonboard.com

Make sure the LED is turned off at boot time, and configure the GPIO LED
device as active low.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-igep0020.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 77e2db7..c5bd537 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -352,6 +352,7 @@ static struct gpio_led igep2_gpio_leds[] = {
.name   = gpio-led:green:d1,
.default_trigger= heartbeat,
.gpio   = -EINVAL, /* gets replaced */
+   .active_low = 1,
},
 };
 
@@ -423,7 +424,7 @@ static int igep2_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
 #if !defined(CONFIG_LEDS_GPIO)  !defined(CONFIG_LEDS_GPIO_MODULE)
if ((gpio_request(gpio+TWL4030_GPIO_MAX+1, gpio-led:green:d1) == 0)
-(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 0) == 0))
+(gpio_direction_output(gpio + TWL4030_GPIO_MAX + 1, 1) == 0))
gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
else
pr_warning(IGEP v2: Could not obtain gpio GPIO_LED1_GREEN\n);

--
To unsubscribe from this list: send the line unsubscribe 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] Keyboard: omap-keypad: use matrix_keypad.h

2010-12-17 Thread Tony Lindgren
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [101217 14:33]:
 Most keypad drivers make use of the linux/input/matrix_keypad.h 
 defined macros, structures and inline functions.
 
 Convert omap-keypad driver to use those as well, as suggested by a 
 compile time warning, hardcoded into the OMAP palt/keypad.h.
 
 Created against linux-2.6.37-rc5.
 Tested on Amstrad Delta.
 Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to 
 board-h4.

Great, good to get rid of those annoying warnings!

  drivers/input/keyboard/omap-keypad.c |   36 
  include/linux/input/matrix_keypad.h  |2

We also need Dmitry's ack for these changes.

Regards,

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


Re: [GIT PULL] OMAP: mailbox and iommu changes: for-next for v2.6.38

2010-12-17 Thread Tony Lindgren
* Kanigeri, Hari h-kanige...@ti.com [101215 14:48]:
 Hi Tony,
 
 The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71:
  Linus Torvalds (1):
Linux 2.6.37-rc4
 
 are available in the git repository at:
 
  git://gitorious.org/iommu_mailbox/iommu_mailbox.git for_2.6.38
...
 
 The above patch set is dependent on the following 2 Russell's patches.
 
 ARM: io: make iounmap() a simple macro
 ARM: io: simplify ioremap* and iounmap definitions
 Ref: http://www.spinics.net/lists/linux-omap/msg42023.html

Thanks pulling these in using Russell's io branch as the base.

Regards,

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


Re: [PATCH] Keyboard: omap-keypad: use matrix_keypad.h

2010-12-17 Thread Cory Maccarrone
On Fri, Dec 17, 2010 at 8:29 PM, Cory Maccarrone darkstar6...@gmail.com wrote:
 On Fri, Dec 17, 2010 at 2:32 PM, Janusz Krzysztofik
 jkrzy...@tis.icnet.pl wrote:
 Most keypad drivers make use of the linux/input/matrix_keypad.h
 defined macros, structures and inline functions.

 Convert omap-keypad driver to use those as well, as suggested by a
 compile time warning, hardcoded into the OMAP palt/keypad.h.

 Created against linux-2.6.37-rc5.
 Tested on Amstrad Delta.
 Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to
 board-h4.

 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 ---

 Works perfectly on the herald, and no more warning message.  Good work!

 Tested-by: Cory Maccarrone darkstar6...@gmail.com

 - Cory


Hmm, I may have spoken too soon.  This works perfectly on the latest
Torvalds master branch, but does not seem to work applied to
linux-omap/master.  There, all my keys report the same KEY_RECORD
event.

Probably not a problem in this patch, I think -- will try and track it
down.  Out of curiosity, which branch did you test it on?

- Cory
--
To unsubscribe from this list: send the line unsubscribe 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] Keyboard: omap-keypad: use matrix_keypad.h

2010-12-17 Thread Cory Maccarrone
On Fri, Dec 17, 2010 at 9:29 PM, Cory Maccarrone darkstar6...@gmail.com wrote:
 On Fri, Dec 17, 2010 at 8:29 PM, Cory Maccarrone darkstar6...@gmail.com 
 wrote:
 On Fri, Dec 17, 2010 at 2:32 PM, Janusz Krzysztofik
 jkrzy...@tis.icnet.pl wrote:
 Most keypad drivers make use of the linux/input/matrix_keypad.h
 defined macros, structures and inline functions.

 Convert omap-keypad driver to use those as well, as suggested by a
 compile time warning, hardcoded into the OMAP palt/keypad.h.

 Created against linux-2.6.37-rc5.
 Tested on Amstrad Delta.
 Compile tested with omap1_defconfig and omap2plus_defconfig shrinked to
 board-h4.

 Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
 ---

 Works perfectly on the herald, and no more warning message.  Good work!

 Tested-by: Cory Maccarrone darkstar6...@gmail.com

 - Cory


 Hmm, I may have spoken too soon.  This works perfectly on the latest
 Torvalds master branch, but does not seem to work applied to
 linux-omap/master.  There, all my keys report the same KEY_RECORD
 event.

 Probably not a problem in this patch, I think -- will try and track it
 down.  Out of curiosity, which branch did you test it on?

 - Cory


OK, looks like it definitely isn't this patch, something else on
linux-omap/master broke it.  I'll bisect and see if I can figure it
out.

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


  1   2   >