Re: [PATCH 00/09] OMAP3 clock: Clock rate change notifiers
On Mon, 23 Mar 2009, Paul Walmsley wrote: On Fri, 20 Mar 2009, Nayak, Rajendra wrote: This patch set reverts some patches from Paul Walmsley to add the clock notification infrastucture for OMAP3, and adds new patches from him on top, which have only been circulating internally. These patches are posted as they are needed for the patch set to remove virtual clock nodes that will follow. These patches are based on the pm-2.6.28 branch from Kevin's pm tree. Thanks for posting these. These aren't ready for merging yet since they don't contain some of the fixes discussed over the past few weeks. I'll repost an updated version of these later today. Will take another shot at this later today; I'd like to do some more testing on the parent change case before I post these. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Export notifier register functions for kernel module building
Hello Kevin, Ramesh,
On Thu, 12 Feb 2009, Kevin Hilman wrote:
Gupta, Ramesh grgu...@ti.com writes:
This Patch exports symbols clk_notifier_register/unregister
function for other kernel modules usage.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
Thanks, pushed to PM branch.
As an aside, this patch should be reverted. DSPBridge and other drivers
needing clock notifiers should pass function pointers to
clk_notifier_{register,unregister}() in their struct platform_data, rather
than exporting those symbols. This will keep the drivers
platform-agnostic, since system-wide clock notifiers are not yet upstream.
regards,
- Paul
---
arch/arm/plat-omap/clock.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index e0940a1..c8d9e96 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -680,6 +680,7 @@ int clk_notifier_register(struct clk *clk, struct
notifier_block *nb)
return r;
}
+EXPORT_SYMBOL(clk_notifier_register);
/**
* clk_notifier_unregister - remove a clock change notifier
@@ -735,6 +736,7 @@ int clk_notifier_unregister(struct clk *clk, struct
notifier_block *nb)
return r;
}
+EXPORT_SYMBOL(clk_notifier_unregister);
--
1.5.3.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
--
To unsubscribe from this list: send the line unsubscribe 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/1] Export notifier register functions for kernel module building
Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, March 24, 2009 2:58 PM
To: Kevin Hilman
Cc: Gupta, Ramesh; linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/1] Export notifier register functions
for kernel module building
Hello Kevin, Ramesh,
On Thu, 12 Feb 2009, Kevin Hilman wrote:
Gupta, Ramesh grgu...@ti.com writes:
This Patch exports symbols
clk_notifier_register/unregister function
for other kernel modules usage.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
Thanks, pushed to PM branch.
As an aside, this patch should be reverted. DSPBridge and
other drivers needing clock notifiers should pass function pointers to
clk_notifier_{register,unregister}() in their struct
platform_data, rather than exporting those symbols. This
will keep the drivers platform-agnostic, since system-wide
clock notifiers are not yet upstream.
I agree on this, I think the latest patch set from Rajendra Naik([1]) removes
the EXPORT_SYMBOL for the clk notifier functions.
Ref[1]: http://marc.info/?l=linux-omapm=123755561914202w=2
Ref[2]: http://marc.info/?l=linux-omapm=123755561914205w=2
We will send a patch to dspbridge sources to adopt these changes.
Please let me know your comments.
Thanks
Ramesh Gupta G--
To unsubscribe from this list: send the line unsubscribe 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/1] Export notifier register functions for kernel module building
On Tue, 24 Mar 2009, Gupta, Ramesh wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
DSPBridge and
other drivers needing clock notifiers should pass function pointers to
clk_notifier_{register,unregister}() in their struct
platform_data, rather than exporting those symbols. This
will keep the drivers platform-agnostic, since system-wide
clock notifiers are not yet upstream.
I agree on this, I think the latest patch set from Rajendra Naik([1])
removes the EXPORT_SYMBOL for the clk notifier functions.
We will send a patch to dspbridge sources to adopt these changes.
Please let me know your comments.
Sounds good to me.
regards,
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Hari, On Mon, Mar 23, 2009 at 8:49 PM, Kanigeri, Hari h-kanige...@ti.com wrote: DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject, pCtxtclosed, (void *)pCtxtclosed-pid); I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. Any pointers? Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: McBSP: Fix legacy interrupts to clear their status
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
If XSYNCERR or RSYNCERR interrupts are enabled, they are never
cleared causing the IRQ handler to be continuously called.
This patch clears the IRQs in question in the event they are
enabled and taken.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e2e8b76..6a10f65 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -91,11 +91,20 @@ static void omap_mcbsp_dump_reg(u8 id)
static irqreturn_t omap_mcbsp_tx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_tx = dev_id;
+ u16 irqst_spcr2;
- dev_dbg(mcbsp_tx-dev, TX IRQ callback : 0x%x\n,
- OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2));
+ irqst_spcr2 = OMAP_MCBSP_READ(mcbsp_tx-io_base, SPCR2);
+ dev_dbg(mcbsp_tx-dev, TX IRQ callback : 0x%x\n, irqst_spcr2);
- complete(mcbsp_tx-tx_irq_completion);
+ if (irqst_spcr2 XSYNC_ERR) {
+ dev_err(mcbsp_tx-dev, TX Frame Sync Error! : 0x%x\n,
+ irqst_spcr2);
+ /* Writing zero to XSYNC_ERR clears the IRQ */
+ OMAP_MCBSP_WRITE(mcbsp_tx-io_base, SPCR2,
+ irqst_spcr2 ~(XSYNC_ERR));
+ } else {
+ complete(mcbsp_tx-tx_irq_completion);
+ }
return IRQ_HANDLED;
}
@@ -103,11 +112,20 @@ static irqreturn_t omap_mcbsp_tx_irq_handler(int irq,
void *dev_id)
static irqreturn_t omap_mcbsp_rx_irq_handler(int irq, void *dev_id)
{
struct omap_mcbsp *mcbsp_rx = dev_id;
+ u16 irqst_spcr1;
- dev_dbg(mcbsp_rx-dev, RX IRQ callback : 0x%x\n,
- OMAP_MCBSP_READ(mcbsp_rx-io_base, SPCR2));
+ irqst_spcr1 = OMAP_MCBSP_READ(mcbsp_rx-io_base, SPCR1);
+ dev_dbg(mcbsp_rx-dev, RX IRQ callback : 0x%x\n, irqst_spcr1);
- complete(mcbsp_rx-rx_irq_completion);
+ if (irqst_spcr1 RSYNC_ERR) {
+ dev_err(mcbsp_rx-dev, RX Frame Sync Error! : 0x%x\n,
+ irqst_spcr1);
+ /* Writing zero to RSYNC_ERR clears the IRQ */
+ OMAP_MCBSP_WRITE(mcbsp_rx-io_base, SPCR1,
+ irqst_spcr1 ~(RSYNC_ERR));
+ } else {
+ complete(mcbsp_rx-tx_irq_completion);
+ }
return IRQ_HANDLED;
}
--
1.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 07/08] OMAP3: SR: Remove redundunt defines
From: Rajendra Nayak rna...@ti.com
This patch removes the local defines (PRCM_VDD1/2) in smartreflex
driver and uses the already existing global definitions (VDD1_OPP/VDD2_OPP)
from omap34xx.h file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/resource34xx.c |6 +++---
arch/arm/mach-omap2/smartreflex.c |8
arch/arm/mach-omap2/smartreflex.h |3 ---
3 files changed, 7 insertions(+), 10 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c 2009-03-24
14:25:28.045987206 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c2009-03-24
14:41:36.122985549 +0530
@@ -217,7 +217,7 @@
/* Send pre notification to CPUFreq */
cpufreq_notify_transition(freqs_notify, CPUFREQ_PRECHANGE);
#endif
- t_opp = ID_VDD(PRCM_VDD1) |
+ t_opp = ID_VDD(VDD1_OPP) |
ID_OPP_NO(mpu_opps[target_level].opp_id);
/* For VDD1 OPP3 and above, make sure the interconnect
@@ -257,7 +257,7 @@
return 0;
l3_freq = get_freq(l3_opps + MAX_VDD2_OPP,
target_level);
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[target_level].opp_id);
if (resp-curr_level target_level) {
/* Scale Frequency and then voltage */
@@ -278,7 +278,7 @@
if (ret) {
#ifdef CONFIG_OMAP_SMARTREFLEX
/* Setting clock failed, revert voltage */
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[resp-curr_level].
opp_id);
sr_voltagescale_vcbypass(t_opp,
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:21.798416209 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:36.123985519 +0530
@@ -677,7 +677,7 @@
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
- if (vdd == PRCM_VDD1) {
+ if (vdd == VDD1_OPP) {
sr_status = sr_stop_vddautocomap(SR1);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -686,7 +686,7 @@
OMAP3_PRM_VC_CMD_VAL_0_OFFSET);
reg_addr = R_VDD1_SR_CONTROL;
- } else if (vdd == PRCM_VDD2) {
+ } else if (vdd == VDD2_OPP) {
sr_status = sr_stop_vddautocomap(SR2);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -725,9 +725,9 @@
udelay(T2_SMPS_UPDATE_DELAY);
if (sr_status) {
- if (vdd == PRCM_VDD1)
+ if (vdd == VDD1_OPP)
sr_start_vddautocomap(SR1, target_opp_no);
- else if (vdd == PRCM_VDD2)
+ else if (vdd == VDD2_OPP)
sr_start_vddautocomap(SR2, target_opp_no);
}
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.h
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.h2009-03-24
14:25:28.046987177 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.h 2009-03-24
14:41:36.123985519 +0530
@@ -171,9 +171,6 @@
/* R_DCDC_GLOBAL_CFG register, SMARTREFLEX_ENABLE values */
#define DCDC_GLOBAL_CFG_ENABLE_SRFLX 0x08
-/* VDDs*/
-#define PRCM_VDD1 1
-#define PRCM_VDD2 2
#define PRCM_MAX_SYSC_REGS 30
/*
--
To unsubscribe from this list: send the line unsubscribe 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 00/08] OMAP3: SR: Fixes in Smartreflex driver - Resending
Hi, Resending the patches sent by Rajendra after fixing Kevin's comments and cleanup. This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. Patches apply on top of the pm-2.6.28 branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git regards, Rajendra-- -- To unsubscribe from this list: send the line unsubscribe 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/08] OMAP3: SR: Fix init voltage on OPP change
From: Rajendra Nayak rna...@ti.com
This patch fixes a bug wherein the inital voltage was not set
correctly on a OPP change
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 42 ++
1 files changed, 38 insertions(+), 4 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:25:28.133984580 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:40:25.024122683 +0530
@@ -30,6 +30,7 @@
#include mach/omap34xx.h
#include mach/control.h
#include mach/clock.h
+#include mach/omap-pm.h
#include prm.h
#include smartreflex.h
@@ -183,7 +184,6 @@
sr-senn_mod = (omap_ctrl_readl(OMAP343X_CONTROL_FUSE_SR)
OMAP343X_SR1_SENNENABLE_MASK)
OMAP343X_SR1_SENNENABLE_SHIFT;
-
sr-senp_mod = (omap_ctrl_readl(OMAP343X_CONTROL_FUSE_SR)
OMAP343X_SR1_SENPENABLE_MASK)
OMAP343X_SR1_SENPENABLE_SHIFT;
@@ -364,7 +364,12 @@
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
{
- u32 nvalue_reciprocal;
+ u32 nvalue_reciprocal, v;
+
+ if (!(mpu_opps l3_opps)) {
+ pr_notice(VSEL values not found\n);
+ return false;
+ }
sr-req_opp_no = target_opp_no;
@@ -418,14 +423,43 @@
sr_modify_reg(sr, ERRCONFIG,
(ERRCONFIG_VPBOUNDINTEN | ERRCONFIG_VPBOUNDINTST),
(ERRCONFIG_VPBOUNDINTEN | ERRCONFIG_VPBOUNDINTST));
+
if (sr-srid == SR1) {
+ /* set/latch init voltage */
+ v = prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+ v = ~(OMAP3430_INITVOLTAGE_MASK | OMAP3430_INITVDD);
+ v |= mpu_opps[target_opp_no].vsel
+ OMAP3430_INITVOLTAGE_SHIFT;
+ prm_write_mod_reg(v, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
+ /* write1 to latch */
+ prm_set_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+OMAP3_PRM_VP1_CONFIG_OFFSET);
+ /* write2 clear */
+ prm_clear_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP1_CONFIG_OFFSET);
/* Enable VP1 */
prm_set_mod_reg_bits(PRM_VP1_CONFIG_VPENABLE, OMAP3430_GR_MOD,
- OMAP3_PRM_VP1_CONFIG_OFFSET);
+OMAP3_PRM_VP1_CONFIG_OFFSET);
} else if (sr-srid == SR2) {
+ /* set/latch init voltage */
+ v = prm_read_mod_reg(OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+ v = ~(OMAP3430_INITVOLTAGE_MASK | OMAP3430_INITVDD);
+ v |= l3_opps[target_opp_no].vsel
+ OMAP3430_INITVOLTAGE_SHIFT;
+ prm_write_mod_reg(v, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
+ /* write1 to latch */
+ prm_set_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+OMAP3_PRM_VP2_CONFIG_OFFSET);
+ /* write2 clear */
+ prm_clear_mod_reg_bits(OMAP3430_INITVDD, OMAP3430_GR_MOD,
+ OMAP3_PRM_VP2_CONFIG_OFFSET);
/* Enable VP2 */
prm_set_mod_reg_bits(PRM_VP2_CONFIG_VPENABLE, OMAP3430_GR_MOD,
- OMAP3_PRM_VP2_CONFIG_OFFSET);
+OMAP3_PRM_VP2_CONFIG_OFFSET);
}
/* SRCONFIG - enable SR */
--
To unsubscribe from this list: send the line unsubscribe 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 03/08] OMAP3: SR: Use sysclk for SR CLKLENGTH calc
From: Rajendra Nayak rna...@ti.com
This patch uses the sysclk to set the SR CLKLENGTH instead
of the OSC clock speed used earlier.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-20
10:49:30.773100978 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-20
10:49:56.473312008 +0530
@@ -146,14 +146,14 @@ static u32 cal_test_nvalue(u32 sennval,
static void sr_set_clk_length(struct omap_sr *sr)
{
- struct clk *osc_sys_ck;
- u32 sys_clk = 0;
+ struct clk *sys_ck;
+ u32 sys_clk_speed;
- osc_sys_ck = clk_get(NULL, osc_sys_ck);
- sys_clk = clk_get_rate(osc_sys_ck);
- clk_put(osc_sys_ck);
+ sys_ck = clk_get(NULL, sys_ck);
+ sys_clk_speed = clk_get_rate(sys_ck);
+ clk_put(sys_ck);
- switch (sys_clk) {
+ switch (sys_clk_speed) {
case 1200:
sr-clk_length = SRCLKLENGTH_12MHZ_SYSCLK;
break;
@@ -170,7 +170,7 @@ static void sr_set_clk_length(struct oma
sr-clk_length = SRCLKLENGTH_38MHZ_SYSCLK;
break;
default :
- printk(KERN_ERR Invalid sysclk value: %d\n, sys_clk);
+ printk(KERN_ERR Invalid sysclk value: %d\n, sys_clk_speed);
break;
}
}
--
To unsubscribe from this list: send the line unsubscribe 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/08] OMAP3: SR: Disable SR autocomp only for CORE trans
From: Rajendra Nayak rna...@ti.com
This patch disables the Smartreflex auto compensation for
both VDD1 and VDD2 only during CORE transitions in idle path.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/pm34xx.c 2009-03-20
10:45:58.505627611 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/pm34xx.c 2009-03-20 10:46:11.362231683
+0530
@@ -321,9 +321,6 @@ void omap_sram_idle(void)
printk(KERN_ERR Invalid mpu state in sram_idle\n);
return;
}
- /* Disable smartreflex before entering WFI */
- disable_smartreflex(SR1);
- disable_smartreflex(SR2);
pwrdm_pre_transition();
@@ -352,6 +349,9 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
+ /* Disable smartreflex before entering WFI */
+ disable_smartreflex(SR1);
+ disable_smartreflex(SR2);
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
if (core_next_state == PWRDM_POWER_OFF) {
@@ -412,6 +412,9 @@ void omap_sram_idle(void)
prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
+ /* Enable smartreflex after WFI */
+ enable_smartreflex(SR1);
+ enable_smartreflex(SR2);
}
/* PER */
@@ -432,9 +435,6 @@ void omap_sram_idle(void)
if (core_next_state PWRDM_POWER_ON)
prm_clear_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
- /* Enable smartreflex after WFI */
- enable_smartreflex(SR1);
- enable_smartreflex(SR2);
pwrdm_post_transition();
--
To unsubscribe from this list: send the line unsubscribe 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 05/08] OMAP3: SR: Reset voltage level on SR disable
From: Rajendra Nayak rna...@ti.com
This patch resets the voltage level for each OPP on SR disable.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/smartreflex.c | 49 ++
1 files changed, 49 insertions(+)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:00.471057326 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:06.054889481 +0530
@@ -379,6 +379,51 @@
sr-is_sr_reset = 0;
}
+static int sr_reset_voltage(int srid)
+{
+ u32 target_opp_no, vsel = 0;
+ u32 reg_addr = 0;
+ u32 loop_cnt = 0, retries_cnt = 0;
+ u32 vc_bypass_value;
+
+ if (srid == SR1) {
+ target_opp_no = resource_get_level(vdd1_opp);
+ vsel = mpu_opps[target_opp_no].vsel;
+ reg_addr = R_VDD1_SR_CONTROL;
+ } else if (srid == SR2) {
+ target_opp_no = resource_get_level(vdd2_opp);
+ vsel = l3_opps[target_opp_no].vsel;
+ reg_addr = R_VDD2_SR_CONTROL;
+ }
+
+ vc_bypass_value = (vsel OMAP3430_DATA_SHIFT) |
+ (reg_addr OMAP3430_REGADDR_SHIFT) |
+ (R_SRI2C_SLAVE_ADDR OMAP3430_SLAVEADDR_SHIFT);
+
+ prm_write_mod_reg(vc_bypass_value, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ vc_bypass_value = prm_set_mod_reg_bits(OMAP3430_VALID, OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+
+ while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
+ loop_cnt++;
+ if (retries_cnt 10) {
+ printk(KERN_INFO Loop count exceeded in check SR I2C
+ write\n);
+ return SR_FAIL;
+ }
+ if (loop_cnt 50) {
+ retries_cnt++;
+ loop_cnt = 0;
+ udelay(10);
+ }
+ vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
+ OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
+ }
+ return SR_PASS;
+}
+
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
{
u32 nvalue_reciprocal, v;
@@ -544,6 +589,8 @@
sr_disable(sr);
sr_clk_disable(sr);
sr-is_autocomp_active = 0;
+ /* Reset the volatage for current OPP */
+ sr_reset_voltage(srid);
return SR_TRUE;
} else {
printk(KERN_WARNING SR%d: VDD autocomp is not active\n,
@@ -612,6 +659,8 @@
OMAP3430_GR_MOD,
OMAP3_PRM_VP2_CONFIG_OFFSET);
}
+ /* Reset the volatage for current OPP */
+ sr_reset_voltage(srid);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe 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/08] OMAP3: SR: Replace printk's with pr_* calls
From: Rajendra Nayak rna...@ti.com
This patch replaces all the printk(KERN_* with pr_* calls.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:06.054889481 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:21.798416209 +0530
@@ -78,7 +78,7 @@
static int sr_clk_enable(struct omap_sr *sr)
{
if (clk_enable(sr-clk) != 0) {
- printk(KERN_ERR Could not enable %s\n, sr-clk-name);
+ pr_err(Could not enable %s\n, sr-clk-name);
return -1;
}
@@ -170,7 +170,7 @@
sr-clk_length = SRCLKLENGTH_38MHZ_SYSCLK;
break;
default :
- printk(KERN_ERR Invalid sysclk value: %d\n, sys_clk_speed);
+ pr_err(Invalid sysclk value: %d\n, sys_clk_speed);
break;
}
}
@@ -409,7 +409,7 @@
while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
loop_cnt++;
if (retries_cnt 10) {
- printk(KERN_INFO Loop count exceeded in check SR I2C
+ pr_info(Loop count exceeded in check SR I2C
write\n);
return SR_FAIL;
}
@@ -474,7 +474,7 @@
}
if (nvalue_reciprocal == 0) {
- printk(KERN_NOTICE OPP%d doesn't support SmartReflex\n,
+ pr_notice(OPP%d doesn't support SmartReflex\n,
target_opp_no);
return SR_FALSE;
}
@@ -563,12 +563,12 @@
}
if (sr-is_autocomp_active == 1)
- printk(KERN_WARNING SR%d: VDD autocomp is already active\n,
+ pr_warning(SR%d: VDD autocomp is already active\n,
srid);
sr-is_autocomp_active = 1;
if (!sr_enable(sr, target_opp_no)) {
- printk(KERN_WARNING SR%d: VDD autocomp not activated\n, srid);
+ pr_warning(SR%d: VDD autocomp not activated\n, srid);
sr-is_autocomp_active = 0;
if (sr-is_sr_reset == 1)
sr_clk_disable(sr);
@@ -593,7 +593,7 @@
sr_reset_voltage(srid);
return SR_TRUE;
} else {
- printk(KERN_WARNING SR%d: VDD autocomp is not active\n,
+ pr_warning(SR%d: VDD autocomp is not active\n,
srid);
return SR_FALSE;
}
@@ -709,7 +709,7 @@
while ((vc_bypass_value OMAP3430_VALID) != 0x0) {
loop_cnt++;
if (retries_cnt 10) {
- printk(KERN_INFO Loop count exceeded in check SR I2C
+ pr_info(Loop count exceeded in check SR I2C
write\n);
return SR_FAIL;
}
@@ -749,7 +749,7 @@
unsigned short value;
if (sscanf(buf, %hu, value) != 1 || (value 1)) {
- printk(KERN_ERR sr_vdd1_autocomp: Invalid value\n);
+ pr_err(sr_vdd1_autocomp: Invalid value\n);
return -EINVAL;
}
@@ -787,7 +787,7 @@
unsigned short value;
if (sscanf(buf, %hu, value) != 1 || (value 1)) {
- printk(KERN_ERR sr_vdd2_autocomp: Invalid value\n);
+ pr_err(sr_vdd2_autocomp: Invalid value\n);
return -EINVAL;
}
@@ -839,15 +839,15 @@
sr_set_nvalues(sr2);
sr_configure_vp(SR2);
- printk(KERN_INFO SmartReflex driver initialized\n);
+ pr_info(SmartReflex driver initialized\n);
ret = sysfs_create_file(power_kobj, sr_vdd1_autocomp.attr);
if (ret)
- printk(KERN_ERR sysfs_create_file failed: %d\n, ret);
+ pr_err(sysfs_create_file failed: %d\n, ret);
ret = sysfs_create_file(power_kobj, sr_vdd2_autocomp.attr);
if (ret)
- printk(KERN_ERR sysfs_create_file failed: %d\n, ret);
+ pr_err(sysfs_create_file failed: %d\n, ret);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/08] OMAP3: SR: Remove redundunt defines
From: Rajendra Nayak rna...@ti.com
This patch removes the local defines (PRCM_VDD1/2) in smartreflex
driver and uses the already existing global definitions (VDD1_OPP/VDD2_OPP)
from omap34xx.h file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/resource34xx.c |6 +++---
arch/arm/mach-omap2/smartreflex.c |8
arch/arm/mach-omap2/smartreflex.h |3 ---
3 files changed, 7 insertions(+), 10 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/resource34xx.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/resource34xx.c 2009-03-24
14:25:28.045987206 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/resource34xx.c2009-03-24
14:41:36.122985549 +0530
@@ -217,7 +217,7 @@
/* Send pre notification to CPUFreq */
cpufreq_notify_transition(freqs_notify, CPUFREQ_PRECHANGE);
#endif
- t_opp = ID_VDD(PRCM_VDD1) |
+ t_opp = ID_VDD(VDD1_OPP) |
ID_OPP_NO(mpu_opps[target_level].opp_id);
/* For VDD1 OPP3 and above, make sure the interconnect
@@ -257,7 +257,7 @@
return 0;
l3_freq = get_freq(l3_opps + MAX_VDD2_OPP,
target_level);
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[target_level].opp_id);
if (resp-curr_level target_level) {
/* Scale Frequency and then voltage */
@@ -278,7 +278,7 @@
if (ret) {
#ifdef CONFIG_OMAP_SMARTREFLEX
/* Setting clock failed, revert voltage */
- t_opp = ID_VDD(PRCM_VDD2) |
+ t_opp = ID_VDD(VDD2_OPP) |
ID_OPP_NO(l3_opps[resp-curr_level].
opp_id);
sr_voltagescale_vcbypass(t_opp,
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:41:21.798416209 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:41:36.123985519 +0530
@@ -677,7 +677,7 @@
vdd = get_vdd(target_opp);
target_opp_no = get_opp_no(target_opp);
- if (vdd == PRCM_VDD1) {
+ if (vdd == VDD1_OPP) {
sr_status = sr_stop_vddautocomap(SR1);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -686,7 +686,7 @@
OMAP3_PRM_VC_CMD_VAL_0_OFFSET);
reg_addr = R_VDD1_SR_CONTROL;
- } else if (vdd == PRCM_VDD2) {
+ } else if (vdd == VDD2_OPP) {
sr_status = sr_stop_vddautocomap(SR2);
prm_rmw_mod_reg_bits(OMAP3430_VC_CMD_ON_MASK,
@@ -725,9 +725,9 @@
udelay(T2_SMPS_UPDATE_DELAY);
if (sr_status) {
- if (vdd == PRCM_VDD1)
+ if (vdd == VDD1_OPP)
sr_start_vddautocomap(SR1, target_opp_no);
- else if (vdd == PRCM_VDD2)
+ else if (vdd == VDD2_OPP)
sr_start_vddautocomap(SR2, target_opp_no);
}
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.h
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.h2009-03-24
14:25:28.046987177 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.h 2009-03-24
14:41:36.123985519 +0530
@@ -171,9 +171,6 @@
/* R_DCDC_GLOBAL_CFG register, SMARTREFLEX_ENABLE values */
#define DCDC_GLOBAL_CFG_ENABLE_SRFLX 0x08
-/* VDDs*/
-#define PRCM_VDD1 1
-#define PRCM_VDD2 2
#define PRCM_MAX_SYSC_REGS 30
/*
--
To unsubscribe from this list: send the line unsubscribe 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/08] OMAP3: SR: Replace SR_PASS/FAIL,SR_TRUE/FALSE with standard kernel values
From: Teerth Reddy tee...@ti.com
This patch has some cleanup , replacing SR_PASS/FAIL,SR_TRUE/FALSE
with standard kernel values.
Signed-off-by: Teerth Reddy tee...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/smartreflex.c2009-03-24
14:42:33.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/smartreflex.c 2009-03-24
14:45:59.336965640 +0530
@@ -411,7 +411,7 @@
if (retries_cnt 10) {
pr_info(Loop count exceeded in check SR I2C
write\n);
- return SR_FAIL;
+ return 1;
}
if (loop_cnt 50) {
retries_cnt++;
@@ -421,7 +421,7 @@
vc_bypass_value = prm_read_mod_reg(OMAP3430_GR_MOD,
OMAP3_PRM_VC_BYPASS_VAL_OFFSET);
}
- return SR_PASS;
+ return 0;
}
static int sr_enable(struct omap_sr *sr, u32 target_opp_no)
@@ -476,7 +476,7 @@
if (nvalue_reciprocal == 0) {
pr_notice(OPP%d doesn't support SmartReflex\n,
target_opp_no);
- return SR_FALSE;
+ return false;
}
sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
@@ -526,7 +526,7 @@
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
- return SR_TRUE;
+ return true;
}
static void sr_disable(struct omap_sr *sr)
@@ -591,11 +591,11 @@
sr-is_autocomp_active = 0;
/* Reset the volatage for current OPP */
sr_reset_voltage(srid);
- return SR_TRUE;
+ return true;
} else {
pr_warning(SR%d: VDD autocomp is not active\n,
srid);
- return SR_FALSE;
+ return false;
}
}
@@ -711,7 +711,7 @@
if (retries_cnt 10) {
pr_info(Loop count exceeded in check SR I2C
write\n);
- return SR_FAIL;
+ return 1;
}
if (loop_cnt 50) {
retries_cnt++;
@@ -731,7 +731,7 @@
sr_start_vddautocomap(SR2, target_opp_no);
}
- return SR_PASS;
+ return 0;
}
/* Sysfs interface to select SR VDD1 auto compensation */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to test regulator driver?
I am seriously confused on how to fetch the struct device * in my consumer driver, for an already registered regulator. I am planning to use this consumer driver as a part of my CPU freq/CPU idle framework but I don't know what to pass in regulator_get. Should I register my regulator device as a platform_device as against an i2c_client device what I am having now? Other regulator drivers (drivers/regulator/twl4030-regulator.c, wm8400.c etc) are doing the same thing in their code. Using the current approach, I am facing difficulty in getting the struct device * for invoking the regulator_get()? Otherwise, can I expose one function in my regulator driver which will return the appropriate struct device * when user calls it with a supply name string? This device pointer then will be used in my consumer driver while calling the regulator_get API? Thanks and Regards, Anuj Aggarwal Platform Support Products Texas Instruments Inc Ph: +91-80-2509-9542 TI IP Ph: 509-9542 PSP Products RSS Feed PSP Product Announcements -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mark Brown Sent: Monday, March 09, 2009 9:03 PM To: Anuj Aggarwal Cc: Linux OMAP List Subject: Re: How to test regulator driver? On Mon, Mar 09, 2009 at 08:32:55PM +0530, Anuj Aggarwal wrote: I want to test my regulator driver by writing a small kernel module. But I am a little confused as what should be passed as the first argument of regulator_get(). How would the kernel module know about the device pointer that needs to be passed to the _get function? regulator_get() takes the struct device for the consumer as an argument so it depends on what your consumer is. For test purposes there's an existing virtual consumer driver in the tree which should hopefully save you having to write your own - it allows you to poke the settings from sysfs. drivers/regulator/virtual.c Questions like this that aren't OMAP-specific should really be asked on the relevant general list (in this case linux-kernel). -- To unsubscribe from this list: send the line unsubscribe 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] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Amey, I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. This pointer is getting freed indirectly through the pCtxt2 pointer. The call to the function DRV_GetProcContext((u32)hProcess, hDRVObject, pCtxt2, NULL, 0) returns pCtxt2, which is same as pCtxtclosed that is passed to this function. In a way, the call to DRV_GetProcContext is kind of redundant, but I think it is present here to provide the support to extract the Process Context when only the PID is passed in. Thank you, Best regards, Hari -Original Message- From: Ameya Palande [mailto:2am...@gmail.com] Sent: Tuesday, March 24, 2009 5:05 AM To: Kanigeri, Hari Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup Hi Hari, On Mon, Mar 23, 2009 at 8:49 PM, Kanigeri, Hari h-kanige...@ti.com wrote: DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject, pCtxtclosed, (void *)pCtxtclosed- pid); I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. Any pointers? Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Hi Hari, ext Kanigeri, Hari wrote: Hi Amey, I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. This pointer is getting freed indirectly through the pCtxt2 pointer. The call to the function DRV_GetProcContext((u32)hProcess, hDRVObject, pCtxt2, NULL, 0) returns pCtxt2, which is same as pCtxtclosed that is passed to this function. In a way, the call to DRV_GetProcContext is kind of redundant, but I think it is present here to provide the support to extract the Process Context when only the PID is passed in. Thanks for the explanation :) Is there any need to pass HANDLE hPCtxt to DRV_RemoveProcContext() function? Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup
Ameya, Is there any need to pass HANDLE hPCtxt to DRV_RemoveProcContext() function? -- It should work even if you don't pass the hPCtxt. This function requires some rework to avoid this confusion. Thanks for bringing up this question. Thank you, Best regards, Hari -Original Message- From: Ameya Palande [mailto:ameya.pala...@nokia.com] Sent: Tuesday, March 24, 2009 6:56 AM To: Kanigeri, Hari Cc: Ameya Palande; linux-omap@vger.kernel.org Subject: Re: [PATCH] [OMAPZOOM]DSPBRIDGE bug in Bridge exit cleanup Hi Hari, ext Kanigeri, Hari wrote: Hi Amey, I am trying to understand this patch. I see that pCtxtclosed is passed to DRV_RemoveProcContext() function but it is not used anywhere inside it. I was expecting to see a statement there which should free its memory. This pointer is getting freed indirectly through the pCtxt2 pointer. The call to the function DRV_GetProcContext((u32)hProcess, hDRVObject, pCtxt2, NULL, 0) returns pCtxt2, which is same as pCtxtclosed that is passed to this function. In a way, the call to DRV_GetProcContext is kind of redundant, but I think it is present here to provide the support to extract the Process Context when only the PID is passed in. Thanks for the explanation :) Is there any need to pass HANDLE hPCtxt to DRV_RemoveProcContext() function? Cheers, Ameya. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: mmc_twl4030 nicely disable vmmc_aux
From 1a3f939d95122d8e58a3750cf5bce09247357203 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
The MMC driver turns the power off before it turns it
on. To avoid regulator warnings, vmmc_aux must only be
disabled if it has previously been enabled.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 2ff50f0..cb56fe2 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -305,7 +305,7 @@ static int twl_mmc23_set_power(struct device *dev, int
slot, int power_on, int v
ret = mmc_regulator_set_ocr(c-vcc, 0);
}
} else {
- if (c-vcc_aux)
+ if (c-vcc_aux (ret = regulator_is_enabled(c-vcc_aux)) 0)
ret = regulator_disable(c-vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(c-vcc, 0);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] RX51: connect VAUX3 to MMC2
From 6d7a4c9322e70e83bdcf66d151c1ce56ba2f949f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 29 +++--
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 6e23587..41bb392 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -30,6 +30,8 @@
#include mmc-twl4030.h
+#define SYSTEM_REV_B_USES_VAUX3 0x1699
+#define SYSTEM_REV_S_USES_VAUX3 0x8
#define SMC91X_CS 1
#define SMC91X_GPIO_IRQ 54
@@ -306,7 +308,7 @@ static struct regulator_init_data rx51_vaux2 = {
};
/* VAUX3 - adds more power to VIO_18 rail */
-static struct regulator_init_data rx51_vaux3 = {
+static struct regulator_init_data rx51_vaux3_cam = {
.constraints = {
.name = VCAM_DIG_18,
.min_uV = 180,
@@ -319,6 +321,22 @@ static struct regulator_init_data rx51_vaux3 = {
},
};
+static struct regulator_init_data rx51_vaux3_mmc = {
+ .constraints = {
+ .name = VMMC2_30,
+ .min_uV = 280,
+ .max_uV = 300,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = rx51_vmmc2_supply,
+};
+
static struct regulator_init_data rx51_vaux4 = {
.constraints = {
.name = VCAM_ANA_28,
@@ -429,10 +447,8 @@ static struct twl4030_platform_data rx51_twldata = {
.vaux1 = rx51_vaux1,
.vaux2 = rx51_vaux2,
- .vaux3 = rx51_vaux3,
.vaux4 = rx51_vaux4,
.vmmc1 = rx51_vmmc1,
- .vmmc2 = rx51_vmmc2,
.vsim = rx51_vsim,
.vdac = rx51_vdac,
};
@@ -448,6 +464,13 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
static int __init rx51_i2c_init(void)
{
+ if ((system_rev = SYSTEM_REV_S_USES_VAUX3 system_rev 0x100) ||
+ system_rev = SYSTEM_REV_B_USES_VAUX3)
+ rx51_twldata.vaux3 = rx51_vaux3_mmc;
+ else {
+ rx51_twldata.vaux3 = rx51_vaux3_cam;
+ rx51_twldata.vmmc2 = rx51_vmmc2;
+ }
omap_register_i2c_bus(1, 2600, rx51_peripherals_i2c_board_info_1,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
omap_register_i2c_bus(2, 100, NULL, 0);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to test regulator driver?
On Tue, Mar 24, 2009 at 05:14:58PM +0530, Aggarwal, Anuj wrote: I am seriously confused on how to fetch the struct device * in my consumer driver, for an already registered regulator. I am planning to use this consumer driver as a part of my CPU freq/CPU idle framework but I don't know what to pass in regulator_get. Your consumer driver should not be using the struct device for the regulator when calling regulator_get(). They should never need to know anything about the struct device of the regulator that is providing a supply to them. The consumer should use a fixed device name and the struct device for itself, these will then be resolved to an actual regulator by the core based on the machine constraints. In the specific case of cpufreq where there is no struct device for the consumer use NULL when calling regulator_get(). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/08] OMAP3: SR: Fixes in Smartreflex driver - Resending
Reddy, Teerth tee...@ti.com writes: Resending the patches sent by Rajendra after fixing Kevin's comments and cleanup. This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse. Patches apply on top of the pm-2.6.28 branch from Kevin's pm tree. git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git This series doesn't compile unless SRF is enabled which after a little more digging makes me see that SmartReflex is not pretty tightly coupled to SRF. I don't think SmartReflex support need to be dependent on SRF? It seems like the resource_get_level() calls should be replaced by OMAP PM layer calls. In particular, resource_get_level(vdd_opp1) could be replaced by omap_pm_dsp_get_opp() etc. Also, one more nitpick about cleanup while we're at it: Can you convert all the bit defines (0x1 n) into BIT(n) 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: PM branch rebased to 2.6.29
On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I'm trying to bring up your PM branch on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into retention but doesn't come back out, and rather than thrash on the LDP defconfig, start with a config/code that is known to work. I'm also resnapping to commit c3127068... to jump to the latest from your tree and start my port over. I have to get suspend/resume working first before I start working in all the drivers, and check that suspend/resume works for each functional addition... Thanks in advance! Kevin -- Misc. conflicts/issues resolved after rebase: - no longer safe to use getnstimeofday() in suspend path since timekeeping subsystem is also suspended in the suspend path. PM debug timing has been converted to use sched_clock() which is 32k sync-timer based. - Update board-rx51.c to use common OMAP3 OPPs Known issues: - Beagle: MMC: off-mode needs work in MMC driver, so if you hit off and have a rootfs on MMC, you're dead. - Beagle: MMC regulator: unbalanced disables. This happens on boot and during suspend/resume. I don't think this is related to the PM branch, but is probably in linux-omap HEAD also, but didn't test. Linux version 2.6.29-rc8-omap1-arm-omap3beagle-default-05653-gd803372-dirty (khil...@vence) (gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) ) #4 PREEMPT Tue Mar 17 21:38:09 PDT 2009 [...] i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz twl4030: PIH (irq 7) chaining IRQs 368..375 twl4030: power (irq 373) chaining IRQs 376..383 twl4030: gpio (irq 368) chaining IRQs 384..401 beagle_twl_gpio_setup:145 twl4030_mmc_init:303 twl4030_mmc_init:318 regulator: VMMC1: 1850 -- 3150 mV normal standby regulator: VDAC: 1800 mV normal standby regulator: VUSB1V5: 1500 -- 0 mV normal standby regulator: VUSB1V8: 1800 -- 0 mV normal standby regulator: VUSB3V1: 3100 -- 0 mV normal standby regulator: VSIM: 1800 -- 3000 mV normal standby [...] mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock [ cut here ] WARNING: at /net/home/khilman/work/kernel/omap/pm/drivers/regulator/core.c:1216 regulator_disable+0x64/0x90() unbalanced disables for supply mmci-omap-hs.0-vmmc Modules linked in: [c02a0830] (dump_stack+0x0/0x14) from [c0053af0] (warn_slowpath+0x6c/0x88) [c0053a84] (warn_slowpath+0x0/0x88) from [c01b8bdc] (regulator_disable+0x64/0x90) r3:c79dc2a0 r2:c03390cb r7:c78e8c20 r6:c78aac38 r5:c78e8c20 r4:fffb [c01b8b78] (regulator_disable+0x0/0x90) from [c0209400] (mmc_regulator_set_ocr+0xb0/0xcc) r7:c78e8c20 r6:0001 r5: r4: [c0209350] (mmc_regulator_set_ocr+0x0/0xcc) from [c003abe8] (twl_mmc1_set_power+0xc0/0xec) r7:c784f538 r6: r5: r4:c039185c [c003ab28] (twl_mmc1_set_power+0x0/0xec) from [c0210aa8] (omap_mmc_set_ios+0x54/0x2b0) r7:c784f538 r6:c784f5c0 r5:c784f400 r4:c7844380 [c0210a54] (omap_mmc_set_ios+0x0/0x2b0) from [c0208dc8] (mmc_power_off+0x54/0x58) r7:c784f400 r6:c7910400 r5: r4:c784f400 [c0208d74] (mmc_power_off+0x0/0x58) from [c0209074] (mmc_start_host+0x14/0x24) [c0209060] (mmc_start_host+0x0/0x24) from [c020a2a0] (mmc_add_host+0x58/0x64) r5: r4:c784f400 [c020a248] (mmc_add_host+0x0/0x64) from [c001ec00] (omap_mmc_probe+0x3d0/0x548) r5:c784f5c0 r4: [c001e830] (omap_mmc_probe+0x0/0x548) from [c01dd554] (platform_drv_probe+0x20/0x24) [c01dd534] (platform_drv_probe+0x0/0x24) from [c01dc740] (driver_probe_device+0xd4/0x180) [c01dc66c] (driver_probe_device+0x0/0x180) from [c01dc854] (__driver_attach+0x68/0x8c) r7:c789d140 r6:c038ada4 r5:c7910490 r4:c7910408 [c01dc7ec] (__driver_attach+0x0/0x8c) from [c01dbf8c] (bus_for_each_dev+0x4c/0x80) r7:c789d140 r6:c038ada4 r5:c01dc7ec r4: [c01dbf40] (bus_for_each_dev+0x0/0x80) from [c01dc584] (driver_attach+0x20/0x28) r6:c038ada4 r5: r4: [c01dc564] (driver_attach+0x0/0x28) from [c01db868] (bus_add_driver+0xa8/0x210) [c01db7c0] (bus_add_driver+0x0/0x210) from [c01dca78] (driver_register+0x98/0x120) r8:0001 r7:c001e814 r6:c038ada4 r5: r4:c0024a44 [c01dc9e0]
Re: PM branch rebased to 2.6.29
Peter Barada pet...@logicpd.com writes: On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. Kevin I'm trying to bring up your PM branch on my OMAP3530_LV_SOM, using LDP as a starting point, and it goes into retention but doesn't come back out, and rather than thrash on the LDP defconfig, start with a config/code that is known to work. I'm also resnapping to commit c3127068... to jump to the latest from your tree and start my port over. I have to get suspend/resume working first before I start working in all the drivers, and check that suspend/resume works for each functional addition... Thanks in advance! [...] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28-omap1 # Tue Mar 24 09:07:57 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_CLASSIC_RCU=y CONFIG_FREEZER=y # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set #
Re: [PATCH] OMAP: mmc_twl4030 nicely disable vmmc_aux
On Tuesday 24 March 2009, Adrian Hunter wrote:
From 1a3f939d95122d8e58a3750cf5bce09247357203 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
The MMC driver turns the power off before it turns it
on. To avoid regulator warnings, vmmc_aux must only be
disabled if it has previously been enabled.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
good catch.
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 2ff50f0..cb56fe2 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -305,7 +305,7 @@ static int twl_mmc23_set_power(struct device *dev, int
slot, int power_on, int v
ret = mmc_regulator_set_ocr(c-vcc, 0);
}
} else {
- if (c-vcc_aux)
+ if (c-vcc_aux (ret = regulator_is_enabled(c-vcc_aux)) 0)
ret = regulator_disable(c-vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(c-vcc, 0);
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH 2/5] omap mmc: Add better MMC low-level init
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: ed39a47fbc83f2c0d82aaadca7dec9fe8f061f83 PatchWorks http://patchwork.kernel.org/patch/13766/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ed39a47fbc83f2c0d82aaadca7dec9fe8f061f83 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM branch rebased to 2.6.29
On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: Peter Barada pet...@logicpd.com writes: On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? -- Peter Barada pet...@logicpd.com NoLo Version : 2.4.6-OMAP3503 0001 NoLo Build : LPD386 Tue Nov 25 15:00:19 CST 2008 NoLo Compiler: gcc version 4.2.1 Image type : Elf Boot Device : NAND * LogicLoader (c) Copyright 2002-2008, Logic Product Development, Inc. All Rights Reserved. Version 2.4.6-OMAP3503 0001 * losh ifconfig sm0 /dev/config losh load elf /tftp/192.168.3.5:u-boot loading from /tftp/192.168.3.5:u-boot: . ELF section 0: download address: 0x80208000 load address: 0x80e8 loaded 140108 @ 0x80e8 Ram ...done file loaded losh exec U-Boot 1.1.4 (Mar 13 2009 - 16:32:42) OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz OMAP3430LV_SOM 0.1 Version + mDDR (Boot NAND) DRAM: 128 MB FLASH: initialize in sync mode NAND: 256 MiB Read production data: done Part Number : 1010194 Model Name : SOMOMAP3530-10-1672IFCR-A Serial Number: 3408M03305 In:serial Out: serial Err: serial Hit any key to stop autoboot: 6 0 = boot DRIVER_VERSION : 101, DATECODE : 092706 LAN9x18 (0x9211) detected. start Auto negotiation... (take ~2sec) Auto negotiation complete, 100BaseTX, full duplex TFTP from server 192.168.3.5; our IP address is 192.168.3.11 Filename 'uImage'. Load address: 0x8100 Loading: *# # # # # done Bytes transferred = 1806408 (1b9048 hex) ## Booting image at 8100 ... Image Name: Linux-2.6.29-rc8-omap1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1806344 Bytes = 1.7 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux done, booting the kernel. Linux version 2.6.29-rc8-omap1 (pe...@blackhole) (gcc version 4.1.2) #5 PREEMPT Tue Mar 24 15:49:34 EDT 2009 CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP OMAP3530LV_SOM board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c038f5dc, node_mem_map c03b9000 Normal zone: 256 pages used for memmap Normal zone: 0 pages reserved Normal zone:
Re: PM branch rebased to 2.6.29
Peter Barada wrote: On Tue, 2009-03-24 at 11:08 -0700, Kevin Hilman wrote: Peter Barada pet...@logicpd.com writes: On Tue, 2009-03-17 at 22:21 -0700, Kevin Hilman wrote: FYI... The PM branch has now been rebased to today's linux-omap HEAD which is based on v2.6.29-rc8. The previous PM branch has been renamed to pm-2.6.28. Depending on when you look, Tony's linux-omap tree may not (yet) have the latest PM branch. If not, you can use my PM tree[1] directly. Also, pm-2.6.28 will only be available on my tree. Tested on OMAP3 Beagle and RX51 and was able to hit RET and OFF in suspend and in PM idle with minimal kernel. No testing yet done for CPUidle or DVFS. Please test on your hardware and submit results to the list. Thanks. Kevin, did you build/test with the /arc/arm/config/omap3_beagle_defconfig, and arc/arm/configs/rx51_defconfig or some other config(could you send it to me if it isn't in the PM tree)? I started with the ones in the tree, but I disable most of the drivers and turn on some debugging features. Attached is the one I used for beagle. [...] Hmm, I modified your config to add smc911x support so I can have an nfsroot, added selector/code for my board(based on omap3beagle.c) and brought it up on my hardware, but I'm not sure if its working correctly. It does look to pause in the suspend sate, and comes out when I hit a key on the console, but the messages don't look quite right as core_pwrdm and per_pwrdm state they didn't go into state 1 (full log attached): omap3530# echo mem /sys/power/state PM: Syncing filesystems ... done. PM: Preparing system for mem sleep Freezing user space processes ... (elapsed 0.00 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. PM: Entering mem sleep Powerdomain (core_pwrdm) didn't enter target state 1 Powerdomain (per_pwrdm) didn't enter target state 1 Could not enter target state in pm_suspend eth0: smc911x_reset timeout waiting for PM restore eth0: link down PM: Finishing wakeup. Restarting tasks ... done. omap3530# omap3530# eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Is this expected? Yes, you haven't allowed the UART clocks to go off during idle/suspend and there are UARTs in both CORE and PER. Try this before going into suspend: echo 1 /sys/power/clocks_off_while_idle This will allow UART clocks to be disabled on suspend, and also allow them to be disabled after 5 seconds of UART inactivity allowing retention in idle as well. 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
Beagle can't mount rootfs from MMC after regulator updates
Hi, The BeagleBoard rev B4 here can't mount its root filesystem from MMC after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf, mmc-twl4030 uses regulator framework. This is with omap3_beagle_defconfig and rootwait in the kernel command line. Kernel hangs after: Waiting for root device /dev/mmcblk0p2... Will look at this in a few hours unless Dave beats me to it ;-) - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Beagle can't mount rootfs from MMC after regulator updates
Hi, On Tue, 24 Mar 2009, Paul Walmsley wrote: The BeagleBoard rev B4 here can't mount its root filesystem from MMC after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf, mmc-twl4030 uses regulator framework. This is with omap3_beagle_defconfig and rootwait in the kernel command line. Kernel hangs after: Waiting for root device /dev/mmcblk0p2... Turns out this is due to missing CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 in the defconfigs; patch coming shortly. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: MMC needs CONFIG_REGULATOR{,_TWL4030} now in defconfigs
MMC doesn't work after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf unless CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 are present in the .config. Add those in for all OMAP3 defconfigs. Tested on BeagleBoard, but this is presumably needed for anything with MMC and TWL4030. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: David Brownell davi...@pacbell.net --- arch/arm/configs/omap3_beagle_defconfig |3 ++- arch/arm/configs/omap3_evm_defconfig |3 ++- arch/arm/configs/omap3_pandora_defconfig |3 ++- arch/arm/configs/omap_3430sdp_defconfig |3 ++- arch/arm/configs/omap_ldp_defconfig |3 ++- arch/arm/configs/overo_defconfig |2 ++ 6 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/omap3_beagle_defconfig b/arch/arm/configs/omap3_beagle_defconfig index 194eafa..aeeac33 100644 --- a/arch/arm/configs/omap3_beagle_defconfig +++ b/arch/arm/configs/omap3_beagle_defconfig @@ -1040,10 +1040,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index f276c3a..018c9e1 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -1098,10 +1098,11 @@ CONFIG_RTC_LIB=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap3_pandora_defconfig b/arch/arm/configs/omap3_pandora_defconfig index 1c2b7a2..3c467fc 100644 --- a/arch/arm/configs/omap3_pandora_defconfig +++ b/arch/arm/configs/omap3_pandora_defconfig @@ -1156,10 +1156,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index f7b1bd6..b686f34 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1165,10 +1165,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/omap_ldp_defconfig b/arch/arm/configs/omap_ldp_defconfig index d88e6d7..a41b844 100644 --- a/arch/arm/configs/omap_ldp_defconfig +++ b/arch/arm/configs/omap_ldp_defconfig @@ -1104,10 +1104,11 @@ CONFIG_RTC_DRV_TWL4030=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # diff --git a/arch/arm/configs/overo_defconfig b/arch/arm/configs/overo_defconfig index 3bdbf94..dcca647 100644 --- a/arch/arm/configs/overo_defconfig +++ b/arch/arm/configs/overo_defconfig @@ -1601,9 +1601,11 @@ CONFIG_RTC_DRV_TWL4030=y # Voltage and Current regulators # # CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # -- To unsubscribe from this list: send the line unsubscribe 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: tidspbridge git repository
On Mon, Mar 23, 2009 at 9:47 PM, Tony Lindgren t...@atomide.com wrote: * ameya.pala...@nokia.com ameya.pala...@nokia.com [090323 00:42]: Hi Tony, I have collected latest patches for tidspbridge at: git://gitorious.org/tidspbridge/mainline.git Branch is: tidspbridge It is based on your pm branch. Can you pull it to your tidspbridge branch? What dependencies are there to the PM branch? To me it sounds like you should rebase your tidspbridge branch against the mainline kernel as the drivers should be arch independent. If something is missing from the mainline kernel to rebase and compile tidspbridge against the mainline, we need to fix those issues. Last time I tried it worked fine, with one minor issue: http://github.com/felipec/linux-omap/commit/1ae534c0ab22e57dd986c50adddc83e2ec42f970 Btw, it seems the 2.6.28-omap1 tag didn't have the defconfig updated. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] OMAP: mmc_twl4030 nicely disable vmmc_aux
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 0268abf95f935c2fe45f778b2a223685e68c7823 PatchWorks http://patchwork.kernel.org/patch/13958/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0268abf95f935c2fe45f778b2a223685e68c7823 -- To unsubscribe from this list: send the line unsubscribe 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: MMC needs CONFIG_REGULATOR{,_TWL4030} now in defconfigs
On Tuesday 24 March 2009, Paul Walmsley wrote: MMC doesn't work after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf unless CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 are present in the .config. Add those in for all OMAP3 defconfigs. Tested on BeagleBoard, but this is presumably needed for anything with MMC and TWL4030. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: David Brownell davi...@pacbell.net Acked-by: David Brownell dbrown...@users.sourceforge.net I seem to have given up on updating defconfigs, but that doesn't mean it's not a good thing to do! Same thing with twl4030 GPIO support, on most of those platforms. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] RX51: connect VAUX3 to MMC2
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: ac709382c70b02f84ba51b987fddafe3464a751b PatchWorks http://patchwork.kernel.org/patch/13959/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ac709382c70b02f84ba51b987fddafe3464a751b -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] OMAP3: MMC needs CONFIG_REGULATOR{,_TWL4030} now in
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 7b2a455b3167755686e048c193911591c9966418 PatchWorks http://patchwork.kernel.org/patch/14147/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7b2a455b3167755686e048c193911591c9966418 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[APPLIED] [PATCH] SDRC: prevent null pointer dereference if sdrc_init_params
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: c4df5a4d436bc3aea65cc665025d5ce62c8dfe09 PatchWorks http://patchwork.kernel.org/patch/13863/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=c4df5a4d436bc3aea65cc665025d5ce62c8dfe09 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MUSB oopses when changing mode on Beagle
Hi, echo'ing 'host' to the musb_hdrc/mode sysfs file triggers an oops on BeagleBoard rev B4 with linux-omap HEAD. Passing along the trace with a little extra debug to see if anyone happens to know what the problem is. - Paul r...@beagleboard:/sys# echo host ./devices/platform/musb_hdrc/mode musb: musb=c78280d8 musb: musb-xceiv=c78281b4 musb: musb-xceiv.host=c78281c4 musb: musb-xceiv-set_host=c78281d0 Unable to handle kernel NULL pointer dereference at virtual address pgd = c7028000 [] *pgd=87bb7031, *pte=, *ppte= Internal error: Oops: 0 [#1] Modules linked in: CPU: 0Not tainted (2.6.29-omap1-05523-g4530004-dirty #375) PC is at 0x0 LR is at musb_platform_set_mode+0x80/0xbc pc : []lr : [c01ef244]psr: 6093 sp : c7b81ed0 ip : c7b81e00 fp : c7b81ee4 r10: c7b81f70 r9 : c79bebb8 r8 : c03705c8 r7 : 0005 r6 : a013 r5 : c78280d8 r4 : c78281b4 r3 : 6093 r2 : c035995c r1 : c7828000 r0 : c78281b4 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 87028019 DAC: 0015 Process echo (pid: 1286, stack limit = 0xc7b802e0) Stack: (0xc7b81ed0 to 0xc7b82000) 1ec0: c7bb6000 c78280d8 c7b81f04 c7b81ee8 1ee0: c01eef34 c01ef1d0 c793d278 0005 c79beba0 c035868c c7b81f14 c7b81f08 1f00: c01b3354 c01eeec0 c7b81f44 c7b81f18 c00dedf4 c01b333c c7b81f70 c7831340 1f20: 4001d000 c7b81f70 0005 4001d000 c7b8 c7b81f6c c7b81f48 1f40: c009b404 c00decf0 c7831340 0005 1f60: c7b81fa4 c7b81f70 c009b8c4 c009b354 c002ff88 1f80: 0005 4001d000 401c1600 0004 c0029f08 c7b81fa8 1fa0: c0029d60 c009b88c 0005 4001d000 0001 4001d000 0005 1fc0: 0005 4001d000 401c1600 0004 0005 001f 0006e02d 0006c67c 1fe0: bee46c28 4010a78c 4015799c 6010 0001 Backtrace: [c01ef1c4] (musb_platform_set_mode+0x0/0xbc) from [c01eef34] (musb_mode_store+0x80/0x9c) r5:c78280d8 r4:c7bb6000 [c01eeeb4] (musb_mode_store+0x0/0x9c) from [c01b3354] (dev_attr_store+0x24/0x28) r7:c035868c r6:c79beba0 r5:0005 r4:c793d278 [c01b3330] (dev_attr_store+0x0/0x28) from [c00dedf4] (sysfs_write_file+0x110/0x144) [c00dece4] (sysfs_write_file+0x0/0x144) from [c009b404] (vfs_write+0xbc/0x14c) [c009b348] (vfs_write+0x0/0x14c) from [c009b8c4] (sys_write+0x44/0x70) r7:0005 r6:c7831340 r5: r4: [c009b880] (sys_write+0x0/0x70) from [c0029d60] (ret_fast_syscall+0x0/0x2c) r8:c0029f08 r7:0004 r6:401c1600 r5:4001d000 r4:0005 Code: bad PC value. ---[ end trace 1dc402be61e486ba ]--- Segmentation fault -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
