Re: [PATCH] tidspbridge: remove revision history
Hi David, On Wed, Mar 18, 2009 at 8:45 AM, David Brownell davi...@pacbell.net wrote: On Tuesday 17 March 2009, Felipe Contreras wrote: Ack, I think we could collate those in revision history to Contributor's section? Here's the list: a0216266 ag AL ap cr cring db dr ge gp HK hn hp jeh kc map mg rg rr sb sg sh swa vp I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line unsubscribe 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] tidspbridge: remove revision history
I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. Nishanth probably can put some points here. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- To unsubscribe from this list: send the line unsubscribe 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] tidspbridge: remove revision history
Hi Trilok, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Trilok Soni Sent: Wednesday, March 18, 2009 11:54 AM To: David Brownell Cc: Felipe Contreras; Menon, Nishanth; Kanigeri, Hari; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando Subject: Re: [PATCH] tidspbridge: remove revision history Hi David, On Wed, Mar 18, 2009 at 8:45 AM, David Brownell davi...@pacbell.net wrote: On Tuesday 17 March 2009, Felipe Contreras wrote: Ack, I think we could collate those in revision history to Contributor's section? Here's the list: a0216266 ag AL ap cr cring db dr ge gp HK hn hp jeh kc map mg rg rr sb sg sh swa vp I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. I agree that short names are given to TI internal devlopers. The names need to be replaced with actual names while adding to the contributors section. regards 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] tidspbridge: remove revision history
-Original Message- From: Trilok Soni [mailto:soni.tri...@gmail.com] Sent: Wednesday, March 18, 2009 8:26 AM To: David Brownell Cc: Felipe Contreras; Menon, Nishanth; Kanigeri, Hari; linux- o...@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando Subject: Re: [PATCH] tidspbridge: remove revision history I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. Nishanth probably can put some points here. Cards on table: I have never been involved personally on DSPBridge :(.. It is just this: as a developer we all contribute to something so that our legacy remains in some form.. Agreed various other motivations exist ;).. But personally, it feels good to see a tiny contribution being part of something else and being acknowledged for it.. do we as a community say: a) Lets kick all those oldies out.. They were yesteryear material, we can afford to forget them now. OR do we say b) Lets find who those guys are and ask them how they want to acknowledged here.. I mean, we all hate dirty code.. and I personally agree to Felipe's point that much of the old time revision history is eating bytespace and eyespace :(.. At the same time, I guess we still retain the old courtesy b/w one code hack to another :D.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] tidspbridge: remove revision history
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Wednesday, March 18, 2009 12:06 PM To: Trilok Soni; David Brownell Cc: Felipe Contreras; Kanigeri, Hari; linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando Subject: RE: [PATCH] tidspbridge: remove revision history -Original Message- From: Trilok Soni [mailto:soni.tri...@gmail.com] Sent: Wednesday, March 18, 2009 8:26 AM To: David Brownell Cc: Felipe Contreras; Menon, Nishanth; Kanigeri, Hari; linux- o...@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando Subject: Re: [PATCH] tidspbridge: remove revision history I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. Nishanth probably can put some points here. Cards on table: I have never been involved personally on DSPBridge :(.. It is just this: as a developer we all contribute to something so that our legacy remains in some form.. Agreed various other motivations exist ;).. But personally, it feels good to see a tiny contribution being part of something else and being acknowledged for it.. do we as a community say: a) Lets kick all those oldies out.. They were yesteryear material, we can afford to forget them now. OR do we say b) Lets find who those guys are and ask them how they want to acknowledged here.. I mean, we all hate dirty code.. and I personally agree to Felipe's point that much of the old time revision history is eating bytespace and eyespace :(.. At the same time, I guess we still retain the old courtesy b/w one code hack to another :D.. May be just add one MAINTAINERS/CONTRIBUTORS file move all rev history here. Sorry.. not sure if this was already discussed. Regards, Khasim -- To unsubscribe from this list: send the line unsubscribe 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] tidspbridge: remove revision history
On Wed, Mar 18, 2009 at 8:36 AM, Menon, Nishanth n...@ti.com wrote: -Original Message- From: Trilok Soni [mailto:soni.tri...@gmail.com] Sent: Wednesday, March 18, 2009 8:26 AM To: David Brownell Cc: Felipe Contreras; Menon, Nishanth; Kanigeri, Hari; linux- o...@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando Subject: Re: [PATCH] tidspbridge: remove revision history I have no idea why I'm in that list. These short names looks like are given to TI internal developers not the open-source contributors to this code. So, ag can mean Amit Agrawal or Andy Grover or anything else... Better to remove these short names from the revision history, it doesn't have any meaning. Nishanth probably can put some points here. Cards on table: I have never been involved personally on DSPBridge :(.. It is just this: as a developer we all contribute to something so that our legacy remains in some form.. Agreed various other motivations exist ;).. But personally, it feels good to see a tiny contribution being part of something else and being acknowledged for it.. do we as a community say: a) Lets kick all those oldies out.. They were yesteryear material, we can afford to forget them now. OR do we say b) Lets find who those guys are and ask them how they want to acknowledged here.. I mean, we all hate dirty code.. and I personally agree to Felipe's point that much of the old time revision history is eating bytespace and eyespace :(.. At the same time, I guess we still retain the old courtesy b/w one code hack to another :D.. I thought b) was kind of agreed. In any case, after cleaning up the dsp-bridge I don't think many files will stay alive, many already have been removed (e.g. [1]), but let's see how it goes. [1] http://github.com/felipec/linux-omap/commit/8ab33fe0a83058d2f9be906c89842ff4486ce68b -- 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
Re: [PATCH A 09/15] tidspbridge: cleanup and remove HW_MBOX_IsFull
On Wed, Mar 18, 2009 at 03:23:05AM +0200, Felipe Contreras wrote: From: Felipe Contreras felipe.contre...@nokia.com HW_MBOX_IsFull has many convoluted macros and is used only once. Clean it up so it's easier to see what it's actually doing. I probably should have integrated this too: --- drivers/dsp/bridge/hw/MLBAccInt.h | 18 -- drivers/dsp/bridge/hw/MLBRegAcM.h | 20 2 files changed, 0 insertions(+), 38 deletions(-) diff --git a/drivers/dsp/bridge/hw/MLBAccInt.h b/drivers/dsp/bridge/hw/MLBAccInt.h index 7a03c6a..1cc5fdd 100644 --- a/drivers/dsp/bridge/hw/MLBAccInt.h +++ b/drivers/dsp/bridge/hw/MLBAccInt.h @@ -33,10 +33,6 @@ (MLB_BASE_EASIL1 + 50) #define EASIL1_MLBMAILBOX_MESSAGE___0_15WriteRegister32 \ (MLB_BASE_EASIL1 + 51) -#define EASIL1_MLBMAILBOX_FIFOSTATUS___0_15ReadRegister32 \ - (MLB_BASE_EASIL1 + 56) -#define EASIL1_MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32 \ - (MLB_BASE_EASIL1 + 57) #define EASIL1_MLBMAILBOX_MSGSTATUS___0_15NbOfMsgMBmRead32 \ (MLB_BASE_EASIL1 + 60) #define EASIL1_MLBMAILBOX_IRQSTATUS___0_3ReadRegister32 \ @@ -60,18 +56,6 @@ #define MLB_MAILBOX_MESSAGE___0_15_OFFSET (u32)(0x0) -/* Register set MAILBOX_FIFOSTATUS___REGSET_0_15 address offset, bank address - * increment and number of banks */ - -#define MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_OFFSET (u32)(0x0080) -#define MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_STEP (u32)(0x0004) - -/* Register offset address definitions relative to register set - * MAILBOX_FIFOSTATUS___REGSET_0_15 */ - -#define MLB_MAILBOX_FIFOSTATUS___0_15_OFFSET(u32)(0x0) - - /* Register set MAILBOX_MSGSTATUS___REGSET_0_15 address offset, bank address * increment and number of banks */ @@ -124,8 +108,6 @@ #define MLB_MAILBOX_SYSCONFIG_AutoIdle_OFFSET(u32)(0) #define MLB_MAILBOX_SYSSTATUS_ResetDone_MASK (u32)(0x1) #define MLB_MAILBOX_SYSSTATUS_ResetDone_OFFSET (u32)(0) -#define MLB_MAILBOX_FIFOSTATUS___0_15_FifoFullMBm_MASK (u32)(0x1) -#define MLB_MAILBOX_FIFOSTATUS___0_15_FifoFullMBm_OFFSET (u32)(0) #define MLB_MAILBOX_MSGSTATUS___0_15_NbOfMsgMBm_MASK(u32)(0x7f) #define MLB_MAILBOX_MSGSTATUS___0_15_NbOfMsgMBm_OFFSET(u32)(0) diff --git a/drivers/dsp/bridge/hw/MLBRegAcM.h b/drivers/dsp/bridge/hw/MLBRegAcM.h index 747a2e1..004e10b 100644 --- a/drivers/dsp/bridge/hw/MLBRegAcM.h +++ b/drivers/dsp/bridge/hw/MLBRegAcM.h @@ -126,26 +126,6 @@ } -#define MLBMAILBOX_FIFOSTATUS___0_15ReadRegister32(baseAddress, bank)\ -(_DEBUG_LEVEL_1_EASI(\ - EASIL1_MLBMAILBOX_FIFOSTATUS___0_15ReadRegister32),\ - RD_MEM_32_VOLATILE(((u32)(baseAddress))+\ - (MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_OFFSET +\ - MLB_MAILBOX_FIFOSTATUS___0_15_OFFSET+\ - ((bank)*MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_STEP - - -#define MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32(baseAddress, bank)\ -(_DEBUG_LEVEL_1_EASI(\ - EASIL1_MLBMAILBOX_FIFOSTATUS___0_15FifoFullMBmRead32),\ - (((RD_MEM_32_VOLATILE(((u32)(baseAddress))+\ - (MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_OFFSET +\ - MLB_MAILBOX_FIFOSTATUS___0_15_OFFSET+\ - ((bank)*MLB_MAILBOX_FIFOSTATUS___REGSET_0_15_STEP \ - MLB_MAILBOX_FIFOSTATUS___0_15_FifoFullMBm_MASK) \ - MLB_MAILBOX_FIFOSTATUS___0_15_FifoFullMBm_OFFSET)) - - #define MLBMAILBOX_MSGSTATUS___0_15NbOfMsgMBmRead32(baseAddress, bank)\ (_DEBUG_LEVEL_1_EASI(\ EASIL1_MLBMAILBOX_MSGSTATUS___0_15NbOfMsgMBmRead32),\ -- -- 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
Re: PM branch rebased to 2.6.29
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. Sorry for ignorance, but in your PM tree the latest stuff is in the pm branch, right? -- 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
[PATCH 00/05] OMAP3: SR: Fixes in Smartreflex driver
Hi, 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 and are validated on the latest pm branch (2.6.28). regards, Rajendra PS: I am having issues getting mails posted on the list, hence in case you comment on these patches, please copy my id as well.-- To unsubscribe from this list: send the line unsubscribe 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/05] 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-2.6/arch/arm/mach-omap2/pm34xx.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/pm34xx.c2009-03-18
13:56:15.853547167 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/pm34xx.c 2009-03-18 13:56:26.570221029
+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 */
@@ -429,9 +432,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/05] 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-2.6/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/smartreflex.c 2009-03-18
13:56:26.106235150 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/smartreflex.c2009-03-18
13:56:27.065205965 +0530
@@ -379,6 +379,51 @@ static void sr_configure(struct omap_sr
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;
@@ -541,6 +586,8 @@ int sr_stop_vddautocomap(int srid)
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,
@@ -609,6 +656,8 @@ void disable_smartreflex(int srid)
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
[PATCHv2] OMAP: McBSP: Always maintain McBSP fclk while active
From: Eero Nurkkala ext-eero.nurkk...@nokia.com McBSP fclk must be maintained for the duration of audio playback or recording. Otherwise the fclk may get autogated when the PER96M clk is no longer required by other modules. This results in audio activity being hang. Also, if the McBSP is run as a slave, it is possible that words are randomly missed from the playback. Fix all this phenomenom by enabling the McBSP fclk clockactivity bit for the entire active duration of the McBSP usage. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |1 + arch/arm/plat-omap/mcbsp.c |6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 26bde05..ec61b89 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -252,6 +252,7 @@ #define RDISABLE 0x0001 /** McBSP SYSCONFIG bit definitions / +#define CLOCKACTIVITY(value) ((value)8) #define SIDLEMODE(value) ((value)3) #define ENAWAKEUP 0x0004 #define SOFTRST0x0002 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index a94d03e..02b3f2d 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -248,8 +248,8 @@ int omap_mcbsp_request(unsigned int id) u16 w; w = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - w = ~(ENAWAKEUP | SIDLEMODE(0x03)); - w |= (ENAWAKEUP | SIDLEMODE(0x02)); + w = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + w |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, w); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL); @@ -308,7 +308,7 @@ void omap_mcbsp_free(unsigned int id) u16 w; w = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - w = ~(ENAWAKEUP | SIDLEMODE(0x03)); + w = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, w); w = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN); -- 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
[PATCHv2] OMAP: McBSP: Do not enable or disable clocks on failed path
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
McBSP clocks are being double enabled in the event the
McBSP is already active. Also, they are unnecessarily
disabled when there's no active McBSP in use. Fix this
phenomenom by enabling and disabling the clocks at the
proper location.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 02b3f2d..e2e8b76 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -226,9 +226,6 @@ int omap_mcbsp_request(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-request)
mcbsp-pdata-ops-request(id);
- for (i = 0; i mcbsp-num_clks; i++)
- clk_enable(mcbsp-clks[i]);
-
spin_lock(mcbsp-lock);
if (!mcbsp-free) {
dev_err(mcbsp-dev, McBSP%d is currently in use\n,
@@ -240,6 +237,9 @@ int omap_mcbsp_request(unsigned int id)
mcbsp-free = 0;
spin_unlock(mcbsp-lock);
+ for (i = 0; i mcbsp-num_clks; i++)
+ clk_enable(mcbsp-clks[i]);
+
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
@@ -319,9 +319,6 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(id);
- for (i = mcbsp-num_clks - 1; i = 0; i--)
- clk_disable(mcbsp-clks[i]);
-
spin_lock(mcbsp-lock);
if (mcbsp-free) {
dev_err(mcbsp-dev, McBSP%d was not reserved\n,
@@ -329,7 +326,12 @@ void omap_mcbsp_free(unsigned int id)
spin_unlock(mcbsp-lock);
return;
}
+ spin_unlock(mcbsp-lock);
+ for (i = mcbsp-num_clks - 1; i = 0; i--)
+ clk_disable(mcbsp-clks[i]);
+
+ spin_lock(mcbsp-lock);
mcbsp-free = 1;
spin_unlock(mcbsp-lock);
--
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
RE: [PATCH A 00/15] tidspbridge: general cleanups
Felipe, Thanks for your contributions. We will push these changes to OZ tree as soon as possible. Thank you, Best -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Tuesday, March 17, 2009 8:23 PM To: linux-omap@vger.kernel.org Cc: Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando; Felipe Contreras Subject: [PATCH A 00/15] tidspbridge: general cleanups This patch series is not doing much, just cleaning up the irq mailbox functions and related stuff. Among the sem-functional changes are: * 0010: avoid udelay and use time_after * 0015: print an error when timing out Felipe Contreras (15): tidspbridge: remove revision history tidspbridge: trivial cleanup tidspbridge: remove unused stuff tidspbridge: remove IO_CALLDPC tidspbridge: whitespace cleanups tidspbridge: trivial cleanups tidspbridge: hDevContext == pDevContext tidspbridge: remove UTIL_Wait wrapper tidspbridge: cleanup and remove HW_MBOX_IsFull tidspbridge: remove udelay and use time_after instead tidspbridge: Remove IO_InterruptDSP tidspbridge: remove IO_InterruptDSP2 tidspbridge: remove CHNLSM_InterruptDSP tidspbridge: remove wIntrVal2Dsp tidspbridge: print an error when timing out arch/arm/plat-omap/include/dspbridge/chnl_sm.h | 42 arch/arm/plat-omap/include/dspbridge/io_sm.h |3 - arch/arm/plat-omap/include/dspbridge/util.h| 51 - drivers/dsp/bridge/hw/hw_mbox.c| 25 --- drivers/dsp/bridge/hw/hw_mbox.h| 35 drivers/dsp/bridge/wmd/_tiomap.h | 23 -- drivers/dsp/bridge/wmd/_tiomap_pwr.h |4 - drivers/dsp/bridge/wmd/_tiomap_util.h |1 - drivers/dsp/bridge/wmd/io_sm.c | 78 +--- drivers/dsp/bridge/wmd/tiomap3430.c| 18 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c| 22 +- drivers/dsp/bridge/wmd/tiomap_sm.c | 260 +++ - 12 files changed, 101 insertions(+), 461 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
dma_alloc_coherent fragmentation
Forwarding on behalf of Nishanth Menon:
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, March 17, 2009 8:17 AM
To: 'linux-arm-ker...@lists.arm.linux.org.uk'
Cc: Gupta, Ramesh; Kevin Hilman; linux-omap@vger.kernel.org; Ramirez Luna,
Omar; Kanigeri, Hari; Ameya Palande; Guzman Lugo, Fernando; Ameya Palande
Subject: dma_alloc_coherent fragmentation
Looping in linux-arm ML:
Discussion Ref: [1](linux-omap mailing list)
While working with Linux OMAP kernel[2] we found that on allocating 4 meg
chunks using dma_alloc_coherent and de-allocating with dma_free_coherent in a
loop using a test driver[7], the memory is getting fragmented as shown by
Ameya's observation [3] finally resulting in dump_stack due to lack of pages.
Searching through previous archives, found [4] which seem to imply that
allocating chunks greater than 1 page could cause fragmentation.
I wonder why we see this even if we allocate and free the memory in sequence as
in [5]. This seems to happen on 2.6.28 and 2.6.29 but not on the 2.6.27 based
kernel[6].
Regards,
Nishanth Menon
Ref:
[1] http://marc.info/?t=12371977912r=1w=2
[2] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git
[3] http://marc.info/?l=linux-omapm=123722460022336w=2
[4] http://lkml.indiana.edu/hypermail/linux/kernel/0706.0/0370.html
[5] http://marc.info/?l=linux-omapm=123719772811746w=2
[6] http://git.omapzoom.com/?p=repo/omapkernel.git;
[7] http://marc.info/?l=linux-omapm=123719772811746q=p3
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH B 1/3] tidspbridge: don't flood the mailbox on MemUnMap
Felipe,
Check the hardware state of the DSP before sending the command to wake
it up thus avoiding to flood the mailbox unnecessarily.
-- So this check was missing in Unmap part. Good catch.
- u32 temp = 0;
- struct CFG_HOSTRES resources;
u32 *pPhysAddrPageTbl = NULL;
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
+ u32 temp = 0;
-- Is temp variable needed ?
Thank you,
Best regards,
Hari
-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Tuesday, March 17, 2009 8:27 PM
To: linux-omap@vger.kernel.org
Cc: Kanigeri, Hari; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando;
Felipe Contreras
Subject: [PATCH B 1/3] tidspbridge: don't flood the mailbox on MemUnMap
From: Felipe Contreras felipe.contre...@nokia.com
Impact: improves performance and reliability
Check the hardware state of the DSP before sending the command to wake
it up thus avoiding to flood the mailbox unnecessarily.
By doing that the mailbox is free most of the time which dramatically
decreases CPU usage since the check for empty slots is done in a busy
loop.
Also, a free mailbox means less timeouts, so now most messages are
posted which improves reliability.
MemMap is doing the flush properly, so this patch also refactors the
code into a common flush_all function.
The problem can be triggered by doing many memmap/unmaps, just like TI's
OpenMAX IL implementation.
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
drivers/dsp/bridge/wmd/tiomap3430.c | 42 +++---
1 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index c0f4ffc..b538ef7 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -235,6 +235,25 @@ static struct WMD_DRV_INTERFACE drvInterfaceFxns = {
WMD_MSG_SetQueueId,
};
+static inline void flush_all(struct WMD_DEV_CONTEXT *pDevContext)
+{
+ struct CFG_HOSTRES resources;
+ u32 temp = 0;
+
+ CFG_GetHostResources((struct CFG_DEVNODE
*)DRV_GetFirstDevExtension(), resources);
+ HW_PWRST_IVA2RegGet(resources.dwPrmBase, temp);
+
+ if ((temp HW_PWR_STATE_ON) == HW_PWR_STATE_OFF) {
+ /* IVA domain is not in ON state*/
+ DBG_Trace(DBG_LEVEL7, temp value is 0x%x\n, temp);
+ CLK_Enable(SERVICESCLK_iva2_ck);
+ WakeDSP(pDevContext, NULL);
+ HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+ CLK_Disable(SERVICESCLK_iva2_ck);
+ } else
+ HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+}
+
/*
* WMD_DRV_Entry
* purpose:
@@ -1283,17 +1302,14 @@ static DSP_STATUS WMD_BRD_MemMap(struct
WMD_DEV_CONTEXT *hDevContext,
struct WMD_DEV_CONTEXT *pDevContext = hDevContext;
struct HW_MMUMapAttrs_t hwAttrs;
u32 numOfActualTabEntries = 0;
- u32 temp = 0;
- struct CFG_HOSTRES resources;
u32 *pPhysAddrPageTbl = NULL;
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
+ u32 temp = 0;
DBG_Trace(DBG_ENTER, WMD_BRD_MemMap hDevContext %x, pa %x, va %x,
size %x, ulMapAttr %x\n, hDevContext, ulMpuAddr,
ulVirtAddr,
ulNumBytes, ulMapAttr);
- status = CFG_GetHostResources(
- (struct CFG_DEVNODE *)DRV_GetFirstDevExtension(),
resources);
if (ulNumBytes == 0)
return DSP_EINVALIDARG;
@@ -1421,16 +1437,7 @@ func_cont:
* This is called from here instead from PteUpdate to avoid
unnecessary
* repetition while mapping non-contiguous physical regions of a
virtual
* region */
- HW_PWRST_IVA2RegGet(resources.dwPrmBase, temp);
- if ((temp HW_PWR_STATE_ON) == HW_PWR_STATE_OFF) {
- /* IVA domain is not in ON state*/
- DBG_Trace(DBG_LEVEL7, temp value is 0x%x\n, temp);
- CLK_Enable(SERVICESCLK_iva2_ck);
- WakeDSP(pDevContext, NULL);
- HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
- CLK_Disable(SERVICESCLK_iva2_ck);
- } else
- HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+ flush_all(pDevContext);
DBG_Trace(DBG_ENTER, WMD_BRD_MemMap status %x\n, status);
return status;
}
@@ -1571,8 +1578,7 @@ static DSP_STATUS WMD_BRD_MemUnMap(struct
WMD_DEV_CONTEXT *hDevContext,
/* It is better to flush the TLB here, so that any stale old
entries
* get flushed */
EXIT_LOOP:
- CHNLSM_InterruptDSP2(pDevContext, MBX_PM_DSPWAKEUP);
- HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+ flush_all(pDevContext);
DBG_Trace(DBG_LEVEL1, WMD_BRD_MemUnMap vaCurr %x, pteAddrL1 %x
pteAddrL2 %x\n, vaCurr, pteAddrL1, pteAddrL2);
DBG_Trace(DBG_ENTER, WMD_BRD_MemUnMap status %x
Re: [PATCH B 1/3] tidspbridge: don't flood the mailbox on MemUnMap
On Wed, Mar 18, 2009 at 3:06 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Felipe, Check the hardware state of the DSP before sending the command to wake it up thus avoiding to flood the mailbox unnecessarily. -- So this check was missing in Unmap part. Good catch. - u32 temp = 0; - struct CFG_HOSTRES resources; u32 *pPhysAddrPageTbl = NULL; struct vm_area_struct *vma; struct mm_struct *mm = current-mm; + u32 temp = 0; -- Is temp variable needed ? You tell me :) I just moved code around. I don't truly understand what it's doing. Maybe the read is needed for some kind of sync? I've removed the tlb flush all completely and I didn't notice any problems, is it really needed? -- 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
Re: [PATCH A 00/15] tidspbridge: general cleanups
On Wed, Mar 18, 2009 at 2:55 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Felipe, Thanks for your contributions. We will push these changes to OZ tree as soon as possible. Cool :) Would that be an ack for l-o? -- 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
RE: [PATCH B 1/3] tidspbridge: don't flood the mailbox on MemUnMap
You tell me :) I just moved code around. I don't truly understand what it's doing. Maybe the read is needed for some kind of sync? I've removed the tlb flush all completely and I didn't notice any problems, is it really needed? -- Ignore my previous comment. I think temp is used for other purpose in the same function. I thought temp was used by only the part of the code section that you stripped out. Thank you, Best regards, Hari -Original Message- From: Felipe Contreras [mailto:felipe.contre...@gmail.com] Sent: Wednesday, March 18, 2009 8:30 AM To: Kanigeri, Hari Cc: linux-omap@vger.kernel.org; Hiroshi DOYU; Ameya Palande; Guzman Lugo, Fernando; Felipe Contreras Subject: Re: [PATCH B 1/3] tidspbridge: don't flood the mailbox on MemUnMap On Wed, Mar 18, 2009 at 3:06 PM, Kanigeri, Hari h-kanige...@ti.com wrote: Felipe, Check the hardware state of the DSP before sending the command to wake it up thus avoiding to flood the mailbox unnecessarily. -- So this check was missing in Unmap part. Good catch. - u32 temp = 0; - struct CFG_HOSTRES resources; u32 *pPhysAddrPageTbl = NULL; struct vm_area_struct *vma; struct mm_struct *mm = current-mm; + u32 temp = 0; -- Is temp variable needed ? You tell me :) I just moved code around. I don't truly understand what it's doing. Maybe the read is needed for some kind of sync? I've removed the tlb flush all completely and I didn't notice any problems, is it really needed? -- 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
[PATCH 1/1] Back-light class driver support for OMAP
From: Vaibhav Hiremath hvaib...@ti.com
Till now OMAPFB driver was handling back-light interface
through it's own custom SYSFS entries. Earliear there
was a discussion where we decided to add support for OMAP
back-light into Generic class driver. Also Sanjeev has submitted
patch supporting back-light class driver.
This patch addresses review comments from 'Richard Purdie', and
adds support for OMAP3EVM.
NOTE:
I am not sure whether back-light class driver interface
still holds this implementation, since not a single platform
I could found in kernel tree which follows this implementation.
Since this implementation has been suggested by 'Richard Purdie',
and I was readily having this patch so I am submitting it for review.
The next version of patch will be devided into 3 seperate patches
- twl4030 related changes
- OMAPFB related changes
- board-omap3evm.c related changes.
TODO:
- Need to add simillar support for other platforms and development
boards.
- Merge it to DSS2 and OMAP2FB
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 37
arch/arm/plat-omap/include/mach/omapfb.h |4 --
drivers/video/omap/lcd_omap3evm.c| 27 ---
drivers/video/omap/omapfb_main.c | 54 --
include/linux/i2c/twl4030.h | 14
5 files changed, 51 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 024d7c4..c749604 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -20,6 +20,7 @@
#include linux/clk.h
#include linux/input.h
#include linux/leds.h
+#include linux/backlight.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
@@ -225,6 +226,41 @@ static struct omap_lcd_config omap3_evm_lcd_config
__initdata = {
.ctrl_name = internal,
};
+#define TWL_PWMA_PWMAOFF 0x01
+
+static void omap3_set_bl_intensity(int intensity)
+{
+ unsigned char c;
+
+ if (intensity 100)
+ return;
+
+ c = ((125 * (100 - intensity)) / 100) + 2;
+
+#if defined(CONFIG_TWL4030_CORE)
+ twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL4030_LED_EN);
+ twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF);
+#endif
+
+}
+static struct generic_bl_info omap3_bl_platform_data = {
+ .name = omap3-bklight,
+ .max_intensity = 100,
+ .default_intensity = 70,
+ .limit_mask = 0,
+ .set_bl_intensity = omap3_set_bl_intensity,
+ .kick_battery = NULL,
+};
+
+static struct platform_device omap3_bklight_device = {
+ .name = generic-bl,
+ .id = -1,
+ .dev= {
+ .parent = omap3_evm_lcd_device.dev,
+ .platform_data = omap3_bl_platform_data,
+ },
+};
+
static void ads7846_dev_init(void)
{
if (gpio_request(OMAP3_EVM_TS_GPIO, ADS7846 pendown) 0)
@@ -286,6 +322,7 @@ static struct omap_board_config_kernel omap3_evm_config[]
__initdata = {
static struct platform_device *omap3_evm_devices[] __initdata = {
omap3_evm_lcd_device,
+ omap3_bklight_device,
omap3evm_smc911x_device,
};
diff --git a/arch/arm/plat-omap/include/mach/omapfb.h
b/arch/arm/plat-omap/include/mach/omapfb.h
index b226bdf..b87466b 100644
--- a/arch/arm/plat-omap/include/mach/omapfb.h
+++ b/arch/arm/plat-omap/include/mach/omapfb.h
@@ -218,10 +218,6 @@ struct lcd_panel {
int (*enable) (struct lcd_panel *panel);
void(*disable) (struct lcd_panel *panel);
unsigned long (*get_caps) (struct lcd_panel *panel);
- int (*set_bklight_level)(struct lcd_panel *panel,
-unsigned int level);
- unsigned int(*get_bklight_level)(struct lcd_panel *panel);
- unsigned int(*get_bklight_max) (struct lcd_panel *panel);
int (*run_test) (struct lcd_panel *panel, int test_num);
};
diff --git a/drivers/video/omap/lcd_omap3evm.c
b/drivers/video/omap/lcd_omap3evm.c
index 1c3d814..23238ae 100644
--- a/drivers/video/omap/lcd_omap3evm.c
+++ b/drivers/video/omap/lcd_omap3evm.c
@@ -49,7 +49,6 @@
#define TWL_PWMA_PWMAON0x00
#define TWL_PWMA_PWMAOFF 0x01
-static unsigned int bklight_level;
static int omap3evm_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
@@ -69,7 +68,6 @@ static int omap3evm_panel_init(struct lcd_panel *panel,
twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL_LED_LEDEN);
RE: [PATCH A 00/15] tidspbridge: general cleanups
Felipe, Would that be an ack for l-o? - Yes. Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe 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
Artem Bityutskiy dedek...@yandex.ru writes: 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. Sorry for ignorance, but in your PM tree the latest stuff is in the pm branch, right? Yes. The master branch of my tree just tracks linux-omap. 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 03/05] OMAP3: SR: Use sysclk for SR CLKLENGTH calc
Nayak, Rajendra rna...@ti.com writes:
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-2.6/arch/arm/mach-omap2/smartreflex.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/smartreflex.c 2009-03-18
13:56:25.610250244 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/smartreflex.c 2009-03-18
13:56:26.106235150 +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 = 0;
Don't need to init this to zero as it is always assigned below.
- 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
--
To unsubscribe from this list: send the line unsubscribe 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/05] OMAP3: SR: Fixes in Smartreflex driver
Nayak, Rajendra rna...@ti.com writes: Hi, 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 and are validated on the latest pm branch (2.6.28). Hi Rajendra, Thanks for this series of SR fixes. I send a couple very minor comments to a couple of the patches. Also, this series does not apply cleanly to pm-2.6.28, I'm not sure why. Applying manually with 'patch' allows them to apply with fuzz suggesting that they were not generated against the current tree. Also, while you are in there cleaing up, could you add one more patch which converts the printk(KERN_* ...) into pr_debug, pr_err, pr_info, etc. Thanks, 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 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you say.
I didn't want to start making such intrusive changes for our trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
to the standard parameters. This string is passed into machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not, could
we still have the sysfs mechanism? A one-character reboot_mode would be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
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: new PM branch available
Nicholas Chen nc...@cs.umd.edu writes: I recently checked out the latest PM branch from your git repository and put it on the Beagleboard (B5). I have been largely able to reproduce the results others have reported on this PM thread, ...not sure what this PM thread you are referring to? but I believe my CORE and PER powerdomains are not hitting RET or OFF. I think this based on the following: after I echo 1 enable_off_mode echo 1 sleep_while_idle echo mem state CORE and PER are still on because UART clocks are not being cut in idle: # echo 1 /sys/power/clocks_off_when_idle And see if that works. Also at least on my Beagle, I am not able to resume from full-chip OFF, so for starters I suggest just testing retention: echo 0 /sys/power/enable_off_mode Suspending starts but upon resume I see the following: ... Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend looking at debug/pm_debug/count/ I see that only the core_pwrdm and per_pwrdm have 0's next to OFF: and RET: Based on the thread, the resolution seems to be to disable USB and upgrade u-boot. I think I have done both. My u-boot is 2009.03-rc2 from Steve Sakoman's tree, and I have disabled USB support in my Kernel build. Is there something that I am overlooking? Also, I'm curious if the two powerdomains linked (i.e. I need to fix PER before CORE will shut off or vice versa). For your problem, they're linked in that they both contain a UART block. UART1,2 are in CORE and UART3 is in PER. 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
MMC: driver fails to recognize insert-remove SD card after data transfer error 84
Hi, I have been trying to fix a problem in the MMC driver on OMAP2430. After rapid insert and remove SD card operation, I see the following error message (caused due to data timeout). After this happens the driver no longer detects insertions/removals.. [ 1013.32] mmcblk2: error -84 transferring data, sector 7961, nr 8, card status 0x900 followed by bunch of I/O errors [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7961 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7962 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7963 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7964 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7965 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7966 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7967 [ 1013.33] end_request: I/O error, dev mmcblk2, sector 7968 I have tried a number of patches that floating around but do no good to fix this problem. Would appreciate if someone could share their views regarding this problem. Thanks Ishaq -- To unsubscribe from this list: send the line unsubscribe 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: dma_alloc_coherent fragmentation
On Wed, Mar 18, 2009 at 08:03:45AM -0500, Kamat, Nishant wrote: Forwarding on behalf of Nishanth Menon: Make sure you're up to date with fixes to the ioremap code, specifically 24f11ec001920f1cfaeeed8e8b55725d900bbb56. This is not in 2.6.28, 2.6.29-rc1, 2.6.29-rc2, but is in -rc3 and later. 2.6.29 itself hasn't been released yet so I don't know what seems to happen on 2.6.28 and 2.6.29 actually means because its nonsense. So, please test with 2.6.29-rc3 or later. -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Tuesday 17 March 2009, Mark Brown wrote: On Tue, Mar 17, 2009 at 11:15:06AM -0700, David Brownell wrote: On Monday 16 March 2009, Mark Brown wrote: Devices that need to do things like set voltages are fairly likely to own the regulator but with devices that just need to ensure that they have their supplies enabled it's much more likely that the supplies will be shared. Right. Do you have a model how such shared supplies would coexist with the enabled at boot time model, and still support being disabled? The drivers can essentially ignore the physical status of the regulator when they start, That is, shared supplies should adopt a different model? That approach can't be used with drivers, as for MMC slots, which need to ensure they start with a power off state as part of a clean reset/init sequence. Maybe sharable should be a regulator constraint flag, so the regulator framework can avoid committing nastiness like allocating multiple consumer handles for them. It will also work well with a late_initcall which disables any unreferenced regulators - The $SUBJECT patch will prevent such things from existing. Also, regulator use that kicks in before that particular late_initcall will still see self-inconsistent state in the regulator framework ... of course, $SUBJECT patch (and its predecessors) is all about preventing self-inconsistency. That self-inconsistency doesn't seem to concern you much. -- To unsubscribe from this list: send the line unsubscribe 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 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you say.
I didn't want to start making such intrusive changes for our trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
to the standard parameters. This string is passed into machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not, could
we still have the sysfs mechanism? A one-character reboot_mode would be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Why not use the mechanism that's already there as I've already pointed
out?
Yes, glibc might be fscked in the head over the reboot() prototype but
that's easy to work-around as I've demonstrated.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] ARM: OMAP: Add command line option for I2C bus speed
On Fri, Mar 06, 2009 at 08:13:50AM -0800, Tony Lindgren wrote: * Jarkko Nikula jarkko.nik...@nokia.com [090305 23:12]: On Thu, 5 Mar 2009 17:20:43 +0100 ext Tony Lindgren t...@atomide.com wrote: Jarkko, this should also be in Documentation/kernel-parameters.txt. Can you please reply with a patch for that, and I'll fold it into this patch? Ah, good, will do it over weekend - early next week. Probably better to handle as a separate patch for easier merging with kernel-parameters.txt? I think they should get merged as a single patch. Also, maybe it should be called omap_i2c_bus instead of i2c_bus? I had similar thought as Felipe that it looks more generic this way. But don't know now immediately would multibuild will work? Was that your concern? E.g. __setup(i2c_bus=, arm_xxx_i2c_bus_setup); __setup(i2c_bus=, omap_i2c_bus_setup); Well is it generic enough to work for everybody? And if so, we should run it by the LKML and the linux-i2c lists. Any comments from the I2C list? -- To unsubscribe from this list: send the line unsubscribe 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: new PM branch available
Dear Kevin, I recently checked out the latest PM branch from your git repository and put it on the Beagleboard (B5). I have been largely able to reproduce the results others have reported on this PM thread, but I believe my CORE and PER powerdomains are not hitting RET or OFF. I think this based on the following: after I echo 1 enable_off_mode echo 1 sleep_while_idle echo mem state Suspending starts but upon resume I see the following: ... Powerdomain (core_pwrdm) didn't enter target state 0 Powerdomain (per_pwrdm) didn't enter target state 0 Could not enter target state in pm_suspend looking at debug/pm_debug/count/ I see that only the core_pwrdm and per_pwrdm have 0's next to OFF: and RET: Based on the thread, the resolution seems to be to disable USB and upgrade u-boot. I think I have done both. My u-boot is 2009.03-rc2 from Steve Sakoman's tree, and I have disabled USB support in my Kernel build. Is there something that I am overlooking? Also, I'm curious if the two powerdomains linked (i.e. I need to fix PER before CORE will shut off or vice versa). Nick -- To unsubscribe from this list: send the line unsubscribe 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: TI OMAP3503 GPMC and SDMA multiplexing modes
Hi, Would anyone know how can I set up the multiplexing modes for the TI OMAP 3503 GPMC and SDMA controller so that I can use them together ? The GPMC has 4 multiplexing options/modes and the SDMA has 8 modes of operation. Which of these modes will enable me to use them together? Best regards, Elvis Dowson -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: dma_alloc_coherent fragmentation
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Wednesday, March 18, 2009 9:25 PM To: Kamat, Nishant Cc: linux-arm-ker...@lists.arm.linux.org.uk; Menon, Nishanth; linux- o...@vger.kernel.org; Ramirez Luna, Omar; Kanigeri, Hari; Guzman Lugo, Fernando; Kevin Hilman; 2am...@gmail.com Subject: Re: dma_alloc_coherent fragmentation Make sure you're up to date with fixes to the ioremap code, specifically 24f11ec001920f1cfaeeed8e8b55725d900bbb56. This is not in 2.6.28, 2.6.29-rc1, 2.6.29-rc2, but is in -rc3 and later. 2.6.29 itself hasn't been released yet so I don't know what seems to happen on 2.6.28 and 2.6.29 actually means because its nonsense. Apologies on the confusion. For this issue, the pertinent tree would be the master branch of [1] linux-omap tree which is synced to 2.6.29-rc8. And yes, the mentioned commit ID is part of the git log. Relevant test code and report of the crash is in [2]. Additional observation in [3] Regards, Nishanth Menon Ref: [1] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git [2] http://marc.info/?l=linux-omapm=123719772811746w=2 [3] http://marc.info/?l=linux-omapm=123722460022336w=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
Re: [PATCH 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
* Russell King - ARM Linux li...@arm.linux.org.uk [090318 12:26]:
On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you say.
I didn't want to start making such intrusive changes for our trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition
to the standard parameters. This string is passed into
machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain
with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not, could
we still have the sysfs mechanism? A one-character reboot_mode would be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Why not use the mechanism that's already there as I've already pointed
out?
Sorry I misunderstood, I thought you did not want to use reboot_mode
for this at all..
To recap, so we change machine_restart() like you described above, and then
this patch is still valid, except to update the description.
Juha, does that sound OK to you?
Yes, glibc might be fscked in the head over the reboot() prototype but
that's easy to work-around as I've demonstrated.
Yeah sounds good to me.
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 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
* Tony Lindgren t...@atomide.com [090318 13:09]:
* Russell King - ARM Linux li...@arm.linux.org.uk [090318 12:26]:
On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing
this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you
say.
I didn't want to start making such intrusive changes for our trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1,
LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in
addition
to the standard parameters. This string is passed into
machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain
with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not,
could
we still have the sysfs mechanism? A one-character reboot_mode would
be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Why not use the mechanism that's already there as I've already pointed
out?
Sorry I misunderstood, I thought you did not want to use reboot_mode
for this at all..
To recap, so we change machine_restart() like you described above, and then
this patch is still valid, except to update the description.
Hmm, after reading it one more time..
Russell you want to pass char *cmd in addition to reboot_mode, right?
And Juha's patch needs to be updated to use the cmd instead of reboot_mode?
Juha, does that sound OK to you?
Yes, glibc might be fscked in the head over the reboot() prototype but
that's easy to work-around as I've demonstrated.
Yeah sounds good to me.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Wed, Mar 18, 2009 at 12:25:11PM -0700, David Brownell wrote: On Tuesday 17 March 2009, Mark Brown wrote: The drivers can essentially ignore the physical status of the regulator when they start, That is, shared supplies should adopt a different model? I think that's a bit strong, once we get past init the problem pretty much goes away AFAICT. That approach can't be used with drivers, as for MMC slots, which need to ensure they start with a power off state as part of a clean reset/init sequence. Pretty much. They could cope if they used the enable/disable bounce hack but if they urgently need to have a specific power state they won't be able to cope with shared regulators anyway so it doesn't really make any odds. Maybe sharable should be a regulator constraint flag, so the regulator framework can avoid committing nastiness like allocating multiple consumer handles for them. Or vice versa - it's as much a property of the consumer driver that it requires exclusivity. From the point of view of the regulator API there's very little difference between the two cases. Note that for well behaved consumers that use mapped supply names we already know about them all in advance anyway... It will also work well with a late_initcall which disables any unreferenced regulators - The $SUBJECT patch will prevent such things from existing. I sent a patch backing that specific change out along with the late_initcall() patch. Also, regulator use that kicks in before that particular late_initcall will still see self-inconsistent state in the regulator framework ... of course, $SUBJECT patch (and its predecessors) is all about preventing self-inconsistency. A driver that can cope with sharing the regulator is not going to be able to observe anything here: it must always enable the regulator when it is using it even if it is already enabled (since otherwise some other consumer could cause it to be turned off) and it should expect that the regulator might be enabled by something else. It can't do an unbalanced disable since otherwise it could be reversing an enable something else did. It's also not possible for it to inspect the use count. If a consumer can't play with that model then I'm reasonably happy with it having to state any additional requirements it has in some way - if nothing else it gives us a bit of documentation about what's going on. That self-inconsistency doesn't seem to concern you much. I think it's more that I'm viewing the use count as being useful information which the API can take advantage of (do any consumers actually want this on right now?). I think we should be able to handle this without changing the use count and that this is preferable because otherwise we make more work with shared consumers, which should be the simplest case. The trick is getting the non-shared regulators into sync with the internal status, ideally without doing things like bouncing supplies during init. I think either using regulator_force_disable() or saying that the consmer wants exclusive access on get and then bumping the use count for it if the regulator is already enabled ought to cover it. I've not thought the latter option through fully, though. -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Wednesday 18 March 2009, Mark Brown wrote: The $SUBJECT patch will prevent such things from existing. I sent a patch backing that specific change out along with the late_initcall() patch. Huh? $SUBJECT patch hasn't merged. How could you have backed it out?? http://marc.info/?l=linux-kernelm=123707714131036w=2 I didn't see such patches. Could you post URLs so I know specifically what you're referring to? In the future, when you're proposing patches you think address bugs I've reported, please remember to CC me ... -- To unsubscribe from this list: send the line unsubscribe 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.6.29-rc8 regulator-next] regulator: init fixes (v4)
On Wednesday 18 March 2009, Mark Brown wrote: That self-inconsistency doesn't seem to concern you much. I think it's more that I'm viewing the use count as being useful information which the API can take advantage of (do any consumers actually want this on right now?). In that case, I don't understand why you didn't like the previous versions of this patch ... which just forced the regulator off (at init time) if that count was zero. I think we should be able to handle this without changing the use count and that this is preferable because otherwise we make more work with shared consumers, which should be the simplest case. That's what the earlier versions of this patch did, but you rejected that approach ... patches against both mainline (which is where the bug hurts TODAY), and against regulator-next. Also, I don't see why you'd think a shared consumer would be the simplest, given all the special rules that you've already noted as only needing to kick in for those cases. The trick is getting the non-shared regulators into sync with the internal status, I don't see why that should need any tricks. At init time you have that state and the regulator; and you know there are no consumers. Put it into a self-consistent state at that time ... done. There are really only two ways to make that state self-consistent. And you have rejected both. ideally without doing things like bouncing supplies during init. I think either using regulator_force_disable() or saying The force_disable() thing looks to me like an API design botch. As you said at one point, it has no users. And since the entire point is to bypass the entire usecount scheme ... it'd be much better to remove it. that the consmer wants exclusive access on get and then bumping the use count for it if the regulator is already enabled ought to cover it. I've not thought the latter option through fully, though. The problem I have with your approach here is that you have rejected quite a few alternative bugfixes applying to a common (and simple!!) configuration, but you haven't provided an alternative that can work for MMC init. I'm really at a loss to see a way out here. -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP2: possible division by 0
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: a170fc43065439cff6d18f02a1571a92718b9623 PatchWorks http://patchwork.kernel.org/patch/12591/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a170fc43065439cff6d18f02a1571a92718b9623 -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP2: possible division by 0
* Roel Kluin roel.kl...@gmail.com [090317 04:50]: In linus' git tree the functions can be found at: vi arch/arm/mach-omap2/usb-tusb6010.c +200- tusb6010_platform_retime() vi arch/arm/mach-omap2/gpmc.c +94 - gpmc_get_fclk_period() vi arch/arm/mach-omap2/usb-tusb6010.c +53 - tusb_set_async_mode() vi arch/arm/mach-omap2/usb-tusb6010.c +111- tusb_set_sync_mode() is -ENODEV appropriate when sysclk_ps == 0? This was found by code analysis, please review. --8-8- gpmc_get_fclk_period() may return 0 when gpmc_l3_clk is not enabled. This is not checked in tusb6010_platform_retime() nor in tusb_set_async_mode() it seems. In tusb_set_sync_mode() this may result in a division by zero. Signed-off-by: Roel Kluin roel.kl...@gmail.com Looks like a valid fix to me. I'll add it to omap-fixes queue. To me it sounds like there's no urgent need to get this integrated as we're missing most of the omap2 PM still. Tony --- diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c index 15e5090..8df55f4 100644 --- a/arch/arm/mach-omap2/usb-tusb6010.c +++ b/arch/arm/mach-omap2/usb-tusb6010.c @@ -187,7 +187,7 @@ int tusb6010_platform_retime(unsigned is_refclk) unsignedsysclk_ps; int status; - if (!refclk_psec) + if (!refclk_psec || sysclk_ps == 0) return -ENODEV; sysclk_ps = is_refclk ? refclk_psec : TUSB6010_OSCCLK_60; -- To unsubscribe from this list: send the line unsubscribe 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
[APPLIED] [PATCH omap-fixes v2] OMAP2/3: GPIO: do not attempt to wake-enable
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Commit: 2ac496a208895c925aec1774a873b5b096b2d3f0 PatchWorks http://patchwork.kernel.org/patch/10719/ Git http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=2ac496a208895c925aec1774a873b5b096b2d3f0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
test
-- To unsubscribe from this list: send the line unsubscribe 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 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
On Wed, Mar 18, 2009 at 01:10:04PM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090318 12:26]:
On Wed, Mar 18, 2009 at 11:28:06AM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [090316 15:22]:
On Mon, Mar 16, 2009 at 07:40:24PM +0200, Juha Yrjola wrote:
Russell King - ARM Linux wrote:
Right. You are aware that there is already a mechanism for doing
this
in the generic kernel (obviously not)?
I am. Unfortunately, glibc fails to support this mechanism, as you
say.
I didn't want to start making such intrusive changes for our trivial
need.
Yes, glibc sucks with that - they hide the Linux reboot syscall.
Luckily, it is accessible via the syscall() interface:
#include linux/reboot.h
int sys_reboot(const char *cmd)
{
return syscall(SYS_reboot, LINUX_REBOOT_MAGIC1,
LINUX_REBOOT_MAGIC2C,
LINUX_REBOOT_CMD_RESTART2, cmd);
}
sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in
addition
to the standard parameters. This string is passed into
machine_restart()
which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this
string is NULL.
We could change machine_restart() to pass this parameter through to
arm_pm_restart() and ultimately down to arch_reset().
Sure. With RESTART2, I could've even used the reboot notifier chain
with
an OMAP3-specific driver to store the string.
The notifier chain is called in any case.
Are you suggesting to get rid of reboot_mode altogether? If not,
could
we still have the sysfs mechanism? A one-character reboot_mode would
be
plenty enough for us.
No, reboot mode tells _how_ to perform the reboot - whether that be
by hardware reset, gpio reset or a soft call via the reset address.
It's not supposed to tell the boot loader what to do.
So if the reboot mode can't be used for this.. Should we change Juha's
sysfs interface patch to store something else like bootloader_mode?
I guess we cannot use kexec for this either?
Why not use the mechanism that's already there as I've already pointed
out?
Sorry I misunderstood, I thought you did not want to use reboot_mode
for this at all..
I don't want to use reboot_mode for this. machine_restart() and the
reboot syscall has a way of passing a string to the platform specific
code, and I'm suggesting that if you want the boot loader to do some
magic, that's the way to do it. Use the 'cmd' argument provided to
arch_reset() by the patch below - this will either be NULL if the
standard reboot call is used, or a string if the alternative version
is used.
To recap, so we change machine_restart() like you described above, and then
this patch is still valid, except to update the description.
No, you've still got the wrong end of the stick.
arch/arm/include/asm/system.h |4 ++--
arch/arm/kernel/process.c | 10 +-
arch/arm/mach-aaec2000/include/mach/system.h |2 +-
arch/arm/mach-at91/include/mach/system.h |2 +-
arch/arm/mach-clps711x/include/mach/system.h |2 +-
arch/arm/mach-davinci/include/mach/system.h |2 +-
arch/arm/mach-ebsa110/include/mach/system.h |2 +-
arch/arm/mach-ep93xx/include/mach/system.h|2 +-
arch/arm/mach-footbridge/include/mach/system.h|2 +-
arch/arm/mach-h720x/include/mach/system.h |2 +-
arch/arm/mach-imx/include/mach/system.h |2 +-
arch/arm/mach-integrator/include/mach/system.h|2 +-
arch/arm/mach-iop13xx/include/mach/system.h |2 +-
arch/arm/mach-iop32x/include/mach/system.h|2 +-
arch/arm/mach-iop33x/include/mach/system.h|2 +-
arch/arm/mach-ixp2000/include/mach/system.h |2 +-
arch/arm/mach-ixp23xx/include/mach/system.h |2 +-
arch/arm/mach-ixp4xx/include/mach/system.h|2 +-
arch/arm/mach-kirkwood/include/mach/system.h |2 +-
arch/arm/mach-ks8695/include/mach/system.h|2 +-
arch/arm/mach-l7200/include/mach/system.h |2 +-
arch/arm/mach-lh7a40x/include/mach/system.h |2 +-
arch/arm/mach-loki/include/mach/system.h |2 +-
arch/arm/mach-msm/include/mach/system.h |2 +-
arch/arm/mach-mv78xx0/include/mach/system.h |2 +-
arch/arm/mach-mx2/system.c|2 +-
arch/arm/mach-netx/include/mach/system.h |2 +-
arch/arm/mach-ns9xxx/include/mach/system.h|2 +-
arch/arm/mach-orion5x/include/mach/system.h |2 +-
arch/arm/mach-orion5x/lsmini-setup.c |2 +-
arch/arm/mach-pnx4008/include/mach/system.h |2 +-
arch/arm/mach-pxa/corgi.c |6 +++---
Re: [PATCH 1/1] OMAP3: PM: Add the wakeup source driver
On Wed, Mar 18, 2009 at 6:47 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Kim Kyuwon chamm...@gmail.com writes:
Sometimes, it is necessary to find out what does wake up my board?.
Notifying wake-up source feature may be used to blame unexpected
wake-up events which increase power consumption. And user mode
applications can act smartly according to the wake-up event to
minimize power consumption.
Hi Kim,
This is a very useful feature, and something that's is lacking in the
current PM code. Thank you so much for this contribution.
Hi Kevin,
Thank you very much for your encouragement, comments and suggestions.
I tried to follow most of your suggestions, but I can miss something.
Please check my new patch again.
My answers are below and I'll send the new patch right away.
Currently this driver only works for wakeups from suspend. I think
the description should be updated to specify that this only affects
wakeups from susupend, and not wakeups from idle.
OK, I fixed it.
Speaking of which, have you considered extending it to handle wakeups
from idle? Currently tools like powertop give a pretty good idea as
to why the system is coming out of idle, so this may not be necessary,
but was just wondering if you had considered it.
I designed this driver only for wakeups from suspend, but thanks for
letting me know that.
More comments and suggestions on general organization below.
This driver uses sysfs interface to give
information to user mode applications like:
cat /sys/power/wakeup_irq
cat /sys/power/wakeup_event
If only suspend/resume is being handled, maybe 'resume' is a better
name than 'wakeup'. These would be better named:
/sys/power/omap_resume_irq
/sys/power/omap_resume_event
OK, I changed those. But I wish not to replace 'wake' or 'wakeup'
strings with 'resume' in other symbols and filenames.
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING | IRQF_SHARED, BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING | IRQF_SHARED, USB_DETECT, 1},
};
Based on the way this works, I think the board code should not
be requird to set IRQF_SHARED. I think this should be explicitly
ORed in in the wake_suspend hook which requests the IRQ since this will
not work correctly without using IRQF_SHARED.
Thanks, I fixed it.
static struct omap_wake_platform_data boardname_wake_data = {
.qpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
I assume that 'qpio' is a typo and should be gpio?
Oops, thanks, I fixed it.
Also, I'm not sure I agree with adding a generic GPIO wakeup
interface. I believe this should be done by the driver using the GPIO
itself. However, I can see this being useful to test external
wakeup events when no driver is present.
I agree with you that it's better that each driver configure GPIO
wakeup. But, as you said, GPIO wakeup interface in this driver is
useful when the specific driver doesn't exist.
Somewhat different topic: All OMAP boards on which l-o tree kernel is
running have the same wake-up source setup as written in the
prcm_setup_regs() and omap3_pm_init(). But I think this wake-up policy
is a board specific feature, so I wish this driver can take charge of
board specific wake-up configurations in the future. [So... I think
GPIO wakeup interface would become a part of it :)]
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 41 +++
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
arch/arm/mach-omap2/wake34xx.c | 470
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |1 +
arch/arm/plat-omap/include/mach/wake.h | 29 ++
8 files changed, 561 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ba65cab..1ab87e7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX) += sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE) += wake34xx.o
endif
# SmartReflex driver
[PATCH] OMAP3: PM: Add the wakeup source driver, v2
Sometimes, it is necessary to find out what does wake up my board
from suspend?. Notifying wake-up source feature may be used to blame
unexpected wake-up events which increase power consumption. And user
mode applications can act smartly according to the wake-up event from
Suspend-to-RAM state to minimize power consumption. Note that this
driver can't inform wake-up events from idle state. This driver uses
sysfs interface to give information to user mode applications like:
cat /sys/power/omap_resume_irq
cat /sys/power/omap_resume_event
This driver also privides the unified GPIO wake-up source
configuration. specific GPIO settings in the board files are:
/* Wakeup source configuration */
static struct gpio_wake boardname_gpio_wake[] = {
{ 23, IRQF_TRIGGER_RISING,BT_WAKEUP,1},
{ 24, IRQF_TRIGGER_RISING,USB_DETECT, 1},
};
static struct omap_wake_platform_data boardname_wake_data = {
.gpio_wakes = boardname_gpio_wake,
.gpio_wake_num = ARRAY_SIZE(boardname_gpio_wake),
};
static struct platform_device boardname_wakeup = {
.name = omap-wake,
.id = -1,
.dev= {
.platform_data = boardname_wake_data,
},
};
The patch adds Kconfig options OMAP34xx wakeup source support under
System type-TI OMAP implementations menu.
Signed-off-by: Kim Kyuwon q1@samsung.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/irq.c | 21 +-
arch/arm/mach-omap2/pm34xx.c | 12 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/prm-regbits-34xx.h |6 +
arch/arm/mach-omap2/wake34xx.c | 539
arch/arm/plat-omap/Kconfig |9 +
arch/arm/plat-omap/include/mach/irqs.h |4 +
arch/arm/plat-omap/include/mach/pm.h | 10 +
arch/arm/plat-omap/include/mach/wake.h | 30 ++
10 files changed, 633 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-omap2/wake34xx.c
create mode 100644 arch/arm/plat-omap/include/mach/wake.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 16c6fb8..29ad0f1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP24XX)+= sleep24xx.o
obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o cpuidle34xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
+obj-$(CONFIG_OMAP_WAKE)+= wake34xx.o
endif
# SmartReflex driver
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index be4b596..6da285e 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -33,9 +33,6 @@
#define INTC_MIR_SET0 0x008c
#define INTC_PENDING_IRQ0 0x0098
-/* Number of IRQ state bits in each MIR register */
-#define IRQ_BITS_PER_REG 32
-
/*
* OMAP2 has a number of different interrupt controllers, each interrupt
* controller is identified as its own bank. Register definitions are
@@ -193,6 +190,24 @@ int omap_irq_pending(void)
return 0;
}
+void omap_get_pending_irqs(u32 *pending_irqs, unsigned len)
+{
+ int i, idx = 0;
+
+ for (i = 0; i ARRAY_SIZE(irq_banks); i++) {
+ struct omap_irq_bank *bank = irq_banks + i;
+ int irq;
+
+ for (irq = 0; irq bank-nr_irqs idx len;
+ irq += IRQ_BITS_PER_REG) {
+ int offset = irq (~(IRQ_BITS_PER_REG - 1));
+
+ pending_irqs[idx++] = intc_bank_read_reg(bank,
+ (INTC_PENDING_IRQ0 + offset));
+ }
+ }
+}
+
void __init omap_init_irq(void)
{
unsigned long nr_of_irqs = 0;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 9102cee..2d17906 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -91,6 +91,13 @@ static struct prm_setup_times prm_setup = {
.voltsetup2 = 0xff,
};
+static struct pm_wakeup_status omap3_pm_wkst;
+
+void omap3_get_wakeup_status(struct pm_wakeup_status **pm_wkst)
+{
+ *pm_wkst = omap3_pm_wkst;
+}
+
static inline void omap3_per_save_context(void)
{
omap3_gpio_save_context();
@@ -174,6 +181,7 @@ static irqreturn_t prcm_interrupt_handler (int
irq, void *dev_id)
/* WKUP */
wkst = prm_read_mod_reg(WKUP_MOD, PM_WKST);
+ omap3_pm_wkst.wkup = wkst;
if (wkst) {
iclk = cm_read_mod_reg(WKUP_MOD, CM_ICLKEN);
fclk = cm_read_mod_reg(WKUP_MOD, CM_FCLKEN);
@@ -187,6 +195,7 @@ static irqreturn_t prcm_interrupt_handler (int
irq, void *dev_id)
/* CORE */
wkst = prm_read_mod_reg(CORE_MOD, PM_WKST1);
+ omap3_pm_wkst.core1 = wkst;
if (wkst) {
iclk
