Re: [PATCH] DSPBRIDGE: Interface tightening to check for invalid
Hi Ernesto, From: ext Ramos Falcon, Ernesto erne...@ti.com Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid Date: Mon, 23 Nov 2009 21:12:08 +0100 From f28ec22e48a9b61ac00b7711e035e117bdc71aeb Mon Sep 17 00:00:00 2001 From: Ernesto Ramos erne...@ti.com Date: Mon, 23 Nov 2009 12:16:45 -0600 Subject: [PATCH] DSPBRIDGE: Interface tightening to check for invalid inputs. Move the error checking to kernel to address usecases accessing kernel API directly. memory_check_vma() wasn't implemented for normal ioctl parameter checking, but one for bridge cache operations with kernel crash risk, especially with the following patch: http://marc.info/?l=linux-omapm=125810716419520w=2 This is because these memory area is expected that: - its pages have been already populated. - its pages shouldn't be swapped out. Otherwise there's risk of kernel crash at these cache operation, although find_vma() and follow_page() may be a bit heavier operation. For most of the normal cases, which just checks ioctl parameters, normal access_ok() would be enough. If it tries to access kernel address, just it returns error to userland. If it tries to access invalid address in user address space, the process dies with SIGSEGV. I think that normally it's ok that a process dies because of invalid address access rather than performance degrade. So I think that memory_check_vma() doesn't fit for normal ioctl parameter checking(copy_from_user/copy_to_user), but access_ok() would work in most of normal cases. In macros, __cp_fm_usr()/__cp_to_usr(), adding access_ok() checking for pointers may work fine, I guess. Signed-off-by: Ernesto Ramos erne...@ti.com --- arch/arm/plat-omap/include/dspbridge/dbdefs.h |3 +- drivers/dsp/bridge/pmgr/wcd.c | 263 +++-- drivers/dsp/bridge/rmgr/proc.c| 42 3 files changed, 249 insertions(+), 59 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
-Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Monday, November 23, 2009 10:36 PM To: Govindraj; g...@lixom.net Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj; G, Manjunath Kondaiah Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Govindaj, I'm having problems with these patches on Zoom2 with debug board, since they don't seem to coexist very well together with 8250. Enabling both options will result in build errors. Why do we need to enable both 8250 and omap-serial for console. The console UART can be either external UART or any one of the omap UART right? -Manjunath Also, you have hardcoded and are using the same major/minor versions as the 8250 driver, which results in failure to allocate those devices when probing 8250. That needs to be corrected. -Olof -- To unsubscribe from this list: send the line unsubscribe 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: sr: Update ON voltage levels based on VSEL
-Original Message- From: Menon, Nishanth Sent: Tuesday, November 24, 2009 7:09 AM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap3: sr: Update ON voltage levels based on VSEL Premi, Sanjeev had written, on 11/23/2009 07:38 AM, the following: The settings for ON voltage level in the registers PRM_VC_CMD_VAL_0,1 was not updated based on OPP table. Once the MPU resumes from OFF mode (during idle OR suspend) the VDD1 voltage always returns to 1.2V. This patch programs the value based on current OPP. thanks for flagging this. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/smartreflex.c | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index be3a1da..4cbbd6f 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -313,6 +313,15 @@ static void sr_configure_vp(int srid) PRM_VP1_CONFIG_TIMEOUTEN | vsel OMAP3430_INITVOLTAGE_SHIFT; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_0_OFFSET); + prm_write_mod_reg(vpconfig, OMAP3430_GR_MOD, OMAP3_PRM_VP1_CONFIG_OFFSET); prm_write_mod_reg(PRM_VP1_VSTEPMIN_SMPSWAITTIMEMIN | @@ -354,6 +363,15 @@ static void sr_configure_vp(int srid) else vsel = l3_opps[target_opp_no].vsel; + /* +* Update the 'ON' voltage levels based on the VSEL. +* (See spruf8c.pdf sec 1.5.3.1) +*/ + prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK, + (vsel OMAP3430_VC_CMD_ON_SHIFT), + OMAP3430_GR_MOD, + OMAP3_PRM_VC_CMD_VAL_1_OFFSET); + vpconfig = PRM_VP2_CONFIG_ERROROFFSET | PRM_VP2_CONFIG_ERRORGAIN | PRM_VP2_CONFIG_TIMEOUTEN | @@ -391,7 +409,6 @@ static void sr_configure_vp(int srid) /* Clear force bit */ prm_clear_mod_reg_bits(OMAP3430_FORCEUPDATE, OMAP3430_GR_MOD, OMAP3_PRM_VP2_CONFIG_OFFSET); - } } CMD_VAL_[01] contains: OFF, RET, ONLowPower, ON voltages. for VDD1 and VDD2 ON voltage: Here is what I see: sr_voltagescale_vcbypass sets the voltage for ON mode. BUT, this is called as part of voltage scale logic (from resource34xx.c::program_opp) == invoked only as part of DVFS transitions. The trouble we have is this: IF OFF mode is hit without DVFS transition, we call disable_smartreflex, which in turn calls sr_reset_voltage(). Unfortunately, this function is a wannabe sr_voltagescale_bypass, but does not do what sr_voltagebypass in it's entirety - critical one being: setting ON voltage based on state it is going into. Yes. One thing I found was that many functions have a bit of overlapping functionality - possibly complete in completely differen respect - but doesn't help flow. (ideally, it should set the RET/ON voltage based on the state it is going into - but that'd be an optimization thing).. Now, without your patch, the OPP voltage is based on nominal OPP at which the system boots up on and CMD_VAL_0::ON voltage is not set when disable_smartreflex::reset_voltage is called. ON voltage is some value someone has set in the reg. Actually, without DVFS the mpurate argument is useful in setting the desired OPP. This functionality was fixed few months back. Hence, the patch is able to set correct value in this patch. For this, we come to the interesting part, we should now also look at arch/arm/mach-omap2/pm34xx.c::configure_vc function - which is another function who hits the ON ret and OFF voltage values based on prm_setup - this is where your bug comes from: defaults: 92 .vdd0_on = 0x30,/* 1.2v */ Initially, I did go the board specific way (to test the implementation); but then the OPPs and the voltages aren't board specific. So, had to find a good point where only one table is used. Moving further as the new OPP layer shapes up, I believe we need simple SR APIs: e.g. (just some pseudo code) #define VDD11 #define VDD22 #define VDD33 /* may be in future */ #define VC_VOLTS_OFF0 #define VC_VOLTS_RET1 #define VC_VOLTS_ON 2 #define VC_OFF_CLEAR_MASK ... #define VC_RET_CLEAR_MASK ... #define VC_ON_CLEAR_MASK... #define
[PATCH 2/2] OMAP3: Implemented VFP restore/save context
From: Tero Kristo tero.kri...@nokia.com
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 21 -
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4f22107..dd5bbaf 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,6 +18,7 @@ extern u32 sleep_while_idle;
extern u32 voltage_off_while_idle;
extern void *omap3_secure_ram_storage;
+extern void vfp_pm_save_context(void);
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b26ae5b..4b01303 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -321,6 +321,18 @@ static void restore_control_register(u32 val)
__asm__ __volatile__ (mcr p15, 0, %0, c1, c0, 0 : : r (val));
}
+static inline void omap3_save_neon_context(void)
+{
+#ifdef CONFIG_VFP
+ vfp_pm_save_context();
+#endif
+}
+
+static inline void omap3_restore_neon_context(void)
+{
+ return;
+}
+
/* Function to restore the table entry that was modified for enabling MMU */
static void restore_table_entry(void)
{
@@ -365,6 +377,7 @@ void omap_sram_idle(void)
/* save_state = 3 = L1, L2 and logic lost */
int save_state = 0;
int mpu_next_state = PWRDM_POWER_ON;
+ int neon_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
@@ -398,8 +411,12 @@ void omap_sram_idle(void)
pwrdm_pre_transition();
/* NEON control */
- if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
+ if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON) {
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ neon_next_state = mpu_next_state;
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_save_neon_context();
+ }
/* PER */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
@@ -537,6 +554,8 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_restore_neon_context();
pwrdm_post_transition();
}
--
1.5.4.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 0/2] VFP save/restore for OMAP3
From: Tero Kristo tero.kri...@nokia.com Hi, The following two patches are needed by OMAP3 to save/restore VFP context during off-mode. Patch 1 adds generic support inside ARM VFP code, and the second one adds the necessary hooks into OMAP3 power management code. --Tero -- To unsubscribe from this list: send the line unsubscribe 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/2] ARM: Implemented support for VFP PM context saving
From: Tero Kristo tero.kri...@nokia.com
In some ARM architectures, like OMAP3, the VFP context can be lost during
dynamic sleep cycle. For this purpose, there is now a function
vfp_pm_save_context() that should be called before the VFP is assumed to
lose context. Next VFP trap will then restore context automatically.
We need to have the last_VFP_context[cpu] cleared after the save in idle,
else the restore would fail to restore when it sees that the last_VFP_context
is same as the current threads vfp_state. This happens when the same
process/thread traps an exception post idle.
Main work for this patch was done by Peter and Rajendra. Some cleanup and
optimization by Tero.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/vfp/vfpmodule.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2d7423a..80a08bd 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -329,6 +329,31 @@ static void vfp_enable(void *unused)
#ifdef CONFIG_PM
#include linux/sysdev.h
+void vfp_pm_save_context(void)
+{
+ struct thread_info *thread = current_thread_info();
+ u32 fpexc = fmrx(FPEXC);
+ __u32 cpu = thread-cpu;
+
+ if (last_VFP_context[cpu]) {
+ if (!(fpexc FPEXC_EN)) {
+ /* enable vfp now to save context */
+ vfp_enable(NULL);
+ fmxr(FPEXC, fmrx(FPEXC) | FPEXC_EN);
+ }
+ vfp_save_state(last_VFP_context[cpu], fpexc);
+
+ /* Disable vfp. The next inst traps an exception and restores*/
+ fmxr(FPEXC, fmrx(FPEXC) ~FPEXC_EN);
+
+ /*
+* This is needed else the restore might fail if it sees
+* last_VFP_context if same as the current threads vfp_state.
+*/
+ last_VFP_context[cpu] = NULL;
+ }
+}
+
static int vfp_pm_suspend(struct sys_device *dev, pm_message_t state)
{
struct thread_info *ti = current_thread_info();
--
1.5.4.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
[RFC][PATCH v2] OMAP: McBSP: Use register cache
Change the way McBSP registers are updated: use cached values instead of
relying upon those read back from the device.
With this patch, I have finally managed to get rid of all random
playback/recording hangups on my OMAP1510 based Amstrad Delta hardware. Before
that, values read back from McBSP registers to be used for updating them
happened to be errornous.
From the hardware side, the issue appeared to be caused by a relatively high
power requirements of an external USB adapter connected to the board's printer
dedicated USB port.
I think there is one important point that makes this patch worth of applying,
apart from my hardware quality. With the current code, if it ever happens to
any machine, no matter if OMAP1510 or newer, to read incorrect value from a
McBSP register, this wrong value will get written back without any checking.
That can lead to hardware damage if, for example, an input pin is turned into
output as a result.
Created against linux-omap for-next,
commit 2963c21fab52bfa8227da7f22864db393ebbc858
Tested on Amstrad Delta
Compile tested with omap_generic_2420_defconfig
Signed-off-by: Janusz Krzysztofik
---
Tuesday 24 November 2009 08:59:23 Jarkko Nikula wrote:
+ OMAP_MCBSP_WRITE(io_base, SPCR2, reg_cache-spcr2 =
config-spcr2); + OMAP_MCBSP_WRITE(io_base, SPCR1,
reg_cache-spcr1
= config-spcr1);
...
- mcbsp-rx_word_length = (OMAP_MCBSP_READ(io_base, RCR1) 5)
0x7; -mcbsp-tx_word_length = (OMAP_MCBSP_READ(io_base, XCR1)
5) 0x7; + mcbsp-rx_word_length = (reg_cache-rcr1 5) 0x7;
+ mcbsp-tx_word_length = (reg_cache-xcr1 5) 0x7;
IMO these would be cleaner if you embed cache handling into read and
write functions only. Probably reading could have explicit _read and
read_cache functions when code is dealing with the status bits and when
just updating some cached bits.
Hi Jarkko,
Could you please have a look at this modified version? It seems to address
your comment above more or less closely.
Thanks,
Janusz
diff -upr git.orig/arch/arm/plat-omap/include/plat/mcbsp.h
git/arch/arm/plat-omap/include/plat/mcbsp.h
--- git.orig/arch/arm/plat-omap/include/plat/mcbsp.h2009-11-21
00:38:46.0 +0100
+++ git/arch/arm/plat-omap/include/plat/mcbsp.h 2009-11-24 02:38:32.0
+0100
@@ -415,6 +415,11 @@ struct omap_mcbsp {
u16 max_tx_thres;
u16 max_rx_thres;
#endif
+#ifdef CONFIG_ARCH_OMAP1
+ u16 reg_cache[OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1];
+#else
+ u32 reg_cache[OMAP_MCBSP_REG_RCCR / sizeof(u32) + 1];
+#endif
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
Only in git/arch/arm/plat-omap/include/plat: mcbsp.h.orig
diff -upr git.orig/arch/arm/plat-omap/mcbsp.c git/arch/arm/plat-omap/mcbsp.c
--- git.orig/arch/arm/plat-omap/mcbsp.c 2009-11-21 00:38:46.0 +0100
+++ git/arch/arm/plat-omap/mcbsp.c 2009-11-24 12:22:42.0 +0100
@@ -46,10 +46,21 @@ int omap_mcbsp_read(void __iomem *io_bas
return __raw_readl(io_base + reg);
}
-#define OMAP_MCBSP_READ(base, reg) \
- omap_mcbsp_read(base, OMAP_MCBSP_REG_##reg)
-#define OMAP_MCBSP_WRITE(base, reg, val) \
- omap_mcbsp_write(base, OMAP_MCBSP_REG_##reg, val)
+#define OMAP_MCBSP_READ(mcbsp, reg) \
+ omap_mcbsp_read(mcbsp-io_base, OMAP_MCBSP_REG_##reg)
+#define OMAP_MCBSP_WRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, val)
+
+#define OMAP_MCBSP_CREAD(mcbsp, reg) \
+ (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1])
+#define OMAP_MCBSP_CWRITE(mcbsp, reg, val) \
+ omap_mcbsp_write(mcbsp-io_base, OMAP_MCBSP_REG_##reg, \
+ mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
+ = val)
+
+#define OMAP_MCBSP_BREAD(mcbsp, reg) \
+ (mcbsp-reg_cache[OMAP_MCBSP_REG_##reg / OMAP_MCBSP_REG_DRR1] \
+ = OMAP_MCBSP_READ(mcbsp-io_base, reg))
#define omap_mcbsp_check_valid_id(id) (id omap_mcbsp_count)
#define id_to_mcbsp_ptr(id)mcbsp_ptr[id];
@@ -60,31 +71,31 @@ static void omap_mcbsp_dump_reg(u8 id)
dev_dbg(mcbsp-dev, McBSP%d regs \n, mcbsp-id);
dev_dbg(mcbsp-dev, DRR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR2));
+ OMAP_MCBSP_READ(mcbsp, DRR2));
dev_dbg(mcbsp-dev, DRR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DRR1));
+ OMAP_MCBSP_READ(mcbsp, DRR1));
dev_dbg(mcbsp-dev, DXR2: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR2));
+ OMAP_MCBSP_READ(mcbsp, DXR2));
dev_dbg(mcbsp-dev, DXR1: 0x%04x\n,
- OMAP_MCBSP_READ(mcbsp-io_base, DXR1));
+ OMAP_MCBSP_READ(mcbsp, DXR1));
dev_dbg(mcbsp-dev, SPCR2: 0x%04x\n,
-
RE: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tero Kristo
Sent: Tuesday, November 24, 2009 4:07 PM
To: linux-arm-ker...@lists.infradead.org
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 2/2] OMAP3: Implemented VFP restore/save context
From: Tero Kristo tero.kri...@nokia.com
VFP save context is called before MPU/NEON off. Restore is not needed as
the next VFP trap will restore context automatically. Uses the support
routine implemented in arch/arm/vfp/vfpmodule.c.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Tony Lindgren t...@atomide.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 21 -
2 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 4f22107..dd5bbaf 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -18,6 +18,7 @@ extern u32 sleep_while_idle;
extern u32 voltage_off_while_idle;
extern void *omap3_secure_ram_storage;
+extern void vfp_pm_save_context(void);
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap3_can_sleep(void);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b26ae5b..4b01303 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -321,6 +321,18 @@ static void restore_control_register(u32 val)
__asm__ __volatile__ (mcr p15, 0, %0, c1, c0, 0 : : r (val));
}
+static inline void omap3_save_neon_context(void)
+{
+#ifdef CONFIG_VFP
+ vfp_pm_save_context();
+#endif
+}
+
+static inline void omap3_restore_neon_context(void)
+{
+ return;
+}
+
/* Function to restore the table entry that was modified for enabling MMU */
static void restore_table_entry(void)
{
@@ -365,6 +377,7 @@ void omap_sram_idle(void)
/* save_state = 3 = L1, L2 and logic lost */
int save_state = 0;
int mpu_next_state = PWRDM_POWER_ON;
+ int neon_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
@@ -398,8 +411,12 @@ void omap_sram_idle(void)
pwrdm_pre_transition();
/* NEON control */
- if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
+ if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON) {
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ neon_next_state = mpu_next_state;
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_save_neon_context();
+ }
/* PER */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
@@ -537,6 +554,8 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ if (neon_next_state == PWRDM_POWER_OFF)
+ omap3_restore_neon_context();
Why do call restore here when restore is done automatically upon context switch?
pwrdm_post_transition();
}
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
Hi,
On Fri, 2009-11-20 at 15:27 +0100, ext Y, Kishore wrote:
From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
From: Mukund Mittal mmit...@ti.com
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
Nec panel has been added which is used on both
zoom2 and zoom3 boards
Please name the file and the driver with a bit more spesific name. Like
panel-nec-nl8048hl11-01b.c, if that is the code of the panel. I'm sure
there are many other panels from NEC also =).
And fix the copyright and author in the comment.
Tomi
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/displays/panel-nec.c | 291
++
1 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec.c
diff --git a/drivers/video/omap2/displays/panel-nec.c
b/drivers/video/omap2/displays/panel-nec.c
new file mode 100644
index 000..c18f3ba
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec.c
@@ -0,0 +1,291 @@
+/*
+ * NEC panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+#include linux/spi/spi.h
+
+#include mach/gpio.h
+#include mach/gpio.h
+#include plat/mux.h
+#include asm/mach-types.h
+#include plat/control.h
+
+#include plat/display.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+
+#define LCD_PIXCLOCK_MIN 21800 /* NEC MIN PIX Clock is 21.8MHz */
+#define LCD_PIXCLOCK_TYP 23800 /* Typical PIX clock is 23.8MHz */
+#define LCD_PIXCLOCK_MAX 25700 /* Maximum is 25.7MHz */
+
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCK LCD_PIXCLOCK_MIN
+
+
+/*NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
+OMAP_DSS_LCD_ONOFF;
+ dssdev-panel.timings = nec_panel_timings;
+ dssdev-panel.recommended_bpp = 16;
+
+ return 0;
+}
+
+static void nec_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mdelay(4);
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
+}
+
+static void nec_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+ mdelay(4);
+}
+
+static int nec_panel_suspend(struct omap_dss_device *dssdev)
+{
+ nec_panel_disable(dssdev);
+ return 0;
+}
+
+static int nec_panel_resume(struct omap_dss_device *dssdev)
+{
+ return nec_panel_enable(dssdev);
+}
+
+static struct omap_dss_driver nec_driver = {
+ .probe = nec_panel_probe,
+ .remove = nec_panel_remove,
+
+ .enable = nec_panel_enable,
+ .disable= nec_panel_disable,
+ .suspend= nec_panel_suspend,
+ .resume = nec_panel_resume,
+
+ .driver = {
+ .name = NEC_panel,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int
+spi_send(struct spi_device *spi, unsigned char reg_addr, unsigned char
reg_data)
+{
+ int ret = 0;
+ unsigned int cmd = 0;
+ unsigned int data = 0;
+
+ cmd = 0x | reg_addr; /* register address write */
+ data = 0x0100 | reg_data ; /* register data write */
+ data = (cmd 16) | data;
+ if (spi_write(spi, (unsigned char *)data, 4))
+ printk(KERN_WARNING error in spi_write %x\n, data);
+
Re: [PATCH 1/2] ARM: Implemented support for VFP PM context saving
On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote: In some ARM architectures, like OMAP3, the VFP context can be lost during dynamic sleep cycle. For this purpose, there is now a function vfp_pm_save_context() that should be called before the VFP is assumed to lose context. Next VFP trap will then restore context automatically. We need to have the last_VFP_context[cpu] cleared after the save in idle, else the restore would fail to restore when it sees that the last_VFP_context is same as the current threads vfp_state. This happens when the same process/thread traps an exception post idle. Main work for this patch was done by Peter and Rajendra. Some cleanup and optimization by Tero. Why not re-use vfp_pm_suspend() ? Haven't you shown that vfp_pm_suspend may be buggy since it doesn't save in the VFP-disabled case? -- To unsubscribe from this list: send the line unsubscribe 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] rtc: make rtc-omap wakeup capable
The rtc-omap driver currently hardcodes the RTC to be not capable of wakeup events. On the DA850/OMAP-L138 SoC, the RTC is a wake up source from its deep sleep mode. Let platform data set the wakeup capability flag instead. Signed-off-by: Sekhar Nori nsek...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- Applies to latest of Linus's tree. drivers/rtc/rtc-omap.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index 0587d53..ac9d55b 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -400,16 +400,11 @@ static int __init omap_rtc_probe(struct platform_device *pdev) /* BOARD-SPECIFIC CUSTOMIZATION CAN GO HERE: * -* - Boards wired so that RTC_WAKE_INT does something, and muxed -*right (W13_1610_RTC_WAKE_INT is the default after chip reset), -*should initialize the device wakeup flag appropriately. -* * - Boards wired so RTC_ON_nOFF is used as the reset signal, *rather than nPWRON_RESET, should forcibly enable split *power mode. (Some chip errata report that RTC_CTRL_SPLIT *is write-only, and always reads as zero...) */ - device_init_wakeup(pdev-dev, 0); if (new_ctrl (u8) OMAP_RTC_CTRL_SPLIT) pr_info(%s: split power mode\n, pdev-name); -- 1.6.2.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 1/2] ARM: Implemented support for VFP PM context saving
On Tue, 2009-11-24 at 11:48 +, Russell King - ARM Linux wrote: On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote: In some ARM architectures, like OMAP3, the VFP context can be lost during dynamic sleep cycle. For this purpose, there is now a function vfp_pm_save_context() that should be called before the VFP is assumed to lose context. Next VFP trap will then restore context automatically. We need to have the last_VFP_context[cpu] cleared after the save in idle, else the restore would fail to restore when it sees that the last_VFP_context is same as the current threads vfp_state. This happens when the same process/thread traps an exception post idle. Main work for this patch was done by Peter and Rajendra. Some cleanup and optimization by Tero. Why not re-use vfp_pm_suspend() ? Haven't you shown that vfp_pm_suspend may be buggy since it doesn't save in the VFP-disabled case? BTW, the two patches below were mentioned to me some time ago but I haven't got the time to look at them: [ARM] vfp: Fix bug in vfp_pm_suspend https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff [ARM] vfp: Add additional vfp interfaces https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 -- Catalin -- To unsubscribe from this list: send the line unsubscribe 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] ARM: Implemented support for VFP PM context saving
-Original Message- From: ext Catalin Marinas [mailto:catalin.mari...@arm.com] Sent: 24 November, 2009 15:20 To: Russell King - ARM Linux Cc: Kristo Tero (Nokia-D/Tampere); linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Dave Estes Subject: Re: [PATCH 1/2] ARM: Implemented support for VFP PM context saving On Tue, 2009-11-24 at 11:48 +, Russell King - ARM Linux wrote: On Tue, Nov 24, 2009 at 12:37:03PM +0200, Tero Kristo wrote: In some ARM architectures, like OMAP3, the VFP context can be lost during dynamic sleep cycle. For this purpose, there is now a function vfp_pm_save_context() that should be called before the VFP is assumed to lose context. Next VFP trap will then restore context automatically. We need to have the last_VFP_context[cpu] cleared after the save in idle, else the restore would fail to restore when it sees that the last_VFP_context is same as the current threads vfp_state. This happens when the same process/thread traps an exception post idle. Main work for this patch was done by Peter and Rajendra. Some cleanup and optimization by Tero. Why not re-use vfp_pm_suspend() ? Haven't you shown that vfp_pm_suspend may be buggy since it doesn't save in the VFP-disabled case? BTW, the two patches below were mentioned to me some time ago but I haven't got the time to look at them: [ARM] vfp: Fix bug in vfp_pm_suspend https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff [ARM] vfp: Add additional vfp interfaces https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=c ommit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 These look pretty much like the same thing we have attempted on the omap3 patches, I could try these out and check if they work for omap3 also. They fix the potentially broken suspend also. -Tero -- To unsubscribe from this list: send the line unsubscribe 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] Mux configuration for AM3517 TouchScreen support
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, November 23, 2009 11:23 PM
To: Hiremath, Vaibhav
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/3] Mux configuration for AM3517 TouchScreen
support
* hvaib...@ti.com hvaib...@ti.com [091119 06:45]:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/mux.c |3 +++
arch/arm/plat-omap/include/plat/mux.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index c18a94e..f64ce14 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -566,6 +566,9 @@ MUX_CFG_34XX(AF9_34XX_GPIO22, 0x5ec,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX(U3_34XX_GPIO61, 0x0c8,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
+ /*Touch-screen*/
+ MUX_CFG_34XX(U1_34XX_GPIO65, 0x0d2,
+ OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT_PULLUP)
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
diff --git a/arch/arm/plat-omap/include/plat/mux.h
b/arch/arm/plat-omap/include/plat/mux.h
index ba77de6..244afee 100644
--- a/arch/arm/plat-omap/include/plat/mux.h
+++ b/arch/arm/plat-omap/include/plat/mux.h
@@ -854,6 +854,7 @@ enum omap34xx_index {
AH14_34XX_GPIO21,
AF9_34XX_GPIO22,
U3_34XX_GPIO61,
+ U1_34XX_GPIO65,
};
struct omap_mux_cfg {
Let's put this on hold until we have the new mux framework
up and running. This should not stop getting in the driver
patch integrated.
[Hiremath, Vaibhav] Ok.
Thanks,
Vaibhav
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 3/3] AM3517: Add support for TSC2004 driver
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, November 23, 2009 11:25 PM
To: Hiremath, Vaibhav
Cc: linux-in...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: Re: [PATCH 3/3] AM3517: Add support for TSC2004 driver
Hi,
* hvaib...@ti.com hvaib...@ti.com [091119 06:46]:
From: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 62
+
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 415a13d..ae47b51 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,8 @@
#include linux/init.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/irq.h
+#include linux/i2c/tsc2004.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -27,10 +29,64 @@
#include asm/mach/map.h
#include plat/board.h
+#include plat/mux.h
#include plat/common.h
#include plat/usb.h
/*
+ * TSC 2004 Support
+ */
+#defineGPIO_TSC2004_IRQ65
+
+static int tsc2004_init_irq(void)
+{
+ int ret = 0;
+
+ ret = gpio_request(GPIO_TSC2004_IRQ, tsc2004-irq);
+ if (ret 0) {
+ printk(KERN_WARNING failed to request GPIO#%d: %d\n,
+ GPIO_TSC2004_IRQ, ret);
+ return ret;
+ }
+
+ if (gpio_direction_input(GPIO_TSC2004_IRQ)) {
+ printk(KERN_WARNING GPIO#%d cannot be configured as
+ input\n, GPIO_TSC2004_IRQ);
+ return -ENXIO;
+ }
+
+ omap_set_gpio_debounce(GPIO_TSC2004_IRQ, 1);
+ omap_set_gpio_debounce_time(GPIO_TSC2004_IRQ, 0xa);
+ return ret;
+}
+
+static void tsc2004_exit_irq(void)
+{
+ gpio_free(GPIO_TSC2004_IRQ);
+}
+
+static int tsc2004_get_irq_level(void)
+{
+ return gpio_get_value(GPIO_TSC2004_IRQ) ? 0 : 1;
+}
+
+struct tsc2004_platform_data am3517evm_tsc2004data = {
+ .model = 2004,
+ .x_plate_ohms = 180,
+ .get_pendown_state = tsc2004_get_irq_level,
+ .init_platform_hw = tsc2004_init_irq,
+ .exit_platform_hw = tsc2004_exit_irq,
+};
+
+static struct i2c_board_info __initdata
am3517evm_tsc_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO(tsc2004, 0x4B),
+ .type = tsc2004,
+ .platform_data = am3517evm_tsc2004data,
+ },
+};
+
+/*
* Board initialization
*/
static struct omap_board_config_kernel am3517_evm_config[]
__initdata = {
@@ -67,6 +123,12 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(ehci_pdata);
+
+ /* TSC 2004 */
+ omap_cfg_reg(U1_34XX_GPIO65);
+ am3517evm_tsc_i2c_boardinfo[0].irq =
gpio_to_irq(GPIO_TSC2004_IRQ);
+ i2c_register_board_info(1, am3517evm_tsc_i2c_boardinfo,
+ ARRAY_SIZE(am3517evm_tsc_i2c_boardinfo));
}
static void __init am3517_evm_map_io(void)
Can you please leave out the omap_cfg_reg call for new mux registers
from this patch? This way it will still compile and we can patch
in the muxing later on.
[Hiremath, Vaibhav] I will resubmit the patch excluding omap_cfg_reg statement.
As of now, I can handle this in u-boot to test, till we don't migrate to new
mux framework.
Thanks,
Vaibhav
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: DVFS: No sdrc AC timing changes during core dvfs
Hi, Is there any update on this chain seeing this has been pending for a month now? -Tero -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext Woodruff, Richard Sent: 22 October, 2009 15:20 To: Cousson, Benoit; Paul Walmsley; Nayak, Rajendra Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs Hi Beonit, From: Cousson, Benoit Sent: Thursday, October 22, 2009 3:59 AM To: Woodruff, Richard; Paul Walmsley; Nayak, Rajendra It is not guaranteed safe to write actim registers on the fly to an active part. It is safe to do RFR as it is buffered and sent out at a safe time. I think that what Paul is suggesting is to change the ACTIM after ensuring that the DDR is in self-refresh. In that case it is perfectly valid; it is just tricky to ensure that all initiators are in mute before doing that. Yes that is true, however, ... That is not the way the code is setup and it's a long way from that. Run time pause of drivers is a minefield. With out a broad notifier they best you would hope for is some opportunistic change time (against full system). You wouldn't have a guaranteed way to speed them up again where you need them most at high opp. Some minimal kernel not using dma and the like could do it but that is probably more misleading to put in the tree than something useful for most. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe 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
Enabling HSUSB1 port on OMAP3430 labrador
Dear All, We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host. To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT). I have all these USB related kernel config options enabled: USB_EHCI_HCD USB_OHCI_HCD USB_MUSB_HDRC TWL4030_USB My guess was that either EHCI or the Inventra should be the one enabling that USB port on the OMAP, but no luck. The external USB port on the MDK works fine with this configuration. The pin multiplexing configuration in the board file omap3430-labrador.c in u-boot also seems to be correct (although the config of USB1_STP seems to be strange, but changing that didn't work either). My assumption is that the ISP1507A does not need support from the kernel, as it acts as an ULPI transceiver only, but please correct me on this point if wrong. What happens is that after connecting an USB mouse is that the LED is on for a sec, but nothing is written in the kernel log. We can see that the transceiver is generating a clock signal, but for some reason, the STP is constantly high. I've also tried setting the port to PHY or TLL, but didn't help. I guess PHY is the correct setting in this situation, right? Note, the ISP1507A is connected to the following pins of the BGA: HSUSB1_STP (AF10) HSUSB1_CLK (AE10) HSUSB1_DIR (AF9) HSUSB1_NXP (AG9) HSUSB1_D0 (AF11) HSUSB1_D1 (AG12) HSUSB1_D2 (AH12) HSUSB1_D3 (AH14) HSUSB1_D4 (AE11) HSUSB1_D5 (AH9) HSUSB1_D6 (AF13) HSUSB1_D7 (AE13) Any suggestion on making this work is greatly appreciated. Thanks for your help, Peter -- To unsubscribe from this list: send the line unsubscribe 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/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote: Here is the v6 of this patch series. I am cc'ing mtd list too this time. From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Thu, 19 Nov 2009 19:28:11 +0530 This patch series adds flash support for NAND (in sdp, zoom and ldp), OneNAND and NOR (in sdp) Tested on Zoom2 and 3430SDP Vimal Singh (4): [PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards [PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards [PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig [PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig Is it possible to separate the MTD and OMAP parts? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP3: enabling CPU idle leads to panic
Hi, all! I use PM branch merged with linux-omap branch. A board is custom, so I can't bisect this problem (and I don't know latest working revision). It seems that's because missing clock domain somewhere, [16515.695617] Unable to handle kernel NULL pointer dereference at virtual address 0020 [16515.703735] pgd = c0004000 [16515.706481] [0020] *pgd= [16515.710083] Internal error: Oops: 5 [#1] PREEMPT [16515.714721] last sysfs file: [16515.717712] Modules linked in: [16515.720794] CPU: 0Not tainted (2.6.32-rc8-07113-g318afc6 #110) [16515.727111] PC is at pwrdm_for_each_clkdm+0x34/0x88 [16515.731994] LR is at pwrdm_for_each_clkdm+0x24/0x88 [16515.736907] pc : [c003b5c0]lr : [c003b5b0]psr: 60d3 [16515.736938] sp : c03f3f68 ip : fa004800 fp : [16515.748474] r10: c003e81c r9 : 411fc082 r8 : [16515.753723] r7 : a0d3 r6 : r5 : 0004 r4 : 0001 [16515.760284] r3 : 0002 r2 : c03f2000 r1 : 0001 r0 : [16515.766845] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [16515.774383] Control: 10c5387d Table: 80004019 DAC: 0017 [16515.780151] Process swapper (pid: 0, stack limit = 0xc03f22e8) [16515.786010] Stack: (0xc03f3f68 to 0xc03f4000) [16515.790405] 3f60: c042e4bc 0003 0003 c042e4bc 80026398 411fc082 [16515.798645] 3f80: 001f c003e76c c022f284 00271d5a 0005 0ec00c5c [16515.806854] 3fa0: c03f8640 c03f8710 c042dadc c03f8640 c0474d0c c022dee8 c03f2000 c042dadc [16515.815093] 3fc0: c0027e14 c03f5bd0 80026398 c002f49c c0459fa4 c0008914 c0008478 [16515.82] 3fe0: c0027e18 10c53c7d c042dbf0 80008034 [16515.831573] [c003b5c0] (pwrdm_for_each_clkdm+0x34/0x88) from [c003e76c] (omap3_enter_idle+0xc0/0x15c) [16515.841217] [c003e76c] (omap3_enter_idle+0xc0/0x15c) from [c022dee8] (cpuidle_idle_call+0xa4/0x180) [16515.850677] [c022dee8] (cpuidle_idle_call+0xa4/0x180) from [c002f49c] (cpu_idle+0x48/0x98) [16515.859344] [c002f49c] (cpu_idle+0x48/0x98) from [c0008914] (start_kernel+0x250/0x2a8) [16515.867675] [c0008914] (start_kernel+0x250/0x2a8) from [80008034] (0x80008034) [16515.875274] Code: e3a06000 e1a05008 e1a04006 ea02 (e595101c) [16515.881530] ---[ end trace f0a89c74ea639f01 ]--- [16515.886230] Kernel panic - not syncing: Attempted to kill the idle task! addr2line -e vmlinux c003b5c0 /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452 It is in function int pwrdm_for_each_clkdm(), where pwrdm is NULL. farther investigations found that core_pwrdm is defined only for 24xx, but I use 3525, and it is being searched. This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here. arch/arm/mach-omap2/cpuidle34xx.c:348: core_pd = pwrdm_lookup(core_pwrdm); Otherwise it crashes the above way. Any ideas on how to fix this? S. -- To unsubscribe from this list: send the line unsubscribe 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 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c
Hi,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of ext
Sonasath, Moiz
Sent: 23. marraskuuta 2009 18:10
To: Kalle Jokiniemi
Cc: khil...@deeprootsystems.com; linux-omap@vger.kernel.org;
Jarkko Nikula; Paul Walmsley; Menon, Nishanth; Pandita,
Vikram; Hogander Jouni (Nokia-D/Tampere)
Subject: RE: [PATCH V4 3/3] OMAP: I2C: Add mpu wake up
latency constraint in i2c
snip-snip
Well, I don't completely agree with the necessity of preparing for
different rx/tx thresholds. For this to make sense, the i2c-omap
driver should first separate in it's code the use of rx and tx
thresholds. If someone is planning to do that, he/she should anyway
update the usage of fifo_size throughout the code,
including the wake up latency setting.
Anyways, attached a patch that separates the mpu wake up
latencies for
rx and tx. In case that is needed. Though I'm not for it, since it
adds unneeded complexity.
Yes Kalle, you are right! Not having different RX/TX wake-up
latencies will absolutely work fine with the in-place code as
we have both the RX/TX thresholds same.
Great :)
But, I think in
future we might have to play around with different RX/TX
thresholds and so from a conceptually right and generic point
of view it makes sense to incur the cost of the added complexity.
I agree. Once someone differentiates the thresholds in the driver, it very much
makes sense to also calculate different mpu wake up latencies for RX and TX.
The patch V4 looks perfect to me :)
Great :)
So, where do we push it?
- Kalle
- Moiz
- Kalle
/* reset ASAP, clearing any IRQs */ diff --git
a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h new file
mode 100644 index 000..1362fba
--- /dev/null
+++ b/include/linux/i2c-omap.h
@@ -0,0 +1,9 @@
+#ifndef __I2C_OMAP_H__
+#define __I2C_OMAP_H__
+
+struct omap_i2c_bus_platform_data {
+ u32 clkrate;
+ void(*set_mpu_wkup_lat)(struct
device *dev, int set);
+};
+
+#endif
--
1.5.4.3
Regards
Moiz Sonasath
--
To unsubscribe from this list: send the line unsubscribe
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 1/2] ARM: Implemented support for VFP PM context saving
On Tue, Nov 24, 2009 at 01:20:26PM +, Catalin Marinas wrote: BTW, the two patches below were mentioned to me some time ago but I haven't got the time to look at them: [ARM] vfp: Fix bug in vfp_pm_suspend https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=88984c9b2d69c222ee1e2afc948ca73f597d40ff This one is bad - it gets the current CPU by directly referencing ti-cpu. Too bad if you have kernel preemption enabled; the value obtained that way is effectively meaningless. The only way to get a meaningful value is via 'get_cpu()' and after you've done with using it, 'put_cpu()'. That ensures you can't be preempted onto a different CPU mid-operation. It's safe in vfp_notifier because we're called in an already atomic context. [ARM] vfp: Add additional vfp interfaces https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=393e4bfaaf79377d29cd6bb2228f87601aeca668 I don't like what's in this one. Lack of explaination in the commit log doesn't help. -- To unsubscribe from this list: send the line unsubscribe 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/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
On Tue, Nov 24, 2009 at 8:36 PM, Artem Bityutskiy dedeki...@gmail.com wrote: On Thu, 2009-11-19 at 19:38 +0530, Vimal Singh wrote: Here is the v6 of this patch series. I am cc'ing mtd list too this time. From 8bc97108cf9c78216f1ea5407ccbd900e6b63dc2 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Thu, 19 Nov 2009 19:28:11 +0530 This patch series adds flash support for NAND (in sdp, zoom and ldp), OneNAND and NOR (in sdp) Tested on Zoom2 and 3430SDP Vimal Singh (4): [PATCH-v6 1/4] OMAP2/3: Add support for flash on SDP boards [PATCH-v6 2/4] OMAP3: Add support for NAND on ZOOM/LDP boards [PATCH-v6 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig [PATCH-v6 4/4] OMAP: 3430SDP: Enable NAND in defconfig Is it possible to separate the MTD and OMAP parts? 1st patch does migration of gpmc low level calls from omap2.c to gpmc-nand.c. I am not sure how we can have separate patches for this. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe 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 3/3] OMAP: I2C: Add mpu wake up latency constraint in i2c
kalle.jokini...@nokia.com writes: The patch V4 looks perfect to me :) Great :) So, where do we push it? I suggest to Ben Dooks (i2c maintainer for embedded platforms) and to linux-i2c list. Also Cc linux-omap. From MAINTAINERS: I2C SUBSYSTEM M: Jean Delvare (PC drivers, core) kh...@linux-fr.org M: Ben Dooks (embedded platforms) ben-li...@fluff.org L: linux-...@vger.kernel.org W: http://i2c.wiki.kernel.org/ T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/ S: Maintained F: Documentation/i2c/ F: drivers/i2c/ F: include/linux/i2c.h F: include/linux/i2c-dev.h F: include/linux/i2c-id.h Also, FYI... in recent kernels there is a scripts/get_maintainer.pl script. If you run a patch through that script, it will spit out a list of folks to send the patch to. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Friday, November 20, 2009 7:58 PM
To: linux-omap@vger.kernel.org
Subject: [PATCH 2/5] ZOOM: DSS2: Add nec panel for zoom display
From df64194feedc16c3f3f552dc26bc3050b7245005 Mon Sep 17 00:00:00 2001
From: Mukund Mittal mmit...@ti.com
Date: Fri, 20 Nov 2009 18:35:26 +0530
Subject: [PATCH] ZOOM: DSS2: Add nec panel for zoom display
Nec panel has been added which is used on both
zoom2 and zoom3 boards
Signed-off-by: Kishore Y kishor...@ti.com
---
drivers/video/omap2/displays/panel-nec.c | 291
++
1 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-nec.c
diff --git a/drivers/video/omap2/displays/panel-nec.c
b/drivers/video/omap2/displays/panel-nec.c
new file mode 100644
index 000..c18f3ba
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-nec.c
@@ -0,0 +1,291 @@
+/*
+ * NEC panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it
and/or modify it
+ * under the terms of the GNU General Public License version
2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be
useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public
License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+#include linux/spi/spi.h
+
+#include mach/gpio.h
This will break the build since header files are moved to plat-omap.
+#include mach/gpio.h
Remove this.
+#include plat/mux.h
+#include asm/mach-types.h
+#include plat/control.h
+
Remove extra line.
+#include plat/display.h
+
+#define LCD_XRES 800
+#define LCD_YRES 480
+
Remove extra line.
+#define LCD_PIXCLOCK_MIN 21800 /* NEC MIN PIX
Clock is 21.8MHz */
+#define LCD_PIXCLOCK_TYP 23800 /* Typical PIX
clock is 23.8MHz */
+#define LCD_PIXCLOCK_MAX 25700 /* Maximum is 25.7MHz */
+
-Ditto-
+/* Current Pixel clock */
+#define LCD_PIXEL_CLOCK LCD_PIXCLOCK_MIN
+
+
-Ditto-
+/*NEC NL8048HL11-01B Manual
+ * defines HFB, HSW, HBP, VFP, VSW, VBP as shown below
+ */
+
+static struct omap_video_timings nec_panel_timings = {
+ /* 800 x 480 @ 60 Hz Reduced blanking VESA CVT 0.31M3-R */
+ .x_res = LCD_XRES,
+ .y_res = LCD_YRES,
+ .pixel_clock= LCD_PIXEL_CLOCK,
+ .hfp= 6,
+ .hsw= 1,
+ .hbp= 4,
+ .vfp= 3,
+ .vsw= 1,
+ .vbp= 4,
+};
+
+static int nec_panel_probe(struct omap_dss_device *dssdev)
+{
+ dssdev-panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_IVS |
+OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_RF |
+OMAP_DSS_LCD_ONOFF;
Checkpatch error - ERROR: code indent should use tabs where possible
+ dssdev-panel.timings = nec_panel_timings;
+ dssdev-panel.recommended_bpp = 16;
+
+ return 0;
+}
This function will always return zero. Either check for sanity of function
Parameters or change return value of the API to void.
+
+static void nec_panel_remove(struct omap_dss_device *dssdev)
+{
+}
+
+static int nec_panel_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ mdelay(4);
Add comment to justify the delay values used.
+ if (dssdev-platform_enable)
+ r = dssdev-platform_enable(dssdev);
+
+ return r;
dssdev parameter is never used inside platform_enable.
I guess platform_enable will always return zero. Please take care
of error checking conditions.
+}
+
+static void nec_panel_disable(struct omap_dss_device *dssdev)
+{
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
dssdev parameter is never used inside platform_disable
+ mdelay(4);
Add comment to justify the delay values used.
+}
+
+static int nec_panel_suspend(struct omap_dss_device *dssdev)
+{
+ nec_panel_disable(dssdev);
+ return 0;
+}
No error checking. Always returns zero.
+
+static int nec_panel_resume(struct omap_dss_device *dssdev)
+{
+ return nec_panel_enable(dssdev);
+}
dssdev parameter is never used inside nec_panel_enable(...)
No error checking. Always returns zero.
+
+static struct omap_dss_driver nec_driver = {
+ .probe = nec_panel_probe,
+ .remove
RE: Enabling HSUSB1 port on OMAP3430 labrador
Kovacs Peter Tamas wrote: Sent: Tuesday, November 24, 2009 8:04 PM To: linux-omap@vger.kernel.org Subject: Enabling HSUSB1 port on OMAP3430 labrador Dear All, We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host. To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT). I have all these USB related kernel config options enabled: USB_EHCI_HCD USB_OHCI_HCD USB_MUSB_HDRC TWL4030_USB My guess was that either EHCI or the Inventra should be the one enabling that USB port on the OMAP, but no luck. The external USB port on the MDK works fine with this configuration. The pin multiplexing configuration in the board file omap3430-labrador.c in u-boot also seems to be correct (although the config of USB1_STP seems to be strange, but changing that didn't work either). HSUSB1 is not supposed to be used with the labrador (do you have a link to the board schematics with the mods?). HSUSB1 is the EHCI port. Not sure why the pad conf is done in u-boot for this board, but maybe it was a copy-paste thing. That being said, if you've got the part installed correctly, it ought to work. My assumption is that the ISP1507A does not need support from the kernel, as it acts as an ULPI transceiver only, but please correct me on this point if wrong. No support is needed for this part - it's supposed to work transparently. However there is an errata for this part for use with the input clocking mode - you need to delay the STP signal a little (to avoid CRC errors). See the errata doc from NXP. What happens is that after connecting an USB mouse is that the LED is on for a sec, but nothing is written in the kernel log. If it's EHCI, you won't be able to use a USB mouse (it's a low-speed device). EHCI on OMAP3 supports high-speed only. You'll need to plug in a high-speed device, or a hub with a built-in transaction translator. We can see that the transceiver is generating a clock signal, but for some reason, the STP is constantly high. I've also tried setting the port to PHY or TLL, but didn't help. I guess PHY is the correct setting in this situation, right? PHY mode is the correct setting for this, yes. Note, the ISP1507A is connected to the following pins of the BGA: HSUSB1_STP (AF10) HSUSB1_CLK (AE10) HSUSB1_DIR (AF9) HSUSB1_NXP (AG9) HSUSB1_D0 (AF11) HSUSB1_D1 (AG12) HSUSB1_D2 (AH12) HSUSB1_D3 (AH14) HSUSB1_D4 (AE11) HSUSB1_D5 (AH9) HSUSB1_D6 (AF13) HSUSB1_D7 (AE13) These are the pads for EHCI. So I suppose that's what you're trying to use. Note that EHCI on the OMAP3 supports only the input clocking mode. This might mean you need to check if you've configured the PHY correctly for this mode. (No XTAL required, OMAP provides the clock to the PHY). NXP seems to have removed all mention of this mode from their data sheets, so you might want to check with them. Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line? On the 3430 SDP, we use the ISP1504C PHY (same family - very similar behavior as the 1507). To make it work, we need to hold the PHY in reset until after the EHCI controller was configured. This could be done by using the PHY's reset line (early boards had this) or by using the CHIP_SEL_n line (newer boards). Any suggestion on making this work is greatly appreciated. Thanks for your help, Peter Regards, Anand-- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote: -Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Monday, November 23, 2009 10:36 PM To: Govindraj; g...@lixom.net Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj; G, Manjunath Kondaiah Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Govindaj, I'm having problems with these patches on Zoom2 with debug board, since they don't seem to coexist very well together with 8250. Enabling both options will result in build errors. Why do we need to enable both 8250 and omap-serial for console. The console UART can be either external UART or any one of the omap UART right? You should allow both of them to be enabled at the same time, so the same kernel can for example be booted on a ZOOM2 with debug board attached (8250 on GPMC), or on a beagle/overo board. Making them exclusive would be a step backwards. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/1] omap3: cpuidle: Update statistics for correct state
This is a fresh look at the problem [1] discussed earlier. Generic approach here is same; but the 'valid' flag for the target state is verified in omap3_enter_idle_bm(). If the valid flag == 0, we look for next (lower) state with valid flag == 1. Have tried to optimize the look-up without loosing readability. Sanjeev Premi (1): omap3: cpuidle: Update statistics for correct state arch/arm/mach-omap2/cpuidle34xx.c | 98 ++--- arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c |4 ++ 3 files changed, 95 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/1] omap3: cpuidle: Update statistics for correct state
When 'enable_off_mode' is 0, the target power state for MPU
and CORE was locally changed to PWRDM_POWER_RET but, the
statistics are updated for idle state originally selected
by the governor.
This patch 'invalidates' the idle states that lead either of
MPU or Core to PWRDM_POWER_OFF state when 'enable_off_mode'
is '0'. The states are valid once 'enable_off_mode' is set
to '1'.
Added function next_valid_state() to check if current state
is valid; else get the next valid state. It is called from
omap3_enter_idle_bm().
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 98 ++---
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c |4 ++
3 files changed, 95 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index fdfa1d5..308865c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -45,6 +45,8 @@
#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core RET */
#define OMAP3_STATE_C7 6 /* C7 - MPU OFF + Core OFF */
+#define OMAP3_STATE_MAX OMAP3_STATE_C7
+
struct omap3_processor_cx {
u8 valid;
u8 type;
@@ -128,13 +130,6 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
local_irq_disable();
local_fiq_disable();
- if (!enable_off_mode) {
- if (mpu_state PWRDM_POWER_RET)
- mpu_state = PWRDM_POWER_RET;
- if (core_state PWRDM_POWER_RET)
- core_state = PWRDM_POWER_RET;
- }
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -164,6 +159,65 @@ return_sleep_time:
return (u32)timespec_to_ns(ts_idle)/1000;
}
+
+/* next_valid_state - Find next valid c-state
+ * @dev: cpuidle device
+ * @state: Currently selected c-state
+ *
+ * If the current state is valid, it is returned back to the caller.
+ * Else, this function searches for a lower c-state which is still
+ * valid (as defined in omap3_power_states[]).
+ */
+static struct cpuidle_state* next_valid_state(struct cpuidle_device *dev,
+ struct cpuidle_state *curr)
+{
+ struct cpuidle_state *next = NULL;
+ struct omap3_processor_cx *cx;
+
+ cx = (struct omap3_processor_cx *)cpuidle_get_statedata(curr);
+
+ /* Check if current state is valid */
+ if (cx-valid) {
+ next = curr;
+ }
+ else {
+ u8 idx = OMAP3_STATE_MAX;
+
+ /* Reach the current state starting at highest C-state */
+ for (; idx = OMAP3_STATE_C1; idx--) {
+ if (dev-states[idx] == curr) {
+ next = dev-states[idx];
+ break;
+ }
+ }
+
+ /*
+* Should never hit this condition.
+*/
+ BUG_ON(next == NULL);
+
+ /* Drop to next valid state.
+* Start search from the next (lower) state.
+*/
+ idx--;
+ for (; idx = OMAP3_STATE_C1; idx--) {
+ if (((struct omap3_processor_cx *)
+ cpuidle_get_statedata(
+ dev-states[idx]))-valid) {
+ next = dev-states[idx];
+ break;
+ }
+ }
+ /*
+* C1 and C2 are always valid.
+* So, no need to check for 'next==NULL' outside this loop.
+*/
+ }
+
+ return next;
+}
+
+
/**
* omap3_enter_idle_bm - Checks for any bus activity
* @dev: cpuidle device
@@ -176,7 +230,7 @@ return_sleep_time:
static int omap3_enter_idle_bm(struct cpuidle_device *dev,
struct cpuidle_state *state)
{
- struct cpuidle_state *new_state = state;
+ struct cpuidle_state *new_state= next_valid_state(dev, state);
if ((state-flags CPUIDLE_FLAG_CHECK_BM) omap3_idle_bm_check()) {
BUG_ON(!dev-safe_state);
@@ -207,6 +261,32 @@ void omap3_pm_init_cpuidle(struct cpuidle_params
*cpuidle_board_params)
return;
}
+/**
+ * omap3_cpuidle_update_states - Update the cpuidle states.
+ *
+ * Currently, this function toggles the validity of idle states based upon
+ * the flag 'enable_off_mode'. When the flag is set all states are valid.
+ * Else, states leading to OFF state set to be invalid.
+ */
+void omap3_cpuidle_update_states(void)
+{
+ int i;
+
+ for (i = OMAP3_STATE_C1; i OMAP3_MAX_STATES; i++) {
+ if (enable_off_mode) {
+ omap3_power_states[i].valid = 1;
+ }
+ else {
+ if ((omap3_power_states[i].mpu_state
+
RE: [PATCHv2 0/1] omap3: cpuidle: Update statistics for correct state
-Original Message- From: Premi, Sanjeev Sent: Tuesday, November 24, 2009 11:20 PM To: linux-omap@vger.kernel.org Cc: Premi, Sanjeev Subject: [PATCHv2 0/1] omap3: cpuidle: Update statistics for correct state This is a fresh look at the problem [1] discussed earlier. Generic approach here is same; but the 'valid' flag for the target state is verified in omap3_enter_idle_bm(). If the valid flag == 0, we look for next (lower) state with valid flag == 1. Have tried to optimize the look-up without loosing readability. Missed this in my message: [1] http://marc.info/?l=linux-omapm=125214460417989w=2 Sanjeev Premi (1): omap3: cpuidle: Update statistics for correct state arch/arm/mach-omap2/cpuidle34xx.c | 98 ++--- arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c |4 ++ 3 files changed, 95 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP: hwmod: allow idle after HWMOD_INIT_NO_IDLE
If an omap_hwmod is setup using HWMOD_INIT_NO_IDLE flag, there is
currently way to idle it since omap_hwmod_idle() requires the hwmod to
be in the enabled state.
This patch adds a check to omap_hwmod_idle() so if the hwmod was has
the INIT_NO_IDLE flag, calling omap_hwmod_idle() will still succeed.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/omap_hwmod.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c5c4ddc..0cdcbdc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -869,7 +869,13 @@ static int _enable(struct omap_hwmod *oh)
*/
static int _idle(struct omap_hwmod *oh)
{
- if (oh-_state != _HWMOD_STATE_ENABLED) {
+ /*
+* To idle, hwmod must be enabled, EXCEPT if hwmod was
+* initialized using the INIT_NO_IDLE flag. In this case it
+* will not yet be enabled so we have to allow it to be idled.
+*/
+ if ((oh-_state != _HWMOD_STATE_ENABLED)
+ !(oh-flags HWMOD_INIT_NO_IDLE)) {
WARN(1, omap_hwmod: %s: idle state can only be entered from
enabled state\n, oh-name);
return -EINVAL;
@@ -884,6 +890,9 @@ static int _idle(struct omap_hwmod *oh)
oh-_state = _HWMOD_STATE_IDLE;
+ /* Clear init flag which should only affect first call to idle */
+ oh-flags = ~HWMOD_INIT_NO_IDLE;
+
return 0;
}
--
1.6.5.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 5/8] OMAP: omap_device: add usecounting
On Wed, Nov 18, 2009 at 2:51 AM, Paul Walmsley p...@pwsan.com wrote: Hello Kevin, On Tue, 17 Nov 2009, Kevin Hilman wrote: Add use counters to omap_device to enable multiple potential users of an omap_device. This is needed if ever there are multiple users or multiple instances of a driver with a single omap_device. Without usecounting, with multiple users, the first one to call idle may forcibly idle the device while other users are still active. Could you please send along an example of the use case for this? I would prefer not to add usecounting at this layer unless it is absolutely necessary, since only one driver should be bound to a device at a time. OK, after some more wrangling with the UART layer, I don't think I will need this patch. If an omap_device is bound to a single driver, the driver itself can do the usecounting and will be more effecient when doing so. Note however that this will prevent any direct replacement of clk_enable/disable with omap_device_enable/disable since some drivers are built on the assumption that the clk API does usecounting. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3: enabling CPU idle leads to panic
Sergey Lapin slapi...@gmail.com writes: I use PM branch merged with linux-omap branch. Not sure what this means. PM branch is already based at linux-omap master branch. You'll need to be more specific, ideally with commit IDs. A board is custom, so I can't bisect this problem (and I don't know latest working revision). It seems that's because missing clock domain somewhere, [16515.695617] Unable to handle kernel NULL pointer dereference at virtual address 0020 [16515.703735] pgd = c0004000 [16515.706481] [0020] *pgd= [16515.710083] Internal error: Oops: 5 [#1] PREEMPT [16515.714721] last sysfs file: [16515.717712] Modules linked in: [16515.720794] CPU: 0Not tainted (2.6.32-rc8-07113-g318afc6 #110) [16515.727111] PC is at pwrdm_for_each_clkdm+0x34/0x88 [16515.731994] LR is at pwrdm_for_each_clkdm+0x24/0x88 [16515.736907] pc : [c003b5c0]lr : [c003b5b0]psr: 60d3 [16515.736938] sp : c03f3f68 ip : fa004800 fp : [16515.748474] r10: c003e81c r9 : 411fc082 r8 : [16515.753723] r7 : a0d3 r6 : r5 : 0004 r4 : 0001 [16515.760284] r3 : 0002 r2 : c03f2000 r1 : 0001 r0 : [16515.766845] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [16515.774383] Control: 10c5387d Table: 80004019 DAC: 0017 [16515.780151] Process swapper (pid: 0, stack limit = 0xc03f22e8) [16515.786010] Stack: (0xc03f3f68 to 0xc03f4000) [16515.790405] 3f60: c042e4bc 0003 0003 c042e4bc 80026398 411fc082 [16515.798645] 3f80: 001f c003e76c c022f284 00271d5a 0005 0ec00c5c [16515.806854] 3fa0: c03f8640 c03f8710 c042dadc c03f8640 c0474d0c c022dee8 c03f2000 c042dadc [16515.815093] 3fc0: c0027e14 c03f5bd0 80026398 c002f49c c0459fa4 c0008914 c0008478 [16515.82] 3fe0: c0027e18 10c53c7d c042dbf0 80008034 [16515.831573] [c003b5c0] (pwrdm_for_each_clkdm+0x34/0x88) from [c003e76c] (omap3_enter_idle+0xc0/0x15c) [16515.841217] [c003e76c] (omap3_enter_idle+0xc0/0x15c) from [c022dee8] (cpuidle_idle_call+0xa4/0x180) [16515.850677] [c022dee8] (cpuidle_idle_call+0xa4/0x180) from [c002f49c] (cpu_idle+0x48/0x98) [16515.859344] [c002f49c] (cpu_idle+0x48/0x98) from [c0008914] (start_kernel+0x250/0x2a8) [16515.867675] [c0008914] (start_kernel+0x250/0x2a8) from [80008034] (0x80008034) [16515.875274] Code: e3a06000 e1a05008 e1a04006 ea02 (e595101c) [16515.881530] ---[ end trace f0a89c74ea639f01 ]--- [16515.886230] Kernel panic - not syncing: Attempted to kill the idle task! addr2line -e vmlinux c003b5c0 /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452 It is in function int pwrdm_for_each_clkdm(), where pwrdm is NULL. farther investigations found that core_pwrdm is defined only for 24xx, but I use 3525, and it is being searched. This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here. arch/arm/mach-omap2/cpuidle34xx.c:348:core_pd = pwrdm_lookup(core_pwrdm); Otherwise it crashes the above way. Any ideas on how to fix this? I think there is still ongoing work on support for the 3525. I'm guessing the clock/pwrdm init still needs work for that SoC. I have no 3525 hardware, but maybe Sanjeev has more details. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: omap_device: add to_omap_device() macro
Following the model of to_platform_device(), add to_omap_device()
macro so a platform_device pointer can be converted into an
omap_device pointer.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/omap_device.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 11a9773..d939246 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -137,5 +137,7 @@ struct omap_device_pm_latency {
};
-#endif
+/* Get omap_device pointer from platform_device pointer */
+#define to_omap_device(x) container_of((x), struct omap_device, pdev)
+#endif
--
1.6.5.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: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
Govindraj.R govindraj.r...@ti.com writes:
From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001
From: Govindraj R govindraj.r...@ti.com
Date: Fri, 13 Nov 2009 12:01:54 +0530
Subject: [PATCH] OMAP UART: Add omap-serial driver support.
This patch adds support for OMAP3430-HIGH SPEED UART Controller.
It adds support for the following features:
1. It supports Interrupt mode and DMA mode of operation.
2. Supports Hardware flow control and sofware flow control.
3. Debug Console support on all UARTs.
Signed-off-by: Govindraj R govindraj.r...@ti.com
Some general comments.
This should summarize how this is different from the 8250 driver on
which it was based, as it's clear that it was based on 8250 but not
clear at all what the changes are.
At first glance, you've dropped several features from the 8250 driver
which we currently use. Namely, the ability for platform code to
override some of the defaults:
- change irq_flags
- serial_in function
- optional ioremapping (omap_hwmod layer will have done ioremap already)
These are now hard-coded in the new driver which makes it
significantly less flexible.
In a few minutes I will be posting a set of patches to convert the
mach-omap2/serial.c to use omap_hwmod/omap_device. This replaces your
PATCH 2/3, so please use with any subsequent updates.
---
arch/arm/plat-omap/include/plat/omap-serial.h | 115 +++
drivers/serial/Kconfig| 23 +
drivers/serial/Makefile |1 +
drivers/serial/omap-serial.c | 1330
+
include/linux/serial_core.h |3 +
5 files changed, 1472 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/omap-serial.h
create mode 100644 drivers/serial/omap-serial.c
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
new file mode 100644
index 000..4341fae
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -0,0 +1,115 @@
+/*
+ * Driver for OMAP3430 UART controller.
This HW block is not unique to OMAP3.
+ * Copyright (C) 2009 Texas Instruments.
+ * Authors:
+ * Govindraj R govindraj.r...@ti.com
+ * Thara Gopinath th...@ti.com
+ *
You should acknowledge that this drier was heavily borrowed from the
current 8250 driver.
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __OMAP_SERIAL_H__
+#define __OMAP_SERIAL_H__
+
+#include linux/serial_core.h
+#include linux/platform_device.h
+
+#include plat/control.h
+#include plat/mux.h
+
+#define DRIVER_NAME omap-hsuart
but you use omap-uart in platform_driver below.
+/* *
+ * tty device name used by omap-serial driver,
+ * in bootargs we specify as console=ttyO0 if uart1
+ * is used as console uart.
+ */
+#define DEVICE_NAME ttyO
I've said this in each review now.
Why can't you stick to 'ttyS'? There is lots of
infrastructure/scripts/userspace/default commandlines/etc. that will
need to change if you change this.y
+/* *
+ * We default to IRQ0 for the no irq hack. Some
+ * machine types want others as well - they're free
+ * to redefine this in their header file.
+ */
+#define is_real_interrupt(irq) ((irq) != 0)
+
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#define OMAP_MDR1_DISABLE0x07
+#define OMAP_MDR1_MODE13X0x03
+#define OMAP_MDR1_MODE16X0x00
+#define OMAP_MODE13X_SPEED 230400
+
+#define CONSOLE_NAME console=
+
+#define RX_TIMEOUT (3 * HZ)
+
+/* To be removed while adding omap_hwmod support */
+#define OMAP_MAX_HSUART_PORTS 3
+
+struct uart_port_info {
+ booldma_enabled;
+ unsigned intuartclk;
+ };
Should this be uart_omap_port_info?
+struct uart_omap_dma {
+ u8 uart_dma_tx;
+ u8 uart_dma_rx;
+ int rx_dma_channel;
+ int tx_dma_channel;
+ /* Physical adress of RX DMA buffer */
+ dma_addr_t rx_buf_dma_phys;
+ /* Physical adress of TX DMA buffer */
+ dma_addr_t tx_buf_dma_phys;
+ /* *
+ * Buffer for rx dma.It is not required for tx because the buffer
+ * comes from port structure
+ */
+ unsigned intuart_base;
+ unsigned char *rx_buf;
+ unsigned intprev_rx_dma_pos;
+ int tx_buf_size;
+ int tx_dma_state;
+ int rx_dma_state;
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
+ /* timer to poll activity on rx dma */
+ struct timer_list rx_timer;
+ int
hwmod and PER going idle before WFI
Hi Paul,
In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.
Namely, in the idle path for PER we do disable the PER UART (via
omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via
omap3_per_save_context();
When switching to use omap_hwmod, I noticed via crashes and then via
lauterbach that as soon as UART3 clocks are disabled, PER goes idle.
This causes the subsequent GPIO context save to fault since PER has
gone idle.
I seem to remember having a similar problem before when the problem
was in the management of autodeps cause by a mis-merge.
The patch below is a hack/workaround that just moves the UART idle after
the GPIO context save because I haven't found the root cause yet.
Any ideas what might be happening here?
Kevin
commit 5f3cbd67a54ae8b8cecbbd9ec3f55ffe07625e88
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Mon Nov 23 11:05:02 2009 -0800
temp: OMAP3: PM: GPIO: disable PER UART after GPIO save
FIXME: GPIO core needs to use clock API to prevent this.
When PER UARTs are disabled in idle path and no GPIOs are in use,
the PER block may go idle. This causes the GPIO context save
that happens right after UART disabling to fail with data aborts
when accessing the GPIO regs in PER.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 627a509..da32764 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -398,7 +398,6 @@ void omap_sram_idle(void)
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF) {
if (core_next_state == PWRDM_POWER_ON) {
@@ -408,6 +407,7 @@ void omap_sram_idle(void)
} else
omap3_per_save_context();
}
+ omap_uart_prepare_idle(2);
}
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] PM branch updated to v2.6.32-rc8
FYI... PM branch was rebased to today's linux-omap master branch (currently v2.6.32-rc8) As usual, the PM wiki[1] has all the details on using the PM branch as well as some known issues. Also note that starting with the official v2.6.32 release, I will be moving from a continual rebase model to a re-branch rebuild model similar to how Tony is now managing l-o master. Kevin [1] http://elinux.org/OMAP_Power_Management -- To unsubscribe from this list: send the line unsubscribe 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: hwmod and PER going idle before WFI
Hi Kevin,
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Hi Paul,
In working with the UART conversion to hwmod, I noticed something I
don't see when not using hwmod for managing the UARTs.
Namely, in the idle path for PER we do disable the PER UART (via
omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via
omap3_per_save_context();
When switching to use omap_hwmod, I noticed via crashes and then via
lauterbach that as soon as UART3 clocks are disabled, PER goes idle.
This causes the subsequent GPIO context save to fault since PER has
gone idle.
I seem to remember having a similar problem before when the problem
was in the management of autodeps cause by a mis-merge.
The patch below is a hack/workaround that just moves the UART idle after
the GPIO context save because I haven't found the root cause yet.
Any ideas what might be happening here?
This is probably due to the PER HW supervised mode and the fact that there is
no sleep dependency by default between MPU and PER or between CORE and PER.
As soon as the latest peripherals inside the PER power domain is going to idle,
the clock domain and thus the power domain can transition to the next power
state, even if the CPU is running.
It can by avoided by enabling the dependency but then you will prevent the PER
to go to OFF mode even if not used.
What was changed to trigger that behavior now?
Regards,
Benoit
Kevin
commit 5f3cbd67a54ae8b8cecbbd9ec3f55ffe07625e88
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Mon Nov 23 11:05:02 2009 -0800
temp: OMAP3: PM: GPIO: disable PER UART after GPIO save
FIXME: GPIO core needs to use clock API to prevent this.
When PER UARTs are disabled in idle path and no GPIOs are in use,
the PER block may go idle. This causes the GPIO context save
that happens right after UART disabling to fail with data aborts
when accessing the GPIO regs in PER.
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 627a509..da32764 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -398,7 +398,6 @@ void omap_sram_idle(void)
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
if (per_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(2);
omap2_gpio_prepare_for_idle(per_next_state);
if (per_next_state == PWRDM_POWER_OFF) {
if (core_next_state == PWRDM_POWER_ON) {
@@ -408,6 +407,7 @@ void omap_sram_idle(void)
} else
omap3_per_save_context();
}
+ omap_uart_prepare_idle(2);
}
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet.
036 420 040 R.C.S Antibes. Capital de EUR 753.920
--
To unsubscribe from this list: send the line unsubscribe 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: hwmod and PER going idle before WFI
Cousson, Benoit b-cous...@ti.com writes: Hi Kevin, From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Hi Paul, In working with the UART conversion to hwmod, I noticed something I don't see when not using hwmod for managing the UARTs. Namely, in the idle path for PER we do disable the PER UART (via omap_uart_prepare_for_idle(2)) and then the GPIO context is saved via omap3_per_save_context(); When switching to use omap_hwmod, I noticed via crashes and then via lauterbach that as soon as UART3 clocks are disabled, PER goes idle. This causes the subsequent GPIO context save to fault since PER has gone idle. I seem to remember having a similar problem before when the problem was in the management of autodeps cause by a mis-merge. The patch below is a hack/workaround that just moves the UART idle after the GPIO context save because I haven't found the root cause yet. Any ideas what might be happening here? This is probably due to the PER HW supervised mode and the fact that there is no sleep dependency by default between MPU and PER or between CORE and PER. As soon as the latest peripherals inside the PER power domain is going to idle, the clock domain and thus the power domain can transition to the next power state, even if the CPU is running. It can by avoided by enabling the dependency but then you will prevent the PER to go to OFF mode even if not used. What was changed to trigger that behavior now? The primary change is using the omap_device API for managing UART PM in mach-omap2/serial.c instead of directly using clock API. I'll be posting the UART patches shortly. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] UART conversion to omap_device layer
This series converts the UART core and PM code to use the omap_device layer based on the omap_hwmod layer. This depends on the various omap_hwmod and omap_device updates from Paul as well as omap_hwmod and omap_device patches I've sent to the list. The 'pm-wip/omap_device' branch in my linux-omap-pm git tree has a collection of all these hwmod/omap_device changes. This UART series applies on top of the pm-wip/omap_device branch. This series is also available in my git tree as branch 'pm-wip/uart' Tested on 3430SDP only using 8250 driver and latest version of omap-serial driver from Govindraj. Govindraj R (1): OMAP: UART: remove 8520 assumptions from UART core Kevin Hilman (2): OMAP3: add omap_hwmods for UART1,2,3 OMAP: UART: convert to use omap_device layer arch/arm/mach-omap2/omap_hwmod_34xx.h | 188 +++ arch/arm/mach-omap2/serial.c | 418 - 2 files changed, 389 insertions(+), 217 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP3: add omap_hwmods for UART1,2,3
This is temporary and will likely be replaced by autogenerated hwmods
for OMAP3.
---
arch/arm/mach-omap2/omap_hwmod_34xx.h | 188 +
1 files changed, 188 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..8225bd3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -18,6 +18,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/serial.h
#include prm-regbits-34xx.h
@@ -48,6 +49,7 @@ static struct omap_hwmod_ocp_if omap34xx_mpu__l3 = {
};
/* Slave interfaces on the L3 interconnect */
+/* KJH: OCP ifs which have L3 interconnect as the slave */
static struct omap_hwmod_ocp_if *omap34xx_l3_slaves[] = {
omap34xx_mpu__l3,
};
@@ -69,6 +71,9 @@ static struct omap_hwmod omap34xx_l3_hwmod = {
};
static struct omap_hwmod omap34xx_l4_wkup_hwmod;
+static struct omap_hwmod omap34xx_uart1_hwmod;
+static struct omap_hwmod omap34xx_uart2_hwmod;
+static struct omap_hwmod omap34xx_uart3_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap34xx_l4_core__l4_wkup = {
@@ -77,14 +82,75 @@ static struct omap_hwmod_ocp_if omap34xx_l4_core__l4_wkup =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 CORE - UART1 interface */
+static struct omap_hwmod_addr_space omap34xx_uart1_addr_space[] = {
+ {
+ .pa_start = OMAP_UART1_BASE,
+ .pa_end = OMAP_UART1_BASE + SZ_8K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__uart1 = {
+ .master = omap34xx_l4_core_hwmod,
+ .slave = omap34xx_uart1_hwmod,
+ .clkdev_dev_id = NULL,
+ .clkdev_con_id = uart1_ick,
+ .addr = omap34xx_uart1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_uart1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - UART2 interface */
+static struct omap_hwmod_addr_space omap34xx_uart2_addr_space[] = {
+ {
+ .pa_start = OMAP_UART2_BASE,
+ .pa_end = OMAP_UART2_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT |ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_core__uart2 = {
+ .master = omap34xx_l4_core_hwmod,
+ .slave = omap34xx_uart2_hwmod,
+ .clkdev_dev_id = NULL,
+ .clkdev_con_id = uart2_ick,
+ .addr = omap34xx_uart2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_uart2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 PER - UART3 interface */
+static struct omap_hwmod_addr_space omap34xx_uart3_addr_space[] = {
+ {
+ .pa_start = OMAP_UART3_BASE,
+ .pa_end = OMAP_UART3_BASE + SZ_1K - 1,
+ .flags = ADDR_MAP_ON_INIT | ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3_l4_per__uart3 = {
+ .master = omap34xx_l4_per_hwmod,
+ .slave = omap34xx_uart3_hwmod,
+ .clkdev_dev_id = NULL,
+ .clkdev_con_id = uart3_ick,
+ .addr = omap34xx_uart3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap34xx_uart3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
+/* KJH: OCP ifs where L4 CORE is the slave */
static struct omap_hwmod_ocp_if *omap34xx_l4_core_slaves[] = {
omap34xx_l3__l4_core,
};
/* Master interfaces on the L4_CORE interconnect */
+/* KJH: OCP ifs where L4 CORE is the master */
static struct omap_hwmod_ocp_if *omap34xx_l4_core_masters[] = {
omap34xx_l4_core__l4_wkup,
+ omap3_l4_core__uart1,
+ omap3_l4_core__uart2,
};
/* L4 CORE */
@@ -104,6 +170,7 @@ static struct omap_hwmod_ocp_if *omap34xx_l4_per_slaves[] =
{
/* Master interfaces on the L4_PER interconnect */
static struct omap_hwmod_ocp_if *omap34xx_l4_per_masters[] = {
+ omap3_l4_per__uart3,
};
/* L4 PER */
@@ -136,6 +203,7 @@ static struct omap_hwmod omap34xx_l4_wkup_hwmod = {
};
/* Master interfaces on the MPU device */
+/* KJH: OCP ifs where MPU is the master */
static struct omap_hwmod_ocp_if *omap34xx_mpu_masters[] = {
omap34xx_mpu__l3,
};
@@ -150,12 +218,132 @@ static struct omap_hwmod omap34xx_mpu_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
+/* UART common */
+
+static struct omap_hwmod_sysconfig uart_if_ctrl = {
+ .rev_offs = 0x50,
+ .sysc_offs = 0x54,
+ .syss_offs = 0x58,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO |
[PATCH 2/3] OMAP: UART: remove 8520 assumptions from UART core
From: Govindraj R govindraj.r...@ti.com
In preparation for a new omap-serial driver, remove 8250 assumptions
and dependencies from the serial core.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 202 ++---
1 files changed, 108 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 2e17b57..3595ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -19,15 +19,16 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_8250.h
#include linux/serial_reg.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_device.h
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/control.h
+#include plat/dma.h
#include prm.h
#include pm.h
@@ -47,12 +48,18 @@ struct omap_uart_state {
void __iomem *wk_en;
u32 wk_mask;
u32 padconf;
+ u32 dma_enabled;
struct clk *ick;
struct clk *fck;
int clocked;
- struct plat_serial8250_port *p;
+ int irq;
+ int regshift;
+ int irqflags;
+ void __iomem *membase;
+ resource_size_t mapbase;
+
struct list_head node;
struct platform_device pdev;
@@ -71,6 +78,9 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
+#ifdef CONFIG_SERIAL_8250
+#include linux/serial_8250.h
+
static struct plat_serial8250_port serial_platform_data0[] = {
{
.mapbase= OMAP_UART1_BASE,
@@ -124,18 +134,59 @@ static struct plat_serial8250_port
serial_platform_data3[] = {
}
};
#endif
-static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
+
+static struct omap_uart_state omap_uart[] = {
+ {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM,
+ .dev= {
+ .platform_data = serial_platform_data0,
+ },
+ },
+ }, {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM1,
+ .dev= {
+ .platform_data = serial_platform_data1,
+ },
+ },
+ }, {
+ .pdev = {
+ .name = serial8250,
+ .id = PLAT8250_DEV_PLATFORM2,
+ .dev= {
+ .platform_data = serial_platform_data2,
+ },
+ },
+ },
+#ifdef CONFIG_ARCH_OMAP4
+ {
+ .pdev = {
+ .name = serial8250,
+ .id = 3,
+ .dev= {
+ .platform_data = serial_platform_data3,
+ },
+ },
+ },
+#endif
+};
+#endif
+
+static inline unsigned int serial_read_reg(struct omap_uart_state *up,
int offset)
{
offset = up-regshift;
return (unsigned int)__raw_readb(up-membase + offset);
}
-static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,
+static inline void serial_write_reg(struct omap_uart_state *up, int offset,
int value)
{
- offset = p-regshift;
- __raw_writeb(value, p-membase + offset);
+ offset = up-regshift;
+ __raw_writeb(value, up-membase + offset);
}
/*
@@ -143,10 +194,9 @@ static inline void serial_write_reg(struct
plat_serial8250_port *p, int offset,
* properly. Note that the TX watermark initialization may not be needed
* once the 8250.c watermark handling code is merged.
*/
-static inline void __init omap_uart_reset(struct omap_uart_state *uart)
-{
- struct plat_serial8250_port *p = uart-p;
+static inline void __init omap_uart_reset(struct omap_uart_state *p)
+{
serial_write_reg(p, UART_OMAP_MDR1, 0x07);
serial_write_reg(p, UART_OMAP_SCR, 0x08);
serial_write_reg(p, UART_OMAP_MDR1, 0x00);
@@ -158,20 +208,19 @@ static inline void __init omap_uart_reset(struct
omap_uart_state *uart)
static void omap_uart_save_context(struct omap_uart_state *uart)
{
u16 lcr = 0;
- struct plat_serial8250_port *p = uart-p;
if (!enable_off_mode)
return;
- lcr = serial_read_reg(p, UART_LCR);
- serial_write_reg(p, UART_LCR, 0xBF);
- uart-dll = serial_read_reg(p, UART_DLL);
- uart-dlh = serial_read_reg(p, UART_DLM);
- serial_write_reg(p, UART_LCR, lcr);
- uart-ier =
[PATCH 3/3] OMAP: UART: convert to use omap_device layer
Convert UART core and PM support to use omap_device layer. Also add
support for both console on 8250 or omap-serial driver.
omap_device conversion:
- Convert clock API calls to omap_device calls
- Remove all static platform_data setup and configuration. This is
all done by the omap_device build phase.
Known issues:
- broken on OMAP4 until OMAP4 UART hwmods are available
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/serial.c | 338 +++---
1 files changed, 154 insertions(+), 184 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3595ffa..c067416 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -24,20 +24,33 @@
#include linux/io.h
#include linux/platform_device.h
+#ifdef CONFIG_SERIAL_8250_CONSOLE
+#include linux/serial_8250.h
+#endif
+
+#ifdef CONFIG_SERIAL_OMAP_CONSOLE
+#include plat/omap-serial.h
+#endif
+
#include plat/common.h
#include plat/board.h
#include plat/clock.h
#include plat/control.h
#include plat/dma.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include prm.h
#include pm.h
+#include cm.h
#include prm-regbits-34xx.h
#define UART_OMAP_WER 0x17/* Wake-up enable register */
#define DEFAULT_TIMEOUT (5 * HZ)
+#define MAX_UART_HWMOD_NAME_LEN16
+
struct omap_uart_state {
int num;
int can_sleep;
@@ -61,7 +74,8 @@ struct omap_uart_state {
resource_size_t mapbase;
struct list_head node;
- struct platform_device pdev;
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
int context_valid;
@@ -78,102 +92,13 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
-#ifdef CONFIG_SERIAL_8250
-#include linux/serial_8250.h
-
-static struct plat_serial8250_port serial_platform_data0[] = {
- {
- .mapbase= OMAP_UART1_BASE,
- .irq= 72,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-static struct plat_serial8250_port serial_platform_data1[] = {
- {
- .mapbase= OMAP_UART2_BASE,
- .irq= 73,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-static struct plat_serial8250_port serial_platform_data2[] = {
+static struct omap_device_pm_latency omap_uart_latency[] = {
{
- .mapbase= OMAP_UART3_BASE,
- .irq= 74,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct plat_serial8250_port serial_platform_data3[] = {
- {
- .mapbase= OMAP_UART4_BASE,
- .irq= 70,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
- }
-};
-#endif
-
-static struct omap_uart_state omap_uart[] = {
- {
- .pdev = {
- .name = serial8250,
- .id = PLAT8250_DEV_PLATFORM,
- .dev= {
- .platform_data = serial_platform_data0,
- },
- },
- }, {
- .pdev = {
- .name = serial8250,
- .id = PLAT8250_DEV_PLATFORM1,
- .dev= {
- .platform_data = serial_platform_data1,
- },
- },
- }, {
- .pdev = {
- .name = serial8250,
- .id = PLAT8250_DEV_PLATFORM2,
- .dev= {
- .platform_data = serial_platform_data2,
- },
- },
- },
-#ifdef CONFIG_ARCH_OMAP4
- {
- .pdev = {
- .name = serial8250,
- .id = 3,
- .dev= {
-
Re: [PATCHv3 1/3] OMAP UART: Add omap-serial driver support.
Govindraj.R govindraj.r...@ti.com writes:
From 4756e3743c7acd2de1030b2bd432c1b19f0b9ff5 Mon Sep 17 00:00:00 2001
From: Govindraj R govindraj.r...@ti.com
Date: Fri, 13 Nov 2009 12:01:54 +0530
Subject: [PATCH] OMAP UART: Add omap-serial driver support.
This patch adds support for OMAP3430-HIGH SPEED UART Controller.
It adds support for the following features:
1. It supports Interrupt mode and DMA mode of operation.
2. Supports Hardware flow control and sofware flow control.
3. Debug Console support on all UARTs.
Signed-off-by: Govindraj R govindraj.r...@ti.com
Govindraj,
FYI... to use this version of the driver with the UART omap_device
conversion I just posted, I used this additional patch on top of your
driver.
These are various issues I pointed out in the review as well, but
wanted to share this with V3 + this patch, I was able to use it
with the omap_device conversion.
Kevin
commit 79285bfc6c8711f580895256a82e7dc127156824
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Mon Nov 23 15:10:13 2009 -0800
OMAP: HS-UART: misc. fixes
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 4341fae..86bec82 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -28,7 +28,7 @@
* in bootargs we specify as console=ttyO0 if uart1
* is used as console uart.
*/
-#define DEVICE_NAMEttyO
+#define DEVICE_NAMEttyS
/* *
* We default to IRQ0 for the no irq hack. Some
diff --git a/drivers/serial/omap-serial.c b/drivers/serial/omap-serial.c
index 6dd8bb4..65d05f8 100644
--- a/drivers/serial/omap-serial.c
+++ b/drivers/serial/omap-serial.c
@@ -993,7 +993,7 @@ static struct console serial_omap_console = {
static void serial_omap_add_console_port(struct uart_omap_port *up)
{
- serial_omap_console_ports[up-pdev-id - 1] = up;
+ serial_omap_console_ports[up-pdev-id] = up;
}
#define OMAP_CONSOLE (serial_omap_console)
@@ -1237,7 +1237,7 @@ static int serial_omap_probe(struct platform_device *pdev)
up-port.regshift = 2;
up-port.fifosize = 64;
up-port.ops = serial_omap_pops;
- up-port.line = pdev-id - 1;
+ up-port.line = pdev-id;
up-port.membase = ioremap_nocache(up-port.mapbase,
0x16 up-port.regshift);
up-port.flags = UPF_BOOT_AUTOCONF;
@@ -1263,7 +1263,7 @@ static int serial_omap_probe(struct platform_device *pdev)
pr_err(\n %s: UART Driver Init Failed!\n, __func__);
return -EPERM;
}
- ui[pdev-id - 1] = up;
+ ui[pdev-id] = up;
serial_omap_add_console_port(up);
ret = uart_add_one_port(serial_omap_reg, up-port);
@@ -1298,7 +1298,7 @@ static struct platform_driver serial_omap_driver = {
.suspend= serial_omap_suspend,
.resume = serial_omap_resume,
.driver = {
- .name = omap-uart,
+ .name = DRIVER_NAME,
},
};
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP3: enabling CPU idle leads to panic
From: Kevin Hilman [khil...@deeprootsystems.com] Sent: Tuesday, November 24, 2009 11:57 PM To: Sergey Lapin; Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: OMAP3: enabling CPU idle leads to panic Sergey Lapin slapi...@gmail.com writes: I use PM branch merged with linux-omap branch. Not sure what this means. PM branch is already based at linux-omap master branch. You'll need to be more specific, ideally with commit IDs. [sp] I will also need the last commit from pm branch - if not the id; the commit header to start. [snip]--[snip] addr2line -e vmlinux c003b5c0 /home/slapin/linux-omap-my-2.6.git/arch/arm/mach-omap2/powerdomain.c:452 It is in function int pwrdm_for_each_clkdm(), where pwrdm is NULL. farther investigations found that core_pwrdm is defined only for 24xx, but I use 3525, and it is being searched. [sp] I am a little confused here. core_pwrdm is defined for 34xx as well. Other than sgx, there isn't any difference between 3530 and 3525. See the definition at: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/powerdomains34xx.h;hb=867d320b6c30d2478358eafeca0e1a6c60cf06c3#l203 This is where variable allocated. If I add BUG_ON(!core_pd), it crashes here. arch/arm/mach-omap2/cpuidle34xx.c:348:core_pd = pwrdm_lookup(core_pwrdm); Otherwise it crashes the above way. Any ideas on how to fix this? [sp] Have you hand-picked the commits from pm branch and applied against master? Best regards, Sanjeev PS: responding thru a web client. It doesn't seem to support quoting the original message. I think there is still ongoing work on support for the 3525. I'm guessing the clock/pwrdm init still needs work for that SoC. I have no 3525 hardware, but maybe Sanjeev has more details. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 30/38] move mipid_spi_remove to .devexit.text
The function mipid_spi_remove is used only wrapped by __devexit_p so
define it using __devexit.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Arnaud Patard arnaud.pat...@rtp-net.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Mike Wege ext-mike.w...@nokia.com
Cc: Imre Deak imre.d...@solidboot.com
Cc: Hiroshi DOYU hiroshi.d...@nokia.com
Cc: linux-ker...@vger.kernel.org
Cc: Imre Deak imre.d...@nokia.com
Cc: linux-fbdev-de...@lists.sourceforge.net
Cc: linux-omap@vger.kernel.org
---
drivers/video/omap/lcd_mipid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap/lcd_mipid.c b/drivers/video/omap/lcd_mipid.c
index 918ee89..24889ca 100644
--- a/drivers/video/omap/lcd_mipid.c
+++ b/drivers/video/omap/lcd_mipid.c
@@ -587,7 +587,7 @@ static int mipid_spi_probe(struct spi_device *spi)
return 0;
}
-static int mipid_spi_remove(struct spi_device *spi)
+static int __devexit mipid_spi_remove(struct spi_device *spi)
{
struct mipid_device *md = dev_get_drvdata(spi-dev);
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe 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] Zoom2/3:Update hsmmc board config params
From: Madhusudhan Chikkature madhu...@ti.com
Subject: [PATCH] Zoom2/3:Update hsmmc board config params.
Update the hsmmc zoom peripheral configuration to support:
Power saving mode
mmc2 8-bit support
Configure mmc2 as non removable
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 221a8e3..258794d 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -152,14 +152,20 @@ static struct regulator_init_data zoom_vsim = {
static struct twl4030_hsmmc_info mmc[] __initdata = {
{
+ .name = external,
.mmc= 1,
.wires = 4,
.gpio_wp= -EINVAL,
+ .power_saving = true,
},
{
+ .name = internal,
.mmc= 2,
- .wires = 4,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .nonremovable = true,
+ .power_saving = true,
},
{} /* Terminator */
};
@@ -167,11 +173,8 @@ static struct twl4030_hsmmc_info mmc[] __initdata = {
static int zoom_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- /* gpio + 0 is mmc0_cd (input/IRQ),
-* gpio + 1 is mmc1_cd (input/IRQ)
-*/
+ /* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
- mmc[1].gpio_cd = gpio + 1;
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters ... we know the
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] OMAP1: LCD_DMA: Use some define rather than a hexadecimal constant for LCD register
The patch corrects the issue introduced with one of my earlier patches: OMAP: DMA: Fix omapfb/lcdc on OMAP1510 broken when PM set[1] as pointed out by OMAP subsystem maintainer. Applies on top of my prevoius patch: OMAP: DMA: move LCD DMA related code from plat-omap to mach-omap1[2] Tested on Amstrad Delta Compile tested with omap_generic_2420_defconfig Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl [1] http://patchwork.kernel.org/patch/57922/ [2] http://patchwork.kernel.org/patch/61952/ --- Tuesday 17 November 2009 17:10:58 Tony Lindgren wrote: * Janusz Krzysztofik jkrzy...@tis.icnet.pl [091117 02:45]: 1. While keeping those hex constants as they are for now, solve the issue during refactoring arch/arm/plat-omap/dma.c for a separate arch/arm/mach-omap1/lcd_dma.c, as Paul suggested (may take some time). Since the register test would be put there, some headers will have to be moved out of drivers/video/omap/lcdc.c anyway. This sounds like the best way to go to me. Tony, At your service :-). Since it's very similiar to reverted v3[*], I hope you have no problems with this one. Thanks, Janusz [*] http://patchwork.kernel.org/patch/60478/ diff -uprN git.orig/arch/arm/mach-omap1/include/mach/lcdc.h git/arch/arm/mach-omap1/include/mach/lcdc.h --- git.orig/arch/arm/mach-omap1/include/mach/lcdc.h1970-01-01 01:00:00.0 +0100 +++ git/arch/arm/mach-omap1/include/mach/lcdc.h 2009-11-21 03:26:32.0 +0100 @@ -0,0 +1,57 @@ +/* + * arch/arm/mach-omap1/include/mach/lcdc.h + * + * Extracted from drivers/video/omap/lcdc.c + * Copyright (C) 2004 Nokia Corporation + * Author: Imre Deak imre.d...@nokia.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ +#ifndef __MACH_LCDC_H__ +#define __MACH_LCDC_H__ + +#define OMAP_LCDC_BASE 0xfffec000 +#define OMAP_LCDC_SIZE 256 +#define OMAP_LCDC_IRQ INT_LCD_CTRL + +#define OMAP_LCDC_CONTROL (OMAP_LCDC_BASE + 0x00) +#define OMAP_LCDC_TIMING0 (OMAP_LCDC_BASE + 0x04) +#define OMAP_LCDC_TIMING1 (OMAP_LCDC_BASE + 0x08) +#define OMAP_LCDC_TIMING2 (OMAP_LCDC_BASE + 0x0c) +#define OMAP_LCDC_STATUS (OMAP_LCDC_BASE + 0x10) +#define OMAP_LCDC_SUBPANEL (OMAP_LCDC_BASE + 0x14) +#define OMAP_LCDC_LINE_INT (OMAP_LCDC_BASE + 0x18) +#define OMAP_LCDC_DISPLAY_STATUS (OMAP_LCDC_BASE + 0x1c) + +#define OMAP_LCDC_STAT_DONE(1 0) +#define OMAP_LCDC_STAT_VSYNC (1 1) +#define OMAP_LCDC_STAT_SYNC_LOST (1 2) +#define OMAP_LCDC_STAT_ABC (1 3) +#define OMAP_LCDC_STAT_LINE_INT(1 4) +#define OMAP_LCDC_STAT_FUF (1 5) +#define OMAP_LCDC_STAT_LOADED_PALETTE (1 6) + +#define OMAP_LCDC_CTRL_LCD_EN (1 0) +#define OMAP_LCDC_CTRL_LCD_TFT (1 7) +#define OMAP_LCDC_CTRL_LINE_IRQ_CLR_SEL(1 10) + +#define OMAP_LCDC_IRQ_VSYNC(1 2) +#define OMAP_LCDC_IRQ_DONE (1 3) +#define OMAP_LCDC_IRQ_LOADED_PALETTE (1 4) +#define OMAP_LCDC_IRQ_LINE_NIRQ(1 5) +#define OMAP_LCDC_IRQ_LINE (1 6) +#define OMAP_LCDC_IRQ_MASK (((1 5) - 1) 2) + +#endif /* __MACH_LCDC_H__ */ diff -uprN git.orig/arch/arm/mach-omap1/lcd_dma.c git/arch/arm/mach-omap1/lcd_dma.c --- git/arch/arm/mach-omap1/lcd_dma.c 2009-11-21 14:36:59.0 +0100 +++ git.orig/arch/arm/mach-omap1/lcd_dma.c 2009-11-21 03:42:25.0 +0100 @@ -28,6 +28,7 @@ #include linux/io.h #include mach/hardware.h +#include mach/lcdc.h #include plat/dma.h int omap_lcd_dma_running(void) @@ -37,7 +38,7 @@ int omap_lcd_dma_running(void) * when it gets enabled, so assume DMA running if LCD enabled. */ if (cpu_is_omap1510()) - if (omap_readw(0xfffec000 + 0x00) (1 0)) + if (omap_readw(OMAP_LCDC_CONTROL) OMAP_LCDC_CTRL_LCD_EN) return 1; /* Check if LCD DMA is running */ diff -uprN git.orig/drivers/video/omap/lcdc.c git/drivers/video/omap/lcdc.c --- git.orig/drivers/video/omap/lcdc.c 2009-11-21 14:33:16.0 +0100 +++ git/drivers/video/omap/lcdc.c 2009-11-21 02:17:17.0 +0100 @@ -29,6 +29,7 @@ #include linux/vmalloc.h
[PATCH 00/10 v3] omap3: pm: introduce support for 3630 OPPs
Hi,
Here is V3 of the patch series. What changed in V3:
* Major rewrite of OPP APIs. This includes changes from offline
discussions with lots of folks and taking in l-o comments - all
patches have changed as a result.
* rebased to latest lo-pm
V2: http://marc.info/?l=linux-omapm=125809232732700w=2
V1: http://marc.info/?l=linux-omapm=125800488923479w=2
NOTE: After a bunch of frustrating efforts, current OPP accessor
implementation is constrained by two files:
smartreflex.c and resource34xx.c. I agree that the current opp
accessor implementation leaves lot to be desired, but the nature of
struct omap_opp cannot change unless we essentially rewrite the
implementation of the mentioned files.
Ref: http://elinux.org/OMAP_Power_Management#Future_directions
I propose we could take this in in three stages:
Stage 1: Introduce this series in as starters if there are no major
issues
Stage 2: We cleanup/replace resource34xx and smartreflex.c
Stage 3: Go through a second round of optimization/cleanup of opp
accessors implementation (this time for good hopefully)
Also note that OMAP3630 is dependent on clk tree changes which needs
to come in - but that is an independent parallel activity.
TODO items:
* Add on a dependency b/w vdd1 and vdd2 in a clean manner - probably
after we cleanup the resource34xx.c, all folks needing a quick hack
can easily follow the following pseudo logic:
resource34xx.c::set_opp:
if (cpu_is_omap3630()) {
vdd1_threshold_freq = 600mhz (opp2)
vdd2_required_freq = 200Mhz
} else {
vdd1_threshold_freq = 500 Mhz (opp3)
vdd2_required_freq = 100Mhz
}
if (vdd1_target vdd1_threshold_freq)
free_vdd2_dep_if_acquired();
/* Do other stuff */
if (vdd1_target_freq = vdd1_threshold_freq)
request_vdd2(at least vdd2_required_freq)
The 3630 vdd1-vdd2 dependency comes from the OPP table dependency
of OPP100 and above on VDD1 requires VDD2 to be OPP100. VDD2 is free
to go as it pleases, but optimal is to be at OPP50 if VDD1 is at
OPP50. Lots of possible hacks are possible, and I dont recommend any
at the moment.
* OMAP3630: Add speedbin detection and enable support for OPP-Turbo and
OPP-SB
Finally,
NOTE: SDP3630 needs the patch for 8250 as discussed here:
http://marc.info/?l=linux-omapm=125873296522723w=2
This patch series is based on previous discussions:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg17632.html
I have modified the initial patch From Sanjeev:
http://patchwork.kernel.org/patch/50998/
Other than these, we cannot use the old VDDx_MAX based usage
anymore as 3630 OPPs are now different and runtime handling
is a must-have, hence introducing these accessor functions is not
avoidable.
The changes are incremental and tries to avoid intrusive change
as much as possible.
The OPP accessor functions introduced in this series is hopefully
a start for us to optimize this heavily used path.
An alternate approach for detecting 3630 OPP is using FEATURES
instead of detecting the cpu_type as I have implemented in this series.
Testing: mostly on SDP3430: using cpufreq-utils, sysfs vddx_lock
RET/OFF using shell scripts. Further testing requested.
Most of the commands used documented here:
http://elinux.org/OMAP_Power_Management
Nishanth Menon (10):
Following are the OPP accessor function introduction:
omap3: pm: introduce enabled flag to omap_opp
omap3: pm: introduce opp accessor functions
omap3: pm: use opp accessor functions for omap34xx
The following are attempts to cleanup existing code from VDDx dep:
omap3: pm: srf: use opp accessor functions
omap3: pm: sr: replace get_opp with freq_to_opp
omap3: pm: use opp accessor functions for omap-target
omap3: clk: use pm accessor functions for cpufreq table
omap3: pm: remove VDDx_MIN/MAX macros
The following two introduce 3630 support:
omap3: pm: introduce 3630 opps
omap3: pm: omap3630 boards: enable 3630 opp tables
arch/arm/mach-omap2/board-3430sdp.c|1 +
arch/arm/mach-omap2/board-3630sdp.c|9 +-
arch/arm/mach-omap2/board-omap3beagle.c|1 +
arch/arm/mach-omap2/board-omap3evm.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 |9 +-
arch/arm/mach-omap2/clock34xx.c| 32 ++--
arch/arm/mach-omap2/omap3-opp.h| 58 +--
arch/arm/mach-omap2/pm.h |6 +
arch/arm/mach-omap2/pm34xx.c | 113
arch/arm/mach-omap2/resource34xx.c | 240 +++---
arch/arm/mach-omap2/smartreflex.c | 42 ++
arch/arm/plat-omap/Makefile|3 +
arch/arm/plat-omap/cpu-omap.c | 19 ++-
arch/arm/plat-omap/include/plat/omap-pm.h | 15 +--
arch/arm/plat-omap/include/plat/omap34xx.h |5 -
arch/arm/plat-omap/include/plat/opp.h | 208 ++
[PATCH 03/10 V3] omap3: pm: use opp accessor functions for omap34xx
Move the definitions from omap3-opp.h to pm34xx.c. The definitions
are now based on omap_opp_def instead of omap_opp itself.
Since the opp.h has the omap_opp definition, omap-pm.h conflicts and
has been removed in favor of opp.h.
omap3_pm_init_opp_table is used to initialize the OPP table and
relevant board files which have omap2_init_common_hw called with opp
arrays have been updated with omap3_pm_init_opp_table.
This change now allows us to dynamically register OPPs to the system
based on silicon type we detect.
NOTE: This introduces the following warnings highlighting areas we
need to cleanup:
arch/arm/mach-omap2/smartreflex.c: In function 'get_opp':
arch/arm/mach-omap2/smartreflex.c:161: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:164: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:166: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'get_opp':
arch/arm/mach-omap2/resource34xx.c:165: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:168: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:170: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:172: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c: In function 'program_opp':
arch/arm/mach-omap2/resource34xx.c:284: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/resource34xx.c:285: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-rx51.c |1 +
arch/arm/mach-omap2/board-zoom2.c |2 +
arch/arm/mach-omap2/omap3-opp.h | 58 +---
arch/arm/mach-omap2/pm.h |6 +++
arch/arm/mach-omap2/pm34xx.c | 68 +
arch/arm/plat-omap/include/plat/omap-pm.h | 17 +---
9 files changed, 84 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index eac529f..0ec8327 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -220,6 +220,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap3_pm_init_opp_table();
omap3_pm_init_vc(omap3_setuptime_table);
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 2ec3520..a937238 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -361,6 +361,7 @@ static void __init omap3_beagle_init_irq(void)
{
omap_board_config = omap3_beagle_config;
omap_board_config_size = ARRAY_SIZE(omap3_beagle_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params, omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8130eca..44a5861 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -404,6 +404,7 @@ static void __init omap3_evm_init_irq(void)
{
omap_board_config = omap3_evm_config;
omap_board_config_size = ARRAY_SIZE(omap3_evm_config);
+ omap3_pm_init_opp_table();
omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 2f1c2be..997fd1c 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -103,6 +103,7 @@ static void __init rx51_init_irq(void)
omap_board_config = rx51_config;
omap_board_config_size = ARRAY_SIZE(rx51_config);
+ omap3_pm_init_opp_table();
omap3_pm_init_cpuidle(rx51_cpuidle_params);
sdrc_params
[PATCH 10/10] omap3: pm: omap3630 boards: enable 3630 opp tables
enable the OPP tables for 3630 platforms: SDP3630, zoom3.
NOTE: This needs the corresponding clockframework changes.
Currently this dumps the following on OPP transitions on SDP3630:
[c002d734] (dump_backtrace+0x0/0x110) from [c02c9698] (dump_stack+0x18/0x1c)
r7: r6:c003bff8 r5:c034a227 r4:0309
[c02c9680] (dump_stack+0x0/0x1c) from [c0052f24]
(warn_slowpath_common+0x50/0x68)
[c0052ed4] (warn_slowpath_common+0x0/0x68) from [c0052f54]
(warn_slowpath_null+0x18/0x1c)
r7:c7801000 r6:0f7f4900 r5:8013 r4:
[c0052f3c] (warn_slowpath_null+0x0/0x1c) from [c003bff8]
(omap3_noncore_dpll_set_rate+0x294/0x2d8)
[c003bd64] (omap3_noncore_dpll_set_rate+0x0/0x2d8) from [c0036e24]
(omap2_clk_set_rate+0x28/0x34)
[c0036dfc] (omap2_clk_set_rate+0x0/0x34) from [c003ecec]
(clk_set_rate+0x54/0xb8)
[c003ec98] (clk_set_rate+0x0/0xb8) from [c003c750] (program_opp+0x120/0x228)
r7:c7801000 r6: r5:c03c9fe0 r4:c03c9fd8
[c003c630] (program_opp+0x0/0x228) from [c003c990]
(resource_set_opp_level+0x138/0x1b0)
[c003c858] (resource_set_opp_level+0x0/0x1b0) from [c0038534]
(vdd_opp_store+0x148/0x17c)
[c00383ec] (vdd_opp_store+0x0/0x17c) from [c01b39dc]
(kobj_attr_store+0x20/0x24)
r7:c7833740 r6:c794bec0 r5:c78c8960 r4:0001
[c01b39bc] (kobj_attr_store+0x0/0x24) from [c0102c3c]
(sysfs_write_file+0x110/0x144)
[c0102b2c] (sysfs_write_file+0x0/0x144) from [c00b2f90]
(vfs_write+0xb8/0x164)
[c00b2ed8] (vfs_write+0x0/0x164) from [c00b3100] (sys_write+0x44/0x70)
r8:4000 r7:0001 r6:c783de00 r5: r4:
[c00b30bc] (sys_write+0x0/0x70) from [c0029f80] (ret_fast_syscall+0x0/0x2c)
r8:c002a104 r7:0004 r6:001d7918 r5:4000 r4:0001
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/board-3630sdp.c |9 -
arch/arm/mach-omap2/board-zoom3.c |9 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index 185f48d..7a429db 100755
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -24,6 +24,8 @@
#include mach/board-zoom.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include pm.h
+#include omap3-opp.h
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -76,9 +78,14 @@ static void __init omap_sdp_init_irq(void)
{
omap_board_config = sdp_config;
omap_board_config_size = ARRAY_SIZE(sdp_config);
+
+ omap3_pm_init_opp_table();
+ /* TODO: Add RET, OFF, cpu_idle params */
+
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params,
- NULL, NULL, NULL);
+omap3_mpu_rate_table, omap3_dsp_rate_table,
+omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index fe97324..0574811 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -22,6 +22,8 @@
#include plat/board.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include pm.h
+#include omap3-opp.h
static void __init omap_zoom_map_io(void)
{
@@ -36,9 +38,14 @@ static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
omap_board_config_size = ARRAY_SIZE(zoom_config);
+
+ omap3_pm_init_opp_table();
+ /* TODO: Add RET, OFF, cpu_idle params */
+
omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
h8mbx00u0mer0em_sdrc_params,
-NULL, NULL, NULL);
+omap3_mpu_rate_table, omap3_dsp_rate_table,
+omap3_l3_rate_table);
omap_init_irq();
omap_gpio_init();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] omap3: pm: introduce enabled flag to omap_opp
We used to enable and disable OPPs based on rate being set to 0, this
has been confusing in general. So, we now allow specific OPPs to be
now enabled/disabled by an explicit enabled flag instead of re-using
rate flag itself.
Tested on: SDP3430
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/omap3-opp.h | 32 ++--
arch/arm/mach-omap2/resource34xx.c|4 +++
arch/arm/plat-omap/include/plat/omap-pm.h |2 +
3 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-opp.h b/arch/arm/mach-omap2/omap3-opp.h
index c773ea7..42557e1 100644
--- a/arch/arm/mach-omap2/omap3-opp.h
+++ b/arch/arm/mach-omap2/omap3-opp.h
@@ -22,41 +22,41 @@
#define S166M 16600
static struct omap_opp omap3_mpu_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {S125M, VDD1_OPP1, 0x1E},
+ {true, S125M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S250M, VDD1_OPP2, 0x26},
+ {true, S250M, VDD1_OPP2, 0x26},
/*OPP3*/
- {S500M, VDD1_OPP3, 0x30},
+ {true, S500M, VDD1_OPP3, 0x30},
/*OPP4*/
- {S550M, VDD1_OPP4, 0x36},
+ {true, S550M, VDD1_OPP4, 0x36},
/*OPP5*/
- {S600M, VDD1_OPP5, 0x3C},
+ {true, S600M, VDD1_OPP5, 0x3C},
};
static struct omap_opp omap3_l3_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {0, VDD2_OPP1, 0x1E},
+ {false, 0, VDD2_OPP1, 0x1E},
/*OPP2*/
- {S83M, VDD2_OPP2, 0x24},
+ {true, S83M, VDD2_OPP2, 0x24},
/*OPP3*/
- {S166M, VDD2_OPP3, 0x2C},
+ {true, S166M, VDD2_OPP3, 0x2C},
};
static struct omap_opp omap3_dsp_rate_table[] = {
- {0, 0, 0},
+ {0, 0, 0, 0},
/*OPP1*/
- {S90M, VDD1_OPP1, 0x1E},
+ {true, S90M, VDD1_OPP1, 0x1E},
/*OPP2*/
- {S180M, VDD1_OPP2, 0x26},
+ {true, S180M, VDD1_OPP2, 0x26},
/*OPP3*/
- {S360M, VDD1_OPP3, 0x30},
+ {true, S360M, VDD1_OPP3, 0x30},
/*OPP4*/
- {S400M, VDD1_OPP4, 0x36},
+ {true, S400M, VDD1_OPP4, 0x36},
/*OPP5*/
- {S430M, VDD1_OPP5, 0x3C},
+ {true, S430M, VDD1_OPP5, 0x3C},
};
#endif
diff --git a/arch/arm/mach-omap2/resource34xx.c
b/arch/arm/mach-omap2/resource34xx.c
index 04be4d2..af6b3c1 100644
--- a/arch/arm/mach-omap2/resource34xx.c
+++ b/arch/arm/mach-omap2/resource34xx.c
@@ -285,6 +285,10 @@ static int program_opp(int res, struct omap_opp *opp, int
target_level,
c_opp = ID_VDD(res) | ID_OPP_NO(opp[current_level].opp_id);
#endif
+ /* Only allow enabled OPPs */
+ if (!opp[target_level].enabled)
+ return -EINVAL;
+
/* Sanity check of the OPP params before attempting to set */
if (!opp[target_level].rate || !opp[target_level].vsel)
return -EINVAL;
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index 583e540..5dc2048 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -21,6 +21,7 @@
/**
* struct omap_opp - clock frequency-to-OPP ID table for DSP, MPU
+ * @enabled: enabled if true, disabled if false
* @rate: target clock rate
* @opp_id: OPP ID
* @min_vdd: minimum VDD1 voltage (in millivolts) for this OPP
@@ -28,6 +29,7 @@
* Operating performance point data. Can vary by OMAP chip and board.
*/
struct omap_opp {
+ bool enabled;
unsigned long rate;
u8 opp_id;
u16 vsel;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10 V3] omap3: pm: introduce opp accessor functions
Modifies the initial patch From Sanjeev:
http://patchwork.kernel.org/patch/50998/
Discussions and comments from:
http://marc.info/?l=linux-omapm=125482970102327w=2
http://marc.info/?t=12580924752r=1w=2
incorporated.
OMAP SOCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. This
is called Operating Points or OPP. The actual definitions of OMAP
Operating Points varies over silicon within the same family of
devices. For a specific domain, you can have a set of
{frequency, voltage} pairs. As the kernel boots and more information
is available, a set of these are activated based on the precise
nature of device the kernel boots up on. It is interesting to
remember that each IP which belongs to a voltage domain may define
their own set of OPPs on top of this.
This introduces a common handling OPP mechanism accross all OMAPs.
As a start this is introduced for OMAP3 and intends to replace
current OMAP3 opp handling mechanism.
Note:
fields of struct omap_opp is currently exposed due to the necessity
that SRF and SR logic directly indexes the structure array fields.
The goal however, is to make the direct usage of omap_opp deprecated
and move to using these accessor functions. The usage in SRF and SR
indexes based on opp_id and hence opp_id is marked deprecated to
generate build warnings at least. Further, this usage necessitates
need of terminator entries at the start and end of opp_* tables which
are dynamically allocated.
The accessor function definitions were collaborated with Kevin, and
doing justice here, this implementation could not go with some of
the better suggestions from kevin due to constraint imposed by SRF
and SR. A better and more optimal implementation is definitely
possible once SRF and SR are cleanedup/replaced.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/Makefile |3 +
arch/arm/plat-omap/include/plat/opp.h | 208 ++
arch/arm/plat-omap/opp.c | 260 +
3 files changed, 471 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/opp.h
create mode 100644 arch/arm/plat-omap/opp.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 95f8413..e9cf601 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -12,6 +12,9 @@ obj- :=
# OCPI interconnect support for 1710, 1610 and 5912
obj-$(CONFIG_ARCH_OMAP16XX) += ocpi.o
+# OPP support in (OMAP3+ only at the moment)
+obj-$(CONFIG_ARCH_OMAP3) += opp.o
+
# omap_device support (OMAP2+ only at the moment)
obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
diff --git a/arch/arm/plat-omap/include/plat/opp.h
b/arch/arm/plat-omap/include/plat/opp.h
new file mode 100644
index 000..d8ae2d3
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/opp.h
@@ -0,0 +1,208 @@
+/*
+ * OMAP OPP Interface
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 Deep Root Systems, LLC.
+ * Kevin Hilman
+ *
+ * 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.
+ */
+#ifndef __ASM_ARM_OMAP_OPP_H
+#define __ASM_ARM_OMAP_OPP_H
+
+/**
+ * struct omap_opp - OMAP OPP description structure
+ * @enabled: true/false - marking this OPP as enabled/disabled
+ * @rate: Frequency in hertz
+ * @opp_id:(DEPRECATED) opp identifier
+ * @vsel: Voltage in volt processor level(this usage is
+ * DEPRECATED to use Voltage in microvolts in future)
+ * uV = ((vsel * 12.5) + 600) * 1000
+ *
+ * This structure stores the OPP information for a given domain.
+ * Due to legacy reasons, this structure is currently exposed and
+ * will soon be removed elsewhere and will only be used as a handle
+ * from the OPP internal referencing mechanism
+ */
+struct omap_opp {
+ bool enabled;
+ unsigned long rate;
+ u8 opp_id __deprecated;
+ u16 vsel;
+};
+
+/**
+ * opp_get_voltage - Gets the voltage corresponding to an opp
+ * @u_volt:Voltage in microvolts corresponding to an opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * Return 0 and the voltage in micro volt corresponding to the opp,
+ * else return the corresponding error value.
+ */
+int opp_get_voltage(u32 *u_volt, const struct omap_opp *opp);
+
+/**
+ * opp_get_freq -
[PATCH 05/10 V3] omap3: pm: sr: replace get_opp with freq_to_opp
SmartReflex implements a get_opp to search through the opp table,
replace it opp_is_valid to verify the OPPs and getting the opp_id.
NOTE: usage of opp_id is deprecated and this introduces the following
warnings:
arch/arm/mach-omap2/smartreflex.c: In function 'get_vdd1_opp':
arch/arm/mach-omap2/smartreflex.c:160: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
arch/arm/mach-omap2/smartreflex.c: In function 'get_vdd2_opp':
arch/arm/mach-omap2/smartreflex.c:174: warning: 'opp_id' is deprecated
(declared at arch/arm/plat-omap/include/plat/opp.h:33)
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 42 ++--
1 files changed, 12 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index be3a1da..6f8b7cc 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -146,50 +146,32 @@ static u32 cal_test_nvalue(u32 sennval, u32 senpval)
(rnsenn NVALUERECIPROCAL_RNSENN_SHIFT);
}
-/* determine the current OPP from the frequency
- * we need to give this function last element of OPP rate table
- * and the frequency
- */
-static u16 get_opp(struct omap_opp *opp_freq_table,
- unsigned long freq)
-{
- struct omap_opp *prcm_config;
-
- prcm_config = opp_freq_table;
-
- if (prcm_config-rate = freq)
- return prcm_config-opp_id; /* Return the Highest OPP */
- for (; prcm_config-rate; prcm_config--)
- if (prcm_config-rate freq)
- return (prcm_config+1)-opp_id;
- else if (prcm_config-rate == freq)
- return prcm_config-opp_id;
- /* Return the least OPP */
- return (prcm_config+1)-opp_id;
-}
-
-static u16 get_vdd1_opp(void)
+static u8 get_vdd1_opp(void)
{
- u16 opp;
+ struct omap_opp *opp;
if (sr1.vdd_opp_clk == NULL || IS_ERR(sr1.vdd_opp_clk) ||
mpu_opps == NULL)
return 0;
- opp = get_opp(mpu_opps + MAX_VDD1_OPP, sr1.vdd_opp_clk-rate);
- return opp;
+ if (unlikely(opp_is_valid(opp, mpu_opps, sr1.vdd_opp_clk-rate)))
+ return 0;
+
+ return opp-opp_id;
}
-static u16 get_vdd2_opp(void)
+static u8 get_vdd2_opp(void)
{
- u16 opp;
+ struct omap_opp *opp;
if (sr2.vdd_opp_clk == NULL || IS_ERR(sr2.vdd_opp_clk) ||
l3_opps == NULL)
return 0;
- opp = get_opp(l3_opps + MAX_VDD2_OPP, sr2.vdd_opp_clk-rate);
- return opp;
+ if (unlikely(opp_is_valid(opp, l3_opps, sr2.vdd_opp_clk-rate)))
+ return 0;
+
+ return opp-opp_id;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] omap3: pm: remove VDDx_MIN/MAX macros
Since accessor functions are used through out, we dont depend on the predefined macros to know the limits of the opp table. Hence, remove these. Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Romit Dasgupta ro...@ti.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Vishwanath Sripathy vishwanath...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/plat-omap/include/plat/omap34xx.h |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap34xx.h b/arch/arm/plat-omap/include/plat/omap34xx.h index 6b849e5..9768f8a 100644 --- a/arch/arm/plat-omap/include/plat/omap34xx.h +++ b/arch/arm/plat-omap/include/plat/omap34xx.h @@ -98,10 +98,5 @@ #define VDD2_OPP2 0x2 #define VDD2_OPP3 0x3 -#define MIN_VDD1_OPP VDD1_OPP1 -#define MAX_VDD1_OPP VDD1_OPP5 -#define MIN_VDD2_OPP VDD2_OPP1 -#define MAX_VDD2_OPP VDD2_OPP3 - #endif /* __ASM_ARCH_OMAP34XX_H */ -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10 V3] omap3: pm: use opp accessor functions for omap-target
The logic in omap-target can now be improved with the accessor
functions. Dont scan through the list manually, instead use
get_next_freq to do the scanning.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/plat-omap/cpu-omap.c | 19 +++
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c
index 449b6b6..7b3ca11 100644
--- a/arch/arm/plat-omap/cpu-omap.c
+++ b/arch/arm/plat-omap/cpu-omap.c
@@ -111,14 +111,17 @@ static int omap_target(struct cpufreq_policy *policy,
cpufreq_notify_transition(freqs, CPUFREQ_POSTCHANGE);
#elif defined(CONFIG_ARCH_OMAP3) !defined(CONFIG_OMAP_PM_NONE)
if (mpu_opps) {
- int ind;
- for (ind = 1; ind = MAX_VDD1_OPP; ind++) {
- if (mpu_opps[ind].rate/1000 = target_freq) {
- omap_pm_cpu_set_freq
- (mpu_opps[ind].rate);
- break;
- }
- }
+ unsigned long freq = target_freq * 1000;
+ struct omap_opp *opp = NULL;
+ int res;
+ /* see if we have exact freq match */
+ res = opp_is_valid(opp, mpu_opps, freq);
+ /* Get next best if we cant find a exact match */
+ if (res)
+ res = opp_get_higher_opp(opp, freq, mpu_opps);
+
+ if (!res)
+ omap_pm_cpu_set_freq(freq);
}
#endif
return ret;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10 V3] omap3: clk: use pm accessor functions for cpufreq table
omap2_clk_init_cpufreq_table currently directly accesses the opp
table, making it unscalable to various OMAPs. Instead use the
accessor functions to populate the cpufreq table
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 32 +++-
1 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 5150939..d07f1c1 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -1042,30 +1042,36 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
#if defined(CONFIG_ARCH_OMAP3)
#ifdef CONFIG_CPU_FREQ
-static struct cpufreq_frequency_table freq_table[MAX_VDD1_OPP+1];
+
+static struct cpufreq_frequency_table *freq_table;
void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
- struct omap_opp *prcm;
int i = 0;
+ u8 opp_num;
+ struct omap_opp *opp = NULL;
+ unsigned long freq = ULONG_MAX;
- if (!mpu_opps)
+ if (!mpu_opps || opp_get_opp_count(opp_num, mpu_opps)) {
+ pr_warning(%s: failed to initialize frequency
+ table\n, __func__);
return;
-
- prcm = mpu_opps + MAX_VDD1_OPP;
- for (; prcm-rate; prcm--) {
- freq_table[i].index = i;
- freq_table[i].frequency = prcm-rate / 1000;
- i++;
}
- if (i == 0) {
- printk(KERN_WARNING %s: failed to initialize frequency \
- table\n,
- __func__);
+ freq_table = kmalloc(sizeof(struct cpufreq_frequency_table) *
+ (opp_num + 1), GFP_KERNEL);
+ if (!freq_table) {
+ pr_warning(%s: failed to allocate frequency
+ table\n, __func__);
return;
}
+ while (!opp_get_lower_opp(opp, freq, mpu_opps)) {
+ freq_table[i].index = i;
+ freq_table[i].frequency = freq / 1000;
+ i++;
+ }
+
freq_table[i].index = i;
freq_table[i].frequency = CPUFREQ_TABLE_END;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10 V3] omap3: pm: srf: use opp accessor functions
With the accessor functions, many of the direct accesses are redundant. However we do not want to rewrite SRF at this point of time We do the following here: Remove get_opp and introduce three SRF specific accessor functions: opp_to_freq, freq_to_opp - need this coz of usage of opp IDs NOTE: These functions should be removed at a later point of time. get_opp is removed because, with the above functions, it is redundant. NOTE: this implementation is just a start and leaves scope for further cleanups which can be added on top. NOTE: this increases the number of warnings to: arch/arm/mach-omap2/resource34xx.c: In function 'opp_to_freq': arch/arm/mach-omap2/resource34xx.c:182: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'freq_to_opp': arch/arm/mach-omap2/resource34xx.c:213: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c: In function 'init_opp': arch/arm/mach-omap2/resource34xx.c:242: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:249: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp_freq': arch/arm/mach-omap2/resource34xx.c:302: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:303: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:308: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'program_opp': arch/arm/mach-omap2/resource34xx.c:351: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:352: warning: 'opp_id' is deprecated (declared at arch/arm/plat-omap/include/plat/opp.h:33) arch/arm/mach-omap2/resource34xx.c:356: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:380: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'resource_set_opp_level': arch/arm/mach-omap2/resource34xx.c:417: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:418: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:420: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_opp': arch/arm/mach-omap2/resource34xx.c:497: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_opp': arch/arm/mach-omap2/resource34xx.c:516: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:518: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'init_freq': arch/arm/mach-omap2/resource34xx.c:541: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c:544: warning: 'opp_to_freq' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:175) arch/arm/mach-omap2/resource34xx.c: In function 'set_freq': arch/arm/mach-omap2/resource34xx.c:560: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:565: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c: In function 'validate_freq': arch/arm/mach-omap2/resource34xx.c:579: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) arch/arm/mach-omap2/resource34xx.c:581: warning: 'freq_to_opp' is deprecated (declared at arch/arm/mach-omap2/resource34xx.c:205) Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Romit Dasgupta ro...@ti.com Cc: Sanjeev Premi pr...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com Cc: Thara Gopinath th...@ti.com Cc: Vishwanath Sripathy vishwanath...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/resource34xx.c | 244 ++-- 1 files changed, 180 insertions(+), 64 deletions(-) diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-omap2/resource34xx.c index
[PATCH 09/10 V3] omap3: pm: introduce 3630 opps
Introduce the OMAP3630 OPPs including the defined OPP tuples.
Further information on OMAP3630 can be found here:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123navigationId=12836contentId=52606
OMAP36xx family introduces:
VDD1 with 4 OPPs, of which OPP3 4 are available only on devices yet
to be introduced in 36xx family. Meanwhile, VDD2 has 2 opps.
Device Support of OPPs-
|-3630-600-| (default)
|- 3630-800-| (device: TBD)
|- 3630-1000-| (device: TBD)
H/w OPP- OPP50 OPP100 OPP-Turbo OPP1G-SB
VDD1 OPP1 OPP2 OPP3OPP4
VDD2 OPP1 OPP2 OPP2OPP2
Note:
a) TI h/w naming for OPPs are now standardized in terms of OPP50, 100,
Turbo and SB. This maps as shown above to the opp IDs (s/w term).
b) For boards which need custom VDD1/2 OPPs, the opp table can be
updated by the board file on a need basis after the
omap3_pm_init_opp_table call. The OPPs introduced here are the
official OPP table at this point in time.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Romit Dasgupta ro...@ti.com
Cc: Sanjeev Premi pr...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Cc: Thara Gopinath th...@ti.com
Cc: Vishwanath Sripathy vishwanath...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 49 -
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ad21f5f..05ecf02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -143,6 +143,41 @@ static struct omap_opp_def __initdata
omap34xx_dsp_rate_table[] = {
{.enabled = 0, .freq = 0, .u_volt = 0}
};
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 3, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 6, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 8, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 10, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /*OPP1 - OPP50 */
+ {.enabled = true, .freq = 1, .u_volt = 93},
+ /*OPP2 - OPP100, OPP-Turbo, OPP-SB*/
+ {.enabled = true, .freq = 2, .u_volt = 1137500},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /*OPP1 - OPP50*/
+ {.enabled = true, .freq = 26000, .u_volt = 93},
+ /*OPP2 - OPP100*/
+ {.enabled = true, .freq = 52000, .u_volt = 110},
+ /*OPP3 - OPP-Turbo*/
+ {.enabled = false, .freq = 66000, .u_volt = 126},
+ /*OPP4 - OPP-SB*/
+ {.enabled = false, .freq = 87500, .u_volt = 131},
+ /* Terminator */
+ {.enabled = 0, .freq = 0, .u_volt = 0}
+};
+
struct omap_opp *omap3_mpu_rate_table;
struct omap_opp *omap3_dsp_rate_table;
struct omap_opp *omap3_l3_rate_table;
@@ -1299,18 +1334,28 @@ static void __init configure_vc(void)
void __init omap3_pm_init_opp_table(void)
{
int ret, i;
+ struct omap_opp_def **omap3_opp_def_list;
struct omap_opp_def *omap34xx_opp_def_list[] = {
omap34xx_mpu_rate_table,
omap34xx_l3_rate_table,
omap34xx_dsp_rate_table
};
+ struct omap_opp_def *omap36xx_opp_def_list[] = {
+ omap36xx_mpu_rate_table,
+ omap36xx_l3_rate_table,
+ omap36xx_dsp_rate_table
+ };
struct omap_opp **omap3_rate_tables[] = {
omap3_mpu_rate_table,
omap3_l3_rate_table,
omap3_dsp_rate_table
};
- for (i = 0; i ARRAY_SIZE(omap34xx_opp_def_list); i++) {
- ret = opp_init(omap3_rate_tables[i], omap34xx_opp_def_list[i]);
+
+ omap3_opp_def_list = cpu_is_omap3630() ? omap36xx_opp_def_list :
+ omap34xx_opp_def_list;
+
+ for (i = 0; i ARRAY_SIZE(omap3_rate_tables); i++) {
+ ret = opp_init(omap3_rate_tables[i], omap3_opp_def_list[i]);
/* We dont want half configured system at the moment */
BUG_ON(ret);
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Olof Johansson Sent: Tuesday, November 24, 2009 10:52 PM To: G, Manjunath Kondaiah Cc: Govindraj; g...@lixom.net; Tony Lindgren; linux- o...@vger.kernel.org; Pandita, Vikram; Raja, Govindraj Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote: -Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Monday, November 23, 2009 10:36 PM To: Govindraj; g...@lixom.net Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj; G, Manjunath Kondaiah Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Govindaj, I'm having problems with these patches on Zoom2 with debug board, since they don't seem to coexist very well together with 8250. Enabling both options will result in build errors. Why do we need to enable both 8250 and omap-serial for console. The console UART can be either external UART or any one of the omap UART right? You should allow both of them to be enabled at the same time, so the same kernel can for example be booted on a ZOOM2 with debug board attached (8250 on GPMC), or on a beagle/overo board. Making them exclusive would be a step backwards. More so, selecting both config option really shouldn't break the build. If one expect a build break because only one of the options can be enabled then clearly the dependency should be used so that user can select only one option at a time. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, November 25, 2009 12:06 PM To: Olof Johansson; G, Manjunath Kondaiah Cc: Govindraj; g...@lixom.net; Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj Subject: RE: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Olof Johansson Sent: Tuesday, November 24, 2009 10:52 PM To: G, Manjunath Kondaiah Cc: Govindraj; g...@lixom.net; Tony Lindgren; linux- o...@vger.kernel.org; Pandita, Vikram; Raja, Govindraj Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Tue, Nov 24, 2009 at 03:04:09PM +0530, G, Manjunath Kondaiah wrote: -Original Message- From: Olof Johansson [mailto:o...@lixom.net] Sent: Monday, November 23, 2009 10:36 PM To: Govindraj; g...@lixom.net Cc: Tony Lindgren; linux-omap@vger.kernel.org; Pandita, Vikram; Raja, Govindraj; G, Manjunath Kondaiah Subject: Re: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver. On Fri, Nov 20, 2009 at 03:21:26PM +0530, Govindraj wrote: I have not seen any comments on this patch series yet. Tony, Is there something I need to modify? Govindaj, I'm having problems with these patches on Zoom2 with debug board, since they don't seem to coexist very well together with 8250. Enabling both options will result in build errors. Why do we need to enable both 8250 and omap-serial for console. The console UART can be either external UART or any one of the omap UART right? You should allow both of them to be enabled at the same time, so the same kernel can for example be booted on a ZOOM2 with debug board attached (8250 on GPMC), or on a beagle/overo board. Making them exclusive would be a step backwards. More so, selecting both config option really shouldn't break the build. If one expect a build break because only one of the options can be enabled then clearly the dependency should be used so that user can select only one option at a time. Ack. There should be dependency in Kconfig so that user can select either 8250 console(through Quad-uart for zoom2/zoom3) or OMAP-serial Console(through OMAP UART's). -Manjunath-- To unsubscribe from this list: send the line unsubscribe 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: [PATCHv3 0/3] OMAP UART: Adding support for omap-serial driver.
G, Manjunath Kondaiah wrote: You should allow both of them to be enabled at the same time, so the same kernel can for example be booted on a ZOOM2 with debug board attached (8250 on GPMC), or on a beagle/overo board. Making them exclusive would be a step backwards. More so, selecting both config option really shouldn't break the build. If one expect a build break because only one of the options can be enabled then clearly the dependency should be used so that user can select only one option at a time. Ack. There should be dependency in Kconfig so that user can select either 8250 console(through Quad-uart for zoom2/zoom3) or OMAP-serial Console(through OMAP UART's). No. The drivers MUST handle co-existing. You can have a bunch of drivers configured to be _potential_ consoles, which one will end up being used depends on, among other things, the bootargs. But it should be allowed to configure both 8250 and omap-serial at the same time. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
