RE: [OMAP 1710] Mainline Broken
> -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 writes: > > > Hi, > > > > On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti > > 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
> -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
Acked-By Vaibhav Hiremath
Thanks,
Vaibhav
> Reviewed-by: Vaibhav Hiremath
> Signed-off-by: Archit Taneja
> ---
> 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
> #include
> #include
> -#include
> #include
> #include
> -#include
>
> #include
> #include
> #include
>
> #include
> -#include
> #include
> #include
>
> @@ -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_NAME"omap_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 (!vout->mirror)
> - return vout->rotation;
> -
> - switch (vout->rotation) {
> - case ds
RE: [PATCH v4 2/2] OMAP_VOUT: Create separate file for VRFB related API's
> -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
Acked-By Vaibhav Hiremath
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
> Signed-off-by: Archit Taneja
> ---
> 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
> #include
>
> -#include
> -#include
> -#include
> -
> #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
RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
> -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Tuesday, November 30, 2010 7:02 PM > To: Hiremath, Vaibhav > Cc: Paul Mundt; Ville Syrj?l?; M?ns Rullg?rd; linux-omap@vger.kernel.org; > linux-fb...@vger.kernel.org > Subject: RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl > > On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote: > > > -Original Message- > > > From: Paul Mundt [mailto:let...@linux-sh.org] > > > Sent: Tuesday, November 30, 2010 12:10 PM > > > To: Ville Syrj?l? > > > Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; > linux- > > > fb...@vger.kernel.org > > > Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl > > > > > > On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: > > > > On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: > > > > > On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav > wrote: > > > a WAITFORHWSYNC or something similar. > > [Hiremath, Vaibhav] Yes exactly, this name fits to the use-case and > sounds ok to me. > > > > Tomi, > > Any comments? > > Ah, I seem to have been dropped out from this mail thread... > > Yes, WAITFORHWSYNC sounds much better. > > But there seems to be some misunderstanding of what this is about. > Deferred IO or manual update displays are not directly related to this. > This is about configuration registers, ie. address, size, etc. of the > framebuffer, not about the contents of the framebuffer. > > The reason why WAITFORGO was implemented is: > > OMAP has user writeable shadow registers and hidden real registers for > display controller. The shadow registers are latched to real registers > on VFP, but only if GO bit has been set. The GO bit is cleared by the HW > when latching has been done. > > If the GO bit is set, we cannot touch the shadow registers because we > don't know when the VFP will happen. That's why there's additionally a > SW cache for the config, so that we don't need to block when the GO bit > is up and the user wants to change the config. The driver "flushes" the > SW config to real registers in VSYNC interrupt handler. > > This is why the user may need to wait multiple vsyncs until the config > has really been written to the real HW registers, and WAITFORGO waits > for this. But if there has not been any config changes, WAITFORGO > doesn't wait at all. > > So WAITFORVSYNC and WAITFORGO do quite a different thing on OMAP. It is > true what Hiremath says, WAITFORVSYNC is difficult (impossible?) to use > properly on OMAP as if the config write happens between VFP and VSYNC, > the config is not actually yet in the real registers. > > But I'm still not comfortable with just moving WAITFORGO over > WAITFORVSYNC. At least we should then change WAITFORGO to always wait at > least for the next vsync, so that it wouldn't return immediately when > there are no pending changes. This would make WAITFORGO act like > WAITFORVSYNC in many cases, but not always. > > And to add to the confusion, there are multiple overlays on OMAP. They > may be currently shared by multiple users (for example omapfb and v4l2). > If the user uses WAITFORVSYNC, the call will return for every vsync, as > expected. If he uses WAITFORGO, the call will return in random number of > vsyncs from the user's point of view, because the other user may be > competing from the same resource. > > One could still argue that always using WAITFORGO is better, as there's > the problem with WAITFORVSYNC that Hiremath described. But then again, > WAITFORGO acts differently than what (I think) WAITFORVSYNC should do. > > So summa summarum, I didn't know how to solve this perfectly earlier, > and thus I implemented WAITFORGO, and I still don't know what would be > the perfect solution. > [Hiremath, Vaibhav] We did not had a closure on this topic, so summarizing our discussion here, Let's keep FBIO_WAITFORVSYNC (or OMAPFB_WAITFORVSYNC) ioctl as is, since as of now the way we understand this ioctl is, it should barely wait for next vsync. Change the OMAPFB_WAITFORGO to (standard) FBIO_WAITFORHWSYNC, currently this will be used in OMAP2/3 Fb-display driver. Thanks, Vaibhav > Tomi > -- To unsubscribe from this list: send the line "unsubscribe 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/7] OMAP3: remove unused code from the ASM sleep code
From: Jean Pihet
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
---
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_V 0xfa00291c
-#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
- OMAP3430_PM_PREPWSTST)
#define PM_PREPWSTST_CORE_P0x48306AE8
-#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_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)
@@ -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]
and r2, r2, #0x3
@@ -284,7 +250,6 @@ restore_3630:
str r2, [r1]
/* Fall thru for the remaining logic */
restore:
- /* b restore*/ @ Enable to debug restore code
/* Check what was the reason for mpu reset and store the reason in r9*/
/* 1 - Only L1 and logic lost */
/* 2 - Only L2 lost - In this case, we wont be here */
@@ -493,7 +458,6 @@ usettbr0:
ldmfd sp!, {r0-r12, pc} @ restore regs and return
[PATCH 0/7 v5] OMAP3: clean up ASM sleep code
From: Jean Pihet 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-omap&m=129139584919242&w=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
From: Jean Pihet 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 Cc: Vishwanath BS --- 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
From: Jean Pihet
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
---
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
+ ldr r4, sdrc_manual_0
[PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths
From: Jean Pihet
- 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
---
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 sp and spsr to SDRAM */
[PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses
From: Jean Pihet
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
---
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
#include
+#include
#include
#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
From: Jean Pihet 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 --- 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
From: Jean Pihet
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
---
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
+ *
* (C) Copyright 2007
* Texas Instruments
* Karthik Dasu
@@ -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 lost
movne r9, #0x1@ Only L1 and L2 lost
Re: twl4030_usb porting advice
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. -- 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 2/7] OMAP2+: use global values for the SRAM PA addresses
Hi Santosh, On Fri, Dec 17, 2010 at 5:48 AM, Santosh Shilimkar 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 2/7] OMAP2+: use global values for the SRAM PA addresses >> >> From: Jean Pihet >> >> The SRAM PA addresses are locally defined and used in both the >> SRAM management code and the idle sleep code. >> A global macro defines the values 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 >> --- >> arch/arm/mach-omap2/sdrc.h | 7 +++ >> arch/arm/plat-omap/sram.c | 7 ++- >> 2 files changed, 9 insertions(+), 5 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/sdrc.h b/arch/arm/mach-omap2/sdrc.h >> index 68f57bb..ada596b 100644 >> --- a/arch/arm/mach-omap2/sdrc.h >> +++ b/arch/arm/mach-omap2/sdrc.h >> @@ -74,5 +74,12 @@ static inline u32 sms_read_reg(u16 reg) >> */ >> #define SDRC_MPURATE_LOOPS 96 >> >> +/* >> + * 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 >> > Header choice is wrong. Certainly SDRC is not the place. > Right place should be "#include " > OMAP4 doesn't even have SDRC IP This is correct Furthermore it would have broken the OMAP1 build since sdrc.h is only included for OMAP2 & 3. Nice catch! Thanks, Jean > >> #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 > -- To unsubscribe from this list: send the line "unsubscribe 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
On Fri, Dec 17, 2010 at 6:04 AM, Santosh Shilimkar
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
>>
>> - 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
>> ---
>> 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
Re: [PATCH 7/7] OMAP3: ASM sleep code format rework
On Fri, Dec 17, 2010 at 6:09 AM, Santosh Shilimkar
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
>>
>> 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
>> ---
>> 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
>> + *
>> * (C) Copyright 2007
>> * Texas Instruments
>> * Karthik Dasu
>> @@ -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 lo
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 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 >> >> 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-omap&m=129139584919242&w=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
> -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 > 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 > >> > >> 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-omap&m=129139584919242&w=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
> -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
>
> 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
Acked-by: Santosh Shilimkar
> ---
> 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 re
RE: [PATCH 2/7] OMAP2+: use global values for the SRAM PA addresses
> -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
>
> 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
Acked-by: Santosh Shilimkar
> ---
> 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
> #include
> +#include
> #include
>
> #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
> -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 > > 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 > Cc: Vishwanath BS Acked-by: Santosh Shilimkar > --- > 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
> -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
>
> 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
Acked-by: Santosh Shilimkar
> ---
> 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
RE: [PATCH 5/7] OMAP3: rework of the ASM sleep code execution paths
> -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
>
> - 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
Acked-by: Santosh Shilimkar
> ---
> 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
RE: [PATCH 6/7] OMAP3: add comments for low power code errata
> -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 > > 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 Acked-by: Santosh Shilimkar > --- > 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
> -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
>
> 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
Acked-by: Santosh Shilimkar
> ---
> 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
> + *
> * (C) Copyright 2007
> * Texas Instruments
> * Karthik Dasu
> @@ -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
Re: twl4030_usb porting advice
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
From: Thomas Petazzoni
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
Cc: Kevin Hilman
Cc: Cousson, Benoit
---
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 "
-"but no wakeup sources are marked\n");
- } else {
[PATCH 0/40] Complete set of clocksource/sched_clock patches
Here is the entire set of clocksource and sched_clock patches which have been previously posted. There's a couple of small tweaks in a few of the patches (such as adding notrace to OMAP clocksource read functions), and this also shows the proper ordering of these patches. Still looking for acks or tested-by's for these 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: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
>>-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 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
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
---
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
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
---
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
+#include
#include
#include
#include
@@ -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
*/
#include
+#include
#include
#include
#include
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
#include
#include
+#include
#include
#include
#include
@@ -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
#include
#include
+#include
#include
#include
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
#include
#include
+#include
#include
#include
@@ -44,7 +45,7 @@
static u32 offset_32k __read_mostly;
#ifdef CONFIG_ARCH_OMAP16XX
-static cycle_t omap16xx_32k_read(struct clocksource *cs)
+static cycle_t notrace omap16xx_32k_read(struct clocksource *cs)
{
return omap_readl(OMAP16XX_TIMER_32K_SYNCHRONIZED) - offset_32k;
}
@@ -53,7 +54,7 @@ static cycle_t omap16xx_32k_read(struct clocksource
[PATCH 37/40] ARM: omap: convert sched_clock() to use new infrastructure
Convert omap to use the new sched_clock() infrastructure for extending
32bit counters to full 64-bit nanoseconds.
Signed-off-by: Russell King
---
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
#include
+#include
+
#include
#include
@@ -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
Hi, On Wed, 15 Dec 2010, Tony Lindgren wrote: * Aaro Koskinen [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
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
Hello.
On 16-12-2010 18:25, srin...@mistralsolutions.com wrote:
From: Srinath
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-omap&w=2&r=1&s=Craneboard%3A+Add+USB+EHCI+support&q=t
Signed-off-by: Srinath
---
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
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 writes: Hi, On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti 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
On Thu, Dec 16, 2010 at 11:47 PM, Kevin Hilman wrote: > Hi Govindraj, > > "Raja, Govindraj" writes: > >> On Wed, Dec 15, 2010 at 9:42 PM, Kevin Hilman >> wrote: >> >> "Govindraj.R" 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
From: Charulatha V
Update clock3xxx_data for mcspi1-4 with appropriate clock domain name.
Signed-off-by: Charulatha V
Signed-off-by: Govindraj.R
Cc: Paul Walmsley
---
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
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the following: From: Jean Pihet 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 Reviewed-by: Nishanth Menon Tested-by: Nishanth Menon 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
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the following: From: Jean Pihet 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 --- 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 Menon 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 3/7] OMAP3: remove hardcoded values from the ASM sleep code
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the following: From: Jean Pihet 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 Cc: Vishwanath BS --- 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) + (reg)) please. I am not convinced that we should call this REGADDR though scratchpad region in DDR is still DDR, not a register. /* 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 + */ err.. technically sdrc scratchpad is not really a register ;) nor is sram_base ;) +#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 please use () for wrapping up a macro with multiple defines. #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) not sure what changed here. -#define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is - * available */ this change I am guessing is a clean up of /* */ comment - might help if you could do formatting changes in a single patch - easier to check if there are functionality issues during reviews in the current patch that way. my suggestion will be to do the functional changes first followed by a formatting cleanup patch at the very end.. -#define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ - + SCRATCHPAD_MEM_OFFS) again, not sure what changed here. +#define SRAM_BASE_POMAP3_SRAM_PA Why not just replace the usage of SRAM_BASE_P with 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_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) Tested-by: Nishanth Menon 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 4/7] OMAP3: re-organize the ASM sleep code
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the
following:
From: Jean Pihet
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
---
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
+
formatting change - recommend a separate patch collating other
formatting changes from other patches as well.
.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
btw, if you prefer me to introduce the enable_omap3630_l2_on_restore
toggle after get_es3_restore_pointer, I can do that.
/*
* 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
Thanks on the fflag/flag :) - but this probably belongs to my patch ;)
could you comment on my latest rev, I will fix it there.
* 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 s
Re: [PATCH v1] OMAP: GPIO: Correct IP version message during boot
Kevin, On Thu, Dec 16, 2010 at 11:49, Kevin Hilman wrote: > "Varadarajan, Charulatha" 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 >> Acked-by: Felipe Balbi >> --- >> 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
Re: [PATCHv5 00/10] OMAP: Adding Smartreflex and Voltage driver support
"Gopinath, Thara" writes:
>>>
>>>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.
>
Sorry...
Here it is. It is not yet functional as I did not assign the function
pointers, but shows an approach to fixing the problem. Please
check/confirm my fix with Rajendra as he has been more involved in the
low-level PRCM API changes.
Kevin
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 6e91748..f28c778 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -150,6 +150,8 @@ struct omap_vdd_info {
bool vp_enabled;
int (*volt_scale) (struct omap_vdd_info *vdd,
unsigned long target_volt);
+ u32 (*read_reg)(s16 inst, u16 idx);
+ u32 (*write_reg)(u32 val, s16 inst, u16 idx);
};
static struct omap_vdd_info *vdd_info;
@@ -321,7 +323,7 @@ static int vp_volt_debug_get(void *data, u64 *val)
return -EINVAL;
}
- vsel = prm_read_mod_reg(vdd->vp_reg.prm_mod, vdd->vp_offs.voltage);
+ vsel = vdd->read_reg(vdd->vp_reg.prm_mod, vdd->vp_offs.voltage);
pr_notice("curr_vsel = %x\n", vsel);
if (!vdd->pmic_info->vsel_to_uv) {
@@ -375,19 +377,19 @@ static void vp_latch_vsel(struct omap_vdd_info *vdd)
vsel = vdd->pmic_info->uv_to_vsel(uvdc);
- vpconfig = prm_read_mod_reg(mod, vdd->vp_offs.vpconfig);
+ vpconfig = vdd->read_reg(mod, vdd->vp_offs.vpconfig);
vpconfig &= ~(vdd->vp_reg.vpconfig_initvoltage_mask |
vdd->vp_reg.vpconfig_initvdd);
vpconfig |= vsel << vdd->vp_reg.vpconfig_initvoltage_shift;
- prm_write_mod_reg(vpconfig, mod, vdd->vp_offs.vpconfig);
+ vdd->write_reg(vpconfig, mod, vdd->vp_offs.vpconfig);
/* Trigger initVDD value copy to voltage processor */
- prm_write_mod_reg((vpconfig | vdd->vp_reg.vpconfig_initvdd), mod,
+ vdd->write_reg((vpconfig | vdd->vp_reg.vpconfig_initvdd), mod,
vdd->vp_offs.vpconfig);
/* Clear initVDD copy trigger bit */
- prm_write_mod_reg(vpconfig, mod, vdd->vp_offs.vpconfig);
+ vdd->write_reg(vpconfig, mod, vdd->vp_offs.vpconfig);
}
/* Generic voltage init functions */
@@ -402,19 +404,19 @@ static void __init vp_init(struct omap_vdd_info *vdd)
(vdd->vp_reg.vpconfig_errorgain <<
vdd->vp_reg.vpconfig_errorgain_shift) |
vdd->vp_reg.vpconfig_timeouten;
- prm_write_mod_reg(vp_val, mod, vdd->vp_offs.vpconfig);
+ vdd->write_reg(vp_val, mod, vdd->vp_offs.vpconfig);
vp_val = ((vdd->vp_reg.vstepmin_smpswaittimemin <<
vdd->vp_reg.vstepmin_smpswaittimemin_shift) |
(vdd->vp_reg.vstepmin_stepmin <<
vdd->vp_reg.vstepmin_stepmin_shift));
- prm_write_mod_reg(vp_val, mod, vdd->vp_offs.vstepmin);
+ vdd->write_reg(vp_val, mod, vdd->vp_offs.vstepmin);
vp_val = ((vdd->vp_reg.vstepmax_smpswaittimemax <<
vdd->vp_reg.vstepmax_smpswaittimemax_shift) |
(vdd->vp_reg.vstepmax_stepmax <<
vdd->vp_reg.vstepmax_stepmax_shift));
- prm_write_mod_reg(vp_val, mod, vdd->vp_offs.vstepmax);
+ vdd->write_reg(vp_val, mod, vdd->vp_offs.vstepmax);
vp_val = ((vdd->vp_reg.vlimitto_vddmax <<
vdd->vp_reg.vlimitto_vddmax_shift) |
@@ -422,7 +424,7 @@ static void __init vp_init(struct omap_vdd_info *vdd)
vdd->vp_reg.vlimitto_vddmin_shift) |
(vdd->vp_reg.vlimitto_timeout <<
vdd->vp_reg.vlimitto_timeout_shift));
- prm_write_mod_reg(vp_val, mod, vdd->vp_offs.vlimitto);
+ vdd->write_reg(vp_val, mod, vdd->vp_offs.vlimitto);
}
static void __init vdd_debugfs_init(struct omap_vdd_info *vdd)
@@ -503,23 +505,23 @@ static int _pre_volt_scale(struct omap_vdd_info *vdd,
volt_data = NULL;
*target_vsel = vdd->pmic_info->uv_to_vsel(target_volt);
- *current_vsel = prm_read_mod_reg(vp_mod, vdd->vp_offs.voltage);
+ *current_vsel = vdd->read_reg(vp_mod, vdd->vp_offs.voltage);
/* Setting the ON voltage to the new target voltage */
- vc_cmdval = prm_read_mod_reg(vc_mod, vdd->vc_reg.cmdval_reg);
+ vc_cmdval = vdd->read_reg(vc_mod, vdd->vc_reg.cmdval_reg);
vc_cmdval &= ~vdd->vc_reg.cmd_on_mask;
vc_cmdval |= (*target_vsel << vdd->vc_reg.cmd_on_shift);
- prm_write_mod_reg(vc_cmdval, vc_mod, vdd->vc_reg.cmdval_reg);
+ vdd->write_reg(vc_cmdval, vc_mod, vdd->vc_reg.cmdval_reg);
/* Setting vp errorgain based on the voltage */
if (volt_data) {
- vp_errgain_va
[PATCH v2]: OMAP: DSS2: Adding check_timings and set_timings for panel-taal
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
---
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
Hi Nishant, On Fri, Dec 17, 2010 at 2:34 PM, Nishanth Menon wrote: > jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the > following: >> >> From: Jean Pihet >> >> 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 >> --- >> 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 Menon > 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
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
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the
following:
From: Jean Pihet
- 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
---
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
|
cache m
[PATCH v2 1/9] OMAP: DMA: Replace read/write macros with functions
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
Tested-by: Kevin Hilman
Acked-by: Kevin Hilman
---
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
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
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
Tested-by: Kevin Hilman
Acked-by: Kevin Hilman
---
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, OCP_SYSCONFIG, 0);
+ if (IS_DMA_ERRATA(DMA_ERRATA_i88))
+
[PATCH v2 5/9] OMAP3: hwmod data: add system DMA
Add OMAP3 DMA hwmod data
Signed-off-by: G, Manjunath Kondaiah
Tested-by: Kevin Hilman
Acked-by: Kevin Hilman
---
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 unsubscribe from this list: se
[PATCH v2 4/9] OMAP2430: hwmod data: add system DMA
Add OMAP2430 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah
---
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)
+#def
[PATCH v2 6/9] OMAP4: hwmod data: add system DMA
From: Benoit Cousson
Add OMAP4 DMA hwmod data
Signed-off-by: Benoit Cousson
Signed-off-by: G, Manjunath Kondaiah
Tested-by: Kevin Hilman
Acked-by: Kevin Hilman
---
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
#include
#include
+#include
#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,
+ },
+ },
+ .slaves = omap44xx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(o
[PATCH v2 7/9] OMAP1: DMA: Implement in platform device model
Implement OMAP1 DMA as platform device and add support for
registering through platform device layer using resource
structures.
Signed-off-by: G, Manjunath Kondaiah
Signed-off-by: Kevin Hilman
---
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ä
+ * DMA channel linking for 1610 by Samuel Ortiz
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak
+ * 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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#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;
+ }
+
+ p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
+ if (!p) {
+ dev_err(&pdev->dev, "%s: Unable to allocate 'p' for %s\n",
[PATCH v2 8/9] OMAP2+: DMA: hwmod: Device registration
Prepare OMAP2+ DMA to use hwmod infrastructure so that DMA can register
as platform device.
Signed-off-by: G, Manjunath Kondaiah
Tested-by: Kevin Hilman
Acked-by: Kevin Hilman
---
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ä
+ * DMA channel linking for 1610 by Samuel Ortiz
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak
+ * 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
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ * Converted DMA library into platform driver
+ * - G, Manjunath Kondaiah
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+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
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
Add OMAP2420 DMA hwmod data and also add required
DMA device attributes.
Signed-off-by: G, Manjunath Kondaiah
---
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
Re: [PATCH 6/7] OMAP3: add comments for low power code errata
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the following: From: Jean Pihet 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 --- 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 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
jean.pi...@newoldbits.com had written, on 12/17/2010 04:08 AM, the
following:
From: Jean Pihet
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
---
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
+ *
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
@@ -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 faster and will change with kernel
* - 'might' have
Re: [PATCH v4 5/5] OMAP: mailbox: use runtime pm for clk and sysc handling
Hi Omar, On 12/16/2010 3:11 PM, Ramirez Luna, Omar wrote: Hi, On Thu, Dec 16, 2010 at 2:28 AM, Varadarajan, Charulatha wrote: On Thu, Dec 16, 2010 at 12:17, Omar Ramirez Luna 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 Luna --- 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 @@ #include #include #include +#include #include #include @@ -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
On Wed, Dec 8, 2010 at 10:49, David Anders 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 Kadiyala
>> Signed-off-by: Raghuveer Murthy
>> Acked-by: Nishanth Menon
>>
>
> Tested-by: David Anders
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
Tony, 2010/12/8 Marek Vasut : > 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 >> Cc: linux-...@lists.arm.linux.org.uk >> Signed-off-by: Raghuveer Murthy >> --- >> 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
* Menon, Nishanth [101217 09:50]: > On Wed, Dec 8, 2010 at 10:49, David Anders 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 Kadiyala > >> Signed-off-by: Raghuveer Murthy > >> Acked-by: Nishanth Menon > >> > > > > Tested-by: David Anders > 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
Tony Lindgren had written, on 12/17/2010 12:02 PM, the following: * Menon, Nishanth [101217 09:50]: On Wed, Dec 8, 2010 at 10:49, David Anders 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 Kadiyala Signed-off-by: Raghuveer Murthy Acked-by: Nishanth Menon Tested-by: David Anders 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
On Fri, Dec 17, 2010 at 10:28 AM, Cousson, Benoit 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 1/3] omap: rx51: Remove __initdata from rx51_tpa6130a2_data
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
---
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,
};
--
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 3/3] omap: rx51: Add supplies and data for codec b part of TLV320AIC34
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
---
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
Remove second tlv320aic3x.h inclusion that came along the commit f0fba2a "ASoC: multi-component - ASoC Multi-Component Support". Signed-off-by: Jarkko Nikula Cc: Liam Girdwood --- 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 #include #include -#include #include #include -- 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
From: Jon Hunter
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
---
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 = 4;
+}
+
+/**
+ * looku
Re: [OMAP 1710] Mainline Broken
"DebBarma, Tarun Kanti" 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 writes: >> >> > Hi, >> > >> > On Thu, Dec 16, 2010 at 4:30 PM, DebBarma, Tarun Kanti >> > 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
Most keypad drivers make use of the
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 .
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
---
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
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)
{
struct omap_kp *omap_kp_data = (struct omap_kp *
Re: [PATCH 5/5 v3] OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Nishanth Menon writes: > Kevin Hilman had written, on 12/16/2010 12:57 PM, the following: >> Nishanth Menon 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
Hi Jean, jean.pi...@newoldbits.com writes: > From: Jean Pihet > > 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-omap&m=129139584919242&w=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
Hi Kevin, On Sat, Dec 18, 2010 at 12:02 AM, Kevin Hilman wrote: > Hi Jean, > > jean.pi...@newoldbits.com writes: > >> From: Jean Pihet >> >> 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-omap&m=129139584919242&w=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
Kevin Hilman had written, on 12/17/2010 04:54 PM, the following:
Nishanth Menon writes:
Kevin Hilman had written, on 12/16/2010 12:57 PM, the following:
Nishanth Menon 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 = 1;
---> valid bi
Re: [PATCH 0/7 v5] OMAP3: clean up ASM sleep code
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 wrote: Hi Jean, jean.pi...@newoldbits.com writes: From: Jean Pihet 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-omap&m=129139584919242&w=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
* Janusz Krzysztofik [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 -- To unsubscribe from this list: send the line "unsubscribe 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
* Sukumar Ghorai [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 > --- > 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
* Sukumar Ghorai [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
> ---
> 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
>
> +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
* Sukumar Ghorai [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 > --- > 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
* Tarun Kanti DebBarma [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
* Aaro Koskinen [101217 04:41]: > Hi, > > On Wed, 15 Dec 2010, Tony Lindgren wrote: > >* Aaro Koskinen [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
* Jarkko Nikula [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
> ---
> 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
* Carlos Chinea [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
* Srikar [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
* Jean Pihet [101117 09:44]: > From: Jean Pihet > > 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
* Ohad Ben-Cohen [101216 13:34]: > On Thu, Dec 16, 2010 at 11:08 PM, Greg KH 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 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
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
Signed-off-by: Kevin Hilman
---
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
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-omap&m=12917626626&w=2
Cc: Paul Walmsley
Signed-off-by: Kevin Hilman
---
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
+#include
#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
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
Signed-off-by: Kevin Hilman
---
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
#include
#include
+#include
/* Interface documentation is in mach/omap-pm.h */
#include
+#include
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);
- return -EINVAL;
- };
+ struct platform_device *pdev = to_platform_device(dev);
+ u32 count;
- p
[APPLIED] [PATCH] OMAP: kill all section mismatch warning for
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
* Bryan Wu [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
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
* John Rigby [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
* Hemanth V [101212 22:08]: > - Original Message - From: "Hemanth V" > To: > 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 > >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
* Hemanth V [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 > 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 > --- > 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 > #include > #include > +#include > +#include > > #include > #include This you should send via the input list along with the cma3000 driver: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe 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 -next] omap2430: hwmod: remove stray declaration
* Anand Gadiyar [101203 11:05]: > Patch "OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430" > in linux-next as of 20101203 introduced the following build > warning - fix this by removing the stray i2c_dev_attr. > > arch/arm/mach-omap2/omap_hwmod_2430_data.c:483: warning: 'i2c_dev_attr' > defined but not used 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] omap: remove dead wdt code in plat-omap/devices.c
* Anand Gadiyar [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 > Cc: Tony Lindgren > --- > 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 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
* Cousson, Benoit [101210 00:29]: > On 12/9/2010 11:18 PM, aaro.koski...@nokia.com wrote: > >Hi, > > > >Kevin Hilman [khil...@deeprootsystems.com]: > >>Ben Dooks writes: > >>>Renaming stuff like this is going to have an impact on the userspace > >>>as anyone looking through /sys's driver heirarchy is going to miss the > >>>old name... > >>> > >>>It all depends if you really want to go ahead with this... > >> > >>Yes, we are aware of the userspace impact, but this name change makes > >>all devices on OMAP have consistent names and actually improves the > >>ability to have userspace tools have consistent naming as well. > > > >So there are no imporant users, or if there is, they are prepared for this > >change? > > Well, I do not know any user of that today. Do you have some in mind? Sounds like it's safe for me to take these two. 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] omap1: pm_bus: Fix compilation warning.
* Kevin Hilman [101207 14:13]: > Marek Belisko writes: > > > Fix following compilation warning: > > arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_resume': > > arch/arm/mach-omap1/pm_bus.c:51: warning: unused variable 'ret' > > > > Signed-off-by: Marek Belisko > > Acked-by: Kevin Hilman Taking these except for the mailbox one which is already fixed. 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
