Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti wrote: > On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren wrote: >> * DebBarma, Tarun Kanti [120424 08:40]: >>> Hi Janusz, >>> >>> On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti >>> wrote: >>> > On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik >>> > wrote: >>> >> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: >>> >>> With register offsets now defined for respective OMAP versions we can >>> >>> get rid >>> >>> of cpu_class_* checks. This function now has common initialization code >>> >>> for >>> >>> all OMAP versions... >>> >>> >>> >>> Signed-off-by: Tarun Kanti DebBarma >>> >>> Signed-off-by: Charulatha V >>> >>> Reviewed-by: Santosh Shilimkar >>> >>> Acked-by: Tony Lindgren >>> >> >>> >> Sorry for being so late with my comment for chanes already present in >>> >> mainline, but this patch breaks GPIO on Amstrad Delta at least, and I >>> >> have neither enough spare time nor enough experience with non OMAP1 >>> >> machines to provide a solution myself. >>> > Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are >>> > overwritten. >>> > Also looks like there is issue in making distinction between omap15xx >>> > and omap16xx. >>> > I will post a patch and you can help me testing it in OMAP1 platform. >>> > Thanks for pointing this out. >> ... >> >>> Here is the patch, with attachment as well. I have just tested on >>> OMAP4 platform. >>> Testing on other OMAP2+ platforms is pending. In the meantime can you please >>> validate on OMAP1 platform and confirm? Thanks. >>> -- >>> Tarun >>> >>> From: Tarun Kanti DebBarma >>> Date: Tue, 24 Apr 2012 20:34:32 +0530 >>> Subject: [PATCH] gpio/omap: fix omap1 register overwrite in >>> omap_gpio_mod_init >>> >>> Initialization of irqenable, irqstatus registers is the common >>> operation done in this function for all OMAP platforms, viz. >>> OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register >>> was overwriting the correctly programmed OMAP1 value at the >>> beginning. As a result, even though it worked on OMAP2+ >>> platforms it was breaking OMAP1 functionality. >> >> Sounds like the original patch was never tested on omap1? > That's right, only bootup test was done on OMAP1710-SDP. > >> >>> On closer observation it is found that the first _gpio_rmw() >>> which is supposedly done to take care of OMAP1 platform is >>> generic enough and takes care of OMAP2+ platform as well. >>> Therefore remove the latter _gpio_rmw() to irqenable as they >>> are redundant. >>> >>> Also, changing the sequence and logic of initializing the >>> irqstatus. >> >> Please mention also the breaking commit here and get this fix >> merged as a regression as soon as it's tested for the current >> -rc series. > Sure, I will do that! Looks like it is regression on 3.4 as well so CC stable when you post the patch. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
On 04/25/2012 05:02 AM, Oleg Matcovschi wrote: > Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 > Signed-off-by: Oleg Matcovschi > --- > v1: > initial revision > v2: > resending patch including maintainers > > sound/soc/omap/omap-pcm.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe 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 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
On Tue, 2012-04-24 at 23:48 -0500, Ricardo Neri wrote: > On 04/23/2012 08:01 AM, Tomi Valkeinen wrote: > > On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: > >> Implement the DSS device driver audio support interface in the HDMI > >> panel driver and generic driver. The implementation relies on the > >> IP-specific functions that are defined at DSS probe time. > >> > >> A HW-safe spinlock is used to protect the audio functions. This is because > > > > What is a "HW-safe spinlock"? > Sorry, I meant a spinlock that disables the HW irqs when held:hardirq-safe. > > > > >> the audio functions may be called while holding a lock; in such case, > >> the panel's driver mutex is not suitable. Functions should be used > >> to set registers and should not wait for any other event. > > > > Are you sure this is the only option? What lock is being held? > For instance, ALSA calls the start audio function while holding a > hardirq-safe readlock. Hence, when reaching the HDMI panel start > function, a lock is held and irqs are disabled. Using a mutex, that > might sleep, is not correct; nor it is using an hardirq-unsafe spinlock. > Otherwise, deadlocks and/or inverse lock ordering may arise. This > situation was signaled by lockdep. > > IMHO, as the DSS device driver does not know who is going to use it (at > least the audio part), it should not assume that no locks are held when > its functions are called. > > > While a spinlock may be ok for now, quite often enabling/disabling things > > do not > > happen immediately,and it's much easier to do the wait synchronously. > I don't understand this comment. To me, holding a lock until the > enabling function returns is synchronous. Would you please clarify? I meant that quite often when enabling things on hardware it takes time until the HW is actually up and running. Perhaps a regulator needs to be started, or such. And it's usually simpler to wait for the HW to be up synchronously in the enable function, instead of some kind of asynchronous mechanism. And if a function waits synchronously, a mutex is better than spinlock. And in that sense it's often better to define (define meaning, adding a comment, or just mentally taking note about it) that the functions in the API may sleep, so that the driver is free to do what is best for the case, and it's also future-proof in a way that you can easily add function calls that sleep to the functions in the future. But you are also right in your previous comment, it's better to define functions so that they never sleep, as that gives the callers the freedom to call the funcs in atomic context. Perhaps we can have audio_start() that never sleeps, it just enables a few bits that start the audio. But how about audio_enable()? Is it possible that on some OMAP version it would need to enable a regulator, or set a gpio that's in an external i2c controlled mux chip, or such? If so, we need to make sure it's not currently called in an atomic context, because it would break if the function will sleep in the future. And with "make sure" I just mean that we check the code and keep it in mind. Or perhaps adding a comment in the header, that says "audio_enable may sleep, other audio functions do not sleep" or such. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 06:33:26, Paul Walmsley wrote: > Hello Vaibhav, Afzal, Vaibhav, > > On Tue, 3 Apr 2012, Vaibhav Hiremath wrote: > > > AM33XX clock implementation is different than any existing OMAP > > family of devices. Although DPLL module is similar to OMAP4 > > device, but the usage is very much different than OMAP4. > > AM33XX has different peripheral set and each module gets > > integrated to the clock framework differently than OMAP > > family of devices. > > > > This patch adds full Clock tree data for AM33XX family > > of devices and also integrates it into existing OMAP framework. > > What do you think about the possibility of removing all of the leaf clocks > that have AM33XX_MODULEMODE_SWCTRL as their .enable_bit, assuming there > are no .fixed_div or .clksel* fields associated with the clocks? > > In theory, I don't think they are needed. The drivers should be using > runtime PM, and that should enable and disable the module via the hwmod > code, rather than the clock code. > > Of course some clocks would still be needed for the main_clk fields for > the hwmods, but the hwmods should be able to use the leaf clock's parent > clocks for that. > > That would save quite a few lines of data. And I think Benoît is planning > to do that for OMAP4+. > > What do you think? > Paul, Yes, theoretically it is possible to do it. But it will also break some of the existing things, like, 1. DebugFS clock interface I believe, with this change, you will not have all the leaf nodes as part of clock tree, so they will not be populated in /debug/clock/ 2. Enable and disable of the module is one part, but what about, changing the rate of the clock (followparent_recalc)? With the proper and complete clock tree, you can traverse the clock and driver code doesn't need to know about parent. Driver can simply call clk_set_rate() on leaf clock, and clock tree will handle it. If at all we take this path, we have to build the clk node runtime (on-the-fly), AND/OR add new pm_runtime_set_rate() api. Are you available on IRC chat anytime? We can discuss on this and align quickly. I am available on linux-omap irc channel (with the name = "hvaibhav") Thanks, Vaibhav > > - 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 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
On 04/23/2012 08:01 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.
A HW-safe spinlock is used to protect the audio functions. This is because
What is a "HW-safe spinlock"?
Sorry, I meant a spinlock that disables the HW irqs when held:hardirq-safe.
the audio functions may be called while holding a lock; in such case,
the panel's driver mutex is not suitable. Functions should be used
to set registers and should not wait for any other event.
Are you sure this is the only option? What lock is being held?
For instance, ALSA calls the start audio function while holding a
hardirq-safe readlock. Hence, when reaching the HDMI panel start
function, a lock is held and irqs are disabled. Using a mutex, that
might sleep, is not correct; nor it is using an hardirq-unsafe spinlock.
Otherwise, deadlocks and/or inverse lock ordering may arise. This
situation was signaled by lockdep.
IMHO, as the DSS device driver does not know who is going to use it (at
least the audio part), it should not assume that no locks are held when
its functions are called.
While a spinlock may be ok for now, quite often enabling/disabling things do not
happen immediately,and it's much easier to do the wait synchronously.
I don't understand this comment. To me, holding a lock until the
enabling function returns is synchronous. Would you please clarify?
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/dss.h|7 +++
drivers/video/omap2/dss/hdmi.c | 33 +++
drivers/video/omap2/dss/hdmi_panel.c | 76 ++
3 files changed, 116 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 32ff69f..fca4490 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -520,6 +520,13 @@ int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
+#ifdef CONFIG_OMAP4_DSS_HDMI_AUDIO
+int hdmi_audio_enable(bool enable);
+int hdmi_audio_start(bool start);
+bool hdmi_mode_has_audio(void);
+int hdmi_audio_config(struct snd_aes_iec958 *iec,
+ struct snd_cea_861_aud_if *aud_if);
+#endif
/* RFBI */
#ifdef CONFIG_OMAP2_DSS_RFBI
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index bd44891..880509d 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -698,6 +698,39 @@ int hdmi_compute_acr(u32 sample_freq, u32 *n, u32 *cts)
return 0;
}
+
+int hdmi_audio_enable(bool enable)
+{
+ DSSDBG("audio_enable\n");
+
+ hdmi.ip_data.ops->audio_enable(&hdmi.ip_data, enable);
Shouldn't this, and the others below, return the value from the called
function, instead of always returning 0?
Yes, at the time of writing this patch, the HDMI ops that you refer to
returned void. In v2, I will submit a patch for the HDMI ops to return a
result value which will also be returned by the DSS audio interface
functions just as you point out.
+
+ return 0;
+}
+
+int hdmi_audio_start(bool start)
+{
+ DSSDBG("audio_enable\n");
+
+ hdmi.ip_data.ops->audio_start(&hdmi.ip_data, start);
+
+ return 0;
+}
+
+bool hdmi_mode_has_audio(void)
+{
+ if (hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)
+ return true;
+ else
+ return false;
+}
+
+int hdmi_audio_config(struct snd_aes_iec958 *iec,
+ struct snd_cea_861_aud_if *aud_if)
+{
+ return hdmi.ip_data.ops->audio_config(&hdmi.ip_data, iec, aud_if);
+}
+
#endif
/* HDMI HW IP initialisation */
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..dac1ac2 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -31,6 +31,10 @@
static struct {
struct mutex hdmi_lock;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ /* protects calls to HDMI driver audio functionality */
+ spinlock_t hdmi_sp_lock;
What does "sp" stand for? Spinlock? Perhaps a better name would be
"audio_lock", if it's audio specific. And probably no reason to prefix
it with "hdmi", as it's inside "hdmi" struct already.
Yes, sp stands for spinlock. I prefixed the name with "hdmi" to align
with the naming of the HDMI mutex. Maybe audio_lock is a better name. I
could also submit a patch to remove the "hdmi" prefix in the mutex name.
BR,
Ricardo
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren wrote: > * DebBarma, Tarun Kanti [120424 08:40]: >> Hi Janusz, >> >> On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti >> wrote: >> > On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik >> > wrote: >> >> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: >> >>> With register offsets now defined for respective OMAP versions we can >> >>> get rid >> >>> of cpu_class_* checks. This function now has common initialization code >> >>> for >> >>> all OMAP versions... >> >>> >> >>> Signed-off-by: Tarun Kanti DebBarma >> >>> Signed-off-by: Charulatha V >> >>> Reviewed-by: Santosh Shilimkar >> >>> Acked-by: Tony Lindgren >> >> >> >> Sorry for being so late with my comment for chanes already present in >> >> mainline, but this patch breaks GPIO on Amstrad Delta at least, and I >> >> have neither enough spare time nor enough experience with non OMAP1 >> >> machines to provide a solution myself. >> > Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are >> > overwritten. >> > Also looks like there is issue in making distinction between omap15xx >> > and omap16xx. >> > I will post a patch and you can help me testing it in OMAP1 platform. >> > Thanks for pointing this out. > ... > >> Here is the patch, with attachment as well. I have just tested on >> OMAP4 platform. >> Testing on other OMAP2+ platforms is pending. In the meantime can you please >> validate on OMAP1 platform and confirm? Thanks. >> -- >> Tarun >> >> From: Tarun Kanti DebBarma >> Date: Tue, 24 Apr 2012 20:34:32 +0530 >> Subject: [PATCH] gpio/omap: fix omap1 register overwrite in >> omap_gpio_mod_init >> >> Initialization of irqenable, irqstatus registers is the common >> operation done in this function for all OMAP platforms, viz. >> OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register >> was overwriting the correctly programmed OMAP1 value at the >> beginning. As a result, even though it worked on OMAP2+ >> platforms it was breaking OMAP1 functionality. > > Sounds like the original patch was never tested on omap1? That's right, only bootup test was done on OMAP1710-SDP. > >> On closer observation it is found that the first _gpio_rmw() >> which is supposedly done to take care of OMAP1 platform is >> generic enough and takes care of OMAP2+ platform as well. >> Therefore remove the latter _gpio_rmw() to irqenable as they >> are redundant. >> >> Also, changing the sequence and logic of initializing the >> irqstatus. > > Please mention also the breaking commit here and get this fix > merged as a regression as soon as it's tested for the current > -rc series. Sure, I will do that! -- Tarun > > Regards, > > Tony > > >> Signed-off-by: Tarun Kanti DebBarma >> --- >> drivers/gpio/gpio-omap.c | 5 + >> 1 files changed, 1 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c >> index 1adc2ec..b8f01c1 100644 >> --- a/drivers/gpio/gpio-omap.c >> +++ b/drivers/gpio/gpio-omap.c >> @@ -964,11 +964,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank) >> return; >> } >> >> + _gpio_rmw(base, bank->regs->irqstatus, l, >> bank->regs->irqenable_inv == 0 ); >> _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->irqenable_inv); >> - _gpio_rmw(base, bank->regs->irqstatus, l, >> - bank->regs->irqenable_inv == false); >> - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->debounce_en != >> 0); >> - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->ctrl != 0); >> if (bank->regs->debounce_en) >> _gpio_rmw(base, bank->regs->debounce_en, 0, 1); >> >> -- >> 1.7.0.4 > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/10] OMAPDSS: HDMI: Decouple HDMI audio from ASoC
On 04/23/2012 08:25 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/Kconfig |4
drivers/video/omap2/dss/dss_features.c|3 +--
drivers/video/omap2/dss/ti_hdmi.h |6 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |3 +--
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |5 +
5 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 7be7c06..b492001 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -68,6 +68,10 @@ config OMAP4_DSS_HDMI
HDMI Interface. This adds the High Definition Multimedia Interface.
See http://www.hdmi.org/ for HDMI specification.
+config OMAP4_DSS_HDMI_AUDIO
+ bool
+ depends on OMAP4_DSS_HDMI
+
config OMAP2_DSS_SDI
bool "SDI support"
depends on ARCH_OMAP3
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index c1839e2..399a28a 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -497,8 +497,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
.audio_enable = ti_hdmi_4xxx_wp_audio_enable,
.audio_start= ti_hdmi_4xxx_audio_start,
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 529e227..211da6f 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -110,8 +110,7 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct hdmi_ip_data *ip_data, struct seq_file *s);
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void (*audio_enable)(struct hdmi_ip_data *ip_data, bool start);
void (*audio_start)(struct hdmi_ip_data *ip_data, bool start);
@@ -145,8 +144,7 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void ti_hdmi_4xxx_wp_audio_enable(struct hdmi_ip_data *ip_data, bool enable);
void ti_hdmi_4xxx_audio_start(struct hdmi_ip_data *ip_data, bool enable);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e6fa61d..e06139a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -1030,8 +1030,7 @@ void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s)
DUMPPHY(HDMI_TXPHY_PAD_CFG_CTRL);
}
-#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
- defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
void hdmi_wp_audio_config_format(struct hdmi_ip_data *ip_data,
struct hdmi_audio_format *aud_fmt)
{
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 9fa5cb1..222cc16 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -26,8 +26,6 @@
#include "ti_hdmi.h"
#if defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI) || \
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
-#include
-#include
Unrelated change. And... is there something wrong with this? Shouldn't
the defines above be changed?
Yes. The defines should have changed. I will also remove the #includes
in a separate patch.
BR,
Ricardo
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/10] OMAPDSS: HDMI: OMAP4: Correcty typo in I2S definitions
On 04/23/2012 07:42 AM, Tomi Valkeinen wrote: On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: Signed-off-by: Ricardo Neri There's a typo in the subject of the typo fix =). Oops! I totally missed it. I will fix. And always provide a patch description, please. In the simplest cases it can be the same as the subject. Understood. BR, Ricardo Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
On 04/23/2012 08:12 AM, Tomi Valkeinen wrote:
On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote:
In order to avoid duplication of definitions. Use the definitions provided
by asoundef.h. Furthermore, as CEA-861 and IEC-60958 are used by both
DisplayPort and HDMI, this helps to make the code more generic.
The first two sentences should probably be just one sentence.
Actually, I just rephrased the whole description :). I will submit it in
v2 of the patch series.
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 15 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 80 ++---
2 files changed, 12 insertions(+), 83 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4740e64..4ab3b19 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -29,7 +29,6 @@
#include
#include
#include
-
Unrelated change.
I will remove it.
#include "ti_hdmi_4xxx_ip.h"
#include "dss.h"
@@ -1156,7 +1155,7 @@ void hdmi_core_audio_config(struct hdmi_ip_data *ip_data,
}
void hdmi_core_audio_infoframe_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_audio *info_aud)
+ struct snd_cea_861_aud_if *info_aud)
{
u8 val;
u8 sum = 0, checksum = 0;
@@ -1172,22 +1171,24 @@ void hdmi_core_audio_infoframe_config(struct
hdmi_ip_data *ip_data,
hdmi_write_reg(av_base, HDMI_CORE_AV_AUDIO_LEN, 0x0a);
sum += 0x84 + 0x001 + 0x00a;
- val = (info_aud->db1_coding_type<< 4)
- | (info_aud->db1_channel_count - 1);
+ val = (info_aud->coding_type<< CEA861_AUDIO_INFOFRAME_DB1CT_SHIFT)
+ | (info_aud->channel_count - 1);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(0), val);
sum += val;
- val = (info_aud->db2_sample_freq<< 2) | info_aud->db2_sample_size;
+ val = (info_aud->sample_freq<< CEA861_AUDIO_INFOFRAME_DB2SF_SHIFT)
+ | (info_aud->sample_size);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(1), val);
sum += val;
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(2), 0x00);
- val = info_aud->db4_channel_alloc;
+ val = info_aud->channel_alloc;
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(3), val);
sum += val;
- val = (info_aud->db5_downmix_inh<< 7) | (info_aud->db5_lsv<< 3);
+ val = (info_aud->st_downmix<< CEA861_AUDIO_INFOFRAME_DB5_DM_INH_SHIFT)
+ | (info_aud->lsv<< CEA861_AUDIO_INFOFRAME_DB5_LSV_SHIFT);
hdmi_write_reg(av_base, HDMI_CORE_AV_AUD_DBYTE(4), val);
sum += val;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index a442998..d6b49b6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -28,6 +28,8 @@
defined(CONFIG_SND_OMAP_SOC_OMAP4_HDMI_MODULE)
#include
#include
+#include
+#include
You don't need to include these in the header file.
I will remove it.
#endif
/* HDMI Wrapper */
@@ -284,35 +286,6 @@ enum hdmi_core_infoframe {
HDMI_INFOFRAME_AVI_DB5PR_8 = 7,
HDMI_INFOFRAME_AVI_DB5PR_9 = 8,
HDMI_INFOFRAME_AVI_DB5PR_10 = 9,
- HDMI_INFOFRAME_AUDIO_DB1CT_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB1CT_IEC60958 = 1,
- HDMI_INFOFRAME_AUDIO_DB1CT_AC3 = 2,
- HDMI_INFOFRAME_AUDIO_DB1CT_MPEG1 = 3,
- HDMI_INFOFRAME_AUDIO_DB1CT_MP3 = 4,
- HDMI_INFOFRAME_AUDIO_DB1CT_MPEG2_MULTICH = 5,
- HDMI_INFOFRAME_AUDIO_DB1CT_AAC = 6,
- HDMI_INFOFRAME_AUDIO_DB1CT_DTS = 7,
- HDMI_INFOFRAME_AUDIO_DB1CT_ATRAC = 8,
- HDMI_INFOFRAME_AUDIO_DB1CT_ONEBIT = 9,
- HDMI_INFOFRAME_AUDIO_DB1CT_DOLBY_DIGITAL_PLUS = 10,
- HDMI_INFOFRAME_AUDIO_DB1CT_DTS_HD = 11,
- HDMI_INFOFRAME_AUDIO_DB1CT_MAT = 12,
- HDMI_INFOFRAME_AUDIO_DB1CT_DST = 13,
- HDMI_INFOFRAME_AUDIO_DB1CT_WMA_PRO = 14,
- HDMI_INFOFRAME_AUDIO_DB2SF_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB2SF_32000 = 1,
- HDMI_INFOFRAME_AUDIO_DB2SF_44100 = 2,
- HDMI_INFOFRAME_AUDIO_DB2SF_48000 = 3,
- HDMI_INFOFRAME_AUDIO_DB2SF_88200 = 4,
- HDMI_INFOFRAME_AUDIO_DB2SF_96000 = 5,
- HDMI_INFOFRAME_AUDIO_DB2SF_176400 = 6,
- HDMI_INFOFRAME_AUDIO_DB2SF_192000 = 7,
- HDMI_INFOFRAME_AUDIO_DB2SS_FROM_STREAM = 0,
- HDMI_INFOFRAME_AUDIO_DB2SS_16BIT = 1,
- HDMI_INFOFRAME_AUDIO_DB2SS_20BIT = 2,
- HDMI_INFOFRAME_AUDIO_DB2SS_24BIT = 3,
- HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PERMITTED = 0,
- HDMI_INFOFRAME_AUDIO_DB5_DM_INH_PROHIBITED = 1
};
enum hdmi_packing_mode {
@@ -322,17 +295,6 @@ enum hdmi_packing_mode {
HDMI_PACK_ALREADYPACKED = 7
};
-enum hdmi_core_audio_sample_freq {
- HDMI_AUDIO_FS_32000 = 0x3,
- HDMI_AUDIO_FS_44100 = 0x0,
-
[PATCH 3/3] twl4030: enable wakeup on twl4030 IRQ.
Most of the interrupts that come through this line should trigger wakeups: power button RTC alarm power available usb plug/unplug so mark the interrupt as a wakeup interrupt. This is particularly important for when the interrupt arrives during the late suspend phase. Without this setting it will be ignored. Signed-off-by: NeilBrown --- drivers/mfd/twl4030-irq.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index 5d656e8..ad733d7 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -757,6 +757,7 @@ int twl4030_init_irq(struct device *dev, int irq_num) dev_err(dev, "could not claim irq%d: %d\n", irq_num, status); goto fail_rqirq; } + enable_irq_wake(irq_num); return irq_base; fail_rqirq: -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
is still asserted will not cause the suspend to abort.
So if any wakeup interrupt is masked, unmask it when checking wakeup
irqs. If the interrupt is asserted, suspend will abort.
Signed-off-by: NeilBrown
---
kernel/irq/pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..0d26206 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -106,6 +106,12 @@ int check_wakeup_irqs(void)
if (irqd_is_wakeup_set(&desc->irq_data)) {
if (desc->istate & IRQS_PENDING)
return -EBUSY;
+ if (irqd_irq_masked(&desc->irq_data))
+ /* Probably a level interrupt
+* which fired recently and was
+* masked
+*/
+ unmask_irq(desc);
continue;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: omap2+: set IRQCHIP_SKIP_SET_WAKE for INTC interrupts.
All interrupts can wake-from-sleep (I think) so it should be permissible to call enable_irq_wake(). Setting this flag allows that. It is needed because without this, an interrupt which is delivered during late suspend will get ignored but will not cause suspend to abort. If enable_irq_wake() is called and succeeds, check_wakuep_irqs() will abort the suspend if the interrupt has fired. Signed-off-by: NeilBrown --- arch/arm/mach-omap2/irq.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c index 65f0d257..b0790a9 100644 --- a/arch/arm/mach-omap2/irq.c +++ b/arch/arm/mach-omap2/irq.c @@ -148,6 +148,7 @@ omap_alloc_gc(void __iomem *base, unsigned int irq_start, unsigned int num) ct->chip.irq_ack = omap_mask_ack_irq; ct->chip.irq_mask = irq_gc_mask_disable_reg; ct->chip.irq_unmask = irq_gc_unmask_enable_reg; + ct->chip.flags |= IRQCHIP_SKIP_SET_WAKE; ct->regs.ack = INTC_CONTROL; ct->regs.enable = INTC_MIR_CLEAR0; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Ensure twl4030 interrupts are lost during suspend.
Sorry for the scatter-gun list of email address, but while each of these patches only touches one subsystem, they really needed each other to provide proper context. The goal is to ensure that an interrupt that arrives on a TWL4030 connected to an OMAP3, during the 'late-suspend' stage will cause the suspend to abort (if the interrupt is properly configured). (e.g. power button, RTC alarm, USB plug/unplug) The interrupt as seen by the OMAP3 is a level-triggered interrupt so if it arrives at this time, it is masked. With the current code it remains masked and so cannot wake the device from suspend. To fix this: The twl4030 drivers must mark the interrupt for wakeup The OMAP interrupt handler must allow the interrupt to be marked for wakeup The core interrupt/PM code must allow masked level-triggered interrupts to abort a suspend. I'm least sure about that last one. My patch unmasks any masked interrupt that is suppose to support wakeup. I suspect that is correct but I don't know enough about general IRQ handling to be sure. Maybe there could be cases where a driver has explicitly masked the interrupt without cleaning the 'wakeup' setting. Is that allowed? --- NeilBrown (3): twl4030: enable wakeup on twl4030 IRQ. IRQ: allow check_wakeup_irqs to notice level-triggered interrupts. ARM: omap2+: set IRQCHIP_SKIP_SET_WAKE for INTC interrupts. arch/arm/mach-omap2/irq.c |1 + drivers/mfd/twl4030-irq.c |1 + kernel/irq/pm.c |6 ++ 3 files changed, 8 insertions(+) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: omap_hdq: use wait_event_timeout to wait for read to complete.
There is no gain in having a loop - there is no risk of missing the
interrupt with wait_event_timeout.
Signed-off-by: NeilBrown
---
drivers/w1/masters/omap_hdq.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 3356d75..eb01c7f 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -357,7 +357,6 @@ static int hdq_read_byte(struct hdq_data *hdq_data, u8 *val)
{
int ret = 0;
u8 status;
- unsigned long timeout = jiffies + OMAP_HDQ_TIMEOUT;
ret = mutex_lock_interruptible(&hdq_data->hdq_mutex);
if (ret < 0) {
@@ -375,15 +374,13 @@ static int hdq_read_byte(struct hdq_data *hdq_data, u8
*val)
OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO,
OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO);
/*
-* The RX comes immediately after TX. It
-* triggers another interrupt before we
-* sleep. So we have to wait for RXCOMPLETE bit.
+* The RX comes immediately after TX.
*/
- while (!(hdq_data->hdq_irqstatus
- & OMAP_HDQ_INT_STATUS_RXCOMPLETE)
- && time_before(jiffies, timeout)) {
- schedule_timeout_uninterruptible(1);
- }
+ wait_event_timeout(hdq_wait_queue,
+ (hdq_data->hdq_irqstatus
+ & OMAP_HDQ_INT_STATUS_RXCOMPLETE),
+ OMAP_HDQ_TIMEOUT);
+
hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS, 0,
OMAP_HDQ_CTRL_STATUS_DIR);
status = hdq_data->hdq_irqstatus;
--
1.7.10
signature.asc
Description: PGP signature
[PATCH 1/2] ARM: omap_hdq: Fix some error/debug handling.
- some debug messages missed spaces. The did this because they
broke a string onto 2 lines - badly. That practice is currently
out of favour, so join the two strings together, insert the space,
and put newlines elsewhere.
- sometimes no error was returned when it should have been
- sometimes a message is printed when there is no error, rather
than when there is one.
Signed-off-by: NeilBrown
---
drivers/w1/masters/omap_hdq.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
index 5ef385b..3356d75 100644
--- a/drivers/w1/masters/omap_hdq.c
+++ b/drivers/w1/masters/omap_hdq.c
@@ -180,14 +180,16 @@ static int hdq_write_byte(struct hdq_data *hdq_data, u8
val, u8 *status)
hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
if (ret == 0) {
dev_dbg(hdq_data->dev, "TX wait elapsed\n");
+ ret = -ETIMEDOUT;
goto out;
}
*status = hdq_data->hdq_irqstatus;
/* check irqstatus */
if (!(*status & OMAP_HDQ_INT_STATUS_TXCOMPLETE)) {
- dev_dbg(hdq_data->dev, "timeout waiting for"
- "TXCOMPLETE/RXCOMPLETE, %x", *status);
+ dev_dbg(hdq_data->dev,
+ "timeout waiting for TXCOMPLETE/RXCOMPLETE, %x",
+ *status);
ret = -ETIMEDOUT;
goto out;
}
@@ -197,8 +199,9 @@ static int hdq_write_byte(struct hdq_data *hdq_data, u8
val, u8 *status)
OMAP_HDQ_CTRL_STATUS_GO,
OMAP_HDQ_FLAG_CLEAR, &tmp_status);
if (ret) {
- dev_dbg(hdq_data->dev, "timeout waiting GO bit"
- "return to zero, %x", tmp_status);
+ dev_dbg(hdq_data->dev,
+ "timeout waiting GO bit return to zero, %x",
+ tmp_status);
}
out:
@@ -340,8 +343,9 @@ static int omap_hdq_break(struct hdq_data *hdq_data)
OMAP_HDQ_CTRL_STATUS_GO, OMAP_HDQ_FLAG_CLEAR,
&tmp_status);
if (ret)
- dev_dbg(hdq_data->dev, "timeout waiting INIT&GO bits"
- "return to zero, %x", tmp_status);
+ dev_dbg(hdq_data->dev,
+ "timeout waiting INIT&GO bits return to zero, %x",
+ tmp_status);
out:
mutex_unlock(&hdq_data->hdq_mutex);
@@ -385,8 +389,9 @@ static int hdq_read_byte(struct hdq_data *hdq_data, u8 *val)
status = hdq_data->hdq_irqstatus;
/* check irqstatus */
if (!(status & OMAP_HDQ_INT_STATUS_RXCOMPLETE)) {
- dev_dbg(hdq_data->dev, "timeout waiting for"
- "RXCOMPLETE, %x", status);
+ dev_dbg(hdq_data->dev,
+ "timeout waiting for RXCOMPLETE, %x",
+ status);
ret = -ETIMEDOUT;
goto out;
}
@@ -396,7 +401,7 @@ static int hdq_read_byte(struct hdq_data *hdq_data, u8 *val)
out:
mutex_unlock(&hdq_data->hdq_mutex);
rtn:
- return 0;
+ return ret;
}
@@ -469,8 +474,8 @@ static int omap_hdq_put(struct hdq_data *hdq_data)
return -EINTR;
if (0 == hdq_data->hdq_usecount) {
- dev_dbg(hdq_data->dev, "attempt to decrement use count"
- "when it is zero");
+ dev_dbg(hdq_data->dev,
+ "attempt to decrement use count when it is zero");
ret = -EINVAL;
} else {
hdq_data->hdq_usecount--;
@@ -540,7 +545,7 @@ static void omap_w1_write_byte(void *_hdq, u8 byte)
mutex_unlock(&hdq_data->hdq_mutex);
ret = hdq_write_byte(hdq_data, byte, &status);
- if (ret == 0) {
+ if (ret < 0) {
dev_dbg(hdq_data->dev, "TX failure:Ctrl status %x\n", status);
return;
}
--
1.7.10
signature.asc
Description: PGP signature
Re: [PATCH 01/10] OMAPDSS: HDMI: Remove ASoC codec
Hi Tomi, Thanks for your comments! On 04/23/2012 08:17 AM, Tomi Valkeinen wrote: On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: Instead of having an ASoC codec embedded into DSS code, use the generic DSS device driverinterface for audio support. This allows to any potential user, including an ASoC driver, take advantage of the HDMI audio functionality. The description could be improved. The patch removes lots of code from the hdmi driver, but the description doesn't really describe what's going on and where the code goes (if anywhere). In fact, it even feels that the description is about something else. It basically just says "use generic DSS interface for audio", but the patch doesn't do that, it removes code. Yes. It seems that the description is more suitable for the whole patch series. I was trying to justify why I was removing the ASoC HDMI codec. I will rephrase to state that this patch removes the HDMI audio support to restore in a separate patch through the DSS audio interface. Also how does this affect the current driver? I presume it effectively removes HDMI audio support? Does the code still compile with this patch? Yes, the code still compiles as the current ASoC HDMI codec exists with independences of the ASoC HDMI DAI and machine drivers. It will compile but it will not probe and ALSA HDMI audio support will be missing. BR, Ricardo Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index a2a464f..380a5bd 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -414,6 +414,10 @@ static int omap_pcm_new(struct snd_soc_pcm_runtime *rtd) } out: + /* free preallocated buffers in case of error */ + if (ret) + omap_pcm_free_dma_buffers(pcm); + return ret; } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
Hello Vaibhav, Afzal, Vaibhav, On Tue, 3 Apr 2012, Vaibhav Hiremath wrote: > AM33XX clock implementation is different than any existing OMAP > family of devices. Although DPLL module is similar to OMAP4 > device, but the usage is very much different than OMAP4. > AM33XX has different peripheral set and each module gets > integrated to the clock framework differently than OMAP > family of devices. > > This patch adds full Clock tree data for AM33XX family > of devices and also integrates it into existing OMAP framework. What do you think about the possibility of removing all of the leaf clocks that have AM33XX_MODULEMODE_SWCTRL as their .enable_bit, assuming there are no .fixed_div or .clksel* fields associated with the clocks? In theory, I don't think they are needed. The drivers should be using runtime PM, and that should enable and disable the module via the hwmod code, rather than the clock code. Of course some clocks would still be needed for the main_clk fields for the hwmods, but the hwmods should be able to use the leaf clock's parent clocks for that. That would save quite a few lines of data. And I think Benoît is planning to do that for OMAP4+. What do you think? - Paul
Re: [PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
Hello Vaibhav, Afzal, Vaibhav,
A few questions while reviewing this patch:
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
> AM33XX PRCM module consist of, various clockdomains, in all
> total we have 18 clockdomains available, with following
> controlling options,
>- NO Sleep: sleep transition can not be initiated,
>- SW Sleep: sw forced sleep transition,
>- SW Wakeup: sw forced wakeup transition,
>- HW Auto: transitions are based upon hw conditions.
>
> This patch adds all available clockdomain data, respective
> clockdomain operations for AM33XX family of device, and also
> integrates it into existing OMAP framework.
>
> Signed-off-by: Vaibhav Hiremath
> Signed-off-by: Afzal Mohammed
> Signed-off-by: Vaibhav Bedia
...
> +static struct clockdomain l4ls_am33xx_clkdm = {
> + .name = "l4ls_clkdm",
> + .pwrdm = { .name = "per_pwrdm" },
> + .cm_inst= AM33XX_CM_PER_MOD,
> + .clkdm_offs = AM33XX_CM_PER_L4LS_CLKSTCTRL_OFFSET,
> + .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
> + .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
It looks to me like we don't need the .clktrctrl_mask field, since
according to the clockdomains code, the CLKTRCTRL field is at the same bit
shift for each clockdomain.
Also, since we're not defining any autodeps for the AM335x platform, we
shouldn't need the CLKDM_NO_AUTODEPS flag either? Since no autodeps are
defined, the default will be to not set any autodeps.
Another question is about the CLKTRCTRL bitfields. According to
_AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference
Manual_ Rev. D (SPRUH73D), most of the clockdomains support NO_SLEEP mode
(i.e., CLKTRCTRL = 0x0). That means that technically, we should also set
the CLKDM_CAN_DISABLE_AUTO flag. Unless the documentation is incorrect
here? In another section (Table 8-9 "Clock Transition Mode Settings"),
it claims that CLKTRCTRL = 0 is not supported...
Also, a question about the L4_WKUP clockdomain:
> +static struct clockdomain l4_wkup_am33xx_clkdm = {
> + .name = "l4_wkup_clkdm",
> + .pwrdm = { .name = "wkup_pwrdm" },
> + .cm_inst= AM33XX_CM_WKUP_MOD,
> + .clkdm_offs = AM33XX_CM_WKUP_CLKSTCTRL_OFFSET,
> + .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
> + .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
> +};
Table 8-89 "CM_WKUP_CLKSTCTRL Register Field Descriptions" of SPRUH73D
claims that this clockdomain supports hardware-supervised automatic
clockdomain transitions. Again this conflicts with Table 8-9. Is this a
documentation bug, or should we update the patch?
- 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: [RFC 00/12] OMAP DMA engine conversion
On Wed, Apr 25, 2012 at 2:29 AM, Russell King - ARM Linux wrote: > On Wed, Apr 25, 2012 at 01:47:21AM +0300, Grazvydas Ignotas wrote: >> On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote: >> > * Russell King - ARM Linux [120424 03:42]: >> >> Here's another patch - for the OMAP NAND driver. >> >> >> >> One thing this doesn't do is configure up the source/destination bursts, >> >> which the old code did: >> >> >> >> omap_set_dma_dest_burst_mode(info->dma_ch, >> >> OMAP_DMA_DATA_BURST_16); >> >> omap_set_dma_src_burst_mode(info->dma_ch, >> >> OMAP_DMA_DATA_BURST_16); >> > >> > Grazvydas, care to give this patch a go? >> >> Tested-by: Grazvydas Ignotas >> for: >> - SD card connected over transceiver to MMC2 >> - touchscreen connected over SPI >> - NAND on GPMC in DMA mode >> Seems to be working just as they did before, except that I'm not sure >> SPI was crossing PIO threshold. > > I think my testing on OMAP4430SDP with the SPI based ethernet should've > caught anything untoward there. > > For the MMC2, could you say whether this was the hsmmc driver or the > older omap1/2 driver please? hsmmc running on OMAP3 pandora. -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] OMAP DMA engine conversion
On Wed, Apr 25, 2012 at 01:47:21AM +0300, Grazvydas Ignotas wrote: > On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote: > > * Russell King - ARM Linux [120424 03:42]: > >> Here's another patch - for the OMAP NAND driver. > >> > >> One thing this doesn't do is configure up the source/destination bursts, > >> which the old code did: > >> > >> omap_set_dma_dest_burst_mode(info->dma_ch, > >> OMAP_DMA_DATA_BURST_16); > >> omap_set_dma_src_burst_mode(info->dma_ch, > >> OMAP_DMA_DATA_BURST_16); > > > > Grazvydas, care to give this patch a go? > > Tested-by: Grazvydas Ignotas > for: > - SD card connected over transceiver to MMC2 > - touchscreen connected over SPI > - NAND on GPMC in DMA mode > Seems to be working just as they did before, except that I'm not sure > SPI was crossing PIO threshold. I think my testing on OMAP4430SDP with the SPI based ethernet should've caught anything untoward there. For the MMC2, could you say whether this was the hsmmc driver or the older omap1/2 driver please? Thanks. -- To unsubscribe from this list: send the line "unsubscribe 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Tue, Apr 24, 2012 at 01:51:05PM -0700, Mark A. Greer wrote: > On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: > > Hi > > Hi Paul, Kevin. > > > On Wed, 11 Apr 2012, Mark A. Greer wrote: > > > > > From: "Mark A. Greer" > > > > > > Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() > > > which calls omap_sram_idle(). omap_sram_idle() eventually > > > causes a 'wfi' instruction to be executed effectively putting > > > the system to sleep. It is assumed that an I/O wake-up event > > > will occur to wake the system up again. This doesn't work on > > > systems that don't support I/O wake-ups (indicated by > > > omap3_has_io_wakeup() returning false). > > > > > > To handle this, follow the same path in omap3_enter_idle() > > > that would be followed if an interrupt were pending. > > > > I don't quite understand this patch. Are you saying that AM3517/3505 > > can't wake from WFI? That would seem odd. > > > > There are other sources of wakeup on the system other than I/O wakeup. > > I/O wakeup only applies to wakeups from the I/O pads when the chip is in > > RETENTION or OFF. And as I understand it, neither of those apply to > > AM3517/3505? > > > > Even if I/O wakeups aren't supported, many of the IP blocks on the system > > should be able to cause the ARM to exit WFI by asserting their > > SWAKEUP lines and raising their interrupt lines. > > I have changed the code to keep everything in the ON state and use > cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything > works well (except networking, see below) when using an mmc-based rootfs. > > The issue is with the emac--it can't wake the system up unless there > is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). > So, when using networking or using an nfs-based rootfs, there are all > kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) > and expecting the emac to wake the system back up won't work. > > How would you like me to proceed (to avoid the wfi in pm_idle & cpuidle)? Just thinking out loud... We could chose whether pm_idle & cpuidle issue a wfi based on whether there is a davinci-emac present. The issue with that is that someday there may be another SoC that has a davinci-emac that can wake up the system. I know cpu_is_xxx() is frowned upon but this does seem like a proper usage of it--the deciding factor really is whether its an am35x or not (and CONFIG_TI_DAVINCI_EMAC is enabled). Mark -- -- To unsubscribe from this list: send the line "unsubscribe 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/RFT 0/3] ARM: OMAP: PM: reduce overhead of pwrdm pre/post transitions
On Tue, Apr 24, 2012 at 5:23 PM, Kevin Hilman wrote: > Here's a first pass attempt to reduce the overhead of the pre/post > transitions by allowing them to be called per powerdomain and making > them conditional on powerdomain transtions. > > This can be used for testing/measurements to see the reduction the > latencies involved in entering/exiting idle with and without these > patches. Seems to have similar effect as my earlier test of simply commenting out pre/post transitions (~4.4MB/s), so this definitely helps. Tested-by: Grazvydas Ignotas -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] OMAP DMA engine conversion
On Tue, Apr 24, 2012 at 7:51 PM, Tony Lindgren wrote: > * Russell King - ARM Linux [120424 03:42]: >> Here's another patch - for the OMAP NAND driver. >> >> One thing this doesn't do is configure up the source/destination bursts, >> which the old code did: >> >> omap_set_dma_dest_burst_mode(info->dma_ch, >> OMAP_DMA_DATA_BURST_16); >> omap_set_dma_src_burst_mode(info->dma_ch, >> OMAP_DMA_DATA_BURST_16); > > Grazvydas, care to give this patch a go? Tested-by: Grazvydas Ignotas for: - SD card connected over transceiver to MMC2 - touchscreen connected over SPI - NAND on GPMC in DMA mode Seems to be working just as they did before, except that I'm not sure SPI was crossing PIO threshold. -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe 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 v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
Dnia wtorek, 24 kwietnia 2012 21:06:59 DebBarma, Tarun Kanti pisze: > Hi Janusz, > > Here is the patch, with attachment as well. I have just tested on > OMAP4 platform. > Testing on other OMAP2+ platforms is pending. In the meantime can you please > validate on OMAP1 platform and confirm? Thanks. Hi, Please give me a day or two. Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe 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 06/12] mmc: omap_hsmmc: remove private DMA API implementation
On Wed, Apr 25, 2012 at 12:51:09AM +0300, Grazvydas Ignotas wrote: > On Mon, Apr 23, 2012 at 7:06 PM, Russell King > wrote: > > Remove the private DMA API implementation from omap_hsmmc, making it > > use entirely the DMA engine API. > > > > Signed-off-by: Russell King > > Since the driver becomes useless without DMA_ENGINE, we probably want > a 'depends on'? I think it's possible to use tweak this to use PIO should DMA_ENGINE not be available - though first we need to sort out all the filter functions and how we select the DMA channels. That's pretty much an open question (which was brought up in my original set of patches) and remains to these ones. How we did this with the AMBA Primecell drivers was to pass in the filter function and filter argument from platform code, allowing the primecell drivers to be used with any DMA engine. That doesn't work with DT though... At the moment, I don't have an answer for this, because of the DT implications here. So, the issue is rather stuck, and as a result I'm just sticking the "extern" declarations for the filter function into drivers that have been converted. -- To unsubscribe from this list: send the line "unsubscribe 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 06/12] mmc: omap_hsmmc: remove private DMA API implementation
On Mon, Apr 23, 2012 at 7:06 PM, Russell King wrote: > Remove the private DMA API implementation from omap_hsmmc, making it > use entirely the DMA engine API. > > Signed-off-by: Russell King Since the driver becomes useless without DMA_ENGINE, we probably want a 'depends on'? -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe 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/12] arm: omap3: Only sleep in cpuidle driver if I/O wake-ups work
On Wed, Apr 11, 2012 at 03:37:47PM -0600, Paul Walmsley wrote: > Hi Hi Paul, Kevin. > On Wed, 11 Apr 2012, Mark A. Greer wrote: > > > From: "Mark A. Greer" > > > > Currently, the OMAP3 cpuidle driver calls omap3_enter_idle() > > which calls omap_sram_idle(). omap_sram_idle() eventually > > causes a 'wfi' instruction to be executed effectively putting > > the system to sleep. It is assumed that an I/O wake-up event > > will occur to wake the system up again. This doesn't work on > > systems that don't support I/O wake-ups (indicated by > > omap3_has_io_wakeup() returning false). > > > > To handle this, follow the same path in omap3_enter_idle() > > that would be followed if an interrupt were pending. > > I don't quite understand this patch. Are you saying that AM3517/3505 > can't wake from WFI? That would seem odd. > > There are other sources of wakeup on the system other than I/O wakeup. > I/O wakeup only applies to wakeups from the I/O pads when the chip is in > RETENTION or OFF. And as I understand it, neither of those apply to > AM3517/3505? > > Even if I/O wakeups aren't supported, many of the IP blocks on the system > should be able to cause the ARM to exit WFI by asserting their > SWAKEUP lines and raising their interrupt lines. I have changed the code to keep everything in the ON state and use cpu_do_idle()--basically a wfi, cpu_v7_do_idle() in this case--and everything works well (except networking, see below) when using an mmc-based rootfs. The issue is with the emac--it can't wake the system up unless there is an irq from the PHY to a wakeup-enabled GPIO (confirmed by h/w engr). So, when using networking or using an nfs-based rootfs, there are all kinds of timeouts, etc. Basically, doing a wfi (i.e., pm_idle or cpuidle) and expecting the emac to wake the system back up won't work. How would you like me to proceed (to avoid the wfi in pm_idle & cpuidle)? Thanks, Mark -- To unsubscribe from this list: send the line "unsubscribe 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 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> From: Santosh Shilimkar
>
> Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode
> Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon
> The issue occurs when EMIF_SDRAM_CONFIG is restored first before
> EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
> is not set properly, we apply the required workaround allowing
> the restore sequence to work properly.
>
> Signed-off-by: Santosh Shilimkar
> [t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
> Signed-off-by: Tero Kristo
> ---
> .../include/mach/ctrl_module_wkup_44xx.h |2 +
> arch/arm/mach-omap2/pm44xx.c | 24
>
> 2 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
> b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
> index a0af9ba..b763a79 100644
> --- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
> +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
> @@ -28,6 +28,8 @@
> #define OMAP4_CTRL_MODULE_WKUP_IP_REVISION 0x
> #define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO 0x0004
> #define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG 0x0010
> +#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG0x0114
> +#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG0x011c
> #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0 0x0460
> #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1 0x0464
> #define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2 0x0468
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 0472921..d4d18d9 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -17,6 +17,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include
>
> #include "common.h"
> #include "clockdomain.h"
> @@ -215,6 +218,27 @@ static int __init omap4_pm_init(void)
>
> pr_err("Power Management for TI OMAP4.\n");
>
> + /*
> + * Work around for OMAP443x Errata i632: "LPDDR2 Corruption After OFF
> + * Mode Transition When CS1 Is Used On EMIF":
> + * Overwrite EMIF1/EMIF2
> + * SECURE_EMIF1_SDRAM_CONFIG2_REG
> + * SECURE_EMIF2_SDRAM_CONFIG2_REG
> + */
> + if (cpu_is_omap443x()) {
> + void __iomem *secure_ctrl_mod;
> +
> + secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
> + BUG_ON(!secure_ctrl_mod);
> +
> + __raw_writel(0x10, secure_ctrl_mod +
> + OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG);
> + __raw_writel(0x10, secure_ctrl_mod +
> + OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG);
According to the erratum description the above registers are used to
restore the EMIFx_SDRAM_CONFIG2 registers. So although the value 0x10,
maybe the value being used for EMIFx_SDRAM_CONFIG2 registers, shouldn't
we read the EMIFx_SDRAM_CONFIG2 registers and store them in the above
registers?
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote: > On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: > >> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) > >> > [ 154.907104] 9fa0: beaf1f04 > >> > 4006be00 000f 000c > >> > [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 > >> > 0007b8d7 > >> > [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 > >> > > >> > [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 > >> > [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- > >> > > >> > Cc: > >> > Signed-off-by: Shubhrajyoti D > > Is this really the correct solution? I do wonder that every driver using > > runtime PM should enable the clocks on their own. That should be done by > > the core, > By core you don't mean the i2c core but the pm layer right? Yes. > > I'd say; it is not unusual that drivers need to write to > > registers in remove(). If it is correct, can I get some acks? > I did see the crash. That was never a doubt. With "correct" I meant "correct solution". > Will wait for the pm experts to comment. Yup. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: >> [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) >> > [ 154.907104] 9fa0: beaf1f04 >> > 4006be00 000f 000c >> > [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 >> > 0007b8d7 >> > [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 >> > >> > [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 >> > [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- >> > >> > Cc: >> > Signed-off-by: Shubhrajyoti D > Is this really the correct solution? I do wonder that every driver using > runtime PM should enable the clocks on their own. That should be done by > the core, By core you don't mean the i2c core but the pm layer right? > I'd say; it is not unusual that drivers need to write to > registers in remove(). If it is correct, can I get some acks? I did see the crash. Will wait for the pm experts to comment. >> > --- >> > drivers/i2c/busses/i2c-omap.c |2 ++ >> > 1 files changed, 2 insertions(+), 0 deletions(-) >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] ARM: OMAP4: PM: save/restore CM L3INSTR registers when MPU hits OSWR/OFF mode
Hi Tero, On 04/20/2012 04:33 AM, Tero Kristo wrote: > From: Rajendra Nayak > > On HS devices on the way out of MPU OSWR and OFF ROM code wrongly > overwrites the CM L3INSTR registers. So to avoid this, save them and > restore on the way out from MPU OSWR/OFF. This appears to be an errata. So, it would be good to state explicitly here that all revisions of all omap4 devices are impacted by this errata. The code implies this but for documentation purposes it would be worth stating. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe 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 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> From: Santosh Shilimkar
>
> The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
> IVA and Tesla execution.
>
> At wakeup from MPU OFF on HS device only (not GP device), when
> restoring the Secure RAM, the ROM Code reconfigures the clocks the
> same way it is done at Cold Reset.
> The IVAHD Clocks and Power Domain settings are:
> IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE
> IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE
> IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO
> IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF
> The TESLA Clocks and Power Domain settings are:
> TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE
> TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO
> TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF
>
> This patch fixes the low power OFF mode code so that the these
> registers are saved and restore across MPU OFF state.
>
> Also because of this limitation, MPU OFF alone is not targeted without
> device OFF to avoid IVAHD and TESLA execution impact
You may wish to state which devices is impacted by this in the changelog.
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Santosh Shilimkar
> [t-kri...@ti.com: added omap4 pm errata support]
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 53
> +
> arch/arm/mach-omap2/pm.h |2 +
> arch/arm/mach-omap2/pm44xx.c |9 +
> 3 files changed, 64 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index b9a2cc7..208d4a4 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -52,6 +52,7 @@
>
> #include
>
> +#include "iomap.h"
> #include "common.h"
> #include "omap4-sar-layout.h"
> #include "pm.h"
> @@ -76,6 +77,24 @@ static DEFINE_PER_CPU(struct omap4_cpu_pm_info,
> omap4_pm_info);
> static struct powerdomain *mpuss_pd;
> static void __iomem *sar_base;
>
> +struct reg_tuple {
> + void __iomem *addr;
> + u32 val;
> +};
> +
> +static struct reg_tuple tesla_reg[] = {
> + {.addr = OMAP4430_CM_TESLA_CLKSTCTRL},
> + {.addr = OMAP4430_CM_TESLA_TESLA_CLKCTRL},
> + {.addr = OMAP4430_PM_TESLA_PWRSTCTRL},
> +};
> +
> +static struct reg_tuple ivahd_reg[] = {
> + {.addr = OMAP4430_CM_IVAHD_CLKSTCTRL},
> + {.addr = OMAP4430_CM_IVAHD_IVAHD_CLKCTRL},
> + {.addr = OMAP4430_CM_IVAHD_SL2_CLKCTRL},
> + {.addr = OMAP4430_PM_IVAHD_PWRSTCTRL}
> +};
> +
> /*
> * Program the wakeup routine address for the CPU0 and CPU1
> * used for OFF or DORMANT wakeup.
> @@ -215,6 +234,34 @@ static void save_l2x0_context(void)
> {}
> #endif
>
> +static inline void save_ivahd_tesla_regs(void)
> +{
> + int i;
> +
> + if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(tesla_reg); i++)
> + tesla_reg[i].val = __raw_readl(tesla_reg[i].addr);
> +
> + for (i = 0; i < ARRAY_SIZE(ivahd_reg); i++)
> + ivahd_reg[i].val = __raw_readl(ivahd_reg[i].addr);
> +}
> +
> +static inline void restore_ivahd_tesla_regs(void)
> +{
> + int i;
> +
> + if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(tesla_reg); i++)
> + __raw_writel(tesla_reg[i].val, tesla_reg[i].addr);
> +
> + for (i = 0; i < ARRAY_SIZE(ivahd_reg); i++)
> + __raw_writel(ivahd_reg[i].val, ivahd_reg[i].addr);
> +}
> +
> /**
> * omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
> * The purpose of this function is to manage low power programming
> @@ -273,11 +320,14 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> omap_sar_overwrite();
> omap4_cm_prepare_off();
> omap4_dpll_prepare_off();
> + save_ivahd_tesla_regs();
> save_state = 3;
> } else if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET) &&
> (pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF)) {
> + save_ivahd_tesla_regs();
> save_state = 2;
> } else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
> + save_ivahd_tesla_regs();
> save_state = 3;
> }
>
> @@ -302,6 +352,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> wakeup_cpu = smp_processor_id();
> set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
>
> + if (omap4_mpuss_read_prev_context_state())
> + restore_ivahd_tesla_regs();
> +
> if (omap4_device_prev_state_off()) {
> omap4_dpll_resume_off();
> omap4_cm_resume_off();
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index e78ec63..051aeb9 100644
> --- a/arch/ar
Re: [PATCH 08/19] ARM: OMAP4: PM: Add device-off support
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
> This patch adds device off support to OMAP4 device type.
>
> OFF mode is disabled by default, however, there are two ways to enable
> OFF mode:
> a) In the board file, call omap4_pm_off_mode_enable(1)
> b) Enable OFF mode using the debugfs entry
> echo "1">/sys/kernel/debug/pm_debug/enable_off_mode
> (conversely echo '0' will disable it as well).
>
> Signed-off-by: Santosh Shilimkar
> [t-kri...@ti.com: largely re-structured the code]
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/omap-mpuss-lowpower.c | 24 ++-
> arch/arm/mach-omap2/omap-wakeupgen.c | 47 +++-
> arch/arm/mach-omap2/pm-debug.c| 17 +--
> arch/arm/mach-omap2/pm.h | 28 ++--
> arch/arm/mach-omap2/pm44xx.c | 45 +++
> arch/arm/mach-omap2/prm44xx.c | 66
> +
> 6 files changed, 214 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> index e02c082..b9a2cc7 100644
> --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
> @@ -60,6 +60,7 @@
> #include "prcm44xx.h"
> #include "prm44xx.h"
> #include "prm-regbits-44xx.h"
> +#include "cm44xx.h"
>
> #ifdef CONFIG_SMP
>
> @@ -232,6 +233,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> {
> unsigned int save_state = 0;
> unsigned int wakeup_cpu;
> + int ret;
>
> if (omap_rev() == OMAP4430_REV_ES1_0)
> return -ENXIO;
> @@ -263,9 +265,21 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
>* In MPUSS OSWR or device OFF, interrupt controller contest is lost.
>*/
> mpuss_clear_prev_logic_pwrst();
> - if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET) &&
> - (pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF))
> + if (omap4_device_next_state_off()) {
> + /* Save the device context to SAR RAM */
> + ret = omap_sar_save();
> + if (ret)
> + return ret;
Is it safe to simply return here? I was not sure if we need to call
pwrdm_post_transition, given that we have already called
pwrdm_pre_transition on entry.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: panda: add statics to remove warnings
* Tomi Valkeinen [120423 00:43]:
> Add statics to board-omap4-panda.c's internal functions and data
> structures to remove warnings.
Care to update with the warnings produced?
Tony
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/mach-omap2/board-omap4panda.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c
> b/arch/arm/mach-omap2/board-omap4panda.c
> index 1b782ba..8216e5f 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -231,7 +231,7 @@ static struct platform_device omap_vwlan_device = {
> },
> };
>
> -struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
> +static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
> /* PANDA ref clock is 38.4 MHz */
> .board_ref_clock = 2,
> };
> @@ -438,7 +438,7 @@ static struct panel_dvi_platform_data omap4_dvi_panel = {
> .i2c_bus_num = 3,
> };
>
> -struct omap_dss_device omap4_panda_dvi_device = {
> +static struct omap_dss_device omap4_panda_dvi_device = {
> .type = OMAP_DISPLAY_TYPE_DPI,
> .name = "dvi",
> .driver_name= "dvi",
> @@ -448,7 +448,7 @@ struct omap_dss_device omap4_panda_dvi_device = {
> .channel= OMAP_DSS_CHANNEL_LCD2,
> };
>
> -int __init omap4_panda_dvi_init(void)
> +static int __init omap4_panda_dvi_init(void)
> {
> int r;
>
> @@ -509,7 +509,7 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
> .default_device = &omap4_panda_dvi_device,
> };
>
> -void __init omap4_panda_display_init(void)
> +static void __init omap4_panda_display_init(void)
> {
> int r;
>
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On 4/24/2012 4:46 PM, Tero Kristo wrote: On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: From: Rajendra Nayak On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relyed on the power domain level context status. Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. Yeah, but still, every OMAP4 IPs are supporting that except two of them I guess, so it is a pity to add that to every IPs. We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not supporting that. Since OMAP 2 & 3 does not have this feature at all, we can check on the cpu revision. I think the issue raised by Rajendra was about AM35xx that looks like an OMAP3 variant but does have these registers like an OMAP4 variant:-( Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3EVM not booting on l-o master
Hi Tero, Tero Kristo writes: > On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote: >> Hi Paul, >> >> On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote: >> > Perhaps you might be willing to add some debugging to omap_mux_late_init() >> > to find out what part of that function is causing it to hang? >> >> It is getting hung as interrupt handler "omap_hwmod_mux_handle_irq" >> is being repeatedly called. >> > > Hi Afzal, > > can you try the attached patch with this branch and omap3evm board? I > don't have the board myself so I can't test it myself (I tested this > with omap3beagle and it works with that one.) Thanks for digging into this problem and coming up with a proposed solution. Some questions below... > > -Tero > > > From 26733dd988ccc9e72355a39e01b2d6e9215a892d Mon Sep 17 00:00:00 2001 > From: Tero Kristo > Date: Mon, 23 Apr 2012 12:14:46 +0300 > Subject: [PATCH] ARM: OMAP3: PM: move wakeup event ack to hwmod_io handler > > PRCM IO interrupts are handled with a shared interrupt handler logic. > Currently hwmod_io is processing the actual event, but the acking > of the IO wakeups is done from the PM code with a separate handler. > If a wakeup event is detected during init before the PM code is in > place, the interrupt handler can hang in an infinite loop. Fix this > by removing the pm_io handler, and calling its functionality from > within the hwmod_io handler. This fix applies only to OMAP3, as > OMAP4 does not have similar wakeup handling logic. > > Signed-off-by: Tero Kristo Doesn't this mean that even on a !PM kernel that IO events might still be firing for nothing? Seems like it would be better to ensure that these interrupts are just disabled until the PM core initializes and can enable them. 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
OMAPDSS basic concepts
Hello All, I'm pretty new to the OMAP DSS and would like to understand how it works under Linux/Android. I have read the TRM and understood that the DSS uses DMA to move pixels from the main memory to several hardware pipelines, with each burst of a few lines. But I am wondering - 1 - when will DSS start to move a new frame from the framebuffer to hardware pipelines? Is it triggered by some timer, or by some signals from the LCD panel (e.g., VSYNC)? 2 - is it possible to measure/estimate the time taken in DMAing a frame? I also looked into the kernel doc and source code but found no answer. I appreciate any comments or pointers. Thanks a lot! -Felix -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] OMAP DMA engine conversion
* Russell King - ARM Linux [120424 03:42]:
> Here's another patch - for the OMAP NAND driver.
>
> One thing this doesn't do is configure up the source/destination bursts,
> which the old code did:
>
> omap_set_dma_dest_burst_mode(info->dma_ch,
> OMAP_DMA_DATA_BURST_16);
> omap_set_dma_src_burst_mode(info->dma_ch,
> OMAP_DMA_DATA_BURST_16);
Grazvydas, care to give this patch a go?
> In dma-engine speak, I'm using "burst" for the number of elements to
> transfer for each frame, with frame sync in place (in other words, the
> number of transfers to occur for every assertion of the DMA request.)
> That's how burst is defined on other DMA hardware, so I'm not entirely
> sure at the moment how critical (or what) the above bursts are doing,
> whether they're configuring the memory side of the transfer or not.
> I'll take a deeper look into that this evening, but in the mean time,
> what's below should be a direct conversion.
For omaps it enables multiple access.
> MTD does have this weirdness that it uses vmalloc regions and passes
> addresses in vmalloc regions into drivers - I've left that hack in but
> it is _highly_ undefined whether the DMA activity would be visible via
> the vmalloc mapping as things currently stand. (You're probably going
> to be okay with non-aliasing VIPT caches, but VIVT and aliasing VIPT
> caches are potential random data corruption candidates.) That's a
> short-coming across many MTD drivers, one which needs sorting out across
> the board.
>
> drivers/mtd/nand/omap2.c | 93
> +-
> 1 files changed, 92 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index c2b0bba..bd4ed08 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -9,6 +9,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -119,6 +120,7 @@ struct omap_nand_info {
> int gpmc_cs;
> unsigned long phys_base;
> struct completion comp;
> + struct dma_chan *dma;
> int dma_ch;
> int gpmc_irq;
> enum {
> @@ -336,6 +338,10 @@ static void omap_nand_dma_cb(int lch, u16 ch_status,
> void *data)
> {
> complete((struct completion *) data);
> }
> +static void omap_nand_dma_callback(void *data)
> +{
> + complete((struct completion *) data);
> +}
>
> /*
> * omap_nand_dma_transfer: configer and start dma transfer
> @@ -373,6 +379,56 @@ static inline int omap_nand_dma_transfer(struct mtd_info
> *mtd, void *addr,
> addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
> }
>
> + if (info->dma) {
> + struct dma_async_tx_descriptor *tx;
> + struct scatterlist sg;
> + unsigned n;
> +
> + sg_init_one(&sg, addr, len);
> + n = dma_map_sg(info->dma->device->dev, &sg, 1, dir);
> + if (n == 0) {
> + dev_err(&info->pdev->dev,
> + "Couldn't DMA map a %d byte buffer\n", len);
> + goto out_copy;
> + }
> +
> + tx = dmaengine_prep_slave_sg(info->dma, &sg, n,
> + is_write ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!tx) {
> + dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
> + goto out_copy;
> + }
> + tx->callback = omap_nand_dma_callback;
> + tx->callback_param = &info->comp;
> + dmaengine_submit(tx);
> +
> + /* configure and start prefetch transfer */
> + ret = gpmc_prefetch_enable(info->gpmc_cs,
> + PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write);
> + if (ret) {
> + /* PFPW engine is busy, use cpu copy method */
> + dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
> + goto out_copy;
> + }
> +
> + init_completion(&info->comp);
> + dma_async_issue_pending(info->dma);
> +
> + /* setup and start DMA using dma_addr */
> + wait_for_completion(&info->comp);
> + tim = 0;
> + limit = (loops_per_jiffy *
> msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
> + while (gpmc_read_status(GPMC_PREFETCH_COUNT) && (tim++ < limit))
> + cpu_relax();
> +
> + /* disable and stop the PFPW engine */
> + gpmc_prefetch_reset(info->gpmc_cs);
> +
> + dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
> + return 0;
> + }
> +
> dma_addr = dma_map_single(&info->pde
Re: HSI: any status updates on omap_ssi?
* Sebastian Reichel [120424 09:31]: > On Tue, Apr 24, 2012 at 08:23:16AM -0700, Tony Lindgren wrote: > > * Sebastian Reichel [120421 04:26]: > > > Hi, > > > > > > Missing omap_ssi support is currently the most important missing > > > feature, to make the mainline kernel on the Nokia N900 useful, see > > > also [0]. > > > > > > Can you prepare SSI inclusion into the mainline kernel, now that HSI > > > has been pulled into 3.4? Do you think we get SSI support in 3.5? > > > > Also FYI related to n900, you need to have bce492c0 (ARM: OMAP2+: UART: Fix > > incorrect population of default uart pads) applied after v3.1 if using > > CONFIG_OMAP_MUX to avoid some SSI pins getting wronly muxed to UART. > > Thanks for the info. > > > Then to verify, the hw floating point error you reported a while back > > with omap2plus_defconfig got resolved, right? > > I have not tried again since then. The error only occured, if the > kernel has been built with OMAP2 support. It does not show up on > kernels, which support only OMAP3/OMAP4. I believe last time I checked it few weeks back it worked correctly with omap2 compiled in. Or else there are some other .config options needed too. Care to verify that? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] ARM: OMAP4: PM: update ROM return address for OSWR and OFF
* Tero Kristo [120420 02:39]:
> @@ -384,6 +386,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
> power_state)
> set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
>
> if (omap4_mpuss_read_prev_context_state()) {
> + /*
> + * Dummy dispatcher call after OSWR and OFF
> + * Restore the right return Kernel address (with MMU on) for
> + * subsequent calls to secure ROM. Otherwise the return address
> + * will be to a PA return address and the system will hang.
> + */
> + if (omap_type() != OMAP2_DEVICE_TYPE_GP)
> + omap_secure_dispatcher(OMAP4_PPA_SERVICE_0,
> +FLAG_START_CRITICAL,
> +0, 0, 0, 0, 0);
> +
> restore_ivahd_tesla_regs();
> restore_l3instr_regs();
This SoC test here too should be only done once during init.
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 06/19] ARM: OMAP4: Auto generate SAR layout contents
* Tero Kristo [120420 02:38]:
> -void omap4_sar_overwrite(void)
> +void omap_sar_overwrite(void)
> {
> u32 val = 0;
> - u32 offset = 0;
> + u32 usb_offset = 0x2ec;
> + u32 usb_offset2 = 0x91c;
>
> - if (cpu_is_omap446x())
> - offset = 0x04;
> + if (cpu_is_omap446x()) {
> + usb_offset = 0x2f4;
> + usb_offset2 = 0x920;
> + }
Here too you should initialized these during __init. Otherwise
we'll end up piling more and more if else cpu_is_omap for
future omaps that again might change the offsets.
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 05/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF
* Tero Kristo [120420 02:39]:
> +
> +static int omap4_sar_not_accessible(void)
> +{
> + u32 usbhost_state, usbtll_state;
> +
> + /*
> + * Make sure that USB host and TLL modules are not
> + * enabled before attempting to save the context
> + * registers, otherwise this will trigger an exception.
> + */
> + usbhost_state = omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
> +OMAP4430_CM2_L3INIT_INST,
> +
> OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET)
> + & (OMAP4430_STBYST_MASK | OMAP4430_IDLEST_MASK);
> +
> + usbtll_state = omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
> + OMAP4430_CM2_L3INIT_INST,
> +
> OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET)
> + & OMAP4430_IDLEST_MASK;
Formatting here looks bad, maybe just do it in separate steps:
usbhost_state = omap4_cminst...
usbhost_state &= OMAP4430_STBYST_MASK | OMAP4430_IDLEST_MASK;
...
> + /*
> + * Not supported on ES1.0 silicon
> + */
> + if (omap_rev() == OMAP4430_REV_ES1_0) {
> + WARN_ONCE(1, "omap4: SAR backup not supported on ES1.0 ..\n");
> + return -ENODEV;
> + }
Everytime there's SoC/hardware revision detection in a non __init function,
something is most likely wrong.
> +void omap4_sar_overwrite(void)
> +{
> + u32 val = 0;
> + u32 offset = 0;
> +
> + if (cpu_is_omap446x())
> + offset = 0x04;
Here too.
> +static int __init omap4_sar_ram_init(void)
> +{
> + /*
> + * To avoid code running on other OMAPs in
> + * multi-omap builds
> + */
> + if (!cpu_is_omap44xx())
> + return -ENODEV;
You should configure things here instead by setting function
pointers or variables.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HSI: any status updates on omap_ssi?
On Tue, Apr 24, 2012 at 08:23:16AM -0700, Tony Lindgren wrote: > * Sebastian Reichel [120421 04:26]: > > Hi, > > > > Missing omap_ssi support is currently the most important missing > > feature, to make the mainline kernel on the Nokia N900 useful, see > > also [0]. > > > > Can you prepare SSI inclusion into the mainline kernel, now that HSI > > has been pulled into 3.4? Do you think we get SSI support in 3.5? > > Also FYI related to n900, you need to have bce492c0 (ARM: OMAP2+: UART: Fix > incorrect population of default uart pads) applied after v3.1 if using > CONFIG_OMAP_MUX to avoid some SSI pins getting wronly muxed to UART. Thanks for the info. > Then to verify, the hw floating point error you reported a while back > with omap2plus_defconfig got resolved, right? I have not tried again since then. The error only occured, if the kernel has been built with OMAP2 support. It does not show up on kernels, which support only OMAP3/OMAP4. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Hi,
* Vaibhav Hiremath [120424 02:54]:
> Current OMAP code supports couple of clocksource options based
> on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
> and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
> So there can be 3 options -
>
> 1. 32KHz sync-timer
> 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
> 3. 32KHz based gptimer.
>
> The optional gptimer based clocksource was added so that it can
> give the high precision than sync-timer, so expected usage was 2
> and not 3.
> Unfortunately option 2, clocksource doesn't meet the requirement of
> free-running clock as per clocksource need. It stops in low power states
> when sys_clock is cut. That makes gptimer based clocksource option
> useless for OMAP2/3/4 devices with sys_clock as a clock input.
> Option 3 will still work but it is no better than 32K sync-timer
> based clocksource.
For some cases sys clock based timer is still valid if you don't
care about PM. In that case deeper idle states need to be disabled,
not the timer as discussed earlier. Please update the comments accordingly.
> So ideally we can kill the gptimer based clocksource option but there
> are some OMAP based derivative SoCs like AM33XX which doesn't have
> 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
> clocksource.
Maybe just say: "We must support both sync timer and gptimer based
clocksource as some AM33XX hardware does not have the sync timer."
> Considering above, make sync-timer and gptimer clocksource runtime
> selectable so that both OMAP and AM continue to use the same code.
>
> Also, in order to precisely configure/setup sched_clock for given
> clocksource, decision has to be made early enough in boot sequence.
>
> So, the solution is,
>
> Use kernel parameter ("clocksource=") to override
Maybe say: "Use standard kernel parameter ("clocksource=")..."
> --- a/arch/arm/mach-omap1/timer32k.c
> +++ b/arch/arm/mach-omap1/timer32k.c
> @@ -71,6 +71,7 @@
>
> /* 16xx specific defines */
> #define OMAP1_32K_TIMER_BASE 0xfffb9000
> +#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
> #define OMAP1_32K_TIMER_CR 0x08
> #define OMAP1_32K_TIMER_TVR 0x00
> #define OMAP1_32K_TIMER_TCR 0x04
> @@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
> */
> bool __init omap_32k_timer_init(void)
> {
> - omap_init_clocksource_32k();
> + u32 pbase;
> +
> + pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
> + omap_init_clocksource_32k(pbase, SZ_1K);
> omap_init_32k_timer();
>
> return true;
Has this patch been tested on omap1?
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -510,3 +540,28 @@ static int __init omap2_dm_timer_init(void)
> return 0;
> }
> arch_initcall(omap2_dm_timer_init);
> +
> +/**
> + * omap2_override_clocksource - clocksource override with user configuration
> + *
> + * Allows user to override default clocksource, using kernel parameter
> + * clocksource="gp timer"
> + *
> + * Note that, here we are using same standard kernel parameter
> "clocksource=",
> + * and not introducing any OMAP specific interface.
> + */
> +static int __init omap2_override_clocksource(char *str)
> +{
> + if (!str)
> + return 0;
> + /*
> + * For OMAP architecture, we only have two options
> + *- sync_32k (default)
> + *- gp timer
> + */
> + if (!strcmp(str, "gp timer"))
> + use_gptimer_clksrc = true;
> +
> + return 0;
> +}
> +early_param("clocksource", omap2_override_clocksource);
Should say "For omap2plus architectures" and should say three options.
If the sys clock based timer is not currently supported, please mention
that in the comments.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
* Govindraj.R [120424 07:12]:
> From: "Govindraj.R"
>
> On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
> PM_WKEN1_CORE/PM_WKEN_PER regs.
>
> Add api to control the module level wakeup mechanism from info provided from
> hwmod data.
>
> omap_hwmod_enable/disable_wakeup is used from serial.c which should
> configure PM_WKEN register to enable or disable the module level wakeup.
>
> Cc: Tero Kristo
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Kevin Hilman
> Cc: Benoit Cousson
> Cc: Rajendra Nayak
> Cc: Santosh Shilimkar
> Signed-off-by: Govindraj.R
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 22 ++
> arch/arm/mach-omap2/prm2xxx_3xxx.c | 16
> arch/arm/mach-omap2/prm2xxx_3xxx.h |9 +
> 3 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index 2c27fdb..4f10619 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -382,6 +382,26 @@ static int _set_module_autoidle(struct omap_hwmod *oh,
> u8 autoidle,
> }
>
> /**
> + * _enable_module_level_wakeup - enable/disable module level wakeup on hwmod.
> + * @oh: struct omap_hwmod *
> + * @set_wake: bool value indicating to set (true) or clear (false) module
> level
> + * wakeup enable
> + *
> + * Set or clear the module level wakeup capability the
> + * hwmod @oh. This function configures th PM_WKEN reg bits if they
> + * are available from hwmod. No return value
> + */
> +static void _enable_module_level_wakeup(struct omap_hwmod *oh, bool set_wake)
> +{
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + omap2_prm_enable_prcm_module_wakeup(
> + oh->prcm.omap2.module_offs,
> + oh->prcm.omap2.prcm_reg_id,
> + oh->prcm.omap2.idlest_idle_bit,
> + set_wake);
> +}
Please don't sprinkle cpu_is_omap tests into code that gets called multiple
times.
Initialize things properly during init instead.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
* DebBarma, Tarun Kanti [120424 08:40]: > Hi Janusz, > > On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti > wrote: > > On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik > > wrote: > >> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: > >>> With register offsets now defined for respective OMAP versions we can get > >>> rid > >>> of cpu_class_* checks. This function now has common initialization code > >>> for > >>> all OMAP versions... > >>> > >>> Signed-off-by: Tarun Kanti DebBarma > >>> Signed-off-by: Charulatha V > >>> Reviewed-by: Santosh Shilimkar > >>> Acked-by: Tony Lindgren > >> > >> Sorry for being so late with my comment for chanes already present in > >> mainline, but this patch breaks GPIO on Amstrad Delta at least, and I > >> have neither enough spare time nor enough experience with non OMAP1 > >> machines to provide a solution myself. > > Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are > > overwritten. > > Also looks like there is issue in making distinction between omap15xx > > and omap16xx. > > I will post a patch and you can help me testing it in OMAP1 platform. > > Thanks for pointing this out. ... > Here is the patch, with attachment as well. I have just tested on > OMAP4 platform. > Testing on other OMAP2+ platforms is pending. In the meantime can you please > validate on OMAP1 platform and confirm? Thanks. > -- > Tarun > > From: Tarun Kanti DebBarma > Date: Tue, 24 Apr 2012 20:34:32 +0530 > Subject: [PATCH] gpio/omap: fix omap1 register overwrite in omap_gpio_mod_init > > Initialization of irqenable, irqstatus registers is the common > operation done in this function for all OMAP platforms, viz. > OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register > was overwriting the correctly programmed OMAP1 value at the > beginning. As a result, even though it worked on OMAP2+ > platforms it was breaking OMAP1 functionality. Sounds like the original patch was never tested on omap1? > On closer observation it is found that the first _gpio_rmw() > which is supposedly done to take care of OMAP1 platform is > generic enough and takes care of OMAP2+ platform as well. > Therefore remove the latter _gpio_rmw() to irqenable as they > are redundant. > > Also, changing the sequence and logic of initializing the > irqstatus. Please mention also the breaking commit here and get this fix merged as a regression as soon as it's tested for the current -rc series. Regards, Tony > Signed-off-by: Tarun Kanti DebBarma > --- > drivers/gpio/gpio-omap.c |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index 1adc2ec..b8f01c1 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -964,11 +964,8 @@ static void omap_gpio_mod_init(struct gpio_bank *bank) > return; > } > > + _gpio_rmw(base, bank->regs->irqstatus, l, > bank->regs->irqenable_inv == 0 ); > _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->irqenable_inv); > - _gpio_rmw(base, bank->regs->irqstatus, l, > - bank->regs->irqenable_inv == false); > - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->debounce_en != > 0); > - _gpio_rmw(base, bank->regs->irqenable, l, bank->regs->ctrl != 0); > if (bank->regs->debounce_en) > _gpio_rmw(base, bank->regs->debounce_en, 0, 1); > > -- > 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
Hi Janusz,
On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti
wrote:
> On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik
> wrote:
>> On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote:
>>> With register offsets now defined for respective OMAP versions we can get
>>> rid
>>> of cpu_class_* checks. This function now has common initialization code for
>>> all OMAP versions...
>>>
>>> Signed-off-by: Tarun Kanti DebBarma
>>> Signed-off-by: Charulatha V
>>> Reviewed-by: Santosh Shilimkar
>>> Acked-by: Tony Lindgren
>>
>> Sorry for being so late with my comment for chanes already present in
>> mainline, but this patch breaks GPIO on Amstrad Delta at least, and I
>> have neither enough spare time nor enough experience with non OMAP1
>> machines to provide a solution myself.
> Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are
> overwritten.
> Also looks like there is issue in making distinction between omap15xx
> and omap16xx.
> I will post a patch and you can help me testing it in OMAP1 platform.
> Thanks for pointing this out.
> --
> Tarun
>>
>>> ---
>>> arch/arm/mach-omap1/gpio16xx.c | 35 +-
>>> drivers/gpio/gpio-omap.c | 77
>>>
>>> 2 files changed, 57 insertions(+), 55 deletions(-)
>> ...
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index f39d9e4..a948351 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>> ...
>>> @@ -898,62 +896,30 @@ static void __init omap_gpio_show_rev(struct
>>> gpio_bank *bank)
>>> */
>>> static struct lock_class_key gpio_lock_class;
>>>
>>> -/* TODO: Cleanup cpu_is_* checks */
>>> static void omap_gpio_mod_init(struct gpio_bank *bank)
>>> {
>>> - if (cpu_class_is_omap2()) {
>>> - if (cpu_is_omap44xx()) {
>>> - __raw_writel(0x, bank->base +
>>> - OMAP4_GPIO_IRQSTATUSCLR0);
>>> - __raw_writel(0x, bank->base +
>>> - OMAP4_GPIO_DEBOUNCENABLE);
>>> - /* Initialize interface clk ungated, module enabled */
>>> - __raw_writel(0, bank->base + OMAP4_GPIO_CTRL);
>>> - } else if (cpu_is_omap34xx()) {
>>> - __raw_writel(0x, bank->base +
>>> - OMAP24XX_GPIO_IRQENABLE1);
>>> - __raw_writel(0x, bank->base +
>>> - OMAP24XX_GPIO_IRQSTATUS1);
>>> - __raw_writel(0x, bank->base +
>>> - OMAP24XX_GPIO_DEBOUNCE_EN);
>>> -
>>> - /* Initialize interface clk ungated, module enabled */
>>> - __raw_writel(0, bank->base + OMAP24XX_GPIO_CTRL);
>>> - }
>>> - } else if (cpu_class_is_omap1()) {
>>> - if (bank_is_mpuio(bank)) {
>>> - __raw_writew(0x, bank->base +
>>> - OMAP_MPUIO_GPIO_MASKIT / bank->stride);
>>> - mpuio_init(bank);
>>> - }
>>> - if (cpu_is_omap15xx() && bank->method == METHOD_GPIO_1510) {
>>> - __raw_writew(0x, bank->base
>>> - + OMAP1510_GPIO_INT_MASK);
>>> - __raw_writew(0x, bank->base
>>> - + OMAP1510_GPIO_INT_STATUS);
>>> - }
>>> - if (cpu_is_omap16xx() && bank->method == METHOD_GPIO_1610) {
>>> - __raw_writew(0x, bank->base
>>> - + OMAP1610_GPIO_IRQENABLE1);
>>> - __raw_writew(0x, bank->base
>>> - + OMAP1610_GPIO_IRQSTATUS1);
>>> - __raw_writew(0x0014, bank->base
>>> - + OMAP1610_GPIO_SYSCONFIG);
>>> + void __iomem *base = bank->base;
>>> + u32 l = 0x;
>>>
>>> - /*
>>> - * Enable system clock for GPIO module.
>>> - * The CAM_CLK_CTRL *is* really the right place.
>>> - */
>>> - omap_writel(omap_readl(ULPD_CAM_CLK_CTRL) | 0x04,
>>> - ULPD_CAM_CLK_CTRL);
>>> - }
>>> - if (cpu_is_omap7xx() && bank->method == METHOD_GPIO_7XX) {
>>> - __raw_writel(0x, bank->base
>>> - + OMAP7XX_GPIO_INT_MASK);
>>> - __raw_writel(0x, bank->base
>>> - + OMAP7XX_GPIO_INT_STATUS);
>>> - }
>>> + if (bank->width == 16)
>>> + l = 0x;
>>> +
>>> + if (bank_is_mpuio(bank)) {
>>> + __
Re: HSI: any status updates on omap_ssi?
* Sebastian Reichel [120421 04:26]: > Hi, > > Missing omap_ssi support is currently the most important missing > feature, to make the mainline kernel on the Nokia N900 useful, see > also [0]. > > Can you prepare SSI inclusion into the mainline kernel, now that HSI > has been pulled into 3.4? Do you think we get SSI support in 3.5? Also FYI related to n900, you need to have bce492c0 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads) applied after v3.1 if using CONFIG_OMAP_MUX to avoid some SSI pins getting wronly muxed to UART. Then to verify, the hw floating point error you reported a while back with omap2plus_defconfig got resolved, right? Regards, Tony > [0] http://elinux.org/N900 -- To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote: > Hi Tero, > > On 04/20/2012 04:19 AM, Tero Kristo wrote: > > From: Rajendra Nayak > > > > On OMAP4 most modules/hwmods support module level context status. On > > OMAP3 and earlier, we relyed on the power domain level context status. > > Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such > > hwmods already have a valid 'context_offs' populated in .prcm structure. > > Is it necessary to add another flag? Can't we just check if context_offs > is non-zero? Would save adding a lot more lines to an already large file > :-) Actually one of the older versions of this patch was just checking against a non-zero value, but it was decided to be changed as potentially the context_offs can be zero even if it is a valid offset. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
> +/**
> + * omap4_dpll_print_reg - dump out a single DPLL register value
> + * @dpll_reg: register to dump
> + * @name: name of the register
> + * @tuple: content of the register
> + *
> + * Helper dump function to print out a DPLL register value in case
> + * of restore failures.
> + */
> +static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
> *name,
> + struct dpll_reg *tuple)
> +{
> + if (tuple->offset)
> + pr_warn("%s - Address offset = 0x%08x, value=0x%08x\n", name,
> + tuple->offset, tuple->val);
Minor nit-pick here ...
1. Offset is 16-bits and so we can just have "offset = 0x%04x"
2. Consider dropping "Address" from "Address offset"
3. Can we be consistent in our spaces for "offset = " and "value="?
> +}
> +
> +/*
> + * omap4_dpll_dump_regs - dump out DPLL registers
> + * @dpll_reg: DPLL to dump
> + *
> + * Dump out the contents of the registers for a DPLL. Called if a
> + * restore for DPLL fails to lock.
> + */
> +static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
> +{
> + pr_warn("%s: Unable to lock dpll %s[part=%x inst=%x]:\n",
> + __func__, dpll_reg->name, dpll_reg->mod_partition,
> + dpll_reg->mod_inst);
> + omap4_dpll_print_reg(dpll_reg, "clksel", &dpll_reg->clksel);
> + omap4_dpll_print_reg(dpll_reg, "div_m2", &dpll_reg->div_m2);
> + omap4_dpll_print_reg(dpll_reg, "div_m3", &dpll_reg->div_m3);
> + omap4_dpll_print_reg(dpll_reg, "div_m4", &dpll_reg->div_m4);
> + omap4_dpll_print_reg(dpll_reg, "div_m5", &dpll_reg->div_m5);
> + omap4_dpll_print_reg(dpll_reg, "div_m6", &dpll_reg->div_m6);
> + omap4_dpll_print_reg(dpll_reg, "div_m7", &dpll_reg->div_m7);
> + omap4_dpll_print_reg(dpll_reg, "clkdcoldo", &dpll_reg->clkdcoldo);
> + omap4_dpll_print_reg(dpll_reg, "clkmode", &dpll_reg->clkmode);
> + omap4_dpll_print_reg(dpll_reg, "autoidle", &dpll_reg->autoidle);
> + if (dpll_reg->idlest.offset)
> + pr_warn("idlest - Address offset = 0x%08x, before val=0x%08x"
> + " after = 0x%08x\n", dpll_reg->idlest.offset,
> + dpll_reg->idlest.val,
> + omap4_dpll_read_reg(dpll_reg, &dpll_reg->idlest));
Nit-pick ...
1. Same comments as above
2. Consider dropping "Address offset" altogether here as we print
"idlest" the offset should be implied.
3. Also can we be consistent in our naming of "before val and "after"?
For example, "val before =" and "val now = ".
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
Hi Tero, On 04/20/2012 04:19 AM, Tero Kristo wrote: > From: Rajendra Nayak > > On OMAP4 most modules/hwmods support module level context status. On > OMAP3 and earlier, we relyed on the power domain level context status. > Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such > hwmods already have a valid 'context_offs' populated in .prcm structure. Is it necessary to add another flag? Can't we just check if context_offs is non-zero? Would save adding a lot more lines to an already large file :-) Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe 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/RFT 1/3] ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
On Tue, Apr 24, 2012 at 7:53 PM, Kevin Hilman wrote: > Iteration over all power domains in the idle path is unnecessary since > only power domains that are transitioning need to be accounted for. > Also PRCM register accesses are known to be expensive, so the > additional latency added to the idle path is signficiant. > > In order allow the pre/post transitions to be isolated and called > per-pwrdm, change the API so passing in a specific power domain will > trigger the pre/post transtion accounting for only that specific power > domain. Passing NULL means iterating over all power domains as is > current behavior. > > Signed-off-by: Kevin Hilman > --- > arch/arm/mach-omap2/omap-mpuss-lowpower.c | 4 ++-- > arch/arm/mach-omap2/pm34xx.c | 4 ++-- > arch/arm/mach-omap2/powerdomain.c | 16 > arch/arm/mach-omap2/powerdomain.h | 4 ++-- > 4 files changed, 18 insertions(+), 10 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c > b/arch/arm/mach-omap2/omap-mpuss-lowpower.c > index 13670aa..e35a86b 100644 > --- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c > +++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c > @@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int > power_state) > return -ENXIO; > } > > - pwrdm_pre_transition(); > + pwrdm_pre_transition(NULL); > > /* > * Check MPUSS next state and save interrupt controller if needed. > @@ -287,7 +287,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int > power_state) > wakeup_cpu = smp_processor_id(); > set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON); > > - pwrdm_post_transition(); > + pwrdm_post_transition(NULL); > > return 0; > } Now since the pwrdm_[pre\post]_transition() takes power domain pointer, OMAP4 can limit this to CPU and MPUSS PD's only. Will create that patch on top of this series and test it out. Thanks for the API change. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
Jean Pihet writes: > Hi Grazvydas, Kevin, > > I did some gather some performance measurements and statistics using > custom tracepoints in __omap3_enter_idle. > All the details are at > http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis > . This is great, thanks. [...] > Here are the results (BW in MB/s) on Beagleboard: > - 4.7: without using DMA, > > - Using DMA > 2.1: [0] > 2.1: [1] only C1 > 2.6: [1]+[2] no pre_ post_ > 2.3: [1]+[5] no pwrdm_for_each_clkdm > 2.8: [1]+[5]+[2] > 3.1: [1]+[5]+[6] no omap_sram_idle > 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON > > So indeed this shows there is some serious performance issue with the > C1 C-state. Yes, this confirms what both Grazvytas and I are seeing as well. [...] > From the list of contributors, the main ones are: > (140us) pwrdm_pre_transition and pwrdm_post_transition, See the series I just posted to address this one: [PATCH/RFT 0/3] ARM: OMAP: PM: reduce overhead of pwrdm pre/post transitions > (105us) omap2_gpio_prepare_for_idle and > omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in > the latency-critical C-states, > (78us) pwrdm_for_each_clkdm(mpu, core, deny_idle/allow_idle), > (33us estimated) omap_set_pwrdm_state(mpu, core, neon), > (11 us) clkdm_allow_idle(mpu). Is this needed? In that same series, I removed this as it appears to be a remnant of a code move (c.f. patch 3 in above series.) > Here are a few questions and suggestions: > - In case of latency critical C-states could the high-latency code be > bypassed in favor of a much simpler version? Pushing the concept a bit > farther one could have a C1 state that just relaxes the cpu (no WFI), > a C2 state which bypasses a lot of code in __omap3_enter_idle, and the > rest of the C-states as we have today, I was thinking a "WFI only" state, with *all* powerdomains staying on is probably sufficient for C1. Do you see the enter/exit latency from that as even being too hight? > - Is it needed to iterate through all the power and clock domains in > order to keep them active? No. My series above starts to addresses this, but I think Tero's use-counting series is the final solution since this should really be done when we know the powerdomains are transitioning. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFT 3/3] ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
commit e7410cf7 (02fdb03e69699f26e1370d0e51593dbc8a4e5265) moved
mangement of cam_pwrdm to CPUidle but left some remnants behind,
namely the call to clkcm_allo_idle() for the clockdomains in the MPU
pwrdm. Remove these since they are not necessary and cause unwanted
latency in the idle path.
Cc: Tero Kristo
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c |4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 74a7f8c..66ff828 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -70,7 +70,6 @@ void (*omap3_do_wfi_sram)(void);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
-static struct powerdomain *cam_pwrdm;
static void omap3_enable_io_chain(void)
{
@@ -395,8 +394,6 @@ void omap_sram_idle(void)
if (mpu_next_state < PWRDM_POWER_ON)
pwrdm_post_transition(mpu_pwrdm);
-
- clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
}
static void omap3_pm_idle(void)
@@ -759,7 +756,6 @@ static int __init omap3_pm_init(void)
neon_pwrdm = pwrdm_lookup("neon_pwrdm");
per_pwrdm = pwrdm_lookup("per_pwrdm");
core_pwrdm = pwrdm_lookup("core_pwrdm");
- cam_pwrdm = pwrdm_lookup("cam_pwrdm");
neon_clkdm = clkdm_lookup("neon_clkdm");
mpu_clkdm = clkdm_lookup("mpu_clkdm");
--
1.7.9.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/RFT 2/3] ARM: OMAP3: PM: call pre/post transition per powerdomain
We only need to call the pre/post transtion methods when we know the
power state is changing. First, split up the pre/post transition
calls to be per-powerdomain, and then make them conditional on whether
the power domain is actually changing states.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm34xx.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2451b90..74a7f8c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -307,16 +307,19 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- pwrdm_pre_transition(NULL);
+ if (mpu_next_state < PWRDM_POWER_ON)
+ pwrdm_pre_transition(mpu_pwrdm);
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
+ pwrdm_pre_transition(per_pwrdm);
per_going_off = (per_next_state == PWRDM_POWER_OFF) ? 1 : 0;
omap2_gpio_prepare_for_idle(per_going_off);
}
/* CORE */
if (core_next_state < PWRDM_POWER_ON) {
+ pwrdm_pre_transition(core_pwrdm);
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_cm_save_context();
@@ -369,15 +372,15 @@ void omap_sram_idle(void)
omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
+ pwrdm_post_transition(core_pwrdm);
}
omap3_intc_resume_idle();
- pwrdm_post_transition(NULL);
-
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
omap2_gpio_resume_after_idle();
+ pwrdm_post_transition(per_pwrdm);
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -390,6 +393,9 @@ void omap_sram_idle(void)
omap3_disable_io_chain();
}
+ if (mpu_next_state < PWRDM_POWER_ON)
+ pwrdm_post_transition(mpu_pwrdm);
+
clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
}
--
1.7.9.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/RFT 1/3] ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.
In order allow the pre/post transitions to be isolated and called
per-pwrdm, change the API so passing in a specific power domain will
trigger the pre/post transtion accounting for only that specific power
domain. Passing NULL means iterating over all power domains as is
current behavior.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 ++--
arch/arm/mach-omap2/pm34xx.c |4 ++--
arch/arm/mach-omap2/powerdomain.c | 16
arch/arm/mach-omap2/powerdomain.h |4 ++--
4 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13670aa..e35a86b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
return -ENXIO;
}
- pwrdm_pre_transition();
+ pwrdm_pre_transition(NULL);
/*
* Check MPUSS next state and save interrupt controller if needed.
@@ -287,7 +287,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
wakeup_cpu = smp_processor_id();
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
- pwrdm_post_transition();
+ pwrdm_post_transition(NULL);
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..2451b90 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -307,7 +307,7 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- pwrdm_pre_transition();
+ pwrdm_pre_transition(NULL);
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
@@ -372,7 +372,7 @@ void omap_sram_idle(void)
}
omap3_intc_resume_idle();
- pwrdm_post_transition();
+ pwrdm_post_transition(NULL);
/* PER */
if (per_next_state < PWRDM_POWER_ON) {
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..0baf8c3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -991,15 +991,23 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
return -EINVAL;
}
-int pwrdm_pre_transition(void)
+int pwrdm_pre_transition(struct powerdomain *pwrdm)
{
- pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+ if (pwrdm)
+ _pwrdm_pre_transition_cb(pwrdm, NULL);
+ else
+ pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+
return 0;
}
-int pwrdm_post_transition(void)
+int pwrdm_post_transition(struct powerdomain *pwrdm)
{
- pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
+ if (pwrdm)
+ _pwrdm_post_transition_cb(pwrdm, NULL);
+ else
+ pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
+
return 0;
}
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..a468de4 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -214,8 +214,8 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm);
int pwrdm_state_switch(struct powerdomain *pwrdm);
int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
-int pwrdm_pre_transition(void);
-int pwrdm_post_transition(void);
+int pwrdm_pre_transition(struct powerdomain *pwrdm);
+int pwrdm_post_transition(struct powerdomain *pwrdm);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
--
1.7.9.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/RFT 0/3] ARM: OMAP: PM: reduce overhead of pwrdm pre/post transitions
Here's a first pass attempt to reduce the overhead of the pre/post transitions by allowing them to be called per powerdomain and making them conditional on powerdomain transtions. This can be used for testing/measurements to see the reduction the latencies involved in entering/exiting idle with and without these patches. Kevin Hilman (3): ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm ARM: OMAP3: PM: call pre/post transition per powerdomain ARM: OMAP3: PM: cleanup cam_pwrdm leftovers arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 ++-- arch/arm/mach-omap2/pm34xx.c | 14 -- arch/arm/mach-omap2/powerdomain.c | 16 arch/arm/mach-omap2/powerdomain.h |4 ++-- 4 files changed, 24 insertions(+), 14 deletions(-) -- 1.7.9.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 v3 0/2] ARM: omap_hwmod: add api to enable/disable module level wakeup
From: "Govindraj.R" On omap2/3 module level wakeup is handled using PM_WKEN registers. Expand the hwmod framework to handle the module level wakeup enable registers. Tested on Beagle-xm by enabling and disabling uart wakeups from sysfs Series depends on following patches for testing. http://marc.info/?l=linux-omap&m=133527588923598&w=2 http://marc.info/?l=linux-omap&m=133518614022144&w=2 Cc: Paul Walmsley Cc: Kevin Hilman Cc: Benoit Cousson Cc: Tero Kristo Cc: Tony Lindgren Cc: Rajendra Nayak Cc: Santosh Shilimkar Govindraj.R (2): ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events ARM: omap3: pm: Remove uart module level wakeup configurations arch/arm/mach-omap2/omap_hwmod.c | 22 ++ arch/arm/mach-omap2/pm34xx.c | 14 +- arch/arm/mach-omap2/prm2xxx_3xxx.c | 16 arch/arm/mach-omap2/prm2xxx_3xxx.h |9 + 4 files changed, 52 insertions(+), 9 deletions(-) -- 1.7.9 -- To unsubscribe from this list: send the line "unsubscribe 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 v3 2/2] ARM: omap3: pm: Remove uart module level wakeup configurations
From: "Govindraj.R"
The uart module level wakeups enabling and disabling
are now handled from uart driver itself remove the uart module
level configurations from pm code.
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Tero Kristo
Cc: Rajendra Nayak
Cc: Santosh Shilimkar
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/pm34xx.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..7a19498 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -529,8 +529,6 @@ static void __init omap3_d2d_idle(void)
static void __init prcm_setup_regs(void)
{
- u32 omap3630_en_uart4_mask = cpu_is_omap3630() ?
- OMAP3630_EN_UART4_MASK : 0;
u32 omap3630_grpsel_uart4_mask = cpu_is_omap3630() ?
OMAP3630_GRPSEL_UART4_MASK : 0;
@@ -562,13 +560,11 @@ static void __init prcm_setup_regs(void)
OMAP3430_DSS_MOD, PM_WKEN);
/* Enable wakeups in PER */
- omap2_prm_write_mod_reg(omap3630_en_uart4_mask |
- OMAP3430_EN_GPIO2_MASK | OMAP3430_EN_GPIO3_MASK |
- OMAP3430_EN_GPIO4_MASK | OMAP3430_EN_GPIO5_MASK |
- OMAP3430_EN_GPIO6_MASK | OMAP3430_EN_UART3_MASK |
- OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
- OMAP3430_EN_MCBSP4_MASK,
- OMAP3430_PER_MOD, PM_WKEN);
+ omap2_prm_write_mod_reg(OMAP3430_EN_GPIO2_MASK |
+ OMAP3430_EN_GPIO3_MASK | OMAP3430_EN_GPIO4_MASK |
+ OMAP3430_EN_GPIO5_MASK | OMAP3430_EN_GPIO6_MASK |
+ OMAP3430_EN_MCBSP2_MASK | OMAP3430_EN_MCBSP3_MASK |
+ OMAP3430_EN_MCBSP4_MASK, OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
omap2_prm_write_mod_reg(omap3630_grpsel_uart4_mask |
OMAP3430_GRPSEL_GPIO2_MASK |
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe 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 v3 1/2] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
From: "Govindraj.R"
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add api to control the module level wakeup mechanism from info provided from
hwmod data.
omap_hwmod_enable/disable_wakeup is used from serial.c which should
configure PM_WKEN register to enable or disable the module level wakeup.
Cc: Tero Kristo
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Benoit Cousson
Cc: Rajendra Nayak
Cc: Santosh Shilimkar
Signed-off-by: Govindraj.R
---
arch/arm/mach-omap2/omap_hwmod.c | 22 ++
arch/arm/mach-omap2/prm2xxx_3xxx.c | 16
arch/arm/mach-omap2/prm2xxx_3xxx.h |9 +
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2c27fdb..4f10619 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -382,6 +382,26 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
}
/**
+ * _enable_module_level_wakeup - enable/disable module level wakeup on hwmod.
+ * @oh: struct omap_hwmod *
+ * @set_wake: bool value indicating to set (true) or clear (false) module level
+ * wakeup enable
+ *
+ * Set or clear the module level wakeup capability the
+ * hwmod @oh. This function configures th PM_WKEN reg bits if they
+ * are available from hwmod. No return value
+ */
+static void _enable_module_level_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ omap2_prm_enable_prcm_module_wakeup(
+ oh->prcm.omap2.module_offs,
+ oh->prcm.omap2.prcm_reg_id,
+ oh->prcm.omap2.idlest_idle_bit,
+ set_wake);
+}
+
+/**
* _set_idle_ioring_wakeup - enable/disable IO pad wakeup on hwmod idle for mux
* @oh: struct omap_hwmod *
* @set_wake: bool value indicating to set (true) or clear (false) wakeup
enable
@@ -2471,6 +2491,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ _enable_module_level_wakeup(oh, true);
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(&oh->_lock, flags);
@@ -2504,6 +2525,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ _enable_module_level_wakeup(oh, false);
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(&oh->_lock, flags);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..85a753e 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -28,6 +28,10 @@
#include "prm-regbits-24xx.h"
#include "prm-regbits-34xx.h"
+static const u8 pm_wken_offs[] = {
+ PM_WKEN1, OMAP24XX_PM_WKEN2
+};
+
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
OMAP_PRCM_IRQ("wkup", 0, 0),
OMAP_PRCM_IRQ("io", 9, 1),
@@ -91,6 +95,18 @@ u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16
idx)
return omap2_prm_rmw_mod_reg_bits(bits, 0x0, module, idx);
}
+void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod, u8 prm_reg_id,
+ u8 prm_reg_shift, bool set_wake)
+{
+ if (prm_reg_id && (prm_reg_id <= ARRAY_SIZE(pm_wken_offs))) {
+ if (set_wake)
+ omap2_prm_set_mod_reg_bits(1 << prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ else
+ omap2_prm_clear_mod_reg_bits(1 << prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ }
+}
/**
* omap2_prm_is_hardreset_asserted - read the HW reset line state of
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 70ac2a1..49a185a 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,13 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
"not suppose to be used on omap4\n");
return 0;
}
+static inline void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod,
+ u8 prm_reg_id, u8 prm_reg_shift, bool set_wake)
+{
+ WARN(1, "prm: omap2xxx/omap3xxx specific function and "
+ "not suppose to be used on omap4\n");
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -297,6 +304,8 @@ extern u32 omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
s16 module, s16 idx);
extern u32 omap2_prm_set_mod_reg_bits(u32 bits, s16 module, s16 idx);
extern u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16 idx);
extern u32 omap2_prm_read_mod_bits_shift(s16 domain, s16 idx, u32 mask);
+extern void omap2_
[PATCH 18/18][V3] ARM: OMAP3: cpuidle - set global variables static
and check the powerdomain lookup is successful.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 0d28596..116a0d8 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -73,7 +73,7 @@ static struct omap3_idle_statedata omap3_idle_data[] = {
},
};
-struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
+static struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
static int _cpuidle_allow_idle(struct powerdomain *pwrdm,
struct clockdomain *clkdm)
@@ -252,6 +252,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
*its own code.
*/
+ if (!mpu_pd || !core_pd || !per_pd || !cam_pd)
+ return -ENODEV;
+
/*
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/18][V3] ARM: OMAP3/4: consolidate cpuidle Makefile
Define a CPU_IDLE section in the makefile, declare the functions in
the header files conforming to the kernel coding rules and remove the
'define's in the C files.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/Makefile | 11 +++
arch/arm/mach-omap2/cpuidle34xx.c |8
arch/arm/mach-omap2/cpuidle44xx.c |8
arch/arm/mach-omap2/pm.h | 17 +++--
4 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d8604a3..92d5fb6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -64,10 +64,8 @@ endif
ifeq ($(CONFIG_PM),y)
obj-$(CONFIG_ARCH_OMAP2) += pm24xx.o
obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o \
- cpuidle34xx.o
-obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
- cpuidle44xx.o
+obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
@@ -81,6 +79,11 @@ endif
endif
+ifeq ($(CONFIG_CPU_IDLE),y)
+obj-$(CONFIG_ARCH_OMAP3)+= cpuidle34xx.o
+obj-$(CONFIG_ARCH_OMAP4)+= cpuidle44xx.o
+endif
+
# PRCM
obj-y += prm_common.o
obj-$(CONFIG_ARCH_OMAP2) += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index ee02a8c..0d28596 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,8 +36,6 @@
#include "control.h"
#include "common.h"
-#ifdef CONFIG_CPU_IDLE
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
@@ -376,9 +374,3 @@ int __init omap3_idle_init(void)
return 0;
}
-#else
-int __init omap3_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..02d15bb 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,8 +22,6 @@
#include "pm.h"
#include "prm.h"
-#ifdef CONFIG_CPU_IDLE
-
/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
@@ -199,9 +197,3 @@ int __init omap4_idle_init(void)
return 0;
}
-#else
-int __init omap4_idle_init(void)
-{
- return 0;
-}
-#endif /* CONFIG_CPU_IDLE */
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 7856489..ab04d3b 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,12 +15,25 @@
#include "powerdomain.h"
+#ifdef CONFIG_CPU_IDLE
+extern int __init omap3_idle_init(void);
+extern int __init omap4_idle_init(void);
+#else
+static inline int omap3_idle_init(void)
+{
+ return 0;
+}
+
+static inline int omap4_idle_init(void)
+{
+ return 0;
+}
+#endif
+
extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
-extern int omap3_idle_init(void);
-extern int omap4_idle_init(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
extern int (*omap_pm_suspend)(void);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/18][V3] ARM: OMAP3: set omap3_idle_data as static
Reduce the scope of the omap3_idle_data to the file as it is only used
in cpuidle34xx.c.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index e7599e7..ee02a8c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -44,7 +44,7 @@ struct omap3_idle_statedata {
u32 core_state;
};
-struct omap3_idle_statedata omap3_idle_data[] = {
+static struct omap3_idle_statedata omap3_idle_data[] = {
{
.mpu_state = PWRDM_POWER_ON,
.core_state = PWRDM_POWER_ON,
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/18][V3] ARM: OMAP3: cpuidle - simplify next_valid_state
Simplify the indentation by removing the useless 'else' statement.
Remove the first loop for the 'idx' search as we have it already
with the 'index' passed as parameter.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 53 +---
1 files changed, 19 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 242f77d..e7599e7 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -172,13 +172,12 @@ static inline int omap3_enter_idle(struct cpuidle_device
*dev,
* if it satisfies the enable_off_mode condition.
*/
static int next_valid_state(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+ struct cpuidle_driver *drv, int index)
{
- struct cpuidle_state *curr = &drv->states[index];
struct omap3_idle_statedata *cx = &omap3_idle_data[index];
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
+ int idx;
int next_index = -1;
if (enable_off_mode) {
@@ -194,42 +193,28 @@ static int next_valid_state(struct cpuidle_device *dev,
/* Check if current state is valid */
if ((cx->mpu_state >= mpu_deepest_state) &&
- (cx->core_state >= core_deepest_state)) {
+ (cx->core_state >= core_deepest_state))
return index;
- } else {
- int idx = ARRAY_SIZE(omap3_idle_data) - 1;
-
- /* Reach the current state starting at highest C-state */
- for (; idx >= 0; idx--) {
- if (&drv->states[idx] == curr) {
- next_index = idx;
- break;
- }
- }
-
- /* Should never hit this condition */
- WARN_ON(next_index == -1);
- /*
-* Drop to next valid state.
-* Start search from the next (lower) state.
-*/
- idx--;
- for (; idx >= 0; idx--) {
- cx = &omap3_idle_data[idx];
- if ((cx->mpu_state >= mpu_deepest_state) &&
- (cx->core_state >= core_deepest_state)) {
- next_index = idx;
- break;
- }
+ /*
+* Drop to next valid state.
+* Start search from the next (lower) state.
+*/
+ for (idx = index - 1; idx >= 0; idx--) {
+ cx = &omap3_idle_data[idx];
+ if ((cx->mpu_state >= mpu_deepest_state) &&
+ (cx->core_state >= core_deepest_state)) {
+ next_index = idx;
+ break;
}
- /*
-* C1 is always valid.
-* So, no need to check for 'next_index == -1' outside
-* this loop.
-*/
}
+ /*
+* C1 is always valid.
+* So, no need to check for 'next_index == -1' outside
+* this loop.
+*/
+
return next_index;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/18][V3] ARM: OMAP3: cpuidle - use omap3_idle_data directly
We are storing the 'omap3_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly.
As the table is initialized statically, let's remove the initialization at
startup too.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 63 +++-
1 files changed, 6 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 93e2450..242f77d 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -95,8 +95,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(&dev->states_usage[index]);
+ struct omap3_idle_statedata *cx = &omap3_idle_data[index];
u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
local_fiq_disable();
@@ -176,9 +175,8 @@ static int next_valid_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct cpuidle_state_usage *curr_usage = &dev->states_usage[index];
struct cpuidle_state *curr = &drv->states[index];
- struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
+ struct omap3_idle_statedata *cx = &omap3_idle_data[index];
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int next_index = -1;
@@ -218,7 +216,7 @@ static int next_valid_state(struct cpuidle_device *dev,
*/
idx--;
for (; idx >= 0; idx--) {
- cx = cpuidle_get_statedata(&dev->states_usage[idx]);
+ cx = &omap3_idle_data[idx];
if ((cx->mpu_state >= mpu_deepest_state) &&
(cx->core_state >= core_deepest_state)) {
next_index = idx;
@@ -275,7 +273,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
* Prevent PER off if CORE is not in retention or off as this
* would disable PER wakeups completely.
*/
- cx = cpuidle_get_statedata(&dev->states_usage[index]);
+ cx = &omap3_idle_data[index];
core_next_state = cx->core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF) &&
@@ -365,19 +363,6 @@ struct cpuidle_driver omap3_idle_driver = {
.safe_state_index = 0,
};
-/* Helper to register the driver_data */
-static inline struct omap3_idle_statedata *_fill_cstate_usage(
- struct cpuidle_device *dev,
- int idx)
-{
- struct omap3_idle_statedata *cx = &omap3_idle_data[idx];
- struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
-
- cpuidle_set_statedata(state_usage, cx);
-
- return cx;
-}
-
/**
* omap3_idle_init - Init routine for OMAP3 idle
*
@@ -387,52 +372,16 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
int __init omap3_idle_init(void)
{
struct cpuidle_device *dev;
- struct omap3_idle_statedata *cx;
mpu_pd = pwrdm_lookup("mpu_pwrdm");
core_pd = pwrdm_lookup("core_pwrdm");
per_pd = pwrdm_lookup("per_pwrdm");
cam_pd = pwrdm_lookup("cam_pwrdm");
+ cpuidle_register_driver(&omap3_idle_driver);
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
-
- /* C1 . MPU WFI + Core active */
- cx = _fill_cstate_usage(dev, 0);
- cx->mpu_state = PWRDM_POWER_ON;
- cx->core_state = PWRDM_POWER_ON;
-
- /* C2 . MPU WFI + Core inactive */
- cx = _fill_cstate_usage(dev, 1);
- cx->mpu_state = PWRDM_POWER_ON;
- cx->core_state = PWRDM_POWER_ON;
-
- /* C3 . MPU CSWR + Core inactive */
- cx = _fill_cstate_usage(dev, 2);
- cx->mpu_state = PWRDM_POWER_RET;
- cx->core_state = PWRDM_POWER_ON;
-
- /* C4 . MPU OFF + Core inactive */
- cx = _fill_cstate_usage(dev, 3);
- cx->mpu_state = PWRDM_POWER_OFF;
- cx->core_state = PWRDM_POWER_ON;
-
- /* C5 . MPU RET + Core RET */
- cx = _fill_cstate_usage(dev, 4);
- cx->mpu_state = PWRDM_POWER_RET;
- cx->core_state = PWRDM_POWER_RET;
-
- /* C6 . MPU OFF + Core RET */
- cx = _fill_cstate_usage(dev, 5);
- cx->mpu_state = PWRDM_POWER_OFF;
- cx->core_state = PWRDM_POWER_RET;
-
- /* C7 . MPU OFF + Core OFF */
- cx = _fill_cstate_usage(dev, 6);
- cx->mpu_state = PWRDM_POWER_OFF;
- cx->core_state = PWRDM_POWER_OFF;
-
- cpuidle_register_driver(&omap3_idle_driver);
[PATCH 13/18][V3] ARM: OMAP3: define statically the omap3_idle_data
Initialize the omap3_idle_data array at compile time, that will allow
to remove the initialization at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 37 -
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index a82a887..93e2450 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -44,9 +44,36 @@ struct omap3_idle_statedata {
u32 core_state;
};
-#define OMAP3_NUM_STATES 7
-
-struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
+struct omap3_idle_statedata omap3_idle_data[] = {
+ {
+ .mpu_state = PWRDM_POWER_ON,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_ON,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_RET,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_ON,
+ },
+ {
+ .mpu_state = PWRDM_POWER_RET,
+ .core_state = PWRDM_POWER_RET,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_RET,
+ },
+ {
+ .mpu_state = PWRDM_POWER_OFF,
+ .core_state = PWRDM_POWER_OFF,
+ },
+};
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
@@ -172,7 +199,7 @@ static int next_valid_state(struct cpuidle_device *dev,
(cx->core_state >= core_deepest_state)) {
return index;
} else {
- int idx = OMAP3_NUM_STATES - 1;
+ int idx = ARRAY_SIZE(omap3_idle_data) - 1;
/* Reach the current state starting at highest C-state */
for (; idx >= 0; idx--) {
@@ -334,7 +361,7 @@ struct cpuidle_driver omap3_idle_driver = {
.desc = "MPU OFF + CORE OFF",
},
},
- .state_count = OMAP3_NUM_STATES,
+ .state_count = ARRAY_SIZE(omap3_idle_data),
.safe_state_index = 0,
};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/18][V3] ARM: OMAP3: cpuidle - remove cpuidle_params_table
We do not longer need the ''cpuidle_params_table' array as
we defined the states in the driver and we checked they are
all valid.
We also remove the structure definition as it is no longer used.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 28 +++-
arch/arm/mach-omap2/pm.h | 12
2 files changed, 3 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 29b4f87..a82a887 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -38,36 +38,14 @@
#ifdef CONFIG_CPU_IDLE
-/*
- * The latencies/thresholds for various C states have
- * to be configured from the respective board files.
- * These are some default values (which might not provide
- * the best power savings) used on boards which do not
- * pass these details from the board file.
- */
-static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
- {2 + 2, 5, 1},
- /* C2 */
- {10 + 10, 30, 1},
- /* C3 */
- {50 + 50, 300, 1},
- /* C4 */
- {1500 + 1800, 4000, 1},
- /* C5 */
- {2500 + 7500, 12000, 1},
- /* C6 */
- {3000 + 8500, 15000, 1},
- /* C7 */
- {1 + 3, 30, 1},
-};
-#define OMAP3_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
-
/* Mach specific information to be recorded in the C-state driver_data */
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
};
+
+#define OMAP3_NUM_STATES 7
+
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
struct powerdomain *mpu_pd, *core_pd, *per_pd, *cam_pd;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 5646b80..7856489 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -38,18 +38,6 @@ static inline int omap4_opp_init(void)
}
#endif
-/*
- * cpuidle mach specific parameters
- *
- * The board code can override the default C-states definition using
- * omap3_pm_init_cpuidle
- */
-struct cpuidle_params {
- u32 exit_latency; /* exit_latency = sleep + wake-up latencies */
- u32 target_residency;
- u8 valid; /* validates the C-state */
-};
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/18][V3] ARM: OMAP3: cpuidle - remove the 'valid' field
With the previous changes all the states are valid, except
the last state which can be handled by decreasing the number
of states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f394ea6..29b4f87 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -67,7 +67,6 @@ static struct cpuidle_params cpuidle_params_table[] = {
struct omap3_idle_statedata {
u32 mpu_state;
u32 core_state;
- u8 valid;
};
struct omap3_idle_statedata omap3_idle_data[OMAP3_NUM_STATES];
@@ -191,8 +190,7 @@ static int next_valid_state(struct cpuidle_device *dev,
}
/* Check if current state is valid */
- if ((cx->valid) &&
- (cx->mpu_state >= mpu_deepest_state) &&
+ if ((cx->mpu_state >= mpu_deepest_state) &&
(cx->core_state >= core_deepest_state)) {
return index;
} else {
@@ -216,8 +214,7 @@ static int next_valid_state(struct cpuidle_device *dev,
idx--;
for (; idx >= 0; idx--) {
cx = cpuidle_get_statedata(&dev->states_usage[idx]);
- if ((cx->valid) &&
- (cx->mpu_state >= mpu_deepest_state) &&
+ if ((cx->mpu_state >= mpu_deepest_state) &&
(cx->core_state >= core_deepest_state)) {
next_index = idx;
break;
@@ -371,7 +368,6 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
struct omap3_idle_statedata *cx = &omap3_idle_data[idx];
struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
- cx->valid = cpuidle_params_table[idx].valid;
cpuidle_set_statedata(state_usage, cx);
return cx;
@@ -386,7 +382,6 @@ static inline struct omap3_idle_statedata
*_fill_cstate_usage(
int __init omap3_idle_init(void)
{
struct cpuidle_device *dev;
- struct cpuidle_driver *drv = &omap3_idle_driver;
struct omap3_idle_statedata *cx;
mpu_pd = pwrdm_lookup("mpu_pwrdm");
@@ -399,7 +394,6 @@ int __init omap3_idle_init(void)
/* C1 . MPU WFI + Core active */
cx = _fill_cstate_usage(dev, 0);
- cx->valid = 1; /* C1 is always valid */
cx->mpu_state = PWRDM_POWER_ON;
cx->core_state = PWRDM_POWER_ON;
@@ -433,7 +427,6 @@ int __init omap3_idle_init(void)
cx->mpu_state = PWRDM_POWER_OFF;
cx->core_state = PWRDM_POWER_OFF;
- drv->state_count = OMAP3_NUM_STATES;
cpuidle_register_driver(&omap3_idle_driver);
if (cpuidle_register_device(dev)) {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/18][V3] ARM: OMAP3: cpuidle - remove errata check in the init function
The errata check is done in the next_valid_state function, no need to check
that in the omap3_idle_init function.
Signed-off-by: Daniel Lezcano
---
arch/arm/mach-omap2/cpuidle34xx.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 11a2c23..f394ea6 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -430,16 +430,6 @@ int __init omap3_idle_init(void)
/* C7 . MPU OFF + Core OFF */
cx = _fill_cstate_usage(dev, 6);
- /*
-* Erratum i583: implementation for ES rev < Es1.2 on 3630. We cannot
-* enable OFF mode in a stable form for previous revisions.
-* We disable C7 state as a result.
-*/
- if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
- cx->valid = 0;
- pr_warn("%s: core off state C7 disabled due to i583\n",
- __func__);
- }
cx->mpu_state = PWRDM_POWER_OFF;
cx->core_state = PWRDM_POWER_OFF;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/18][V3] ARM: OMAP3: define cpuidle statically
Use the new cpuidle API and define in the driver the states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 86 +---
1 files changed, 60 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 3519a8b..11a2c23 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -301,23 +301,68 @@ DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
struct cpuidle_driver omap3_idle_driver = {
.name = "omap3_idle",
.owner =THIS_MODULE,
+ .states = {
+ {
+ .enter= omap3_enter_idle,
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C1",
+ .desc = "MPU ON + CORE ON",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 10 + 10,
+ .target_residency = 30,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C2",
+ .desc = "MPU ON + CORE ON",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 50 + 50,
+ .target_residency = 300,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C3",
+ .desc = "MPU RET + CORE ON",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 1500 + 1800,
+ .target_residency = 4000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C4",
+ .desc = "MPU OFF + CORE ON",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 2500 + 7500,
+ .target_residency = 12000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C5",
+ .desc = "MPU RET + CORE RET",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 3000 + 8500,
+ .target_residency = 15000,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C6",
+ .desc = "MPU OFF + CORE RET",
+ },
+ {
+ .enter= omap3_enter_idle_bm,
+ .exit_latency = 1 + 3,
+ .target_residency = 3,
+ .flags= CPUIDLE_FLAG_TIME_VALID,
+ .name = "C7",
+ .desc = "MPU OFF + CORE OFF",
+ },
+ },
+ .state_count = OMAP3_NUM_STATES,
+ .safe_state_index = 0,
};
-/* Helper to fill the C-state common data*/
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = &drv->states[idx];
-
- state->exit_latency = cpuidle_params_table[idx].exit_latency;
- state->target_residency = cpuidle_params_table[idx].target_residency;
- state->flags= CPUIDLE_FLAG_TIME_VALID;
- state->enter= omap3_enter_idle_bm;
- sprintf(state->name, "C%d", idx + 1);
- strncpy(state->desc, descr, CPUIDLE_DESC_LEN);
-
-}
-
/* Helper to register the driver_data */
static inline struct omap3_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
@@ -350,50 +395,40 @@ int __init omap3_idle_init(void)
cam_pd = pwrdm_lookup("cam_pwrdm");
- drv->safe_state_index = -1;
dev = &per_cpu(omap3_idle_dev, smp_processor_id());
/* C1 . MPU WFI + Core active */
- _fill_cstate(drv, 0, "MPU ON + CORE ON");
- (&drv->states[0])->enter = omap3_enter_idle;
- drv->safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx->valid = 1; /* C1 is always valid */
cx->mpu_state = PWRDM_POWER_ON;
cx->core_state = PWRDM_POWER_ON;
/* C2 . MPU WFI + Core inactive */
- _fill_cstate(drv, 1, "MPU ON + CORE ON");
cx = _fill_cstate_usage(dev, 1);
cx->mpu_state = PWRDM_POWER_ON;
[PATCH 08/18][V3] ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table
As suggested, this table is an optimized version for rx51 and we
remove it in order to consolidate the cpuidle code between omap3
and omap4, we remove this specific data definition which is used
to override the default omap3 latencies but at the cost of extra
code and complexity.
In order to not lose the values which probably took time to be
measured, the table is converted into a comment with an array
description.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
---
arch/arm/mach-omap2/board-rx51.c | 38 +---
arch/arm/mach-omap2/cpuidle34xx.c | 17
arch/arm/mach-omap2/pm.h |9
3 files changed, 18 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51.c b/arch/arm/mach-omap2/board-rx51.c
index 27f01f0..2da92a6 100644
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
@@ -59,25 +59,24 @@ static struct platform_device leds_gpio = {
};
/*
- * cpuidle C-states definition override from the default values.
- * The 'exit_latency' field is the sum of sleep and wake-up latencies.
- */
-static struct cpuidle_params rx51_cpuidle_params[] = {
- /* C1 */
- {110 + 162, 5 , 1},
- /* C2 */
- {106 + 180, 309, 1},
- /* C3 */
- {107 + 410, 46057, 0},
- /* C4 */
- {121 + 3374, 46057, 0},
- /* C5 */
- {855 + 1146, 46057, 1},
- /* C6 */
- {7580 + 4134, 484329, 0},
- /* C7 */
- {7505 + 15274, 484329, 1},
-};
+ * cpuidle C-states definition for rx51.
+ *
+ * The 'exit_latency' field is the sum of sleep
+ * and wake-up latencies.
+
+-
+ | state | exit_latency | target_residency |
+-
+ | C1 |110 + 162 |5 |
+ | C2 |106 + 180 | 309 |
+ | C3 |107 + 410 |46057 |
+ | C4 |121 + 3374 |46057 |
+ | C5 |855 + 1146 |46057 |
+ | C6 | 7580 + 4134 | 484329 |
+ | C7 | 7505 + 15274 | 484329 |
+-
+
+*/
extern void __init rx51_peripherals_init(void);
@@ -98,7 +97,6 @@ static void __init rx51_init(void)
struct omap_sdrc_params *sdrc_params;
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
- omap3_pm_init_cpuidle(rx51_cpuidle_params);
omap_serial_init();
sdrc_params = nokia_get_sdram_timings();
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 5358664..3519a8b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -298,23 +298,6 @@ select_state:
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
-void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
-{
- int i;
-
- if (!cpuidle_board_params)
- return;
-
- for (i = 0; i < OMAP3_NUM_STATES; i++) {
- cpuidle_params_table[i].valid = cpuidle_board_params[i].valid;
- cpuidle_params_table[i].exit_latency =
- cpuidle_board_params[i].exit_latency;
- cpuidle_params_table[i].target_residency =
- cpuidle_board_params[i].target_residency;
- }
- return;
-}
-
struct cpuidle_driver omap3_idle_driver = {
.name = "omap3_idle",
.owner =THIS_MODULE,
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 36fa90b..5646b80 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -50,15 +50,6 @@ struct cpuidle_params {
u8 valid; /* validates the C-state */
};
-#if defined(CONFIG_PM) && defined(CONFIG_CPU_IDLE)
-extern void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params);
-#else
-static
-inline void omap3_pm_init_cpuidle(struct cpuidle_params *cpuidle_board_params)
-{
-}
-#endif
-
extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18][V3] ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time
We initialized it at compile time, no need to do that at boot
time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 24
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f1410f1..be1617c 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -170,14 +170,6 @@ struct cpuidle_driver omap4_idle_driver = {
.safe_state_index = 0,
};
-static inline struct omap4_idle_statedata *_fill_cstate_usage(
- struct cpuidle_device *dev,
- int idx)
-{
- struct omap4_idle_statedata *cx = &omap4_idle_data[idx];
- return cx;
-}
-
/**
* omap4_idle_init - Init routine for OMAP4 idle
*
@@ -186,7 +178,6 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
*/
int __init omap4_idle_init(void)
{
- struct omap4_idle_statedata *cx;
struct cpuidle_device *dev;
unsigned int cpu_id = 0;
@@ -199,21 +190,6 @@ int __init omap4_idle_init(void)
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
- cx = _fill_cstate_usage(dev, 0);
- cx->cpu_state = PWRDM_POWER_ON;
- cx->mpu_state = PWRDM_POWER_ON;
- cx->mpu_logic_state = PWRDM_POWER_RET;
-
- cx = _fill_cstate_usage(dev, 1);
- cx->cpu_state = PWRDM_POWER_OFF;
- cx->mpu_state = PWRDM_POWER_RET;
- cx->mpu_logic_state = PWRDM_POWER_RET;
-
- cx = _fill_cstate_usage(dev, 2);
- cx->cpu_state = PWRDM_POWER_OFF;
- cx->mpu_state = PWRDM_POWER_RET;
- cx->mpu_logic_state = PWRDM_POWER_OFF;
-
cpuidle_register_driver(&omap4_idle_driver);
if (cpuidle_register_device(dev)) {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/18][V3] ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly
We are storing the 'omap4_idle_data' in the private data field
of the cpuidle device. As we are using this variable only in this file,
that does not really make sense. Let's use the global variable directly.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 9e3effa..f1410f1 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -24,7 +24,7 @@
#ifdef CONFIG_CPU_IDLE
-/* Machine specific information to be recorded in the C-state driver_data */
+/* Machine specific information */
struct omap4_idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
@@ -65,8 +65,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap4_idle_statedata *cx =
- cpuidle_get_statedata(&dev->states_usage[index]);
+ struct omap4_idle_statedata *cx = &omap4_idle_data[index];
u32 cpu1_state;
int cpu_id = smp_processor_id();
@@ -83,7 +82,7 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
cpu1_state = pwrdm_read_pwrst(cpu1_pd);
if (cpu1_state != PWRDM_POWER_OFF) {
index = drv->safe_state_index;
- cx = cpuidle_get_statedata(&dev->states_usage[index]);
+ cx = &omap4_idle_data[index];
}
if (index > 0)
@@ -176,15 +175,9 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
int idx)
{
struct omap4_idle_statedata *cx = &omap4_idle_data[idx];
- struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
-
- cpuidle_set_statedata(state_usage, cx);
-
return cx;
}
-
-
/**
* omap4_idle_init - Init routine for OMAP4 idle
*
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/18][V3] ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time
We initialize the omap4_idle_data variable at compile time allowing us
to remove in the next patch the initialization done at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 38ecd27..9e3effa 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -31,9 +31,24 @@ struct omap4_idle_statedata {
u32 mpu_state;
};
-#define OMAP4_NUM_STATES 3
+static struct omap4_idle_statedata omap4_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+ {
+ .cpu_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_OFF,
+ },
+};
-static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
/**
@@ -152,7 +167,7 @@ struct cpuidle_driver omap4_idle_driver = {
.desc = "MPUSS OSWR",
},
},
- .state_count = OMAP4_NUM_STATES,
+ .state_count = ARRAY_SIZE(omap4_idle_data),
.safe_state_index = 0,
};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/18][V3] ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration
Add the static declaration for the omap4_idle_data variable because its scope
is in the file only.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 522ec23..38ecd27 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -33,7 +33,7 @@ struct omap4_idle_statedata {
#define OMAP4_NUM_STATES 3
-struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
+static struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
/**
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/18][V3] ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table
We do not longer need this table as we defined the values
in the driver states.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 7072c9e..522ec23 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -31,16 +31,7 @@ struct omap4_idle_statedata {
u32 mpu_state;
};
-static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- {.exit_latency = 2 + 2 , .target_residency = 5 },
- /* C2- CPU0 OFF + CPU1 OFF + MPU CSWR */
- {.exit_latency = 328 + 440 , .target_residency = 960 },
- /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- {.exit_latency = 460 + 518 , .target_residency = 1100 },
-};
-
-#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
+#define OMAP4_NUM_STATES 3
struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18][V3] ARM: OMAP4: cpuidle - Declare the states with the driver declaration
The cpuidle API allows to declare statically the states in the driver
structure. Let's use it.
We do no longer need the fill_cstate function called at runtime and
by the way adding more instructions at boot time.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c | 60
1 files changed, 33 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index ee0bc50..7072c9e 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -132,21 +132,39 @@ struct cpuidle_driver omap4_idle_driver = {
.name = "omap4_idle",
.owner = THIS_MODULE,
.en_core_tk_irqen = 1,
+ .states = {
+ {
+ /* C1 - CPU0 ON + CPU1 ON + MPU ON */
+ .exit_latency = 2 + 2,
+ .target_residency = 5,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = "C1",
+ .desc = "MPUSS ON"
+ },
+ {
+/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
+ .exit_latency = 328 + 440,
+ .target_residency = 960,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = "C2",
+ .desc = "MPUSS CSWR",
+ },
+ {
+ /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
+ .exit_latency = 460 + 518,
+ .target_residency = 1100,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .enter = omap4_enter_idle,
+ .name = "C3",
+ .desc = "MPUSS OSWR",
+ },
+ },
+ .state_count = OMAP4_NUM_STATES,
+ .safe_state_index = 0,
};
-static inline void _fill_cstate(struct cpuidle_driver *drv,
- int idx, const char *descr)
-{
- struct cpuidle_state *state = &drv->states[idx];
-
- state->exit_latency = cpuidle_params_table[idx].exit_latency;
- state->target_residency = cpuidle_params_table[idx].target_residency;
- state->flags= CPUIDLE_FLAG_TIME_VALID;
- state->enter= omap4_enter_idle;
- sprintf(state->name, "C%d", idx + 1);
- strncpy(state->desc, descr, CPUIDLE_DESC_LEN);
-}
-
static inline struct omap4_idle_statedata *_fill_cstate_usage(
struct cpuidle_device *dev,
int idx)
@@ -171,7 +189,6 @@ int __init omap4_idle_init(void)
{
struct omap4_idle_statedata *cx;
struct cpuidle_device *dev;
- struct cpuidle_driver *drv = &omap4_idle_driver;
unsigned int cpu_id = 0;
mpu_pd = pwrdm_lookup("mpu_pwrdm");
@@ -180,41 +197,30 @@ int __init omap4_idle_init(void)
if ((!mpu_pd) || (!cpu0_pd) || (!cpu1_pd))
return -ENODEV;
-
- drv->safe_state_index = -1;
dev = &per_cpu(omap4_idle_dev, cpu_id);
dev->cpu = cpu_id;
- /* C1 - CPU0 ON + CPU1 ON + MPU ON */
- _fill_cstate(drv, 0, "MPUSS ON");
- drv->safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
cx->cpu_state = PWRDM_POWER_ON;
cx->mpu_state = PWRDM_POWER_ON;
cx->mpu_logic_state = PWRDM_POWER_RET;
- /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
- _fill_cstate(drv, 1, "MPUSS CSWR");
cx = _fill_cstate_usage(dev, 1);
cx->cpu_state = PWRDM_POWER_OFF;
cx->mpu_state = PWRDM_POWER_RET;
cx->mpu_logic_state = PWRDM_POWER_RET;
- /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- _fill_cstate(drv, 2, "MPUSS OSWR");
cx = _fill_cstate_usage(dev, 2);
cx->cpu_state = PWRDM_POWER_OFF;
cx->mpu_state = PWRDM_POWER_RET;
cx->mpu_logic_state = PWRDM_POWER_OFF;
- drv->state_count = OMAP4_NUM_STATES;
cpuidle_register_driver(&omap4_idle_driver);
- dev->state_count = OMAP4_NUM_STATES;
if (cpuidle_register_device(dev)) {
pr_err("%s: CPUidle register device failed\n", __func__);
- return -EIO;
- }
+ return -EIO;
+ }
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/18][V3] ARM: OMAP4: cpuidle - Remove unused valid field
The 'valid' field is never used in the code, let's remove it.
Signed-off-by: Daniel Lezcano
Reviewed-by: Jean Pihet
Reviewed-by: Santosh Shilimkar
---
arch/arm/mach-omap2/cpuidle44xx.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f386cbe..ee0bc50 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -29,16 +29,15 @@ struct omap4_idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
- u8 valid;
};
static struct cpuidle_params cpuidle_params_table[] = {
/* C1 - CPU0 ON + CPU1 ON + MPU ON */
- {.exit_latency = 2 + 2 , .target_residency = 5, .valid = 1},
+ {.exit_latency = 2 + 2 , .target_residency = 5 },
/* C2- CPU0 OFF + CPU1 OFF + MPU CSWR */
- {.exit_latency = 328 + 440 , .target_residency = 960, .valid = 1},
+ {.exit_latency = 328 + 440 , .target_residency = 960 },
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
- {.exit_latency = 460 + 518 , .target_residency = 1100, .valid = 1},
+ {.exit_latency = 460 + 518 , .target_residency = 1100 },
};
#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
@@ -155,7 +154,6 @@ static inline struct omap4_idle_statedata
*_fill_cstate_usage(
struct omap4_idle_statedata *cx = &omap4_idle_data[idx];
struct cpuidle_state_usage *state_usage = &dev->states_usage[idx];
- cx->valid = cpuidle_params_table[idx].valid;
cpuidle_set_statedata(state_usage, cx);
return cx;
@@ -191,7 +189,6 @@ int __init omap4_idle_init(void)
_fill_cstate(drv, 0, "MPUSS ON");
drv->safe_state_index = 0;
cx = _fill_cstate_usage(dev, 0);
- cx->valid = 1; /* C1 is always valid */
cx->cpu_state = PWRDM_POWER_ON;
cx->mpu_state = PWRDM_POWER_ON;
cx->mpu_logic_state = PWRDM_POWER_RET;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18][V3] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Tested on OMAP3 (igepV2). Partially tested on OMAP4 (pandaboard), without offlining the cpu1. V3 : * replace OMAP4_NUM_STATES and OMAP3_NUM_STATES by ARRAY_SIZE * Fixed changelog * Fixed OMAP4_NUM_STATES going back and forth in the patchset * Removed erratum check at init time V2 : * Fixed a couple of typos in the patch description V1 : Initial Post Daniel Lezcano (18): ARM: OMAP4: cpuidle - Remove unused valid field ARM: OMAP4: cpuidle - Declare the states with the driver declaration ARM: OMAP4: cpuidle - Remove the cpuidle_params_table table ARM: OMAP4: cpuidle - fix static omap4_idle_data declaration ARM: OMAP4: cpuidle - Initialize omap4_idle_data at compile time ARM: OMAP4: cpuidle - use the omap4_idle_data variable directly ARM: OMAP4: cpuidle - remove omap4_idle_data initialization at boot time ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table ARM: OMAP3: define cpuidle statically ARM: OMAP3: cpuidle - remove errata check in the init function ARM: OMAP3: cpuidle - remove the 'valid' field ARM: OMAP3: cpuidle - remove cpuidle_params_table ARM: OMAP3: define statically the omap3_idle_data ARM: OMAP3: cpuidle - use omap3_idle_data directly ARM: OMAP3: cpuidle - simplify next_valid_state ARM: OMAP3: set omap3_idle_data as static ARM: OMAP3/4: consolidate cpuidle Makefile ARM: OMAP3: cpuidle - set global variables static arch/arm/mach-omap2/Makefile | 11 +- arch/arm/mach-omap2/board-rx51.c | 38 +++--- arch/arm/mach-omap2/cpuidle34xx.c | 306 +++-- arch/arm/mach-omap2/cpuidle44xx.c | 134 +++-- arch/arm/mach-omap2/pm.h | 38 ++--- 5 files changed, 212 insertions(+), 315 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] tty: omap-serial: configure wakeup mechanism based on port usage.
From: "Govindraj.R"
With set_wakeup port ops availability from serial_core layer
which will be called when port is opened with state as true
indicating the wakeups can be enabled for this port and state
as false while port shutdown where we can disable the wakeups.
But wakeup can be also enabled/disabled when requested from sysfs.
If wakeups are disabled while entering suspend we have to enable them
back while port is used from resume. This can be done with serial_omap_pm
this uart ops has state flag indicating if port is going to be used.
serial_omap_pm gets called from serial_core layer.
Thanks to Kevin Hilman for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Cc: Kevin Hilman
Cc: Paul Walmsley
Signed-off-by: Govindraj.R
---
Patch is tested using the patch as in here[1]
Tested on beagle-XM by enabling and disabling wakeups
from sysfs and opening and closing a uart port.
[1]: http://marc.info/?l=linux-omap&m=133518614022144&w=2
arch/arm/plat-omap/include/plat/omap-serial.h |1 -
drivers/tty/serial/omap-serial.c | 40 +---
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..8e6d734 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -130,7 +130,6 @@ struct uart_omap_port {
unsigned long port_activity;
u32 context_loss_cnt;
u32 errata;
- u8 wakeups_enabled;
struct pm_qos_request pm_qos_request;
u32 latency;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d00b38e..b66818b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -910,11 +910,23 @@ serial_omap_set_termios(struct uart_port *port, struct
ktermios *termios,
dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
}
+static int serial_omap_set_wake(struct uart_port *port, unsigned int state)
+{
+ struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
+
+ if (pdata->enable_wakeup)
+ pdata->enable_wakeup(up->pdev, state ? true : false);
+
+ return 0;
+}
+
static void
serial_omap_pm(struct uart_port *port, unsigned int state,
unsigned int oldstate)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct omap_uart_port_info *pdata = up->pdev->dev.platform_data;
unsigned char efr;
dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->port.line);
@@ -930,12 +942,8 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
serial_out(up, UART_EFR, efr);
serial_out(up, UART_LCR, 0);
- if (!device_may_wakeup(&up->pdev->dev)) {
- if (!state)
- pm_runtime_forbid(&up->pdev->dev);
- else
- pm_runtime_allow(&up->pdev->dev);
- }
+ if (!state && pdata->enable_wakeup)
+ pdata->enable_wakeup(up->pdev, true);
pm_runtime_put(&up->pdev->dev);
}
@@ -1161,6 +1169,7 @@ static struct uart_ops serial_omap_pops = {
.shutdown = serial_omap_shutdown,
.set_termios= serial_omap_set_termios,
.pm = serial_omap_pm,
+ .set_wake = serial_omap_set_wake,
.type = serial_omap_type,
.release_port = serial_omap_release_port,
.request_port = serial_omap_request_port,
@@ -1184,10 +1193,14 @@ static struct uart_driver serial_omap_reg = {
static int serial_omap_suspend(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ struct omap_uart_port_info *pdata = dev->platform_data;
if (up) {
uart_suspend_port(&serial_omap_reg, &up->port);
flush_work_sync(&up->qos_work);
+
+ if (!device_may_wakeup(dev))
+ pdata->enable_wakeup(up->pdev, false);
}
return 0;
@@ -1476,6 +1489,9 @@ static int serial_omap_probe(struct platform_device *pdev)
if (ret != 0)
goto err_add_port;
+ if (omap_up_info->enable_wakeup)
+ omap_up_info->enable_wakeup(pdev, false);
+
pm_runtime_put(&pdev->dev);
platform_set_drvdata(pdev, up);
return 0;
@@ -1582,18 +1598,6 @@ static int serial_omap_runtime_suspend(struct device
*dev)
if (pdata->get_context_loss_count)
up->context_loss_cnt = pdata->get_context_loss_count(dev);
- if (device_may_wakeup(dev)) {
- if (!up->wakeups_enabled) {
- pdata->enable_wakeup(up->pd
Re: PM related performance degradation on OMAP3
On Tue, 2012-04-24 at 14:50 +0200, Jean Pihet wrote: > Hi Tero, > > On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo wrote: > > On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote: > >> + Tero > >> > >> On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote: > >> > Hi Grazvydas, Kevin, > >> > > >> > I did some gather some performance measurements and statistics using > >> > custom tracepoints in __omap3_enter_idle. > >> > All the details are at > >> > http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis > >> > . > >> > > >> Nice data. > >> > >> > The setup is: > >> > - Beagleboard (OMAP3530) at 500MHz, > >> > - l-o master kernel + functional power states + per-device PM QoS. It > >> > has been checked that the changes from l-o master do not have an > >> > impact on the performance. > >> > - The data transfer is performed using dd from a file in JFFS2 to > >> > /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. > > > > Question: what is used for gathering the latency values? > I used ftrace tracepoints which are supposed to be low overhead. I > checked that the overhead cannot be measured on the measurement > interval (>400us), given the fact that the time base is 31us (32 KHz > clock). If you want to get accurate measurements, you could use ARM performance counters, namely the cycle counter. I have a couple of patches for that purpose I've used if you are interested. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
Hi Tero, On Tue, Apr 24, 2012 at 2:21 PM, Tero Kristo wrote: > On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote: >> + Tero >> >> On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote: >> > Hi Grazvydas, Kevin, >> > >> > I did some gather some performance measurements and statistics using >> > custom tracepoints in __omap3_enter_idle. >> > All the details are at >> > http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis >> > . >> > >> Nice data. >> >> > The setup is: >> > - Beagleboard (OMAP3530) at 500MHz, >> > - l-o master kernel + functional power states + per-device PM QoS. It >> > has been checked that the changes from l-o master do not have an >> > impact on the performance. >> > - The data transfer is performed using dd from a file in JFFS2 to >> > /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. > > Question: what is used for gathering the latency values? I used ftrace tracepoints which are supposed to be low overhead. I checked that the overhead cannot be measured on the measurement interval (>400us), given the fact that the time base is 31us (32 KHz clock). >> > >> > On Tue, Apr 17, 2012 at 4:30 PM, Kevin Hilman wrote: >> >> Grazvydas Ignotas writes: >> >> >> >>> On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman wrote: >> It would be helpful now to narrow down what are the big contributors to >> the overhead in omap_sram_idle(). Most of the code there is skipped for >> C1 because the next states for MPU and CORE are both ON. >> >>> >> >>> Ok I did some tests, all in mostly idle system with just init, busybox >> >>> shell and dd doing a NAND read to /dev/null . >> >> >> > ... >> >> >> >>> MB/s is throughput that >> >>> dd reports, mA and approx. current draw during the transfer, read from >> >>> fuel gauge that's onboard. >> >>> >> >>> MB/s| mA|comment >> >>> 3.7|218|mainline f549e088b80 >> >>> 3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1] >> >>> 4.4|220|[1] + pwrdm_p*_transition commented [2] >> >>> 3.8|225|[1] + omap34xx_do_sram_idle->cpu_do_idle [3] >> >>> 4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4] >> >>> 4.0|224|[1] + 'Deny idle' [5] >> >>> 5.1|210|[2] + [4] + [5] >> >>> 5.2|202|[5] + omap_sram_idle->cpu_do_idle [6] >> >>> 5.5|243|!CONFIG_PM >> >>> 6.1|282|busywait DMA end (for reference) >> > >> > Here are the results (BW in MB/s) on Beagleboard: >> > - 4.7: without using DMA, >> > >> > - Using DMA >> > 2.1: [0] >> > 2.1: [1] only C1 >> > 2.6: [1]+[2] no pre_ post_ >> > 2.3: [1]+[5] no pwrdm_for_each_clkdm >> > 2.8: [1]+[5]+[2] >> > 3.1: [1]+[5]+[6] no omap_sram_idle >> > 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON >> > >> > So indeed this shows there is some serious performance issue with the >> > C1 C-state. >> > >> Looks like other clock-domain (notably l4, per, AON) should be denied >> idle in C1 to avoid the huge penalties. It might just do the trick. >> >> >> >> Thanks for the detailed experiments. This definitely confirms we have >> >> some serious unwanted overhead for C1, and our C-state latency values >> >> are clearly way off base, since they only account HW latency and not any >> >> of the SW latency introduced in omap_sram_idle(). >> >> >> There are 2 primary differences that I see as possible causes. I list >> them here with a couple more experiments for you to try to help us >> narrow this down. >> >> 1) powerdomain accounting: pwrdm_pre_transition(), >> pwrdm_post_transition() >> >> Could you try using omap_sram_idle() and just commenting out those >> calls? Does that help performance? Those iterate over all the >> powerdomains, so defintely add some overhead, but I don't think it >> would be as significant as what you're seeing. >> >>> >> >>> Seems to be taking good part of it. >> >>> >> Much more likely is... >> >> 2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds >> >>> >> >>> Could not notice any difference. >> >>> >> >>> To me it looks like this results from many small things adding up.. >> >>> Idle is called so often that pwrdm_p*_transition() and those >> >>> pwrdm_for_each_clkdm() walks start slowing everything down, perhaps >> >>> because they access lots of registers on slow buses? >> > >> > From the list of contributors, the main ones are: >> > (140us) pwrdm_pre_transition and pwrdm_post_transition, >> >> I have observed this one on OMAP4 too. There was a plan to remove >> this as part of Tero's PD/CD use-counting series. > > pwrdm_pre / post transitions could be optimized a bit already now. They > only should need to be called for mpu / core and per domains, but > currently they scan through everything. > >> >> > (105us) omap2_gpio_prepare_for_idle and >> > omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in >> > the latency-critical C-states, >> Yes. In C1 when you deny idle for per, there should be no need to >>
RE: OMAP3EVM not booting on l-o master
On Tue, 2012-04-24 at 14:00 +0200, Mohammed, Afzal wrote: > Hi Tero, > > On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote: > > Okay thats good (although I wonder why the attachment got corrupted.) > > Did you check if the device suspends / resumes properly also? Can you > > check what do you have in the /proc/interrupts for the hwmod_io > > interrupt just after boot / after one suspend? > > Device suspends & resumes properly. > > At boot 2, after one suspend-resume 3 Okay that looks normal to me, you just get some prcm interrupts during boot which was causing the device to hang earlier. Thanks for testing out. Paul, how should we take this forward? -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
On Tue, 2012-04-24 at 16:08 +0530, Santosh Shilimkar wrote: > + Tero > > On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote: > > Hi Grazvydas, Kevin, > > > > I did some gather some performance measurements and statistics using > > custom tracepoints in __omap3_enter_idle. > > All the details are at > > http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis > > . > > > Nice data. > > > The setup is: > > - Beagleboard (OMAP3530) at 500MHz, > > - l-o master kernel + functional power states + per-device PM QoS. It > > has been checked that the changes from l-o master do not have an > > impact on the performance. > > - The data transfer is performed using dd from a file in JFFS2 to > > /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. Question: what is used for gathering the latency values? > > > > On Tue, Apr 17, 2012 at 4:30 PM, Kevin Hilman wrote: > >> Grazvydas Ignotas writes: > >> > >>> On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman wrote: > It would be helpful now to narrow down what are the big contributors to > the overhead in omap_sram_idle(). Most of the code there is skipped for > C1 because the next states for MPU and CORE are both ON. > >>> > >>> Ok I did some tests, all in mostly idle system with just init, busybox > >>> shell and dd doing a NAND read to /dev/null . > >> > > ... > >> > >>> MB/s is throughput that > >>> dd reports, mA and approx. current draw during the transfer, read from > >>> fuel gauge that's onboard. > >>> > >>> MB/s| mA|comment > >>> 3.7|218|mainline f549e088b80 > >>> 3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1] > >>> 4.4|220|[1] + pwrdm_p*_transition commented [2] > >>> 3.8|225|[1] + omap34xx_do_sram_idle->cpu_do_idle [3] > >>> 4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4] > >>> 4.0|224|[1] + 'Deny idle' [5] > >>> 5.1|210|[2] + [4] + [5] > >>> 5.2|202|[5] + omap_sram_idle->cpu_do_idle [6] > >>> 5.5|243|!CONFIG_PM > >>> 6.1|282|busywait DMA end (for reference) > > > > Here are the results (BW in MB/s) on Beagleboard: > > - 4.7: without using DMA, > > > > - Using DMA > > 2.1: [0] > > 2.1: [1] only C1 > > 2.6: [1]+[2] no pre_ post_ > > 2.3: [1]+[5] no pwrdm_for_each_clkdm > > 2.8: [1]+[5]+[2] > > 3.1: [1]+[5]+[6] no omap_sram_idle > > 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON > > > > So indeed this shows there is some serious performance issue with the > > C1 C-state. > > > Looks like other clock-domain (notably l4, per, AON) should be denied > idle in C1 to avoid the huge penalties. It might just do the trick. > > > >> Thanks for the detailed experiments. This definitely confirms we have > >> some serious unwanted overhead for C1, and our C-state latency values > >> are clearly way off base, since they only account HW latency and not any > >> of the SW latency introduced in omap_sram_idle(). > >> > There are 2 primary differences that I see as possible causes. I list > them here with a couple more experiments for you to try to help us > narrow this down. > > 1) powerdomain accounting: pwrdm_pre_transition(), > pwrdm_post_transition() > > Could you try using omap_sram_idle() and just commenting out those > calls? Does that help performance? Those iterate over all the > powerdomains, so defintely add some overhead, but I don't think it > would be as significant as what you're seeing. > >>> > >>> Seems to be taking good part of it. > >>> > Much more likely is... > > 2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds > >>> > >>> Could not notice any difference. > >>> > >>> To me it looks like this results from many small things adding up.. > >>> Idle is called so often that pwrdm_p*_transition() and those > >>> pwrdm_for_each_clkdm() walks start slowing everything down, perhaps > >>> because they access lots of registers on slow buses? > > > > From the list of contributors, the main ones are: > > (140us) pwrdm_pre_transition and pwrdm_post_transition, > > I have observed this one on OMAP4 too. There was a plan to remove > this as part of Tero's PD/CD use-counting series. pwrdm_pre / post transitions could be optimized a bit already now. They only should need to be called for mpu / core and per domains, but currently they scan through everything. > > > (105us) omap2_gpio_prepare_for_idle and > > omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in > > the latency-critical C-states, > Yes. In C1 when you deny idle for per, there should be no need to > call this. But even in the case when it is called, why is it taking > 105 uS. Needs to dig further. > > > (78us) pwrdm_for_each_clkdm(mpu, core, deny_idle/allow_idle), > Depending on OPP, a PRCM read can take upto ~12-14 uS, so above > shouldn't be surprising. > > > (33us estimated) omap_set_pwrdm_state(mpu, core, neon), > This is again dominated by PRCM read > > >
RE: OMAP3EVM not booting on l-o master
Hi Tero, On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote: > Okay thats good (although I wonder why the attachment got corrupted.) > Did you check if the device suspends / resumes properly also? Can you > check what do you have in the /proc/interrupts for the hwmod_io > interrupt just after boot / after one suspend? Device suspends & resumes properly. At boot 2, after one suspend-resume 3 Regards Afzal
Re: [PATCH 3/8] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Tuesday 24 April 2012 04:20 PM, Russell King - ARM Linux wrote: For cyclic case, we will not like to call the dma_cookie_complete() but want to put the desc in callback list. So can we have one more arg on this function which byspass the call of dma_cookie_complete() See the discussion on what's supposed to happen with cyclic transfers. Cyclic transfers don't complete, so adding them to the completed list and marking them complete is the wrong thing to be doing. So arguably calling this function is also the wrong thing to be doing because you're not completing the transfer. OK, we will not call this function but still need to call the callback. So do you suggest to call callback directly from dma driver rather than the virt_chan? I'll be addressing the issue of cyclic transfers when I eventually get to sorting out the OMAP ASoC driver. Here I am developing the dma driver for Tegra in cyclic and normal mode and what is your suggestion here? Should I use your virt_chan now or I can go ahead with my first patch without virt_chan and once you are done with your virt_chan with all cyclic support then port the tegra_dma to use virt chan and next enhanced patch? In this way, my Tegra dma will be there in tree, all client will be move to dma engine based driver and then I will comeback to tegra_dma for using the virt_channel. -- To unsubscribe from this list: send the line "unsubscribe 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/8] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Tue, Apr 24, 2012 at 04:05:29PM +0530, Laxman Dewangan wrote:
> On Wednesday 18 April 2012 03:41 PM, Russell King wrote:
>> +/**
>> + * vchan_cookie_complete - report completion of a descriptor
>> + * vd: virtual descriptor to update
>> + *
>> + * vc.lock must be held by caller
>> + */
>> +static inline void vchan_cookie_complete(struct virt_dma_desc *vd)
>> +{
>> + struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
>> +
>> + dma_cookie_complete(&vd->tx);
>> + dev_vdbg(vc->chan.device->dev, "txd %p[%x]: marked complete\n",
>> + vd, vd->tx.cookie);
>> + list_add_tail(&vd->node,&vc->desc_completed);
>> +
>> + tasklet_schedule(&vc->task);
>> +}
>
> For cyclic case, we will not like to call the dma_cookie_complete() but
> want to put the desc in callback list.
> So can we have one more arg on this function which byspass the call of
> dma_cookie_complete()
See the discussion on what's supposed to happen with cyclic transfers.
Cyclic transfers don't complete, so adding them to the completed list
and marking them complete is the wrong thing to be doing. So arguably
calling this function is also the wrong thing to be doing because
you're not completing the transfer.
I'll be addressing the issue of cyclic transfers when I eventually get
to sorting out the OMAP ASoC driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/12] OMAP DMA engine conversion
Here's another patch - for the OMAP NAND driver.
One thing this doesn't do is configure up the source/destination bursts,
which the old code did:
omap_set_dma_dest_burst_mode(info->dma_ch,
OMAP_DMA_DATA_BURST_16);
omap_set_dma_src_burst_mode(info->dma_ch,
OMAP_DMA_DATA_BURST_16);
In dma-engine speak, I'm using "burst" for the number of elements to
transfer for each frame, with frame sync in place (in other words, the
number of transfers to occur for every assertion of the DMA request.)
That's how burst is defined on other DMA hardware, so I'm not entirely
sure at the moment how critical (or what) the above bursts are doing,
whether they're configuring the memory side of the transfer or not.
I'll take a deeper look into that this evening, but in the mean time,
what's below should be a direct conversion.
MTD does have this weirdness that it uses vmalloc regions and passes
addresses in vmalloc regions into drivers - I've left that hack in but
it is _highly_ undefined whether the DMA activity would be visible via
the vmalloc mapping as things currently stand. (You're probably going
to be okay with non-aliasing VIPT caches, but VIVT and aliasing VIPT
caches are potential random data corruption candidates.) That's a
short-coming across many MTD drivers, one which needs sorting out across
the board.
drivers/mtd/nand/omap2.c | 93 +-
1 files changed, 92 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c2b0bba..bd4ed08 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -9,6 +9,7 @@
*/
#include
+#include
#include
#include
#include
@@ -119,6 +120,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
struct completion comp;
+ struct dma_chan *dma;
int dma_ch;
int gpmc_irq;
enum {
@@ -336,6 +338,10 @@ static void omap_nand_dma_cb(int lch, u16 ch_status, void
*data)
{
complete((struct completion *) data);
}
+static void omap_nand_dma_callback(void *data)
+{
+ complete((struct completion *) data);
+}
/*
* omap_nand_dma_transfer: configer and start dma transfer
@@ -373,6 +379,56 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
}
+ if (info->dma) {
+ struct dma_async_tx_descriptor *tx;
+ struct scatterlist sg;
+ unsigned n;
+
+ sg_init_one(&sg, addr, len);
+ n = dma_map_sg(info->dma->device->dev, &sg, 1, dir);
+ if (n == 0) {
+ dev_err(&info->pdev->dev,
+ "Couldn't DMA map a %d byte buffer\n", len);
+ goto out_copy;
+ }
+
+ tx = dmaengine_prep_slave_sg(info->dma, &sg, n,
+ is_write ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!tx) {
+ dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
+ goto out_copy;
+ }
+ tx->callback = omap_nand_dma_callback;
+ tx->callback_param = &info->comp;
+ dmaengine_submit(tx);
+
+ /* configure and start prefetch transfer */
+ ret = gpmc_prefetch_enable(info->gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write);
+ if (ret) {
+ /* PFPW engine is busy, use cpu copy method */
+ dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
+ goto out_copy;
+ }
+
+ init_completion(&info->comp);
+ dma_async_issue_pending(info->dma);
+
+ /* setup and start DMA using dma_addr */
+ wait_for_completion(&info->comp);
+ tim = 0;
+ limit = (loops_per_jiffy *
msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
+ while (gpmc_read_status(GPMC_PREFETCH_COUNT) && (tim++ < limit))
+ cpu_relax();
+
+ /* disable and stop the PFPW engine */
+ gpmc_prefetch_reset(info->gpmc_cs);
+
+ dma_unmap_sg(info->dma->device->dev, &sg, 1, dir);
+ return 0;
+ }
+
dma_addr = dma_map_single(&info->pdev->dev, addr, len, dir);
if (dma_mapping_error(&info->pdev->dev, dma_addr)) {
dev_err(&info->pdev->dev,
@@ -405,7 +461,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
goto out_copy;
Re: PM related performance degradation on OMAP3
+ Tero On Tuesday 24 April 2012 03:20 PM, Jean Pihet wrote: > Hi Grazvydas, Kevin, > > I did some gather some performance measurements and statistics using > custom tracepoints in __omap3_enter_idle. > All the details are at > http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis > . > Nice data. > The setup is: > - Beagleboard (OMAP3530) at 500MHz, > - l-o master kernel + functional power states + per-device PM QoS. It > has been checked that the changes from l-o master do not have an > impact on the performance. > - The data transfer is performed using dd from a file in JFFS2 to > /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. > > On Tue, Apr 17, 2012 at 4:30 PM, Kevin Hilman wrote: >> Grazvydas Ignotas writes: >> >>> On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman wrote: It would be helpful now to narrow down what are the big contributors to the overhead in omap_sram_idle(). Most of the code there is skipped for C1 because the next states for MPU and CORE are both ON. >>> >>> Ok I did some tests, all in mostly idle system with just init, busybox >>> shell and dd doing a NAND read to /dev/null . >> > ... >> >>> MB/s is throughput that >>> dd reports, mA and approx. current draw during the transfer, read from >>> fuel gauge that's onboard. >>> >>> MB/s| mA|comment >>> 3.7|218|mainline f549e088b80 >>> 3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1] >>> 4.4|220|[1] + pwrdm_p*_transition commented [2] >>> 3.8|225|[1] + omap34xx_do_sram_idle->cpu_do_idle [3] >>> 4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4] >>> 4.0|224|[1] + 'Deny idle' [5] >>> 5.1|210|[2] + [4] + [5] >>> 5.2|202|[5] + omap_sram_idle->cpu_do_idle [6] >>> 5.5|243|!CONFIG_PM >>> 6.1|282|busywait DMA end (for reference) > > Here are the results (BW in MB/s) on Beagleboard: > - 4.7: without using DMA, > > - Using DMA > 2.1: [0] > 2.1: [1] only C1 > 2.6: [1]+[2] no pre_ post_ > 2.3: [1]+[5] no pwrdm_for_each_clkdm > 2.8: [1]+[5]+[2] > 3.1: [1]+[5]+[6] no omap_sram_idle > 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON > > So indeed this shows there is some serious performance issue with the > C1 C-state. > Looks like other clock-domain (notably l4, per, AON) should be denied idle in C1 to avoid the huge penalties. It might just do the trick. >> Thanks for the detailed experiments. This definitely confirms we have >> some serious unwanted overhead for C1, and our C-state latency values >> are clearly way off base, since they only account HW latency and not any >> of the SW latency introduced in omap_sram_idle(). >> There are 2 primary differences that I see as possible causes. I list them here with a couple more experiments for you to try to help us narrow this down. 1) powerdomain accounting: pwrdm_pre_transition(), pwrdm_post_transition() Could you try using omap_sram_idle() and just commenting out those calls? Does that help performance? Those iterate over all the powerdomains, so defintely add some overhead, but I don't think it would be as significant as what you're seeing. >>> >>> Seems to be taking good part of it. >>> Much more likely is... 2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds >>> >>> Could not notice any difference. >>> >>> To me it looks like this results from many small things adding up.. >>> Idle is called so often that pwrdm_p*_transition() and those >>> pwrdm_for_each_clkdm() walks start slowing everything down, perhaps >>> because they access lots of registers on slow buses? > > From the list of contributors, the main ones are: > (140us) pwrdm_pre_transition and pwrdm_post_transition, I have observed this one on OMAP4 too. There was a plan to remove this as part of Tero's PD/CD use-counting series. > (105us) omap2_gpio_prepare_for_idle and > omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in > the latency-critical C-states, Yes. In C1 when you deny idle for per, there should be no need to call this. But even in the case when it is called, why is it taking 105 uS. Needs to dig further. > (78us) pwrdm_for_each_clkdm(mpu, core, deny_idle/allow_idle), Depending on OPP, a PRCM read can take upto ~12-14 uS, so above shouldn't be surprising. > (33us estimated) omap_set_pwrdm_state(mpu, core, neon), This is again dominated by PRCM read > (11 us) clkdm_allow_idle(mpu). Is this needed? > I guess yes other wise when C2+ is attempted MPU CD can't idle. > Here are a few questions and suggestions: > - In case of latency critical C-states could the high-latency code be > bypassed in favor of a much simpler version? Pushing the concept a bit > farther one could have a C1 state that just relaxes the cpu (no WFI), > a C2 state which bypasses a lot of code in __omap3_enter_idle, and the > rest of the C-states as we have today, We should do that. Infact C1 state should be as lite
Re: [PATCH 3/8] dmaengine: split out virtual channel DMA support from sa11x0 driver
On Wednesday 18 April 2012 03:41 PM, Russell King wrote:
+/**
+ * vchan_cookie_complete - report completion of a descriptor
+ * vd: virtual descriptor to update
+ *
+ * vc.lock must be held by caller
+ */
+static inline void vchan_cookie_complete(struct virt_dma_desc *vd)
+{
+ struct virt_dma_chan *vc = to_virt_chan(vd->tx.chan);
+
+ dma_cookie_complete(&vd->tx);
+ dev_vdbg(vc->chan.device->dev, "txd %p[%x]: marked complete\n",
+ vd, vd->tx.cookie);
+ list_add_tail(&vd->node,&vc->desc_completed);
+
+ tasklet_schedule(&vc->task);
+}
For cyclic case, we will not like to call the dma_cookie_complete() but
want to put the desc in callback list.
So can we have one more arg on this function which byspass the call of
dma_cookie_complete()
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V4 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Tue, Apr 24, 2012 at 15:36:43, Shilimkar, Santosh wrote: > On Tue, Apr 24, 2012 at 3:15 PM, Vaibhav Hiremath wrote: > > Current OMAP code supports couple of clocksource options based > > on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer > > and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) > > > > This patch series cleans up the existing 32k-sync timer implementation > > without any major code changes, uses kernel parameter to override > > the default clocksource of "counter_32k", also in order to support > > some OMAP based derivative SoCs like AM33XX which doesn't have > > 32K sync-timer hardware IP, adds hwmod lookup for omap2+ > > devices, and if lookup fails then fall back to gp-timer. > > > > if(use_gptimer_clksrc == true) > > gptimer clocksource init; > > else if (counter_32 init == false) > > /* Fallback to gptimer */ > > gptimer clocksource init(; > > > > With this, we should be able to support multi-omap boot > > including devices with/without 32k-sync timer. > > > > This patch-series has been boot tested on AM37xEVM platform, it > > would be helpful if somebody help me to validate it on OMAP1/2 > > platforms. > > > > The patches are also available at - > > https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup > > > > History: > > > > Changes from V3: > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66462.html > > - Fixed all review comments from Kevin H > > * Moved counter_32k CR register offset handling to > > counter_32k.c file, so now, calling funtion don't have > > to maintain or add offset to base addr. > > * Added comment for funtion omap_init_clocksource_32k() > > * Used resource_size() for calculate size > > * Convert WARN_ON to pr_warn > > > Have given my reviewed-by on v2. Just quickly scanned the series > based on above minor updates. > Feel free to add, > > Sorry, I missed to add your Reviewed-by here. I believe this should be now last version, and should get merged by either Tony or Paul. Tony & Paul, Note to add line, "Reviewed-by: Santosh Shilimkar " Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V4 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
On Tue, Apr 24, 2012 at 3:15 PM, Vaibhav Hiremath wrote: > Current OMAP code supports couple of clocksource options based > on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer > and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) > > This patch series cleans up the existing 32k-sync timer implementation > without any major code changes, uses kernel parameter to override > the default clocksource of "counter_32k", also in order to support > some OMAP based derivative SoCs like AM33XX which doesn't have > 32K sync-timer hardware IP, adds hwmod lookup for omap2+ > devices, and if lookup fails then fall back to gp-timer. > > if(use_gptimer_clksrc == true) > gptimer clocksource init; > else if (counter_32 init == false) > /* Fallback to gptimer */ > gptimer clocksource init(; > > With this, we should be able to support multi-omap boot > including devices with/without 32k-sync timer. > > This patch-series has been boot tested on AM37xEVM platform, it > would be helpful if somebody help me to validate it on OMAP1/2 > platforms. > > The patches are also available at - > https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup > > History: > > Changes from V3: > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66462.html > - Fixed all review comments from Kevin H > * Moved counter_32k CR register offset handling to > counter_32k.c file, so now, calling funtion don't have > to maintain or add offset to base addr. > * Added comment for funtion omap_init_clocksource_32k() > * Used resource_size() for calculate size > * Convert WARN_ON to pr_warn > Have given my reviewed-by on v2. Just quickly scanned the series based on above minor updates. Feel free to add, Reviewed-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe 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-V4 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the existing 32k-sync timer implementation
without any major code changes, uses kernel parameter to override
the default clocksource of "counter_32k", also in order to support
some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP, adds hwmod lookup for omap2+
devices, and if lookup fails then fall back to gp-timer.
if(use_gptimer_clksrc == true)
gptimer clocksource init;
else if (counter_32 init == false)
/* Fallback to gptimer */
gptimer clocksource init(;
With this, we should be able to support multi-omap boot
including devices with/without 32k-sync timer.
This patch-series has been boot tested on AM37xEVM platform, it
would be helpful if somebody help me to validate it on OMAP1/2
platforms.
The patches are also available at -
https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup
History:
Changes from V3:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66462.html
- Fixed all review comments from Kevin H
* Moved counter_32k CR register offset handling to
counter_32k.c file, so now, calling funtion don't have
to maintain or add offset to base addr.
* Added comment for funtion omap_init_clocksource_32k()
* Used resource_size() for calculate size
* Convert WARN_ON to pr_warn
Changes from V2:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/092037.html
- Added early_param support to read clocksource selection
from user through kernel parameter ("clocksource=")
- Converted to ocp_if changes from Paul
Changes from V1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081037.html
- Based on Tony's comment, added pbase & size argument to
omap_init_clocksource_32k(), to avoid cpu_is_xxx() check.
- Added commit description based on discussion on list
(Thanks to Santosh here)
- Reorder patch sequence
Vaibhav Hiremath (3):
ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common
header
ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database
ARM: OMAP: Make OMAP clocksource source selection using kernel param
arch/arm/mach-omap1/timer32k.c |6 +-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 19
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 ++
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
arch/arm/mach-omap2/prcm-common.h |4 +
arch/arm/mach-omap2/timer.c| 99 ++
arch/arm/plat-omap/counter_32k.c | 108 ++--
arch/arm/plat-omap/include/plat/common.h |2 +-
10 files changed, 254 insertions(+), 77 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Also, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use kernel parameter ("clocksource=") to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Felipe Balbi
Cc: Santosh Shilimkar
Cc: Kevin Hilman
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Paul Walmsley
Cc: Tarun Kanti DebBarma
Cc: Ming Lei
---
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 99 +--
arch/arm/plat-omap/counter_32k.c | 108 +++---
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 138 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 325b9a0..6262e11 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -71,6 +71,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ecec873..2afc4ab 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -243,22 +243,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
+static bool use_gptimer_clksrc;
/*
* clocksource
@@ -285,7 +271,33 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static int __init omap2_sync32k_clocksource_init(void)
+{
+ int ret;
+ struct omap_hwmod *oh;
+ struct resource res;
+ const char *oh_name = "counter_32k";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh || oh->slaves_cnt == 0)
+ return -ENODEV;
+
+ ret = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM, NULL, &res);
+ if (ret) {
+ pr_warn("%s: failed to get counter_32k resource (%d)\n",
+ __func__, ret);
+ return ret;
+ }
+
+ ret = omap_init_clocksource_32k(res.start, resource_size(&res));
+ if (ret)
+ pr_warn("%s: failed to initialize counter_32k (%d)\n",
+ __func__, ret);
+
+ return ret;
+}
+
+static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
{
int res;
@@ -293,9 +305,6 @@ static void __init omap2_gp_clocksource_init(int gptimer_id,
res = omap_dm_timer_init_one(&clksrc, gptimer_id, fck_source);
[PATCH-V4 2/3] ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database
Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 & 3 hwmod table.
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Felipe Balbi
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
5 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2c087ff..b961b0d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -428,6 +428,24 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup -> 32ksync_counter */
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x4800401f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master = &omap2xxx_l4_wkup_hwmod,
+ .slave = &omap2xxx_counter_32k_hwmod,
+ .clk= "sync_32k_ick",
+ .addr = omap2420_counter_32k_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -468,6 +486,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
&omap2420_l4_core__mailbox,
&omap2420_l4_core__mcbsp1,
&omap2420_l4_core__mcbsp2,
+ &omap2420_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 71d9f88..c9ac3ec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -838,6 +838,24 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp5 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup -> 32ksync_counter */
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x4902,
+ .pa_end = 0x4902001f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master = &omap2xxx_l4_wkup_hwmod,
+ .slave = &omap2xxx_counter_32k_hwmod,
+ .clk= "sync_32k_ick",
+ .addr = omap2430_counter_32k_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
&omap2xxx_l3_main__l4_core,
&omap2xxx_mpu__l3_main,
@@ -886,6 +904,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
&omap2430_l4_core__mcbsp3,
&omap2430_l4_core__mcbsp4,
&omap2430_l4_core__mcbsp5,
+ &omap2430_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 45aaa07..8c37cb5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -732,3 +732,22 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.class = &omap2xxx_mcspi_class,
.dev_attr = &omap_mcspi2_dev_attr,
};
+
+static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
+ .name = "counter",
+};
+
+struct omap_hwmod omap2xxx_counter_32k_hwmod = {
+ .name = "counter_32k",
+ .main_clk = "func_32k_ck",
+ .prcm = {
+ .omap2 = {
+ .module_offs = WKUP_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_ST_32KSYNC_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_32KSYNC_SHIFT,
+ },
+ },
+ .class = &omap2xxx_counter_hwmod_class,
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c65079..f55dc6a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1981,6 +1981,40 @@ static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
};
/*
+ * '32K sync counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+static struct omap_hwmod_class_sysconfig omap3xxx_counter_sysc = {
+ .rev_offs = 0x,
+ .sysc_o
[PATCH-V4 1/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath Cc: Felipe Balbi Cc: Benoit Cousson Cc: Tony Lindgren Cc: Paul Walmsley --- arch/arm/mach-omap2/prcm-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 5aa5435..29955d5 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -177,6 +177,8 @@ /* PM_WKST_WKUP, CM_IDLEST_WKUP shared bits */ #define OMAP24XX_ST_GPIOS_SHIFT2 #define OMAP24XX_ST_GPIOS_MASK (1 << 2) +#define OMAP24XX_ST_32KSYNC_SHIFT 1 +#define OMAP24XX_ST_32KSYNC_MASK (1 << 1) #define OMAP24XX_ST_GPT1_SHIFT 0 #define OMAP24XX_ST_GPT1_MASK (1 << 0) @@ -307,6 +309,8 @@ #define OMAP3430_ST_SR1_MASK (1 << 6) #define OMAP3430_ST_GPIO1_SHIFT3 #define OMAP3430_ST_GPIO1_MASK (1 << 3) +#define OMAP3430_ST_32KSYNC_SHIFT 2 +#define OMAP3430_ST_32KSYNC_MASK (1 << 2) #define OMAP3430_ST_GPT12_SHIFT1 #define OMAP3430_ST_GPT12_MASK (1 << 1) #define OMAP3430_ST_GPT1_SHIFT 0 -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PM related performance degradation on OMAP3
Hi Grazvydas, Kevin, I did some gather some performance measurements and statistics using custom tracepoints in __omap3_enter_idle. All the details are at http://www.omappedia.org/wiki/Power_Management_Device_Latencies_Measurement#C1_performance_problem:_analysis . The setup is: - Beagleboard (OMAP3530) at 500MHz, - l-o master kernel + functional power states + per-device PM QoS. It has been checked that the changes from l-o master do not have an impact on the performance. - The data transfer is performed using dd from a file in JFFS2 to /dev/null: 'dd if=/tmp/mnt/a of=/dev/null bs=1M count=32'. On Tue, Apr 17, 2012 at 4:30 PM, Kevin Hilman wrote: > Grazvydas Ignotas writes: > >> On Thu, Apr 12, 2012 at 3:19 AM, Kevin Hilman wrote: >>> It would be helpful now to narrow down what are the big contributors to >>> the overhead in omap_sram_idle(). Most of the code there is skipped for >>> C1 because the next states for MPU and CORE are both ON. >> >> Ok I did some tests, all in mostly idle system with just init, busybox >> shell and dd doing a NAND read to /dev/null . > ... > >> MB/s is throughput that >> dd reports, mA and approx. current draw during the transfer, read from >> fuel gauge that's onboard. >> >> MB/s| mA|comment >> 3.7|218|mainline f549e088b80 >> 3.8|224|nand qos PM_QOS_CPU_DMA_LATENCY 0 [1] >> 4.4|220|[1] + pwrdm_p*_transition commented [2] >> 3.8|225|[1] + omap34xx_do_sram_idle->cpu_do_idle [3] >> 4.2|210|[1] + pwrdm_set_next_pwrst(per_pd, PWRDM_POWER_ON) [4] >> 4.0|224|[1] + 'Deny idle' [5] >> 5.1|210|[2] + [4] + [5] >> 5.2|202|[5] + omap_sram_idle->cpu_do_idle [6] >> 5.5|243|!CONFIG_PM >> 6.1|282|busywait DMA end (for reference) Here are the results (BW in MB/s) on Beagleboard: - 4.7: without using DMA, - Using DMA 2.1: [0] 2.1: [1] only C1 2.6: [1]+[2] no pre_ post_ 2.3: [1]+[5] no pwrdm_for_each_clkdm 2.8: [1]+[5]+[2] 3.1: [1]+[5]+[6] no omap_sram_idle 3.1: No IDLE, no omap_sram_idle, all pwrdms to ON So indeed this shows there is some serious performance issue with the C1 C-state. > Thanks for the detailed experiments. This definitely confirms we have > some serious unwanted overhead for C1, and our C-state latency values > are clearly way off base, since they only account HW latency and not any > of the SW latency introduced in omap_sram_idle(). > >>> There are 2 primary differences that I see as possible causes. I list >>> them here with a couple more experiments for you to try to help us >>> narrow this down. >>> >>> 1) powerdomain accounting: pwrdm_pre_transition(), pwrdm_post_transition() >>> >>> Could you try using omap_sram_idle() and just commenting out those >>> calls? Does that help performance? Those iterate over all the >>> powerdomains, so defintely add some overhead, but I don't think it >>> would be as significant as what you're seeing. >> >> Seems to be taking good part of it. >> >>> Much more likely is... >>> >>> 2) jump to SRAM, SDRC self-refresh, SDRC errata workarounds >> >> Could not notice any difference. >> >> To me it looks like this results from many small things adding up.. >> Idle is called so often that pwrdm_p*_transition() and those >> pwrdm_for_each_clkdm() walks start slowing everything down, perhaps >> because they access lots of registers on slow buses? >From the list of contributors, the main ones are: (140us) pwrdm_pre_transition and pwrdm_post_transition, (105us) omap2_gpio_prepare_for_idle and omap2_gpio_resume_after_idle. This could be avoided if PER stays ON in the latency-critical C-states, (78us) pwrdm_for_each_clkdm(mpu, core, deny_idle/allow_idle), (33us estimated) omap_set_pwrdm_state(mpu, core, neon), (11 us) clkdm_allow_idle(mpu). Is this needed? Here are a few questions and suggestions: - In case of latency critical C-states could the high-latency code be bypassed in favor of a much simpler version? Pushing the concept a bit farther one could have a C1 state that just relaxes the cpu (no WFI), a C2 state which bypasses a lot of code in __omap3_enter_idle, and the rest of the C-states as we have today, - Is it needed to iterate through all the power and clock domains in order to keep them active? - Trying to idle some non related power domains (e.g. PER) causes a performance hit. How to link all the power domains states to the cpuidle C-state? The per-device PM QoS framework could be used to constraint some power domains, but this is highly dependent on the use case. > Yes PRCM register accesses are unfortunately rather slow, and we've > known that for some time, but haven't done any detailed analysis of the > overhead. That would be worth doing the analysis. A lot of read accesses to the current, next and previous power states are performed in the idle code. > Using the function_graph tracer, I was able to see that the pre/post > transition are taking an enormous amount of time: > > - pwrdm pre-transition: 1400+ us at 600MHz (4000+ us at 125MHz) > - pwrdm post-transtion: 160
Re: defconfig for panda
On Fri, Apr 20, 2012 at 10:43 PM, Tony Lindgren wrote: > * Matt Porter [120420 09:04]: >> On Fri, Mar 30, 2012 at 02:39:32PM -0700, Tony Lindgren wrote: >> > * Kumar Gala [120330 14:14]: >> > > >> > > On Mar 30, 2012, at 1:48 PM, Tony Lindgren wrote: >> > > >> > > > Hi, >> > > > >> > > > * Kumar Gala [120329 12:24]: >> > > >> As I'm new to the OMAP community this might be a stupid question but >> > > >> trying to just build and run a stock v3.3 kernel on a pandaboard. In >> > > >> doing so it seems as if some basic drivers are not enabled in >> > > >> omap2plus_defconfig for the board. I'm trying to figure out if this >> > > >> is normal for some reason or just an oversight. >> > > >> >> > > >> For example, USB and USB ethernet (SMC95xx). I notice the linaro >> > > >> kernel tree introduces an omap4_defconfig, so just wondering should I >> > > >> send patches to omap2plus_defconfig or what? >> > > > >> > > > We can add those to omap2plus_defconfig for sure, but let's have >> > > > them added as modules. Then distros can use that easily in a >> > > > standard way using initramfs-tools etc. >> > > > >> > > > Let's not change the drivers that are currently built in if they're >> > > > needed for mounting mmc or nfsroot. Those can be changed later on. >> > > >> > > I'll work up a patch, however I was doing this as I was trying to get >> > > NFS root working and thus would need USB + USB ethernet compiled in and >> > > not as modules for panda. Is that ok? >> > >> > Maybe, let's take a look how much bigger the kernel becomes. >> > Also we need to check if the same EHCI configuration works >> > for omap3/4. >> >> FWIW, the same EHCI + SMSC95xx config is used for Beagle xM for >> nfsroot. First thing I enable on any builds. > > OK, can somebody please do a minimal patch to omap2plus_defconfig > for this? > > Basically run make savedefconfig with those changes added and > then diff against omap2plus_defconfig. > I have not seen the patch to enable this on the list, so here is the patch[1] to do the same. -- Thanks, Govindraj.R [1]: >From 2965cfb8c05003dba333963c6206b5457adad943 Mon Sep 17 00:00:00 2001 From: "Govindraj.R" Date: Tue, 24 Apr 2012 14:41:53 +0530 Subject: [PATCH] ARM: omap2plus_defconfig: Enable ehci-omap and sms95xx support Boards like beagle and panda use ehci based smsc95xx lan chips one has to manually enable these supports to get nfs working on these boards. So keep these support enable by default. Signed-off-by: Govindraj.R --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..9854ff4 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -98,6 +98,7 @@ CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y CONFIG_USB_USBNET=y +CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y @@ -175,6 +176,7 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y -- 1.7.9 0001-ARM-omap2plus_defconfig-Enable-ehci-omap-and-sms95xx.patch Description: Binary data
Re: [PATCH 1/2] OMAP2+: UART: Fix incorrect population of default uart pads
On Tue, Apr 24, 2012 at 5:15 AM, Kevin Hilman wrote: > "Govindraj.R" writes: > >> From: "Govindraj.R" >> >> The following commit: >> (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) >> added default pads for all uarts. But not all boards tend to >> use all uarts and most of unused uart pins are muxed for >> other purpose. This commit breaks the modules which where trying >> to use unused uart pins on their boards. >> >> So remove the default pads adding. > > I just noticed that this patch breaks runtime PM & wakeups for UART > console (at least on 3530/Overo with ttyO2 console.) > > By removing the pads, the initial device_init_wakeup() is not called on > port init. Without this call serial_omap_pm() disables runtime PM > because it checks device_may_wakeup(). > > Since runtime PM was disabled, I manually re-enabled it and then enabled > wakeups: > > echo auto > /sys/devices/platform/omap_uart.2/power/control > echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup > > Then, after enabling auto-suspend timeouts, it seems wakeups are still > not working since the console hangs. > > Reverting $SUBJECT patch gets things working again. This was decided as part of discussion [1] If we are _reconsidering_ taking this patch [2] to dynamically probe uart pins and enable rx wakeup. I can re-work on the patch[2] as per tony's comments[1] and re-post it. -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-omap/msg68226.html [2]: http://www.spinics.net/lists/linux-omap/msg67822.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
