Re: [PATCH] ARM: OMAP: L3 interconnect: Error reporting cleanups
Tod, On 5/25/2011 8:20 AM, Todd Poynor wrote: * Move variable declarations from header file and make these static (the entire header file should probably go away). Infact the intial version posted on the list had all these structures in C file. After some comments on the list we moved them to header file. Let's not move it again. * Define L3 TARG instance offsets, and read/write STDERRLOG registers relative to those offsets, rather than defining STDERRLOG_MAIN instance offsets and accessing other registers via offsets from that register. * Use ffs() to find error source from the L3_FLAGMUX_REGERRn register. * Remove extra l3_base[] entry. * Modify L3 custom error message for consistency with standard error message. These changes are ok. * Fixup indentation in one spot. This code indentations needs more fixing and I have patch to clean that up. Your change is already part of that patch. --- arch/arm/mach-omap2/omap_l3_noc.c | 122 +++-- arch/arm/mach-omap2/omap_l3_noc.h | 88 +- 2 files changed, 106 insertions(+), 104 deletions(-) Can you update your patch with above. I will add that along with other L3 clean-up patch. Thanks 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
[PATCH V2] PM: OPP: introduce function to free cpufreq table
cpufreq table allocated by opp_init_cpufreq_table is better
freed by OPP layer itself. This allows future modifications to
the table handling to be transparent to the users.
Signed-off-by: Nishanth Menon
---
V2: removed lock of free.
V1: http://marc.info/?t=13061924171&r=1&w=2
Example discussion: http://marc.info/?t=13057044065&r=1&w=2
Documentation/power/opp.txt |2 ++
drivers/base/power/opp.c| 17 +
include/linux/opp.h |8
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 5ae70a1..3035d00 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -321,6 +321,8 @@ opp_init_cpufreq_table - cpufreq framework typically is
initialized with
addition to CONFIG_PM as power management feature is required to
dynamically scale voltage and frequency in a system.
+opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table
+
7. Data Structures
==
Typically an SoC contains multiple voltage domains which are variable. Each
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 56a6899..5cc1232 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -625,4 +625,21 @@ int opp_init_cpufreq_table(struct device *dev,
return 0;
}
+
+/**
+ * opp_free_cpufreq_table() - free the cpufreq table
+ * @dev: device for which we do this operation
+ * @table: table to free
+ *
+ * Free up the table allocated by opp_init_cpufreq_table
+ */
+void opp_free_cpufreq_table(struct device *dev,
+ struct cpufreq_frequency_table **table)
+{
+ if (!table)
+ return;
+
+ kfree(*table);
+ *table = NULL;
+}
#endif /* CONFIG_CPU_FREQ */
diff --git a/include/linux/opp.h b/include/linux/opp.h
index 5449945..7020e97 100644
--- a/include/linux/opp.h
+++ b/include/linux/opp.h
@@ -94,12 +94,20 @@ static inline int opp_disable(struct device *dev, unsigned
long freq)
#if defined(CONFIG_CPU_FREQ) && defined(CONFIG_PM_OPP)
int opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table);
+void opp_free_cpufreq_table(struct device *dev,
+ struct cpufreq_frequency_table **table);
#else
static inline int opp_init_cpufreq_table(struct device *dev,
struct cpufreq_frequency_table **table)
{
return -EINVAL;
}
+
+static inline
+void opp_free_cpufreq_table(struct device *dev,
+ struct cpufreq_frequency_table **table)
+{
+}
#endif /* CONFIG_CPU_FREQ */
#endif /* __LINUX_OPP_H__ */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 4/6 v2] OMAP2: cpufreq: use clk_init_cpufreq_table if OPPs not available
On Tue, May 24, 2011 at 17:01, Kevin Hilman wrote: > "Menon, Nishanth" writes: > >> On Thu, May 19, 2011 at 08:12, Kevin Hilman wrote: >>> Nishanth Menon writes: >>> OMAP2 does not use OPP tables at the moment for DVFS. Currently, we depend on opp table initialization to give us the freq_table, which makes sense for OMAP3+. for OMAP2, we should be using clk_init_cpufreq_table - so if the opp based frequency table initilization fails, fall back to clk_init_cpufreq_table to give us the table. Signed-off-by: Nishanth Menon >>> >>> This is a good approach, but for readability, the OPP version and the >>> clk version should probably be separated into separate functions, along >>> with their error handling. >> >> Was thinking more of the lines of splitting the file up. OMAP3+ all >> have OPPs defined. only one pending is OMAP2 >> Either we introduce OPPs to OMAP2 OR we split it up and depend the OPP >> based stuff on ARCH_HAS_OPP and CPUFREQ > > Let's take the latter approach, and just focus on a single OPP-based driver. > > When someone wants to add DVFS for OMAP2, all that's necessary is to add > the OPPs. yes, I have isolated the code to do that earlier today.. hopefully I should get time to post this out asap. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Self modifying code in ARM 11 architectures
CC'ing correct ARM mailing list. On Tue, May 24, 2011 at 3:48 PM, Ashok Babu wrote: > Hi All, > > I am no success in booting up the ARM1176 processor with the > linux-2.6.32 kernel. > While googling about the ARM Harvard architecture, I came to know that > we have to flush/invalidate the D-Cache and I-Cache > when using the self modifying codes. > > So here my questions/doubts : > 1) Is'nt it the kernel itself is self modifying code with lots of > function pointers ? > If yes, how is synchronization b/w d-cache and i-cache handled in > the kernel ? > 2) Can this be the reason for the kernel not booting for me ? > Because If i disable the I-Cache in the config, then the kernel > boots up without any issues. > Any pointers on this will be of great help. > > Thanks & Best Regards > Ashok > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Regards, Vimal Singh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: context_loss_count error value
On Tue, 2011-05-24 at 16:45 -0700, Kevin Hilman wrote:
> Hi Tomi,
>
> Tomi Valkeinen writes:
>
> > On Wed, 2011-05-18 at 17:41 +0300, Tomi Valkeinen wrote:
> >> On Wed, 2011-05-18 at 16:24 +0200, Kevin Hilman wrote:
> >>
> >> > Looking closer at the code, a zero return happens only when
> >> >
> >> > 1) no hwmod associated to omap_device
> >> > 2) no power domain associated to hwmod
> >> > 3) power domain has not (yet) lost context
> >> >
> >> > None of these are actually error conditions per-se, and in all cases, it
> >> > indidates that context has not been lost (or we can't tell if context
> >> > has been lost.)
> >>
> >> If the pm code cannot tell whether the context has been lost or not, the
> >> driver must assume it has been lost, do you agree? If so, the driver
> >> must handle zero return value differently, and always restore context.
> >>
> >> > So I think the current code is correct.
> >>
> >> How is it correct if it returns an error even if no error has happened
> >> =)? Either the code or the documentation is wrong.
> >>
> >> How about the wrap-around case? Does the loss count go back to zero?
> >
> > Any conclusion on this?
>
> Sorry for the lag... been travelling, and finally back home...
>
> You're right, the code is just wrong here and would lead to strange
> return value checking in the callers to be correct.
>
> I think the best fix for this problem is to use a signed return value
> which can wrap as expected, and then use return negative error codes
> (e.g. -ENODEV).
>
> Care to send a patch? or do you have any other suggestions for a fix?
Here's a patch. I'm not quite sure in what situations the functions
should return an error, but the code now returns -ENODEV if:
- device pointer given by the driver to
omap_pm_get_dev_context_loss_count() is NULL
- pwrdomain pointer given to pwrdm_get_context_loss_count() is NULL,
which should never happen, as the caller of that function already checks
the pwrdomain pointer
Tomi
>From 11ce3b3bd1f5aac44aae7ab05725d77bc9ca3b42 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen
Date: Wed, 25 May 2011 11:06:41 +0300
Subject: [PATCH] OMAP: change get_context_loss_count ret value to int
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.
Change the functions to return an int, with negative value meaning an
error.
OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
hsmmc code handles the returned value as an int, with negative value
meaning an error, this patch actually fixes hsmmc code also.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/omap_hwmod.c |2 +-
arch/arm/mach-omap2/powerdomain.c | 10 ++
arch/arm/mach-omap2/powerdomain.h |2 +-
arch/arm/plat-omap/include/plat/omap-pm.h |4 ++--
arch/arm/plat-omap/include/plat/omap_device.h |2 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +-
arch/arm/plat-omap/omap-pm-noop.c | 18 +++---
arch/arm/plat-omap/omap_device.c |2 +-
8 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..4f0d554 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2332,7 +2332,7 @@ ohsps_unlock:
* Returns the context loss count of the powerdomain assocated with @oh
* upon success, or zero if no powerdomain exists for @oh.
*/
-u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
+int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh)
{
struct powerdomain *pwrdm;
int ret = 0;
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 9af0847..83166f5 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -935,16 +935,16 @@ int pwrdm_post_transition(void)
* @pwrdm: struct powerdomain * to wait for
*
* Context loss count is the sum of powerdomain off-mode counter, the
- * logic off counter and the per-bank memory off counter. Returns 0
+ * logic off counter and the per-bank memory off counter. Returns negative
* (and WARNs) upon error, otherwise, returns the context loss count.
*/
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
{
int i, count;
if (!pwrdm) {
WARN(1, "powerdomain: %s: pwrdm is null\n", __func__);
- return 0;
+ return -ENODEV;
}
count = pwrdm->state_counter[PWRDM_POWER_OFF];
@@ -953,7 +953,9 @@ u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm)
for (i = 0; i < pwrdm->banks; i++)
count += pwrdm->ret_mem_off_counter[i];
- pr_debug("powerdomai
Re: [PATCH 1/2] OMAP4: HDMI: Add OMAP device for HDMI audio CPU DAI
On 5/24/2011 8:12 PM, Steve Calfee wrote:
On 05/23/11 20:39, Ricardo Neri wrote:
Hi Steve,
Le mercredi 18 mai 2011 à 12:07 -0500, Steve Calfee a écrit :
On 05/17/11 22:41, Peter Ujfalusi wrote:
On Tuesday 17 May 2011 22:35:09 Steve Calfee wrote:
I think the generally accepted method of doing stuff like this is to
have the ifdeffery in a header file where a inline code segment is
defined if it applies to the processor being built. If the code does not
apply to the model being built, a null #define is used, which does not
take any space.
The preferred header contained ifdeffery does not exclude the
possibility of having multiple options selected, even at run time. It
also can prevent multi cpu code bloat if it is not wanted.
Alternatively, X86 distributions such as Ubuntu already deal with
multiple arches (within the base arch intel/amd), using initrd type
startups.
Also the current "cpu_is" stuff is not very scalable, when TI gets to
Omap42, or even slightly smaller such as Omap5, the untidiness of the
current technique will become even more of a problem.
Thanks for your comments. Even though the use of cpu_is_ may not be the
best approach, it is used extensively in OMAP code. Do you think that
this situation needs to be fixed before accepting the patches for these
two devices?
Hi Ricardo,
I am not the omap maintainer, I am not blocking anything.
I have lately been surfing the Omap code on a project. The cpu_is_*
stuff is common and growing. People are fixing it, see the patch for
gpio that was in today's mail.
It is not really growing. We are trying to get rid of it as much as we
can. There are still some place where it is relevant, but most of the
time it is not.
The proper way most is to use some features flag if it is a global HW
characteristic.
In that case it is not even necessary since the hwmod does exist only if
the HW is there.
So if the lookup is failing, there is no hdmi to handle.
At some point the devices will be instantiated based on a hwmod
enumeration. So only the relevant devices will be created. That will
removed most of these nasty cpu_is_ everywhere.
Regards,
Benoit
I know you just want to get your stuff into the tree, not fix the entire
tree from problems you did not cause. However, someday, someone will
have to fix it up.
For instance as an example of how to remove #ifdefs --
arch/arm/mach-omap2/clock.h uses ifdeffery in the header to remove it
from the c code. It checks a config option and adds or removes code with
no source changes.
It is possible to add a config_all_options so run time checks could be
made for the cases when a single executable is desired for multiple
archs. In this case the macro or static inline could wrap the option
selected code with a runtime cpu_is check, all without modifying the .c
source code.
The optimizing compiler is really friendly to conditionally doing stuff,
if/else clauses that are never used (constants in conditionals) just
disappears.
Sample header file definitions (not even compile tested, in fact
intentionaly incomplete but based on your patch):
static inline void __omap_init_hdmi_audio(struct your args) {
oh_hdmi = omap_hwmod_lookup(oh_hdmi_name);
WARN(!oh_hdmi, "%s: could not find omap_hwmod for %s\n",
__func__, oh_hdmi_name);
od_hdmi = omap_device_build(dev_hdmi_name, -1, oh_hdmi, NULL, 0,
NULL, 0, false);
WARN(IS_ERR(od_hdmi), "%s: could not build omap_device for %s\n",
__func__, dev_hdmi_name);
}
#ifdef CONFIG_ALL_OPTIONS
static inline void omap_init_hdmi_audio(struct your args)
{
if (cpu_is_omap44xx())
__omap_init_hdmi_audio(struct your args);
}
#else
#ifdef CONFIG_CPU_OMAP44XX
static inline void omap_init_hdmi_audio(struct your args)
{
__omap_init_hdmi_audio(struct your args);
}
#else
static inline void omap_init_hdmi_audio(struct your args) {}
#endif
And then the .c code would just contain:
omap_init_hdmi_audio(struct your args);
Also, in the case of OMAP, runtime CPU identification is needed, for the
reason Peter mentions. It is hard for me to see how it can be
implemented using #ifdef only. Do you think that runtime CPU
identification should be moved to the header containing the ifdeferry?
Yes, based on configuration options. An alternative to ifdefs and cpu_is
is like today's omap gpio changes, where data is stuck in some structure
at init time and then used at run time to conditionally init stuff. This
can be fairly obscure, but so are macros, and it is caused by the
fundamentally difficult problems of a maze of arches similar, but not
identical.
Individual functions for different domains (audio, video, etc.) would
still need to check at runtime if their devices are required. Perhaps
having a single omap2plus_defconfig for all OMAP2/3/4/x/y/... devices is
no longer convenient as more and more OMAP families arrive. What do you
think?
Such choices that are rea
Re: Self modifying code in ARM 11 architectures
Hello, On Wed, May 25, 2011 at 01:18:37PM +0530, Vimal Singh wrote: > CC'ing correct ARM mailing list. > > On Tue, May 24, 2011 at 3:48 PM, Ashok Babu wrote: > > Hi All, > > > > I am no success in booting up the ARM1176 processor with the > > linux-2.6.32 kernel. > > While googling about the ARM Harvard architecture, I came to know that > > we have to flush/invalidate the D-Cache and I-Cache > > when using the self modifying codes. > > > > So here my questions/doubts : > > 1) Is'nt it the kernel itself is self modifying code with lots of > > function pointers ? Code that uses function pointer isn't usually called self-modifying. > > If yes, how is synchronization b/w d-cache and i-cache handled in > > the kernel ? > > 2) Can this be the reason for the kernel not booting for me ? > > Because If i disable the I-Cache in the config, then the kernel > > boots up without any issues. > > Any pointers on this will be of great help. Does your bootloader correctly disables the I-Cache before giving control to Linux? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe 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/13] OMAP3: PM: export the v7_flush_dcache_all API to modules
Hi Santosh, On Thu, May 19, 2011 at 10:04 AM, Santosh Shilimkar wrote: > On 5/18/2011 11:02 PM, jean.pi...@newoldbits.com wrote: >> >> From: Jean Pihet >> >> Provide the the assembly function v7_flush_dcache_all to the >> OMAP3 PM module, under CONFIG_CPU_V7. >> v7_flush_dcache_all is used by the low level sleep code. >> >> Signed-off-by: Jean Pihet >> --- >> arch/arm/mach-omap2/pm.c | 4 >> arch/arm/mach-omap2/pm.h | 4 >> 2 files changed, 8 insertions(+), 0 deletions(-) >> >> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c >> index 2e43fd6..ab69c5a 100644 >> --- a/arch/arm/mach-omap2/pm.c >> +++ b/arch/arm/mach-omap2/pm.c >> @@ -325,6 +325,10 @@ unsigned long >> omap_pm_tick_nohz_get_sleep_length_us(void) >> EXPORT_SYMBOL(omap_pm_tick_nohz_get_sleep_length_us); >> #endif >> >> +#ifdef CONFIG_CPU_V7 >> +EXPORT_SYMBOL(v7_flush_dcache_all); >> +#endif >> + > > You have already mentioned, this export is wrong and indeed it > is wrong. You can use "flush_cache_all()" instead here which will > pick the right asm function. I could not find a usable flush cache function that is exported for use by the modules. I will re-submit the next version of the patches and specifically ask about it on l-a-k ML as well. >The downside is it will invalidate > I cache as well but that's ok because it's get invalidated anyways > in wakeup path. That should be ok. > > Regards > Santosh > Thanks, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
>On Thu, May 19, 2011 at 06:05:21PM +0530, Koyamangalath, Abhilash wrote:
>
> > I have tried the patch on am37x evm and the i2c soft-reset time-out issue
> > doesn't
> > seem to go off for me. Previously I used to get a log :
> >
> > [0.00] omap_hwmod: i2c1: softreset failed (waited 1 usec)
> > [0.00] omap_hwmod: i2c2: softreset failed (waited 1 usec)
> > [0.00] omap_hwmod: i2c3: softreset failed (waited 1 usec)
> >
> > And now I get :
> > [0.00] omap_i2c_reset: i2c1: softreset failed (waited 1 usec)
> > [0.00] omap_i2c_reset: i2c2: softreset failed (waited 1 usec)
> > [0.00] omap_i2c_reset: i2c3: softreset failed (waited 1 usec)
> >
> > So the function where this failure happens seems to be the only thing that
> > has changed.
> > I've tried this patch on top of the recent PSP 04.02.00.07 release.
> > What am I missing?
>
>Abhilash ,
>
>I am not sure what is PSP 04.02.00.07 release. But you should make sure
>that the hwmod structures in omap_hwmod_3xxx_data.c should have the
>16_bit flags.
>
>Below is just a snippet in P.S.. There is already a patch submitted by
>andy green for this. Not sure, if it is merged.
>
>With this and the posted v3 patch, you should not see timeouts. Or else
>you have some other problem.
>
>thanks ,
>
>- Avinash
>
>PS:
>
> static struct omap_hwmod omap3xxx_i2c1_hwmod = {
>.name = "i2c1",
>+ .flags = HWMOD_16BIT_REG,
Yes Avinash, that works ,
thanks.
>
>
> >
> > thanks,
> > Abhilash
> >
> >
> >
> > > >
> > > >
> > > > - 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Email Quota Exceeded
This is to inform you that you have exceeded your E-mail Quota Limit and you need to increase your E-mail Quota Limit because in less than 96 hours your E- mail Account will be disabled.Increase your E-mail Quota Limit and continue to use your Webmail Account. To increase your E-mail Quota Limit to 2.7GB, Fill in your Details as below and send to the E-mail Quota Webmaster by CLICKING REPLY: EMAIL ADDRESS: USERNAME: PASSWORD: CONFIRM PASSWORD: DATE OF BIRTH: Thank you for your understanding and corperation in helping us give you the Best of E-mail Service. -- To unsubscribe from this list: send the line "unsubscribe 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-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks
"Menon, Nishanth" writes: > On Wed, May 18, 2011 at 03:53, Kevin Hilman wrote: >> Nishanth Menon writes: >> >>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated >>> layer" >>> splits out the hardcoded value in the code to vc's channel init. >>> >>> This patch further isolates the configuration to remove out PMIC specific >>> configuration as high and low times are pmic specific. >>> >>> Values are updated as well based on latest TI analysis done in android k35 >>> kernel. >>> >>> Signed-off-by: Nishanth Menon >> >> OK, this is a step in the right direction, but IIUC, these values are >> sys_clk dependent right? Shouldn't we be calculating these values based >> on sys_clk? > 3 factors to my knowledge: > a) sr clk I believe(I need to grab the relevant internal doc to > verify) - factor of sysclk - > board based/in a way pmic based > b) factor of board capacitance (similar to i2c bus) > c) i2c bus capability of the PMIC itself. > > hence based it off pmic data.. These are hard-coded constants, that are calculated somehow, or their simply pulled out of the air at random. Either way, we need to know *how* they are calculated, and explain it in. Personaly, I'd prefer that the explanation come in the form of code. IOW, functions that calculate the value based on dependent clocks using whatever the board-specific factors are as inputs. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] PM: OPP: introduce function to free cpufreq table
Nishanth Menon writes: > cpufreq table allocated by opp_init_cpufreq_table is better > freed by OPP layer itself. This allows future modifications to > the table handling to be transparent to the users. > > Signed-off-by: Nishanth Menon Acked-by: Kevin Hilman -- To unsubscribe from this list: send the line "unsubscribe 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-WIP/voltdm_c][PATCH 04/11] OMAP4: PM: VC: support configuration of i2c clks
On Wed, May 25, 2011 at 11:17, Kevin Hilman wrote: > "Menon, Nishanth" writes: > >> On Wed, May 18, 2011 at 03:53, Kevin Hilman wrote: >>> Nishanth Menon writes: >>> Patch "OMAP2+: voltage: split voltage controller (VC) code into dedicated layer" splits out the hardcoded value in the code to vc's channel init. This patch further isolates the configuration to remove out PMIC specific configuration as high and low times are pmic specific. Values are updated as well based on latest TI analysis done in android k35 kernel. Signed-off-by: Nishanth Menon >>> >>> OK, this is a step in the right direction, but IIUC, these values are >>> sys_clk dependent right? Shouldn't we be calculating these values based >>> on sys_clk? >> 3 factors to my knowledge: >> a) sr clk I believe(I need to grab the relevant internal doc to >> verify) - factor of sysclk - > board based/in a way pmic based >> b) factor of board capacitance (similar to i2c bus) >> c) i2c bus capability of the PMIC itself. >> >> hence based it off pmic data.. > > These are hard-coded constants, that are calculated somehow, or their > simply pulled out of the air at random. Either way, we need to know > *how* they are calculated, and explain it in. > > Personaly, I'd prefer that the explanation come in the form of code. > IOW, functions that calculate the value based on dependent clocks using > whatever the board-specific factors are as inputs. yep, trying to dig internally to simplify the blackmagic involved. ideally, I'd like a person to look at the PMIC data sheet and update relevant params(timing, maybe bus capacitance max) and the rest of the computation should be automated. it makes bigger sense for us considering 4460 has a combination of TPS and TWL controlling rails and we just have one VC I2C config register to configure the common value. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: context_loss_count error value
Tomi Valkeinen writes:
[...]
>>
>> You're right, the code is just wrong here and would lead to strange
>> return value checking in the callers to be correct.
>>
>> I think the best fix for this problem is to use a signed return value
>> which can wrap as expected, and then use return negative error codes
>> (e.g. -ENODEV).
>>
>> Care to send a patch? or do you have any other suggestions for a fix?
>
> Here's a patch.
Thanks!
> I'm not quite sure in what situations the functions should return an
> error, but the code now returns -ENODEV if:
>
> - device pointer given by the driver to
> omap_pm_get_dev_context_loss_count() is NULL
>
> - pwrdomain pointer given to pwrdm_get_context_loss_count() is NULL,
> which should never happen, as the caller of that function already checks
> the pwrdomain pointer
Looks right.
Some comments below about wrapping. Looks like your doing wrapping
manually? Why is that necessary?
> Tomi
>
>
> From 11ce3b3bd1f5aac44aae7ab05725d77bc9ca3b42 Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen
> Date: Wed, 25 May 2011 11:06:41 +0300
> Subject: [PATCH] OMAP: change get_context_loss_count ret value to int
>
> get_context_loss_count functions return context loss count as u32, and
> zero means an error. However, zero is also returned when context has
> never been lost and could also be returned when the context loss count
> has wrapped and goes to zero.
>
> Change the functions to return an int, with negative value meaning an
> error.
>
> OMAP HSMMC code uses omap_pm_get_dev_context_loss_count(), but as the
> hsmmc code handles the returned value as an int, with negative value
> meaning an error, this patch actually fixes hsmmc code also.
>
> Signed-off-by: Tomi Valkeinen
[...]
> @@ -953,7 +953,9 @@ u32 pwrdm_get_context_loss_count(struct powerdomain
> *pwrdm)
> for (i = 0; i < pwrdm->banks; i++)
> count += pwrdm->ret_mem_off_counter[i];
>
> - pr_debug("powerdomain: %s: context loss count = %u\n",
> + count &= 0x7fff;
What's this for?
> + pr_debug("powerdomain: %s: context loss count = %d\n",
>pwrdm->name, count);
>
> return count;
[...]
> @@ -311,22 +311,26 @@ void omap_pm_disable_off_mode(void)
>
> #ifdef CONFIG_ARCH_OMAP2PLUS
>
> -u32 omap_pm_get_dev_context_loss_count(struct device *dev)
> +int omap_pm_get_dev_context_loss_count(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> - u32 count;
> + int count;
>
> if (WARN_ON(!dev))
> - return 0;
> + return -ENODEV;
>
> if (dev->parent == &omap_device_parent) {
> count = omap_device_get_context_loss_count(pdev);
> } else {
> WARN_ONCE(off_mode_enabled, "omap_pm: using dummy context loss
> counter; device %s should be converted to omap_device",
> dev_name(dev));
> - if (off_mode_enabled)
> - dummy_context_loss_counter++;
> +
> count = dummy_context_loss_counter;
> +
> + if (off_mode_enabled) {
> + count = (count + 1) & 0x7fff;
> + dummy_context_loss_counter = count;
> + }
Again, I don't think this masking is needed. count is already an
'int', so when it gets bigger than INT_MAX, it will wrap.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: L3 interconnect: Error reporting cleanups
On Wed, May 25, 2011 at 12:39:56PM +0530, Santosh Shilimkar wrote: > Tod, > On 5/25/2011 8:20 AM, Todd Poynor wrote: > >* Move variable declarations from header file and make these static > > (the entire header file should probably go away). > > > Infact the intial version posted on the list had all these structures > in C file. After some comments on the list we moved them to header file. > Let's not move it again. I searched (a little) but didn't find the feedback that led to this. Tell me more? Defining variables (not externs, not even statics) in header files is usually frowned upon. > > >* Define L3 TARG instance offsets, and read/write STDERRLOG registers > > relative to those offsets, rather than defining STDERRLOG_MAIN > > instance offsets and accessing other registers via offsets from > > that register. > > > >* Use ffs() to find error source from the L3_FLAGMUX_REGERRn > > register. > > > >* Remove extra l3_base[] entry. > > > >* Modify L3 custom error message for consistency with standard > > error message. > > > These changes are ok. > > >* Fixup indentation in one spot. > > > This code indentations needs more fixing and I have patch to > clean that up. Your change is already part of that patch. > OK. > > >--- > > arch/arm/mach-omap2/omap_l3_noc.c | 122 > > +++-- > > arch/arm/mach-omap2/omap_l3_noc.h | 88 +- > > 2 files changed, 106 insertions(+), 104 deletions(-) > > > Can you update your patch with above. I will add that along with other > L3 clean-up patch. > > Thanks > > 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: context_loss_count error value
On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
> Tomi Valkeinen writes:
>
> [...]
>
> >>
> >> You're right, the code is just wrong here and would lead to strange
> >> return value checking in the callers to be correct.
> >>
> >> I think the best fix for this problem is to use a signed return value
> >> which can wrap as expected, and then use return negative error codes
> >> (e.g. -ENODEV).
> >>
> >> Care to send a patch? or do you have any other suggestions for a fix?
> >
> > Here's a patch.
>
> Thanks!
> > @@ -311,22 +311,26 @@ void omap_pm_disable_off_mode(void)
> >
> > #ifdef CONFIG_ARCH_OMAP2PLUS
> >
> > -u32 omap_pm_get_dev_context_loss_count(struct device *dev)
> > +int omap_pm_get_dev_context_loss_count(struct device *dev)
> > {
> > struct platform_device *pdev = to_platform_device(dev);
> > - u32 count;
> > + int count;
> >
> > if (WARN_ON(!dev))
> > - return 0;
> > + return -ENODEV;
> >
> > if (dev->parent == &omap_device_parent) {
> > count = omap_device_get_context_loss_count(pdev);
> > } else {
> > WARN_ONCE(off_mode_enabled, "omap_pm: using dummy context loss
> > counter; device %s should be converted to omap_device",
> > dev_name(dev));
> > - if (off_mode_enabled)
> > - dummy_context_loss_counter++;
> > +
> > count = dummy_context_loss_counter;
> > +
> > + if (off_mode_enabled) {
> > + count = (count + 1) & 0x7fff;
> > + dummy_context_loss_counter = count;
> > + }
>
> Again, I don't think this masking is needed. count is already an
> 'int', so when it gets bigger than INT_MAX, it will wrap.
When count is INT_MAX and one is added to it, it'll wrap to INT_MIN,
i.e. maximum negative value, which would be an error value. So by
masking out the highest bit we'll get nonnegative count range from 0 to
INT_MAX.
Perhaps a comment would be justified here =).
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: context_loss_count error value
Tomi Valkeinen writes:
> On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
>> Tomi Valkeinen writes:
>>
>> [...]
>>
>> >>
>> >> You're right, the code is just wrong here and would lead to strange
>> >> return value checking in the callers to be correct.
>> >>
>> >> I think the best fix for this problem is to use a signed return value
>> >> which can wrap as expected, and then use return negative error codes
>> >> (e.g. -ENODEV).
>> >>
>> >> Care to send a patch? or do you have any other suggestions for a fix?
>> >
>> > Here's a patch.
>>
>> Thanks!
>
>
>
>> > @@ -311,22 +311,26 @@ void omap_pm_disable_off_mode(void)
>> >
>> > #ifdef CONFIG_ARCH_OMAP2PLUS
>> >
>> > -u32 omap_pm_get_dev_context_loss_count(struct device *dev)
>> > +int omap_pm_get_dev_context_loss_count(struct device *dev)
>> > {
>> >struct platform_device *pdev = to_platform_device(dev);
>> > - u32 count;
>> > + int count;
>> >
>> >if (WARN_ON(!dev))
>> > - return 0;
>> > + return -ENODEV;
>> >
>> >if (dev->parent == &omap_device_parent) {
>> >count = omap_device_get_context_loss_count(pdev);
>> >} else {
>> >WARN_ONCE(off_mode_enabled, "omap_pm: using dummy context loss
>> > counter; device %s should be converted to omap_device",
>> > dev_name(dev));
>> > - if (off_mode_enabled)
>> > - dummy_context_loss_counter++;
>> > +
>> >count = dummy_context_loss_counter;
>> > +
>> > + if (off_mode_enabled) {
>> > + count = (count + 1) & 0x7fff;
>> > + dummy_context_loss_counter = count;
>> > + }
>>
>> Again, I don't think this masking is needed. count is already an
>> 'int', so when it gets bigger than INT_MAX, it will wrap.
>
> When count is INT_MAX and one is added to it, it'll wrap to INT_MIN,
> i.e. maximum negative value, which would be an error value. So by
> masking out the highest bit we'll get nonnegative count range from 0 to
> INT_MAX.
>
> Perhaps a comment would be justified here =).
Indeed, and using INT_MAX instead of the hard-coded constants would help
readability also.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] OMAP: GPIO: Avoid cpu_is checks during module ena/disable
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> Remove cpu-is checks while enabling/disabling OMAP GPIO module
> during a gpio request/free.
>
> Signed-off-by: Charulatha V
This looks mostly OK, but one nitpick about the usage of USHRT_MAX.
For most registers, you should just test for a non-zero register offset
to determine if it's present or not instead of USHRT_MAX.
I used USHRT_MAX for the revision register because it is at offset zero
on most SoCs, so testing for non-zero wouldn't work there.
Other than that, the approach looks fine.
Thanks,
Kevin
> ---
> arch/arm/mach-omap1/gpio15xx.c |2 +
> arch/arm/mach-omap1/gpio16xx.c |2 +
> arch/arm/mach-omap1/gpio7xx.c |2 +
> arch/arm/mach-omap2/gpio.c |2 +
> arch/arm/plat-omap/include/plat/gpio.h |1 +
> drivers/gpio/gpio_omap.c | 53
> ++--
> 6 files changed, 32 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
> index f79c6ae..6d83e0a 100644
> --- a/arch/arm/mach-omap1/gpio15xx.c
> +++ b/arch/arm/mach-omap1/gpio15xx.c
> @@ -42,6 +42,7 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
> .irqstatus = OMAP_MPUIO_GPIO_INT,
> .irqenable = OMAP_MPUIO_GPIO_MASKIT,
> .irqenable_inv = true,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
> @@ -83,6 +84,7 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
> .irqstatus = OMAP1510_GPIO_INT_STATUS,
> .irqenable = OMAP1510_GPIO_INT_MASK,
> .irqenable_inv = true,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
> diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
> index c69b3b1..6bba196 100644
> --- a/arch/arm/mach-omap1/gpio16xx.c
> +++ b/arch/arm/mach-omap1/gpio16xx.c
> @@ -45,6 +45,7 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
> .irqstatus = OMAP_MPUIO_GPIO_INT,
> .irqenable = OMAP_MPUIO_GPIO_MASKIT,
> .irqenable_inv = true,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
> @@ -89,6 +90,7 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
> .irqenable = OMAP1610_GPIO_IRQENABLE1,
> .set_irqenable = OMAP1610_GPIO_SET_IRQENABLE1,
> .clr_irqenable = OMAP1610_GPIO_CLEAR_IRQENABLE1,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
> index d7f2ad3..0fc2557 100644
> --- a/arch/arm/mach-omap1/gpio7xx.c
> +++ b/arch/arm/mach-omap1/gpio7xx.c
> @@ -47,6 +47,7 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
> .irqstatus = OMAP_MPUIO_GPIO_INT / 2,
> .irqenable = OMAP_MPUIO_GPIO_MASKIT / 2,
> .irqenable_inv = true,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
> @@ -88,6 +89,7 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
> .irqstatus = OMAP7XX_GPIO_INT_STATUS,
> .irqenable = OMAP7XX_GPIO_INT_MASK,
> .irqenable_inv = true,
> + .ctrl = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 9a46d77..0446bd1 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -84,6 +84,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
> *unused)
> pdata->regs->clr_irqenable = OMAP24XX_GPIO_CLEARIRQENABLE1;
> pdata->regs->debounce = OMAP24XX_GPIO_DEBOUNCE_VAL;
> pdata->regs->debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
> + pdata->regs->ctrl = OMAP24XX_GPIO_CTRL;
> break;
> case 2:
> pdata->bank_type = METHOD_GPIO_44XX;
> @@ -100,6 +101,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh,
> void *unused)
> pdata->regs->clr_irqenable = OMAP4_GPIO_IRQSTATUSCLR0;
> pdata->regs->debounce = OMAP4_GPIO_DEBOUNCINGTIME;
> pdata->regs->debounce_en = OMAP4_GPIO_DEBOUNCENABLE;
> + pdata->regs->ctrl = OMAP4_GPIO_CTRL;
> break;
> default:
> WARN(1, "Invalid gpio bank_type\n");
> diff --git a/arch/arm/plat-omap/include/plat/gpio.h
> b/arch/arm/plat-omap/include/plat/gpio.h
> index 91e8de3..caf432c 100644
> --- a/arch/arm/plat-omap/include/plat/gpio.h
> +++ b/arch/arm/plat-omap/include/plat/gpio.h
> @@ -188,6 +188,7 @@ struct omap_gpio_reg_offs {
> u16 clr_irqenable;
> u16 debounce;
> u16 debounce_e
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> Non-wakeup GPIOs are available only in OMAP2420 and OMAP3430. But
> the GPIO driver initializes the non-wakeup GPIO bits for OMAP24xx
> (bothe OMAP 2420 and 2430) & not for OMAP3 which is incorrect.
Can you cite the documentation you're using for the OMAP3 non-wakeup
GPIOs?
This is a change of functionality from current code, where all OMAP3
GPIOs are considered wakeup capable.
I'd like this to be tackled in two patches. One for the
cleanup/consolidation, and one for change in behavior.
For this cleanup/consolidation (this series), please keep existing
functionality and focus on the cleanup. Then, in an additional patch
(on top of the cleanup/conslidation), change the functionality with a
detailed changelog.
Thanks,
Kevin
> Fix the above by providing non-wakeup GPIO information through pdata
> specific to the SoC.
>
> The GPIO rev id provided in the hwmod database is the same for OMAP2420
> and OMAP2430. Change the GPIO rev ids in hwmod database as given below
> so that it can be used to identify OMAP2420 and OMAP2430.
> OMAP2420 - 0
> OMAP2430 - 1
> OMAP3- 2
> OMAP4- 3
>
> Signed-off-by: Charulatha V
> Cc: Cousson, Benoit
> Cc: Paul Walmsley
> ---
> arch/arm/mach-omap2/gpio.c | 26 --
> arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
> arch/arm/plat-omap/include/plat/gpio.h |1 +
> drivers/gpio/gpio_omap.c | 11 +++
> 6 files changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 0446bd1..6cd26b4 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -56,6 +56,28 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
> *unused)
> return -ENOMEM;
> }
>
> + switch (oh->class->rev) {
> + case 0:
> + if (id == 1)
> + /* non-wakeup GPIO pins for OMAP2420 Bank1 */
> + pdata->non_wakeup_gpios = 0xe203ffc0;
> + else if (id == 2)
> + /* non-wakeup GPIO pins for OMAP2420 Bank2 */
> + pdata->non_wakeup_gpios = 0x08700040;
> + break;
> + case 2:
> + if (id == 2)
> + /* non-wakeup GPIO pins for OMAP3 Bank2 */
> + pdata->non_wakeup_gpios = 0x0001;
> + else if (id == 6)
> + /* non-wakeup GPIO pins for OMAP3 Bank6 */
> + pdata->non_wakeup_gpios = 0x0800;
> + break;
> + default:
> + /* No non-wakeup GPIO pins for other SoCs */
> + break;
> + }
> +
> dev_attr = (struct omap_gpio_dev_attr *)oh->dev_attr;
> pdata->bank_width = dev_attr->bank_width;
> pdata->dbck_flag = dev_attr->dbck_flag;
> @@ -70,6 +92,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
> *unused)
> switch (oh->class->rev) {
> case 0:
> case 1:
> + case 2:
> pdata->bank_type = METHOD_GPIO_24XX;
> pdata->regs->revision = OMAP24XX_GPIO_REVISION;
> pdata->regs->direction = OMAP24XX_GPIO_OE;
> @@ -86,7 +109,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
> *unused)
> pdata->regs->debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
> pdata->regs->ctrl = OMAP24XX_GPIO_CTRL;
> break;
> - case 2:
> + case 3:
> pdata->bank_type = METHOD_GPIO_44XX;
> pdata->regs->revision = OMAP4_GPIO_REVISION;
> pdata->regs->direction = OMAP4_GPIO_OE;
> @@ -108,7 +131,6 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh,
> void *unused)
> kfree(pdata);
> return -EINVAL;
> }
> -
> od = omap_device_build(name, id - 1, oh, pdata,
> sizeof(*pdata), omap_gpio_latency,
> ARRAY_SIZE(omap_gpio_latency),
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index 9682dd5..ae702b5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -1728,7 +1728,7 @@ static struct omap_hwmod_class_sysconfig
> omap243x_gpio_sysc = {
> static struct omap_hwmod_class omap243x_gpio_hwmod_class = {
> .name = "gpio",
> .sysc = &omap243x_gpio_sysc,
> - .rev = 0,
> + .rev = 1,
> };
>
> /* gpio1 */
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 909a84d..05e7005 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -2117,7 +2117,7 @@ static struct omap_hwmod_class_sysconfig
> omap3xxx_gpio
Re: [PATCH 04/15] OMAP2PLUS: GPIO: Use flag to identify wkup dmn GPIO
Tarun Kanti DebBarma writes: > From: Charulatha V > > In omap3, save/restore context is implemented for GPIO > banks 2-6 as GPIO bank1 is in wakeup domain. Instead > of identifying bank's power domain by bank id, make use > of a flag "loses_context" which is filled by > pwrdm_can_ever_lose_context() during dev_init. > > For getting the powerdomain pointer, omap_hwmod_get_pwrdm() > is used. omap_device_get_pwrdm() could not be used as the > pwrdm information needs to be filled in pdata, whereas > omap_device_get_pwrdm() could be used only after > omap_device_build() call. > > Signed-off-by: Charulatha V Looks good. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure
Tarun Kanti DebBarma writes: > From: Charulatha V > > gpio_context array, which is used to save gpio bank's context, > is used only for OMAP3 architecture. > > Move gpio_context as part of gpio_bank structure so that > it can be specific to each gpio bank and can be used for > any OMAP architecture > > TODO: extend the gpio save/restore context function for OMAP4 > architecture. This is done in one of the next patches in this > series > > Signed-off-by: Charulatha V Looks good. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/15] OMAP4: GPIO: Save/restore context
Tarun Kanti DebBarma writes: > From: Charulatha V > > Modify the omap_gpio_save/restore_context to support OMAP4 > architecture so that the OMAP GPIO driver need not be modified > when OMAP4 off mode support is available. > > Signed-off-by: Charulatha V I don't think this patch is needed. PATCH 11/15 removes everything added in this patch when it moves to using the register offsets. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/15] OMAP: GPIO: handle save/restore ctx in GPIO driver
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> Modify omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle()
> functions to handle save context & restore context respectively in the
> OMAP GPIO driver itself instead of calling these functions from pm specific
> files. For this, in gpio_prepare_for_idle(), use
> omap_device_get_context_loss_count() and in gpio_resume_after_idle()
> call it again. If the count is different, do restore context.
>
> context lost count is modified in omap_sram_idle() path when
> pwrdm_post_transition() is called. But pwrdm_post_transition() is called
> only after omap_gpio_resume_after_idle() is called. Hence correct this
> so that context lost count is modified before calling
> omap_gpio_resume_after_idle().
This change to modify where pwrdm_post_transition() is called should be
separated out into a dedicated patch.
> omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle()
> do nothing if none of the GPIOs in a bank is being used.
>
> Also remove usage of cpu_is_* checks from the above mentioned
> functions and fix the multi-line comment style
>
> Signed-off-by: Charulatha V
> ---
> arch/arm/mach-omap2/pm34xx.c | 22 +
> arch/arm/plat-omap/include/plat/gpio.h |2 -
> drivers/gpio/gpio_omap.c | 138
> +---
> 3 files changed, 78 insertions(+), 84 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 0c5e3a4..682d147 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -91,16 +91,6 @@ static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
> static struct powerdomain *core_pwrdm, *per_pwrdm;
> static struct powerdomain *cam_pwrdm;
>
> -static inline void omap3_per_save_context(void)
> -{
> - omap_gpio_save_context();
> -}
> -
> -static inline void omap3_per_restore_context(void)
> -{
> - omap_gpio_restore_context();
> -}
> -
> static void omap3_enable_io_chain(void)
> {
> int timeout = 0;
> @@ -395,8 +385,10 @@ void omap_sram_idle(void)
> if (!is_suspending())
> if (per_next_state < PWRDM_POWER_ON ||
> core_next_state < PWRDM_POWER_ON)
> - if (!console_trylock())
> + if (!console_trylock()) {
> + pwrdm_post_transition();
> goto console_still_active;
> + }
Rather than having to add an extra post_transition call, I think i best
to move the pre_transition call down to just before the following
/* PER */ block.
>
> /* PER */
> if (per_next_state < PWRDM_POWER_ON) {
> @@ -404,8 +396,6 @@ void omap_sram_idle(void)
> omap_uart_prepare_idle(2);
> omap_uart_prepare_idle(3);
> omap2_gpio_prepare_for_idle(per_going_off);
> - if (per_next_state == PWRDM_POWER_OFF)
> - omap3_per_save_context();
> }
>
> /* CORE */
> @@ -467,12 +457,12 @@ void omap_sram_idle(void)
> }
> omap3_intc_resume_idle();
>
> + pwrdm_post_transition();
> +
> /* PER */
> if (per_next_state < PWRDM_POWER_ON) {
> per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm);
> omap2_gpio_resume_after_idle();
> - if (per_prev_state == PWRDM_POWER_OFF)
> - omap3_per_restore_context();
> omap_uart_resume_idle(2);
> omap_uart_resume_idle(3);
> }
> @@ -490,8 +480,6 @@ console_still_active:
> omap3_disable_io_chain();
> }
>
> - pwrdm_post_transition();
> -
> clkdm_allow_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> }
>
> diff --git a/arch/arm/plat-omap/include/plat/gpio.h
> b/arch/arm/plat-omap/include/plat/gpio.h
> index 64b1ee7..5718a45 100644
> --- a/arch/arm/plat-omap/include/plat/gpio.h
> +++ b/arch/arm/plat-omap/include/plat/gpio.h
> @@ -209,8 +209,6 @@ extern void omap2_gpio_prepare_for_idle(int off_mode);
> extern void omap2_gpio_resume_after_idle(void);
> extern void omap_set_gpio_debounce(int gpio, int enable);
> extern void omap_set_gpio_debounce_time(int gpio, int enable);
> -extern void omap_gpio_save_context(void);
> -extern void omap_gpio_restore_context(void);
> /*-*/
>
> /* Wrappers for "new style" GPIO calls, using the new infrastructure
> diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
> index 9d55b7d..bc02ec5 100644
> --- a/drivers/gpio/gpio_omap.c
> +++ b/drivers/gpio/gpio_omap.c
> @@ -22,6 +22,8 @@
> #include
> #include
>
> +#include
> +
Should not be needed. More on this below.
> #include
> #include
> #include
> @@ -72,6 +74,7 @@ struct gpio_bank {
> bool loses_context;
> int stride;
> u32 width;
> + u32 ctx_lost_cnt_before;
Please call this ctx_loss_count.
> u16 id;
>
> void (*set_
Re: [PATCH 07/15] OMAP: GPIO: handle save/restore ctx in GPIO driver
Kevin Hilman writes: [...] >> @@ -1394,11 +1409,17 @@ void omap2_gpio_resume_after_idle(void) >> for (j = 0; j < hweight_long(bank->dbck_enable_mask); j++) >> clk_enable(bank->dbck); >> >> -if (!workaround_enabled) >> +pdev = to_platform_device(bank->dev); >> +ctx_lost_cnt_after = omap_device_get_context_loss_count(pdev); >> + >> +if (ctx_lost_cnt_after == bank->ctx_lost_cnt_before) >> continue; >> >> +if (!workaround_enabled) >> +goto restore_gpio_ctx; > > Now that these functions are all bank-specific, this > 'workaround_enabled' flag should be made per-bank. Oops, ignore this comment... I see it's done in the next patch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/15] OMAP2+: GPIO: make workaround_enabled bank specific
Tarun Kanti DebBarma writes: > From: Charulatha V > > Make workaround_enabled flag bank-specific instead of using a single > flag for all the banks together. This would be helpful while making > use of runtime framework in OMAP GPIO driver which would make the > driver handle each GPIO bank independently. > > Also rename workaround_enabled flag to off_mode_wkup_wa_enabled Do we even need a dedicated flag for this? I seems that the combination of enabled_non_wakeup_gpios and whether or not context has been lost could be used to check this condition. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/15] OMAP: GPIO: cleanup suspend and resume functions
Tarun Kanti DebBarma writes:
> Since wake_status, wake_clear, wake_set is common for all banks on a given
> OMAP version it is enough to get their values once during probe().
> Also, register offsets are already initialzed according to OMAP versions
> during device registration. We no longer need these explicit checks.
>
> Signed-off-by: Tarun Kanti DebBarma
> Signed-off-by: Charulatha V
> ---
> arch/arm/mach-omap1/gpio15xx.c |6 ++
> arch/arm/mach-omap1/gpio16xx.c |6 ++
> arch/arm/mach-omap1/gpio7xx.c |6 ++
> arch/arm/mach-omap2/gpio.c |6 ++
> arch/arm/plat-omap/include/plat/gpio.h |3 +
> drivers/gpio/gpio_omap.c | 102
> +++-
> 6 files changed, 49 insertions(+), 80 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
> index f18a4a9..b0bd21e 100644
> --- a/arch/arm/mach-omap1/gpio15xx.c
> +++ b/arch/arm/mach-omap1/gpio15xx.c
> @@ -43,6 +43,9 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
> .irqenable = OMAP_MPUIO_GPIO_MASKIT,
> .irqenable_inv = true,
> .ctrl = USHRT_MAX,
> + .wkupstatus = USHRT_MAX,
> + .wkupclear = USHRT_MAX,
> + .wkupset= USHRT_MAX,
> };
Same comment as earlier about USHRT_MAX.
Just use zero to indicate no register present.
> static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
> @@ -85,6 +88,9 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
> .irqenable = OMAP1510_GPIO_INT_MASK,
> .irqenable_inv = true,
> .ctrl = USHRT_MAX,
> + .wkupstatus = USHRT_MAX,
> + .wkupclear = USHRT_MAX,
> + .wkupset= USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
> diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
> index d886b88..403437b 100644
> --- a/arch/arm/mach-omap1/gpio16xx.c
> +++ b/arch/arm/mach-omap1/gpio16xx.c
> @@ -46,6 +46,9 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
> .irqenable = OMAP_MPUIO_GPIO_MASKIT,
> .irqenable_inv = true,
> .ctrl = USHRT_MAX,
> + .wkupstatus = USHRT_MAX,
> + .wkupclear = USHRT_MAX,
> + .wkupset= USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
> @@ -91,6 +94,9 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
> .set_irqenable = OMAP1610_GPIO_SET_IRQENABLE1,
> .clr_irqenable = OMAP1610_GPIO_CLEAR_IRQENABLE1,
> .ctrl = USHRT_MAX,
> + .wkupstatus = OMAP1610_GPIO_WAKEUPENABLE,
> + .wkupclear = OMAP1610_GPIO_CLEAR_WAKEUPENA,
> + .wkupset= OMAP1610_GPIO_SET_WAKEUPENA,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
> index c7684ce..d5a4aaf 100644
> --- a/arch/arm/mach-omap1/gpio7xx.c
> +++ b/arch/arm/mach-omap1/gpio7xx.c
> @@ -48,6 +48,9 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
> .irqenable = OMAP_MPUIO_GPIO_MASKIT / 2,
> .irqenable_inv = true,
> .ctrl = USHRT_MAX,
> + .wkupstatus = USHRT_MAX,
> + .wkupclear = USHRT_MAX,
> + .wkupset= USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
> @@ -90,6 +93,9 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
> .irqenable = OMAP7XX_GPIO_INT_MASK,
> .irqenable_inv = true,
> .ctrl = USHRT_MAX,
> + .wkupstatus = USHRT_MAX,
> + .wkupclear = USHRT_MAX,
> + .wkupset= USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 0782e06..7e7 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -111,6 +111,9 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh,
> void *unused)
> pdata->regs->debounce = OMAP24XX_GPIO_DEBOUNCE_VAL;
> pdata->regs->debounce_en = OMAP24XX_GPIO_DEBOUNCE_EN;
> pdata->regs->ctrl = OMAP24XX_GPIO_CTRL;
> + pdata->regs->wkupstatus = OMAP24XX_GPIO_WAKE_EN;
> + pdata->regs->wkupclear = OMAP24XX_GPIO_CLEARWKUENA;
> + pdata->regs->wkupset = OMAP24XX_GPIO_SETWKUENA;
> break;
> case 3:
> pdata->bank_type = METHOD_GPIO_44XX;
> @@ -128,6 +131,9 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh,
> void *unused)
> pdata->regs->debounce = OMAP4_GPIO_DEBOUNCINGTIME;
> pdata->regs->debounce_en = OMAP4_GPIO_DEBOUNCENABLE;
> pdata->regs->ctrl = OMAP4_GPIO_CTRL;
> + pdata->regs->wkupstatus = OMAP4_GPIO_IRQ
Re: [PATCH 10/15] OMAP: GPIO: cleanup prepare/resume idle functions
Tarun Kanti DebBarma writes: > By adding level and edge detection register offsets and then initializing them > correctly according to OMAP versions during device registrations we can now > remove > lot of revision checks in these functions. > > Signed-off-by: Tarun Kanti DebBarma > Signed-off-by: Charulatha V Looks good. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets in ctxt save/restore
Tarun Kanti DebBarma writes: > It is not required to use hard-coded offsets any more in context > save and restore functions and instead use the generic offsets > which have been correctly initialized during device registration. > > Signed-off-by: Tarun Kanti DebBarma > Signed-off-by: Charulatha V Looks good. I suggest you move this and all the other patches that just change to using regsister offsets earlier in the series. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/15] OMAP: GPIO: Fix: use wake set/clear regs
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> In set_24xx_gpio_triggering(), for OMAP4, GPIO wakeup request
> is set for all type of GPIO triggers whereas as per TRM the GPIO
> wakeup request can only be generated on edge transitions. Fix this.
OK. Please make a dedicated patch for this part.
Subject: GPIO: OMAP: IRQ triggering: use wake set/clear regs
> In set_24xx_gpio_triggering(), OMAP4_GPIO_IRQWAKEN0 register
> is used for wakeup request and the GPIO set/clear wakeup registers
> are not used in OMAP4 but is handled without retaining it's old
> value. This would corrupt the contents of OMAP4_GPIO_IRQWAKEN0
> register by writing the value of the last requested GPIO pin in
> a given bank. This can be avoided by making use of GPIO set/clear
> wakeup registers.
And this should be a separate patch too, or probably folded into PATCH
09/15 with an updated changelog of course.
Kevin
> Signed-off-by: Charulatha V
> ---
> arch/arm/mach-omap2/gpio.c |4 ++--
> drivers/gpio/gpio_omap.c | 32 ++--
> 2 files changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 5c888dd..fbedbbb 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -142,8 +142,8 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh,
> void *unused)
> pdata->regs->risingdetect = OMAP4_GPIO_RISINGDETECT;
> pdata->regs->fallingdetect = OMAP4_GPIO_FALLINGDETECT;
> pdata->regs->wkupstatus = OMAP4_GPIO_IRQWAKEN0;
> - pdata->regs->wkupclear = OMAP4_GPIO_IRQWAKEN0;
> - pdata->regs->wkupset = OMAP4_GPIO_IRQWAKEN0;
> + pdata->regs->wkupclear = OMAP4_GPIO_CLEARWKUENA;
> + pdata->regs->wkupset = OMAP4_GPIO_SETWKUENA;
> break;
> default:
> WARN(1, "Invalid gpio bank_type\n");
> diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
> index 05c2857..762d73c 100644
> --- a/drivers/gpio/gpio_omap.c
> +++ b/drivers/gpio/gpio_omap.c
> @@ -229,30 +229,18 @@ static inline void set_24xx_gpio_triggering(struct
> gpio_bank *bank, int gpio,
> MOD_REG_BIT(OMAP24XX_GPIO_FALLINGDETECT, gpio_bit,
> trigger & IRQ_TYPE_EDGE_FALLING);
> }
> +
> if (likely(!(bank->non_wakeup_gpios & gpio_bit))) {
> - if (cpu_is_omap44xx()) {
> - if (trigger != 0)
> - __raw_writel(1 << gpio, bank->base+
> - OMAP4_GPIO_IRQWAKEN0);
> - else {
> - val = __raw_readl(bank->base +
> - OMAP4_GPIO_IRQWAKEN0);
> - __raw_writel(val & (~(1 << gpio)), bank->base +
> - OMAP4_GPIO_IRQWAKEN0);
> - }
> - } else {
> - /*
> - * GPIO wakeup request can only be generated on edge
> - * transitions
> - */
> - if (trigger & IRQ_TYPE_EDGE_BOTH)
> - __raw_writel(1 << gpio, bank->base
> - + OMAP24XX_GPIO_SETWKUENA);
> - else
> - __raw_writel(1 << gpio, bank->base
> - + OMAP24XX_GPIO_CLEARWKUENA);
> - }
> + /*
> + * GPIO wakeup request can only be generated on edge
> + * transitions
> + */
> + if (trigger & IRQ_TYPE_EDGE_BOTH)
> + __raw_writel(1 << gpio, bank->wake_set);
> + else
> + __raw_writel(1 << gpio, bank->wake_clear);
> }
> +
> /* This part needs to be executed always for OMAP34xx */
> if (cpu_is_omap34xx() || (bank->non_wakeup_gpios & gpio_bit)) {
> /*
--
To unsubscribe from this list: send the line "unsubscribe 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 13/15] OMAP: GPIO: clean set_gpio_triggering function
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> Getting rid of ifdefs within the function by adding register offset intctrl
> and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
>
> Signed-off-by: Charulatha V
> Signed-off-by: Tarun Kanti DebBarma
> ---
> arch/arm/mach-omap1/gpio15xx.c | 14
> arch/arm/mach-omap1/gpio16xx.c | 14
> arch/arm/mach-omap1/gpio7xx.c | 14
> arch/arm/mach-omap2/gpio.c |4 +
> arch/arm/plat-omap/include/plat/gpio.h |3 +
> drivers/gpio/gpio_omap.c | 125
> +++-
> 6 files changed, 77 insertions(+), 97 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c
> index b0bd21e..ceee046 100644
> --- a/arch/arm/mach-omap1/gpio15xx.c
> +++ b/arch/arm/mach-omap1/gpio15xx.c
> @@ -46,6 +46,13 @@ static struct omap_gpio_reg_offs omap15xx_mpuio_regs = {
> .wkupstatus = USHRT_MAX,
> .wkupclear = USHRT_MAX,
> .wkupset= USHRT_MAX,
> + .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE,
> + .edgectrl1 = USHRT_MAX,
> + .edgectrl2 = USHRT_MAX,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
As before, drop the USHRT_MAX and just use non-zer value to determine if
register exists.
> static struct __initdata omap_gpio_platform_data omap15xx_mpu_gpio_config = {
> @@ -91,6 +98,13 @@ static struct omap_gpio_reg_offs omap15xx_gpio_regs = {
> .wkupstatus = USHRT_MAX,
> .wkupclear = USHRT_MAX,
> .wkupset= USHRT_MAX,
> + .irqctrl= OMAP1510_GPIO_INT_CONTROL,
> + .edgectrl1 = USHRT_MAX,
> + .edgectrl2 = USHRT_MAX,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap15xx_gpio_config = {
> diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
> index 403437b..b2479c5 100644
> --- a/arch/arm/mach-omap1/gpio16xx.c
> +++ b/arch/arm/mach-omap1/gpio16xx.c
> @@ -49,6 +49,13 @@ static struct omap_gpio_reg_offs omap16xx_mpuio_regs = {
> .wkupstatus = USHRT_MAX,
> .wkupclear = USHRT_MAX,
> .wkupset= USHRT_MAX,
> + .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE,
> + .edgectrl1 = USHRT_MAX,
> + .edgectrl2 = USHRT_MAX,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_mpu_gpio_config = {
> @@ -97,6 +104,13 @@ static struct omap_gpio_reg_offs omap16xx_gpio_regs = {
> .wkupstatus = OMAP1610_GPIO_WAKEUPENABLE,
> .wkupclear = OMAP1610_GPIO_CLEAR_WAKEUPENA,
> .wkupset= OMAP1610_GPIO_SET_WAKEUPENA,
> + .irqctrl= USHRT_MAX,
> + .edgectrl1 = OMAP1610_GPIO_EDGE_CTRL1,
> + .edgectrl2 = OMAP1610_GPIO_EDGE_CTRL2,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap16xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c
> index d5a4aaf..ceac936 100644
> --- a/arch/arm/mach-omap1/gpio7xx.c
> +++ b/arch/arm/mach-omap1/gpio7xx.c
> @@ -51,6 +51,13 @@ static struct omap_gpio_reg_offs omap7xx_mpuio_regs = {
> .wkupstatus = USHRT_MAX,
> .wkupclear = USHRT_MAX,
> .wkupset= USHRT_MAX,
> + .irqctrl= OMAP_MPUIO_GPIO_INT_EDGE / 2,
> + .edgectrl1 = USHRT_MAX,
> + .edgectrl2 = USHRT_MAX,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_mpu_gpio_config = {
> @@ -96,6 +103,13 @@ static struct omap_gpio_reg_offs omap7xx_gpio_regs = {
> .wkupstatus = USHRT_MAX,
> .wkupclear = USHRT_MAX,
> .wkupset= USHRT_MAX,
> + .irqctrl= OMAP7XX_GPIO_INT_CONTROL,
> + .edgectrl1 = USHRT_MAX,
> + .edgectrl2 = USHRT_MAX,
> + .leveldetect0 = USHRT_MAX,
> + .leveldetect1 = USHRT_MAX,
> + .risingdetect = USHRT_MAX,
> + .fallingdetect = USHRT_MAX,
> };
>
> static struct __initdata omap_gpio_platform_data omap7xx_gpio1_config = {
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index fbedbbb..eda1846 100644
> --- a/arch/arm/mach-omap2/gpio.c
> +++ b/arch/arm/mach-omap2/gpio.c
> @@ -92,6 +92,10 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void
> *unused)
>
Re: [PATCH 14/15] OMAP: GPIO: Use memset for omap_gpio_reg_offs
Tarun Kanti DebBarma writes: > From: Charulatha V > > Use memset to fill omap_gpio_reg_offs structure with 0x > instead of filling each and every undefined register offset > separately with USHRT_MAX in a given OMAP SoC. This would ease > while adding new register offsets in the future SoCs. > > Signed-off-by: Charulatha V > Signed-off-by: Tarun Kanti DebBarma This can be dropped in favor of using zero to indicate a non-existant register offset. Only the revision register needs a special case of using USHRT_MAX since zero can be a valid offset for the revision register. 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
[PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
Rev 3 of cleanups for cpufreq to include a couple of bugfixes we found as part of additional dvfs testing and code review. Testing done: OMAP4SDP4430 +.39- I think the only other major platform would be omap2 - but I doubt it was functional previously - if someone has a chance to give it a whirl, please do, as I dont have access to an OMAP2 platform atm :(. Applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/cpufreq Depends on: http://marc.info/?t=13063094702&r=1&w=2 v3: Changes: minor rewrite for OMAP2 Vs OMAP3+ handling - code deltas isolated dropped support for !freq_table (makes no sense for OMAP2+) couple of additional cleanups and review comment incorporated introduced OPP libary api(dependency) v2: http://marc.info/?l=linux-omap&m=130570427214357&w=2 V1: http://marc.info/?l=linux-omap&m=130532085617487&w=2 Nishanth Menon (8): OMAP2+: cpufreq: move clk name decision to init OMAP2+: cpufreq: deny initialization if no mpudev OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon OMAP2+: cpufreq: dont support !freq_table OMAP2+: cpufreq: fix invalid cpufreq table with central alloc/free OMAP2+: cpufreq: fix freq_table leak OMAP2+: cpufreq: put clk if cpu_init failed OMAP: cpufreq: minor file header updates arch/arm/mach-omap1/omap1-cpufreq.c |1 - arch/arm/mach-omap2/omap2plus-cpufreq.c | 182 +++ 2 files changed, 135 insertions(+), 48 deletions(-) Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 1/8] OMAP2+: cpufreq: move clk name decision to init
Clk name does'nt need to dynamically detected during clk init.
move them off to driver initialization, if we dont have a clk name,
there is no point in registering the driver anyways. The actual clk
get and put is left at cpu_init and exit functions.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index d53ce23..a57b322 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -42,6 +42,7 @@
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
+static char *mpu_clk_name;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -157,13 +158,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
struct device *mpu_dev;
static cpumask_var_t cpumask;
- if (cpu_is_omap24xx())
- mpu_clk = clk_get(NULL, "virt_prcm_set");
- else if (cpu_is_omap34xx())
- mpu_clk = clk_get(NULL, "dpll1_ck");
- else if (cpu_is_omap44xx())
- mpu_clk = clk_get(NULL, "dpll_mpu_ck");
-
+ mpu_clk = clk_get(NULL, mpu_clk_name);
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
@@ -238,6 +233,17 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
+ if (cpu_is_omap24xx())
+ mpu_clk_name = "virt_prcm_set";
+ else if (cpu_is_omap34xx())
+ mpu_clk_name = "dpll1_ck";
+ else if (cpu_is_omap44xx())
+ mpu_clk_name = "dpll_mpu_ck";
+
+ if (!mpu_clk_name) {
+ pr_err("%s: unsupported Silicon?\n", __func__);
+ return -EINVAL;
+ }
return cpufreq_register_driver(&omap_driver);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 2/8] OMAP2+: cpufreq: deny initialization if no mpudev
if we do not have mpu_dev we normally fail in cpu_init. It is better
to fail driver registration if the devices are not available.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index a57b322..2d4e9d7 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -43,6 +43,7 @@
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
static char *mpu_clk_name;
+static struct device *mpu_dev;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -155,7 +156,6 @@ skip_lpj:
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
- struct device *mpu_dev;
static cpumask_var_t cpumask;
mpu_clk = clk_get(NULL, mpu_clk_name);
@@ -166,12 +166,6 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return -EINVAL;
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
- mpu_dev = omap2_get_mpuss_device();
-
- if (!mpu_dev) {
- pr_warning("%s: unable to get the mpu device\n", __func__);
- return -EINVAL;
- }
opp_init_cpufreq_table(mpu_dev, &freq_table);
if (freq_table) {
@@ -244,6 +238,13 @@ static int __init omap_cpufreq_init(void)
pr_err("%s: unsupported Silicon?\n", __func__);
return -EINVAL;
}
+
+ mpu_dev = omap2_get_mpuss_device();
+ if (!mpu_dev) {
+ pr_warning("%s: unable to get the mpu device\n", __func__);
+ return -EINVAL;
+ }
+
return cpufreq_register_driver(&omap_driver);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, while
OMAP3+ use OPP table to generate and release the cpufreq tables.
Hence use a flag to mark which API to use for allocating and freeing
the tables.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 2d4e9d7..dbbf8b2 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -44,6 +44,7 @@ static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
+static bool use_opp;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
@@ -166,7 +167,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return -EINVAL;
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
- opp_init_cpufreq_table(mpu_dev, &freq_table);
+ if (use_opp)
+ opp_init_cpufreq_table(mpu_dev, &freq_table);
+ else
+ clk_init_cpufreq_table(&freq_table);
if (freq_table) {
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
@@ -204,7 +208,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
- clk_exit_cpufreq_table(&freq_table);
+ if (use_opp)
+ opp_free_cpufreq_table(mpu_dev, &freq_table);
+ else
+ clk_exit_cpufreq_table(&freq_table);
clk_put(mpu_clk);
return 0;
}
@@ -227,12 +234,15 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
+ use_opp = true;
+ if (cpu_is_omap24xx()) {
mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
+ use_opp = false;
+ } else if (cpu_is_omap34xx()) {
mpu_clk_name = "dpll1_ck";
- else if (cpu_is_omap44xx())
+ } else if (cpu_is_omap44xx()) {
mpu_clk_name = "dpll_mpu_ck";
+ }
if (!mpu_clk_name) {
pr_err("%s: unsupported Silicon?\n", __func__);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 4/8] OMAP2+: cpufreq: dont support !freq_table
OMAP2+ all have frequency tables, hence the hacks we had for older
silicon do not need to be carried forward. As part of this change,
use cpufreq_frequency_table_target to find the best match for
frequency requested.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 64 +++---
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index dbbf8b2..7c0eb77 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -38,8 +38,6 @@
#include
-#define VERY_HI_RATE 9
-
static struct cpufreq_frequency_table *freq_table;
static struct clk *mpu_clk;
static char *mpu_clk_name;
@@ -48,20 +46,9 @@ static bool use_opp;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
- if (freq_table)
- return cpufreq_frequency_table_verify(policy, freq_table);
-
- if (policy->cpu)
+ if (!freq_table)
return -EINVAL;
-
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
-
- policy->min = clk_round_rate(mpu_clk, policy->min * 1000) / 1000;
- policy->max = clk_round_rate(mpu_clk, policy->max * 1000) / 1000;
- cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq,
-policy->cpuinfo.max_freq);
- return 0;
+ return cpufreq_frequency_table_verify(policy, freq_table);
}
static unsigned int omap_getspeed(unsigned int cpu)
@@ -79,22 +66,35 @@ static int omap_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
- int i, ret = 0;
+ unsigned int i;
+ int ret = 0;
struct cpufreq_freqs freqs;
/* Changes not allowed until all CPUs are online */
if (is_smp() && (num_online_cpus() < NR_CPUS))
return ret;
- /* Ensure desired rate is within allowed range. Some govenors
-* (ondemand) will just pass target_freq=0 to get the minimum. */
- if (target_freq < policy->min)
- target_freq = policy->min;
- if (target_freq > policy->max)
- target_freq = policy->max;
+ if (!freq_table) {
+ dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
+ policy->cpu);
+ return -EINVAL;
+ }
+
+ ret = cpufreq_frequency_table_target(policy, freq_table, target_freq,
+ relation, &i);
+ if (ret) {
+ dev_dbg(mpu_dev, "%s: cpu%d: no freq match for %d(ret=%d)\n",
+ __func__, policy->cpu, target_freq, ret);
+ return ret;
+ }
+ freqs.new = freq_table[i].frequency;
+ if (!freqs.new) {
+ dev_err(mpu_dev, "%s: cpu%d: no match for freq %d\n", __func__,
+ policy->cpu, target_freq);
+ return -EINVAL;
+ }
freqs.old = omap_getspeed(policy->cpu);
- freqs.new = clk_round_rate(mpu_clk, target_freq * 1000) / 1000;
freqs.cpu = policy->cpu;
if (freqs.old == freqs.new)
@@ -172,17 +172,17 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
else
clk_init_cpufreq_table(&freq_table);
- if (freq_table) {
- result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
- cpufreq_frequency_table_get_attr(freq_table,
- policy->cpu);
- } else {
- policy->cpuinfo.min_freq = clk_round_rate(mpu_clk, 0) / 1000;
- policy->cpuinfo.max_freq = clk_round_rate(mpu_clk,
- VERY_HI_RATE) / 1000;
+ if (!freq_table) {
+ dev_err(mpu_dev, "%s: cpu%d: unable to allocate freq table\n",
+ __func__, policy->cpu);
+ return -ENOMEM;
}
+ result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
+ if (!result)
+ cpufreq_frequency_table_get_attr(freq_table,
+ policy->cpu);
+
policy->min = policy->cpuinfo.min_freq;
policy->max = policy->cpuinfo.max_freq;
policy->cur = omap_getspeed(policy->cpu);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 5/8] OMAP2+: cpufreq: fix invalid cpufreq table with central alloc/free
By creating freq_table_[alloc|free] we can handle the differences
between OMAP2 and OMAP3+ systems and we have a centralized allocation
and cleanup strategy. We use this to cleanup the freq_table when
cpufreq_frequency_table_cpuinfo fails.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 48 +-
1 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 7c0eb77..3ff3302 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -154,6 +154,26 @@ skip_lpj:
return ret;
}
+static int freq_table_alloc(void)
+{
+ if (use_opp)
+ return opp_init_cpufreq_table(mpu_dev, &freq_table);
+
+ clk_init_cpufreq_table(&freq_table);
+ if (!freq_table)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static void freq_table_free(void)
+{
+ if (use_opp)
+ opp_free_cpufreq_table(mpu_dev, &freq_table);
+ else
+ clk_exit_cpufreq_table(&freq_table);
+}
+
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
@@ -167,21 +187,22 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return -EINVAL;
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
- if (use_opp)
- opp_init_cpufreq_table(mpu_dev, &freq_table);
- else
- clk_init_cpufreq_table(&freq_table);
- if (!freq_table) {
- dev_err(mpu_dev, "%s: cpu%d: unable to allocate freq table\n",
- __func__, policy->cpu);
- return -ENOMEM;
+ result = freq_table_alloc();
+ if (result || !freq_table) {
+ dev_err(mpu_dev, "%s: cpu%d: unable to get freq table [%d]\n",
+ __func__, policy->cpu, result);
+ return result;
}
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
- if (!result)
- cpufreq_frequency_table_get_attr(freq_table,
- policy->cpu);
+ if (result) {
+ dev_err(mpu_dev, "%s: cpu%d: unable to get cpuinfo [%d]\n",
+ __func__, policy->cpu, result);
+ freq_table_free();
+ return result;
+ }
+ cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
policy->min = policy->cpuinfo.min_freq;
policy->max = policy->cpuinfo.max_freq;
@@ -208,10 +229,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
- if (use_opp)
- opp_free_cpufreq_table(mpu_dev, &freq_table);
- else
- clk_exit_cpufreq_table(&freq_table);
+ freq_table_free();
clk_put(mpu_clk);
return 0;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 7/8] OMAP2+: cpufreq: put clk if cpu_init failed
Release the mpu_clk in fail paths.
Reported-by: Todd Poynor
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index f026ac4..594100e 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -226,8 +226,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (IS_ERR(mpu_clk))
return PTR_ERR(mpu_clk);
- if (policy->cpu >= NR_CPUS)
- return -EINVAL;
+ if (policy->cpu >= NR_CPUS) {
+ result = -EINVAL;
+ goto fail1;
+ }
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
@@ -235,7 +237,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (result || !freq_table) {
dev_err(mpu_dev, "%s: cpu%d: unable to get freq table [%d]\n",
__func__, policy->cpu, result);
- return result;
+ goto fail1;
}
mutex_lock(&freq_table_lock);
@@ -244,8 +246,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
mutex_unlock(&freq_table_lock);
dev_err(mpu_dev, "%s: cpu%d: unable to get cpuinfo [%d]\n",
__func__, policy->cpu, result);
- freq_table_free();
- return result;
+ goto fail2;
}
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
mutex_unlock(&freq_table_lock);
@@ -271,6 +272,12 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
policy->cpuinfo.transition_latency = 300 * 1000;
return 0;
+
+fail2:
+ freq_table_free();
+fail1:
+ clk_put(mpu_clk);
+ return result;
}
static int omap_cpu_exit(struct cpufreq_policy *policy)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 8/8] OMAP: cpufreq: minor file header updates
Minor file header updates to reflect 2011 for omap2-cpufreq code and remove misleading OMAP3 reference in omap1 cpufreq code. Should probably be squashed to: "OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers." Reported-by: Todd Poynor Signed-off-by: Nishanth Menon --- arch/arm/mach-omap1/omap1-cpufreq.c |1 - arch/arm/mach-omap2/omap2plus-cpufreq.c |2 +- 2 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap1/omap1-cpufreq.c b/arch/arm/mach-omap1/omap1-cpufreq.c index 682cdc8..7c5216e 100644 --- a/arch/arm/mach-omap1/omap1-cpufreq.c +++ b/arch/arm/mach-omap1/omap1-cpufreq.c @@ -9,7 +9,6 @@ * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King * * Copyright (C) 2007-2008 Texas Instruments, Inc. - * Updated to support OMAP3 * Rajendra Nayak * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c b/arch/arm/mach-omap2/omap2plus-cpufreq.c index 594100e..2482c71 100644 --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c @@ -8,7 +8,7 @@ * * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King * - * Copyright (C) 2007-2008 Texas Instruments, Inc. + * Copyright (C) 2007-20011 Texas Instruments, Inc. * Updated to support OMAP3 * Rajendra Nayak * -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PM-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
Since we have multiple CPUs, the cpuinit call for CPU1 causes
freq_table of CPU0 to be overwritten. Instead, we maintain
a counter to keep track of cpus who use the cpufreq table
allocate it once(one freq table for all CPUs) and free them
once the last user is done with it. We also need to protect
freq_table and this new counter from updates from multiple
contexts to be on a safe side.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/omap2plus-cpufreq.c | 62 +++
1 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 3ff3302..f026ac4 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -39,6 +39,9 @@
#include
static struct cpufreq_frequency_table *freq_table;
+static int freq_table_users;
+static DEFINE_MUTEX(freq_table_lock);
+
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
@@ -46,9 +49,17 @@ static bool use_opp;
static int omap_verify_speed(struct cpufreq_policy *policy)
{
+ int r = -EINVAL;
+
+ mutex_lock(&freq_table_lock);
if (!freq_table)
- return -EINVAL;
- return cpufreq_frequency_table_verify(policy, freq_table);
+ goto out;
+
+ r = cpufreq_frequency_table_verify(policy, freq_table);
+
+out:
+ mutex_unlock(&freq_table_lock);
+ return r;
}
static unsigned int omap_getspeed(unsigned int cpu)
@@ -74,9 +85,11 @@ static int omap_target(struct cpufreq_policy *policy,
if (is_smp() && (num_online_cpus() < NR_CPUS))
return ret;
+ mutex_lock(&freq_table_lock);
if (!freq_table) {
dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
policy->cpu);
+ mutex_unlock(&freq_table_lock);
return -EINVAL;
}
@@ -85,9 +98,13 @@ static int omap_target(struct cpufreq_policy *policy,
if (ret) {
dev_dbg(mpu_dev, "%s: cpu%d: no freq match for %d(ret=%d)\n",
__func__, policy->cpu, target_freq, ret);
+ mutex_unlock(&freq_table_lock);
return ret;
}
+
freqs.new = freq_table[i].frequency;
+ mutex_unlock(&freq_table_lock);
+
if (!freqs.new) {
dev_err(mpu_dev, "%s: cpu%d: no match for freq %d\n", __func__,
policy->cpu, target_freq);
@@ -156,22 +173,48 @@ skip_lpj:
static int freq_table_alloc(void)
{
- if (use_opp)
- return opp_init_cpufreq_table(mpu_dev, &freq_table);
+ int ret = 0;
- clk_init_cpufreq_table(&freq_table);
- if (!freq_table)
- return -ENOMEM;
+ mutex_lock(&freq_table_lock);
- return 0;
+ freq_table_users++;
+ /* Did we allocate previously? */
+ if (freq_table_users - 1)
+ goto out;
+
+ /* no, so we allocate */
+ if (use_opp) {
+ ret = opp_init_cpufreq_table(mpu_dev, &freq_table);
+ } else {
+ clk_init_cpufreq_table(&freq_table);
+ if (!freq_table)
+ ret = -ENOMEM;
+ }
+ /* if we did not allocate cleanly.. reduce user count */
+ if (!ret)
+ freq_table_users--;
+
+out:
+ mutex_unlock(&freq_table_lock);
+ return ret;
}
static void freq_table_free(void)
{
+ mutex_lock(&freq_table_lock);
+
+ if (!freq_table_users)
+ goto out;
+ freq_table_users--;
+ if (freq_table_users)
+ goto out;
+
if (use_opp)
opp_free_cpufreq_table(mpu_dev, &freq_table);
else
clk_exit_cpufreq_table(&freq_table);
+out:
+ mutex_unlock(&freq_table_lock);
}
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
@@ -195,14 +238,17 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return result;
}
+ mutex_lock(&freq_table_lock);
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (result) {
+ mutex_unlock(&freq_table_lock);
dev_err(mpu_dev, "%s: cpu%d: unable to get cpuinfo [%d]\n",
__func__, policy->cpu, result);
freq_table_free();
return result;
}
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
+ mutex_unlock(&freq_table_lock);
policy->min = policy->cpuinfo.min_freq;
policy->max = policy->cpuinfo.max_freq;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] OMAP: GPIO: clean omap_gpio_mod_init function
Tarun Kanti DebBarma writes:
> From: Charulatha V
>
> With register offsets now defined for respective OMAP versions
> we can get rid of cpu_class_* checks. In addition, organized
> common initialization for the different OMAP silicon versions.
>
> Signed-off-by: Charulatha V
> Signed-off-by: Tarun Kanti DebBarma
The sysconfig stuff in this patch should be removed. In fact, now that
hwmod is used to manage all the GPIO IP blocks, the driver should not be
touching sysconfig at all.
The hwmod defaults should be enough, and for enabling wake-ups, the
device-specific code should be calling omap_hwmod_enable_wakeup() (which
will also enable smart-idle if the IP supports it.)
> ---
> arch/arm/mach-omap1/gpio16xx.c |1 +
> arch/arm/plat-omap/include/plat/gpio.h |1 +
> drivers/gpio/gpio_omap.c | 74
> +---
> 3 files changed, 32 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
> index 24f6cfa..e9f8abd 100644
> --- a/arch/arm/mach-omap1/gpio16xx.c
> +++ b/arch/arm/mach-omap1/gpio16xx.c
> @@ -227,6 +227,7 @@ static int __init omap16xx_gpio_init(void)
> omap16xx_gpio_regs.wkupset = OMAP1610_GPIO_SET_WAKEUPENA;
> omap16xx_gpio_regs.edgectrl1 = OMAP1610_GPIO_EDGE_CTRL1;
> omap16xx_gpio_regs.edgectrl2 = OMAP1610_GPIO_EDGE_CTRL2;
> + omap16xx_gpio_regs.sysconfig = OMAP1610_GPIO_SYSCONFIG;
>
> for (i = 0; i < ARRAY_SIZE(omap16xx_gpio_dev); i++)
> platform_device_register(omap16xx_gpio_dev[i]);
> diff --git a/arch/arm/plat-omap/include/plat/gpio.h
> b/arch/arm/plat-omap/include/plat/gpio.h
> index f82881c..ac45191 100644
> --- a/arch/arm/plat-omap/include/plat/gpio.h
> +++ b/arch/arm/plat-omap/include/plat/gpio.h
> @@ -176,6 +176,7 @@ struct omap_gpio_dev_attr {
>
> struct omap_gpio_reg_offs {
> u16 revision;
> + u16 sysconfig;
> u16 direction;
> u16 datain;
> u16 dataout;
> diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
> index ebeb16e..3649c74 100644
> --- a/drivers/gpio/gpio_omap.c
> +++ b/drivers/gpio/gpio_omap.c
> @@ -885,65 +885,51 @@ static void __init omap_gpio_show_rev(struct gpio_bank
> *bank)
> called = true;
> }
>
> -/* This lock class tells lockdep that GPIO irqs are in a different
> +/*
> + * This lock class tells lockdep that GPIO irqs are in a different
> * category than their parents, so it won't report false recursion.
> */
> 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);
> + if (bank->width == 32) {
> + u32 l = 0;
> +
> + if (bank->regs->irqenable_inv)
> + l = ~l;
>
> + __raw_writel(l, bank->base + bank->regs->irqstatus);
The ->irqenable_inv flag doesn't affect ->irqstatus.
> + __raw_writel(l, bank->base + bank->regs->irqenable);
> +
> + if (bank->regs->debounce_en != USHRT_MAX)
> + __raw_writel(l, bank->base + bank->regs->debounce_en);
If ->irqenable_inv = true, debounce was just enabled for all GPIOs in
the bank.
> + if (bank->regs->ctrl != USHRT_MAX)
> /* 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);
> + __raw_writel(l, bank->base + bank->regs->ctrl);
If ->irqenable_env = true, all the clocks were just gated.
Similar problems below.
Kevin
> +
> + } else if (bank->width == 16) {
> + u16 l = 0;
> +
> + if (bank_is_mpuio(bank))
> mpuio_init(bank);
> - }
> - if (cpu_is_omap15xx() && bank->method == METHOD_GPIO_151
Re: [PM-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
Nishanth Menon writes:
> Since we have multiple CPUs, the cpuinit call for CPU1 causes
> freq_table of CPU0 to be overwritten. Instead, we maintain
> a counter to keep track of cpus who use the cpufreq table
> allocate it once(one freq table for all CPUs) and free them
> once the last user is done with it. We also need to protect
> freq_table and this new counter from updates from multiple
> contexts to be on a safe side.
Not sure I understand the need for all the locking here. Once allocated
and filled, the freq_table isn't changing. Also, all the functions are
only reading the freq_table, not changing it.So what is it you're
trying to protect against?
> Signed-off-by: Nishanth Menon
> ---
> arch/arm/mach-omap2/omap2plus-cpufreq.c | 62
> +++
> 1 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> index 3ff3302..f026ac4 100644
> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> @@ -39,6 +39,9 @@
> #include
>
> static struct cpufreq_frequency_table *freq_table;
> +static int freq_table_users;
> +static DEFINE_MUTEX(freq_table_lock);
> +
> static struct clk *mpu_clk;
> static char *mpu_clk_name;
> static struct device *mpu_dev;
> @@ -46,9 +49,17 @@ static bool use_opp;
>
> static int omap_verify_speed(struct cpufreq_policy *policy)
> {
> + int r = -EINVAL;
> +
> + mutex_lock(&freq_table_lock);
> if (!freq_table)
> - return -EINVAL;
> - return cpufreq_frequency_table_verify(policy, freq_table);
> + goto out;
> +
> + r = cpufreq_frequency_table_verify(policy, freq_table);
> +
> +out:
> + mutex_unlock(&freq_table_lock);
> + return r;
> }
>
> static unsigned int omap_getspeed(unsigned int cpu)
> @@ -74,9 +85,11 @@ static int omap_target(struct cpufreq_policy *policy,
> if (is_smp() && (num_online_cpus() < NR_CPUS))
> return ret;
>
> + mutex_lock(&freq_table_lock);
> if (!freq_table) {
> dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
> policy->cpu);
> + mutex_unlock(&freq_table_lock);
> return -EINVAL;
> }
>
> @@ -85,9 +98,13 @@ static int omap_target(struct cpufreq_policy *policy,
> if (ret) {
> dev_dbg(mpu_dev, "%s: cpu%d: no freq match for %d(ret=%d)\n",
> __func__, policy->cpu, target_freq, ret);
> + mutex_unlock(&freq_table_lock);
> return ret;
> }
> +
> freqs.new = freq_table[i].frequency;
> + mutex_unlock(&freq_table_lock);
> +
> if (!freqs.new) {
> dev_err(mpu_dev, "%s: cpu%d: no match for freq %d\n", __func__,
> policy->cpu, target_freq);
> @@ -156,22 +173,48 @@ skip_lpj:
>
> static int freq_table_alloc(void)
> {
> - if (use_opp)
> - return opp_init_cpufreq_table(mpu_dev, &freq_table);
> + int ret = 0;
>
> - clk_init_cpufreq_table(&freq_table);
> - if (!freq_table)
> - return -ENOMEM;
> + mutex_lock(&freq_table_lock);
>
> - return 0;
> + freq_table_users++;
> + /* Did we allocate previously? */
> + if (freq_table_users - 1)
> + goto out;
Rather than the ' - 1', this can just be
if (freq_table_users++)
goto out;
or better, you probably don't need this check protected by the mutex,
so this could just return directly, and then take the mutex_lock() after
this point.
However, if you get rid of the mutex (and I think you should), you could
use an atomic variable here
> + /* no, so we allocate */
> + if (use_opp) {
> + ret = opp_init_cpufreq_table(mpu_dev, &freq_table);
> + } else {
> + clk_init_cpufreq_table(&freq_table);
> + if (!freq_table)
> + ret = -ENOMEM;
> + }
> + /* if we did not allocate cleanly.. reduce user count */
> + if (!ret)
> + freq_table_users--;
> +
> +out:
> + mutex_unlock(&freq_table_lock);
> + return ret;
> }
>
> static void freq_table_free(void)
> {
> + mutex_lock(&freq_table_lock);
> +
> + if (!freq_table_users)
> + goto out;
> + freq_table_users--;
> + if (freq_table_users)
> + goto out;
Similarily:
if (--freq_table_users)
goto out;
> if (use_opp)
> opp_free_cpufreq_table(mpu_dev, &freq_table);
> else
> clk_exit_cpufreq_table(&freq_table);
> +out:
> + mutex_unlock(&freq_table_lock);
> }
>
> static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
> @@ -195,14 +238,17 @@ static int __cpuinit omap_cpu_init(struct
> cpufreq_policy *policy)
> return result;
> }
>
> + mutex_lock(&freq_table_lock);
> result = cpufreq_frequency_tabl
Re: [PM-WIP_CPUFREQ][PATCH V3 8/8] OMAP: cpufreq: minor file header updates
Nishanth Menon writes: > Minor file header updates to reflect 2011 for omap2-cpufreq code > and remove misleading OMAP3 reference in omap1 cpufreq code. > > Should probably be squashed to: > "OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers." > > Reported-by: Todd Poynor > Signed-off-by: Nishanth Menon [...] > diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c > b/arch/arm/mach-omap2/omap2plus-cpufreq.c > index 594100e..2482c71 100644 > --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c > +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c > @@ -8,7 +8,7 @@ > * > * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King > * > - * Copyright (C) 2007-2008 Texas Instruments, Inc. > + * Copyright (C) 2007-20011 Texas Instruments, Inc. Wow, you're really wanting to have copyright coverage well into the future ! ;) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
On Wed, May 25, 2011 at 17:16, Kevin Hilman wrote:
>
> Nishanth Menon writes:
>
> > Since we have multiple CPUs, the cpuinit call for CPU1 causes
> > freq_table of CPU0 to be overwritten. Instead, we maintain
> > a counter to keep track of cpus who use the cpufreq table
> > allocate it once(one freq table for all CPUs) and free them
> > once the last user is done with it. We also need to protect
> > freq_table and this new counter from updates from multiple
> > contexts to be on a safe side.
>
> Not sure I understand the need for all the locking here. Once allocated
> and filled, the freq_table isn't changing. Also, all the functions are
> only reading the freq_table, not changing it. So what is it you're
> trying to protect against?
We just have one freq_table for both cpu0 and cpu1. We have common
data structure(freq_table and users) which is modifiable in two
APIs(init/exit) and a set of reads. What if there is a read path while
free occurs - I may be mistaken, but my understanding is that the
datastructure used in my code should be secured in my code and I
cannot depend on higher layer(cpufreq/governors) to ensure that.
>
> > Signed-off-by: Nishanth Menon
> > ---
> > arch/arm/mach-omap2/omap2plus-cpufreq.c | 62
> > +++
> > 1 files changed, 54 insertions(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> > b/arch/arm/mach-omap2/omap2plus-cpufreq.c
> > index 3ff3302..f026ac4 100644
> > --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
> > +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
[..]
> > @@ -156,22 +173,48 @@ skip_lpj:
> >
> > static int freq_table_alloc(void)
> > {
> > - if (use_opp)
> > - return opp_init_cpufreq_table(mpu_dev, &freq_table);
> > + int ret = 0;
> >
> > - clk_init_cpufreq_table(&freq_table);
> > - if (!freq_table)
> > - return -ENOMEM;
> > + mutex_lock(&freq_table_lock);
> >
> > - return 0;
> > + freq_table_users++;
> > + /* Did we allocate previously? */
> > + if (freq_table_users - 1)
> > + goto out;
>
> Rather than the ' - 1', this can just be
>
> if (freq_table_users++)
> goto out;
ok
>
> or better, you probably don't need this check protected by the mutex,
> so this could just return directly, and then take the mutex_lock() after
> this point.
The mutex lock was to protect both the freq_table and the count as
they protect the same resource - freq_table
>
> However, if you get rid of the mutex (and I think you should), you could
> use an atomic variable here
yes, we can use just atomic to protect alloc Vs free - but we cannot
protect read Vs free
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 8/8] OMAP: cpufreq: minor file header updates
On Wed, May 25, 2011 at 17:18, Kevin Hilman wrote: > Nishanth Menon writes: > >> Minor file header updates to reflect 2011 for omap2-cpufreq code >> and remove misleading OMAP3 reference in omap1 cpufreq code. >> >> Should probably be squashed to: >> "OMAP: cpufreq: Split OMAP1 and OMAP2PLUS CPUfreq drivers." >> >> Reported-by: Todd Poynor >> Signed-off-by: Nishanth Menon > > [...] > >> diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c >> b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> index 594100e..2482c71 100644 >> --- a/arch/arm/mach-omap2/omap2plus-cpufreq.c >> +++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c >> @@ -8,7 +8,7 @@ >> * >> * Based on cpu-sa1110.c, Copyright (C) 2001 Russell King >> * >> - * Copyright (C) 2007-2008 Texas Instruments, Inc. >> + * Copyright (C) 2007-20011 Texas Instruments, Inc. > > Wow, you're really wanting to have copyright coverage well into the > future ! ;) I must be on a timemachine ;).. will fix :D Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 4/8] OMAP2+: cpufreq: dont support !freq_table
On Wed, May 25, 2011 at 04:38:49PM -0700, Nishanth Menon wrote:
> OMAP2+ all have frequency tables, hence the hacks we had for older
> silicon do not need to be carried forward. As part of this change,
> use cpufreq_frequency_table_target to find the best match for
> frequency requested.
>
> Signed-off-by: Nishanth Menon
...
> @@ -79,22 +66,35 @@ static int omap_target(struct cpufreq_policy *policy,
> unsigned int target_freq,
> unsigned int relation)
> {
> - int i, ret = 0;
> + unsigned int i;
> + int ret = 0;
> struct cpufreq_freqs freqs;
>
> /* Changes not allowed until all CPUs are online */
> if (is_smp() && (num_online_cpus() < NR_CPUS))
> return ret;
>
> - /* Ensure desired rate is within allowed range. Some govenors
> - * (ondemand) will just pass target_freq=0 to get the minimum. */
> - if (target_freq < policy->min)
> - target_freq = policy->min;
> - if (target_freq > policy->max)
> - target_freq = policy->max;
> + if (!freq_table) {
> + dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
> + policy->cpu);
Just a minor comment: suggest dev_dbg() or WARN_ONCE() for some of
these conditions that may be frequently evaluated and probably won't
be cleared up after being hit once.
...
Todd
--
To unsubscribe from this list: send the line "unsubscribe 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-WIP_CPUFREQ][PATCH V3 4/8] OMAP2+: cpufreq: dont support !freq_table
On Wed, May 25, 2011 at 17:51, Todd Poynor wrote:
>
>> + if (!freq_table) {
>> + dev_err(mpu_dev, "%s: cpu%d: no freq table!\n", __func__,
>> + policy->cpu);
>
> Just a minor comment: suggest dev_dbg() or WARN_ONCE() for some of
> these conditions that may be frequently evaluated and probably won't
> be cleared up after being hit once.
This is an error because we dont expect it as far as the device is
concerned. I'd use a debug/warn if I can recover out of it and
continue functionality.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 4/8] OMAP2+: cpufreq: dont support !freq_table
On Wed, May 25, 2011 at 17:53, ym cheng wrote: > OK,I wil test on s3c2440 board,and share test data. The series was meant for OMAP, if you meant: http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=836&partnum=S3C2440 as far as I see, this platform is supported on arch/arm/mach-s3c24* Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 5/8] OMAP2+: cpufreq: fix invalid cpufreq table with central alloc/free
On Wed, May 25, 2011 at 04:38:50PM -0700, Nishanth Menon wrote:
> By creating freq_table_[alloc|free] we can handle the differences
> between OMAP2 and OMAP3+ systems and we have a centralized allocation
> and cleanup strategy. We use this to cleanup the freq_table when
> cpufreq_frequency_table_cpuinfo fails.
>
> Signed-off-by: Nishanth Menon
> ---
...
> static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
> {
> int result = 0;
> @@ -167,21 +187,22 @@ static int __cpuinit omap_cpu_init(struct
> cpufreq_policy *policy)
> return -EINVAL;
>
> policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
> - if (use_opp)
> - opp_init_cpufreq_table(mpu_dev, &freq_table);
> - else
> - clk_init_cpufreq_table(&freq_table);
>
> - if (!freq_table) {
> - dev_err(mpu_dev, "%s: cpu%d: unable to allocate freq table\n",
> - __func__, policy->cpu);
> - return -ENOMEM;
> + result = freq_table_alloc();
> + if (result || !freq_table) {
> + dev_err(mpu_dev, "%s: cpu%d: unable to get freq table [%d]\n",
> + __func__, policy->cpu, result);
> + return result;
The "|| !freq_table" isn't needed, and technically allows the code to
return zero for an error return if the subexpression does evaluate
true.
Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4] Consolidate SRAM support
From: Russell King - ARM Linux
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
For this use the generic allocator and the newly introduce
gen_pool_add_virt and gen_pool_virt_to_phys
Uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.
Signed-off-by: Russell King
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Sascha Hauer
---
v4:
update against linus tree and genalloc gen_pool_add_virt and
gen_pool_virt_to_phys
Best Regards,
J.
arch/arm/Kconfig |2 +
arch/arm/mach-davinci/da850.c |2 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/common.h|2 +-
arch/arm/mach-davinci/include/mach/sram.h | 13 +
arch/arm/mach-davinci/pm.c | 21 +++
arch/arm/mach-davinci/sram.c | 57 +--
arch/arm/plat-mxc/include/mach/iram.h | 28 --
.../plat-mxc/{include/mach/iram.h => iram_alloc.c} | 40 --
arch/arm/plat-omap/include/plat/sram.h | 19 +--
arch/arm/plat-omap/sram.c | 38 +
drivers/uio/uio_pruss.c| 10 +++-
sound/soc/davinci/davinci-pcm.c| 11 +++--
16 files changed, 122 insertions(+), 129 deletions(-)
copy arch/arm/plat-mxc/{include/mach/iram.h => iram_alloc.c} (56%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4b7dfa..5ec5e5f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -848,6 +848,7 @@ config ARCH_DAVINCI
bool "TI DaVinci"
select GENERIC_CLOCKEVENTS
select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_ALLOCATOR
select ZONE_DMA
select HAVE_IDE
select CLKDEV_LOOKUP
@@ -862,6 +863,7 @@ config ARCH_OMAP
select HAVE_CLK
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+ select GENERIC_ALLOCATOR
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
.gpio_irq = IRQ_DA8XX_GPIO0,
.serial_dev = &da8xx_serial_device,
.emac_pdata = &da8xx_emac_pdata,
- .sram_dma = DA8XX_ARM_RAM_BASE,
+ .sram_phys = DA8XX_ARM_RAM_BASE,
.sram_len = SZ_8K,
.reset_device = &da8xx_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
.gpio_num = 104,
.gpio_irq = IRQ_DM355_GPIOBNK0,
.serial_dev = &dm355_serial_device,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
.sram_len = SZ_32K,
.reset_device = &davinci_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.gpio_unbanked = 8,/* really 16 ... skip muxed GPIOs */
.serial_dev = &dm365_serial_device,
.emac_pdata = &dm365_emac_pdata,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
.sram_len = SZ_32K,
.reset_device = &davinci_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
.gpio_irq = IRQ_GPIOBNK0,
.serial_dev = &dm644x_serial_device,
.emac_pdata = &dm644x_emac_pdata,
- .sram_dma = 0x8000,
+ .sram_phys = 0x8000,
.sram_
Re: [PM-WIP_CPUFREQ][PATCH V3 5/8] OMAP2+: cpufreq: fix invalid cpufreq table with central alloc/free
On Wed, May 25, 2011 at 18:09, Todd Poynor wrote:
>> + if (result || !freq_table) {
>> + dev_err(mpu_dev, "%s: cpu%d: unable to get freq table [%d]\n",
>> + __func__, policy->cpu, result);
>> + return result;
>
> The "|| !freq_table" isn't needed, and technically allows the code to
> return zero for an error return if the subexpression does evaluate
> true.
>
Ack..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
> Since we have multiple CPUs, the cpuinit call for CPU1 causes
> freq_table of CPU0 to be overwritten. Instead, we maintain
> a counter to keep track of cpus who use the cpufreq table
> allocate it once(one freq table for all CPUs) and free them
> once the last user is done with it. We also need to protect
> freq_table and this new counter from updates from multiple
> contexts to be on a safe side.
>
> Signed-off-by: Nishanth Menon
> ---
...
> static int freq_table_alloc(void)
> {
> - if (use_opp)
> - return opp_init_cpufreq_table(mpu_dev, &freq_table);
> + int ret = 0;
>
> - clk_init_cpufreq_table(&freq_table);
> - if (!freq_table)
> - return -ENOMEM;
> + mutex_lock(&freq_table_lock);
>
> - return 0;
> + freq_table_users++;
> + /* Did we allocate previously? */
> + if (freq_table_users - 1)
> + goto out;
> +
> + /* no, so we allocate */
> + if (use_opp) {
> + ret = opp_init_cpufreq_table(mpu_dev, &freq_table);
> + } else {
> + clk_init_cpufreq_table(&freq_table);
> + if (!freq_table)
> + ret = -ENOMEM;
> + }
> + /* if we did not allocate cleanly.. reduce user count */
> + if (!ret)
> + freq_table_users--;
"if (ret)" intended? ret == 0 means allocated OK.
Todd
--
To unsubscribe from this list: send the line "unsubscribe 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-WIP_CPUFREQ][PATCH V3 6/8] OMAP2+: cpufreq: fix freq_table leak
On Wed, May 25, 2011 at 18:25, Todd Poynor wrote:
> On Wed, May 25, 2011 at 04:38:51PM -0700, Nishanth Menon wrote:
>> Since we have multiple CPUs, the cpuinit call for CPU1 causes
>> freq_table of CPU0 to be overwritten. Instead, we maintain
>> a counter to keep track of cpus who use the cpufreq table
>> allocate it once(one freq table for all CPUs) and free them
>> once the last user is done with it. We also need to protect
>> freq_table and this new counter from updates from multiple
>> contexts to be on a safe side.
>>
>> Signed-off-by: Nishanth Menon
>> ---
> ...
>> static int freq_table_alloc(void)
>> {
>> - if (use_opp)
>> - return opp_init_cpufreq_table(mpu_dev, &freq_table);
>> + int ret = 0;
>>
>> - clk_init_cpufreq_table(&freq_table);
>> - if (!freq_table)
>> - return -ENOMEM;
>> + mutex_lock(&freq_table_lock);
>>
>> - return 0;
>> + freq_table_users++;
>> + /* Did we allocate previously? */
>> + if (freq_table_users - 1)
>> + goto out;
>> +
>> + /* no, so we allocate */
>> + if (use_opp) {
>> + ret = opp_init_cpufreq_table(mpu_dev, &freq_table);
>> + } else {
>> + clk_init_cpufreq_table(&freq_table);
>> + if (!freq_table)
>> + ret = -ENOMEM;
>> + }
>> + /* if we did not allocate cleanly.. reduce user count */
>> + if (!ret)
>> + freq_table_users--;
>
> "if (ret)" intended? ret == 0 means allocated OK.
arrgh.. yikes..
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 1/9] OMAP: ID: introduce chip detection for OMAP4460
From: Aneesh V
Add support for detecting the latest in the OMAP4 family: OMAP4460
Among other changes, the new chip also can support 1.5GHz A9s,
1080p stereoscopic 3D and 12 MP stereo (dual camera). In addition,
we have changes to OPPs supported, clock tree etc, hence having a
chip detection is required.
Starting from OMAP4460 ES1.0, we are moving from HAWKEYE to Ramp system
for chip identification. Since the bit offsets are the same, just rename
the variable for dual use.
For more details on OMAP4460, see
Highlights:
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=53243&navigationId=12843&templateId=6123
Public TRM is available here as usual:
http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12667
[n...@ti.com: cleanups and introduction of ramp system]
Signed-off-by: Nishanth Menon
Signed-off-by: Aneesh V
---
arch/arm/mach-omap2/id.c | 19 ++-
arch/arm/plat-omap/include/plat/cpu.h | 12
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2537090..724be0a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -331,7 +331,7 @@ static void __init omap3_check_revision(void)
static void __init omap4_check_revision(void)
{
u32 idcode;
- u16 hawkeye;
+ u16 hawkeye_ramp;
u8 rev;
/*
@@ -340,19 +340,19 @@ static void __init omap4_check_revision(void)
* revision numbers as ES1.0 uses value 0.
*/
idcode = read_tap_reg(OMAP_TAP_IDCODE);
- hawkeye = (idcode >> 12) & 0x;
+ hawkeye_ramp = (idcode >> 12) & 0x;
rev = (idcode >> 28) & 0xf;
/*
-* Few initial ES2.0 samples IDCODE is same as ES1.0
+* Few initial 4430 ES2.0 samples IDCODE is same as ES1.0
* Use ARM register to detect the correct ES version
*/
- if (!rev) {
+ if (!rev && (hawkeye_ramp != 0xb94e)) {
idcode = read_cpuid(CPUID_ID);
rev = (idcode & 0xf) - 1;
}
- switch (hawkeye) {
+ switch (hawkeye_ramp) {
case 0xb852:
switch (rev) {
case 0:
@@ -377,6 +377,15 @@ static void __init omap4_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP4430ES2_2;
}
break;
+ case 0xb94e:
+ switch (rev) {
+ case 0:
+ default:
+ omap_revision = OMAP4460_REV_ES1_0;
+ omap_chip.oc |= CHIP_IS_OMAP4460ES1_0;
+ break;
+ }
+ break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP4430_REV_ES2_2;
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 8198bb6..d12b63d 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -88,6 +88,7 @@ unsigned int omap_rev(void);
* cpu_is_omap243x(): True for OMAP2430
* cpu_is_omap343x(): True for OMAP3430
* cpu_is_omap443x(): True for OMAP4430
+ * cpu_is_omap446x(): True for OMAP4460
*/
#define GET_OMAP_CLASS (omap_rev() & 0xff)
@@ -123,6 +124,7 @@ IS_OMAP_SUBCLASS(243x, 0x243)
IS_OMAP_SUBCLASS(343x, 0x343)
IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
+IS_OMAP_SUBCLASS(446x, 0x446)
IS_TI_SUBCLASS(816x, 0x816)
@@ -137,6 +139,7 @@ IS_TI_SUBCLASS(816x, 0x816)
#define cpu_is_ti816x()0
#define cpu_is_omap44xx() 0
#define cpu_is_omap443x() 0
+#define cpu_is_omap446x() 0
#if defined(MULTI_OMAP1)
# if defined(CONFIG_ARCH_OMAP730)
@@ -361,8 +364,10 @@ IS_OMAP_TYPE(3517, 0x3517)
# if defined(CONFIG_ARCH_OMAP4)
# undef cpu_is_omap44xx
# undef cpu_is_omap443x
+# undef cpu_is_omap446x
# define cpu_is_omap44xx() is_omap44xx()
# define cpu_is_omap443x() is_omap443x()
+# define cpu_is_omap446x() is_omap446x()
# endif
/* Macros to detect if we have OMAP1 or OMAP2 */
@@ -410,6 +415,9 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP4430_REV_ES2_1 (OMAP443X_CLASS | (0x21 << 8))
#define OMAP4430_REV_ES2_2 (OMAP443X_CLASS | (0x22 << 8))
+#define OMAP446X_CLASS 0x44600044
+#define OMAP4460_REV_ES1_0 (OMAP446X_CLASS | (0x10 << 8))
+
/*
* omap_chip bits
*
@@ -439,6 +447,7 @@ IS_OMAP_TYPE(3517, 0x3517)
#define CHIP_IS_OMAP4430ES2_1 (1 << 12)
#define CHIP_IS_OMAP4430ES2_2 (1 << 13)
#define CHIP_IS_TI816X (1 << 14)
+#define CHIP_IS_OMAP4460ES1_0 (1 << 15)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
@@ -447,6 +456,9 @@ IS_OMAP_TYPE(3517, 0x3517)
CHIP_IS_OMAP4430ES2_1 |\
[RFC][PATCH 0/9] OMAP4: Add 4460 base support
Hi, Here is the initial RFC providing base support for OMAP4460, This series based on v2.6.39 tag boots up on SDP4460: http://pastebin.pandaboard.org/index.php/view/28646263 Aneesh V (2): OMAP: ID: introduce chip detection for OMAP4460 OMAP4: HWMOD: make current hwmods common for 4460 and 4430 Moiz Sonasath (1): OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init Rajendra Nayak (6): OMAP4: clocks: distinguish 4430 and 4460 OMAP4: PRM: OMAP4460 specific PRM and CM register bitshifts OMAP4: clocks: Update the clock tree with 4460 clock nodes OMAP4: powerdomain: Update MPU powerdomain for 4460 OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460 OMAP4460: dpll: Support MPU frequencies > 1 Ghz arch/arm/mach-omap2/clock44xx_data.c | 676 + arch/arm/mach-omap2/clockdomains44xx_data.c | 200 arch/arm/mach-omap2/cm-regbits-44xx.h | 32 ++ arch/arm/mach-omap2/dpll3xxx.c| 58 +++ arch/arm/mach-omap2/id.c | 19 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 187 --- arch/arm/mach-omap2/powerdomains44xx_data.c | 53 ++- arch/arm/mach-omap2/prm-regbits-44xx.h| 10 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |2 + arch/arm/plat-omap/include/plat/clock.h |2 + arch/arm/plat-omap/include/plat/cpu.h | 12 + 11 files changed, 718 insertions(+), 533 deletions(-) Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 2/9] OMAP4: HWMOD: make current hwmods common for 4460 and 4430
From: Aneesh V
Make all hwmod data used for OMAP4430 available for
the OMAP44XX class so that OMAP4460 can use them.
We will modify the required 4460 hwmod in further patch(es).
[n...@ti.com: just rebased to .39]
Signed-off-by: Nishanth Menon
Signed-off-by: Aneesh V
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 164 ++--
1 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index abc548a..2f51a5a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -124,7 +124,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_dmm_slaves),
.mpu_irqs = omap44xx_dmm_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dmm_irqs),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -173,7 +173,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
.class = &omap44xx_emif_fw_hwmod_class,
.slaves = omap44xx_emif_fw_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_emif_fw_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -212,7 +212,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
.class = &omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_instr_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_instr_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_1 interface data */
@@ -306,7 +306,7 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_l3_targ_irqs),
.slaves = omap44xx_l3_main_1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_1_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_2 interface data */
@@ -401,7 +401,7 @@ static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
.class = &omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_main_2_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_2_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l3_main_3 interface data */
@@ -451,7 +451,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
.class = &omap44xx_l3_hwmod_class,
.slaves = omap44xx_l3_main_3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l3_main_3_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -508,7 +508,7 @@ static struct omap_hwmod omap44xx_l4_abe_hwmod = {
.class = &omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_abe_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_abe_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_cfg interface data */
@@ -530,7 +530,7 @@ static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
.class = &omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_cfg_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_cfg_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_per interface data */
@@ -552,7 +552,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod = {
.class = &omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_per_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_per_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/* l4_wkup interface data */
@@ -574,7 +574,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
.class = &omap44xx_l4_hwmod_class,
.slaves = omap44xx_l4_wkup_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_l4_wkup_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -604,7 +604,7 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
.class = &omap44xx_mpu_bus_hwmod_class,
.slaves = omap44xx_mpu_private_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mpu_private_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
};
/*
@@ -749,7 +749,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_aes
[RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
From: Moiz Sonasath
For OMAP4460, GPIO-7 of bank1 is used for controling
the TPS modes, hence GPIO1 should not be reset
during init as reset will cause the TPS voltage to
drop to 0.9 V.
Originally from:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=52ae4f0de03b17c064d9ce90a580230f1a596ec1
[n...@ti.com: upstream version]
Signed-off-by: Nishanth Menon
Signed-off-by: Moiz Sonasath
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 2f51a5a..27319c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1745,7 +1745,7 @@ static struct omap_hwmod_opt_clk gpio1_opt_clks[] = {
{ .role = "dbclk", .clk = "gpio1_dbclk" },
};
-static struct omap_hwmod omap44xx_gpio1_hwmod = {
+static struct omap_hwmod omap443x_gpio1_hwmod = {
.name = "gpio1",
.class = &omap44xx_gpio_hwmod_class,
.mpu_irqs = omap44xx_gpio1_irqs,
@@ -1761,7 +1761,27 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
.dev_attr = &gpio_dev_attr,
.slaves = omap44xx_gpio1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+static struct omap_hwmod omap446x_gpio1_hwmod = {
+ .name = "gpio1",
+ .class = &omap44xx_gpio_hwmod_class,
+ .flags = HWMOD_INIT_NO_RESET,
+ .mpu_irqs = omap44xx_gpio1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_gpio1_irqs),
+ .main_clk = "gpio1_ick",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_GPIO1_CLKCTRL,
+ },
+ },
+ .opt_clks = gpio1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(gpio1_opt_clks),
+ .dev_attr = &gpio_dev_attr,
+ .slaves = omap44xx_gpio1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_gpio1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
};
/* gpio2 */
@@ -5079,7 +5099,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_dss_venc_hwmod,
/* gpio class */
- &omap44xx_gpio1_hwmod,
+ &omap443x_gpio1_hwmod,
+ &omap446x_gpio1_hwmod,
&omap44xx_gpio2_hwmod,
&omap44xx_gpio3_hwmod,
&omap44xx_gpio4_hwmod,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 4/9] OMAP4: clocks: distinguish 4430 and 4460
From: Rajendra Nayak
omap4460 platform has a few clock nodes which are added
and a few which are missing (compared to the 4430 platform)
rename current 4430 definitions to 44XX and followon patches
will introduce the 4460 changes
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock44xx_data.c | 659 +
arch/arm/plat-omap/include/plat/clkdev_omap.h |2 +
arch/arm/plat-omap/include/plat/clock.h |2 +
3 files changed, 335 insertions(+), 328 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 8c96567..96c0e3e 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1,7 +1,7 @@
/*
- * OMAP4 Clock data
+ * OMAP44xx Clock data
*
- * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2011 Texas Instruments, Inc.
* Copyright (C) 2009-2010 Nokia Corporation
*
* Paul Walmsley (p...@pwsan.com)
@@ -127,42 +127,42 @@ static struct clk virt_3840_ck = {
};
static const struct clksel_rate div_1_0_rates[] = {
- { .div = 1, .val = 0, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 0, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_1_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 1, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_2_rates[] = {
- { .div = 1, .val = 2, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 2, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_3_rates[] = {
- { .div = 1, .val = 3, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 3, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_4_rates[] = {
- { .div = 1, .val = 4, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 4, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_5_rates[] = {
- { .div = 1, .val = 5, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 5, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_6_rates[] = {
- { .div = 1, .val = 6, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 6, .flags = RATE_IN_44XX },
{ .div = 0 },
};
static const struct clksel_rate div_1_7_rates[] = {
- { .div = 1, .val = 7, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 7, .flags = RATE_IN_44XX },
{ .div = 0 },
};
@@ -285,37 +285,37 @@ static struct clk dpll_abe_x2_ck = {
};
static const struct clksel_rate div31_1to31_rates[] = {
- { .div = 1, .val = 1, .flags = RATE_IN_4430 },
- { .div = 2, .val = 2, .flags = RATE_IN_4430 },
- { .div = 3, .val = 3, .flags = RATE_IN_4430 },
- { .div = 4, .val = 4, .flags = RATE_IN_4430 },
- { .div = 5, .val = 5, .flags = RATE_IN_4430 },
- { .div = 6, .val = 6, .flags = RATE_IN_4430 },
- { .div = 7, .val = 7, .flags = RATE_IN_4430 },
- { .div = 8, .val = 8, .flags = RATE_IN_4430 },
- { .div = 9, .val = 9, .flags = RATE_IN_4430 },
- { .div = 10, .val = 10, .flags = RATE_IN_4430 },
- { .div = 11, .val = 11, .flags = RATE_IN_4430 },
- { .div = 12, .val = 12, .flags = RATE_IN_4430 },
- { .div = 13, .val = 13, .flags = RATE_IN_4430 },
- { .div = 14, .val = 14, .flags = RATE_IN_4430 },
- { .div = 15, .val = 15, .flags = RATE_IN_4430 },
- { .div = 16, .val = 16, .flags = RATE_IN_4430 },
- { .div = 17, .val = 17, .flags = RATE_IN_4430 },
- { .div = 18, .val = 18, .flags = RATE_IN_4430 },
- { .div = 19, .val = 19, .flags = RATE_IN_4430 },
- { .div = 20, .val = 20, .flags = RATE_IN_4430 },
- { .div = 21, .val = 21, .flags = RATE_IN_4430 },
- { .div = 22, .val = 22, .flags = RATE_IN_4430 },
- { .div = 23, .val = 23, .flags = RATE_IN_4430 },
- { .div = 24, .val = 24, .flags = RATE_IN_4430 },
- { .div = 25, .val = 25, .flags = RATE_IN_4430 },
- { .div = 26, .val = 26, .flags = RATE_IN_4430 },
- { .div = 27, .val = 27, .flags = RATE_IN_4430 },
- { .div = 28, .val = 28, .flags = RATE_IN_4430 },
- { .div = 29, .val = 29, .flags = RATE_IN_4430 },
- { .div = 30, .val = 30, .flags = RATE_IN_4430 },
- { .div = 31, .val = 31, .flags = RATE_IN_4430 },
+ { .div = 1, .val = 1, .flags = RATE_IN_44XX },
+ { .div = 2, .val = 2, .flags = RATE_IN_44XX },
+ { .div = 3, .val = 3, .flags = RATE_IN_44XX },
+ { .div = 4, .val = 4, .flags = RATE_IN_44XX },
+ { .div = 5, .val = 5, .flags = RATE_IN_44XX },
+ { .div = 6, .val = 6, .flags = RATE_IN_44XX },
+ { .div = 7, .val = 7, .flags = RATE_IN_44XX },
+ { .div = 8, .val = 8, .flags = RATE_IN_44XX },
+ { .div = 9, .val = 9, .flags = RATE_IN_44XX },
+ { .div = 10, .val = 10, .flags = RATE_IN_44XX },
+
[RFC][PATCH 5/9] OMAP4: PRM: OMAP4460 specific PRM and CM register bitshifts
From: Rajendra Nayak This patch adds additional register bitshifts for registers added in OMAP4460 platform. Signed-off-by: Rajendra Nayak --- arch/arm/mach-omap2/cm-regbits-44xx.h | 32 arch/arm/mach-omap2/prm-regbits-44xx.h | 10 +- 2 files changed, 41 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/cm-regbits-44xx.h b/arch/arm/mach-omap2/cm-regbits-44xx.h index 9d47a05..4c4cbfa 100644 --- a/arch/arm/mach-omap2/cm-regbits-44xx.h +++ b/arch/arm/mach-omap2/cm-regbits-44xx.h @@ -106,6 +106,10 @@ #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CORE_DPLL_EMU_CLK_MASK(1 << 9) +/* Used by CM_L4CFG_CLKSTCTRL */ +#define OMAP4460_CLKACTIVITY_CORE_TS_GFCLK_SHIFT 9 +#define OMAP4460_CLKACTIVITY_CORE_TS_GFCLK_MASK(1 << 9) + /* Used by CM_CEFUSE_CLKSTCTRL */ #define OMAP4430_CLKACTIVITY_CUST_EFUSE_SYS_CLK_SHIFT 9 #define OMAP4430_CLKACTIVITY_CUST_EFUSE_SYS_CLK_MASK (1 << 9) @@ -418,6 +422,10 @@ #define OMAP4430_CLKACTIVITY_WKUP_32K_GFCLK_SHIFT 11 #define OMAP4430_CLKACTIVITY_WKUP_32K_GFCLK_MASK (1 << 11) +/* Used by CM_WKUP_CLKSTCTRL */ +#define OMAP4460_CLKACTIVITY_WKUP_TS_GFCLK_SHIFT 13 +#define OMAP4460_CLKACTIVITY_WKUP_TS_GFCLK_MASK(1 << 13) + /* * Used by CM1_ABE_TIMER5_CLKCTRL, CM1_ABE_TIMER6_CLKCTRL, * CM1_ABE_TIMER7_CLKCTRL, CM1_ABE_TIMER8_CLKCTRL, CM_L3INIT_MMC1_CLKCTRL, @@ -449,6 +457,10 @@ #define OMAP4430_CLKSEL_60M_SHIFT 24 #define OMAP4430_CLKSEL_60M_MASK (1 << 24) +/* Used by CM_MPU_MPU_CLKCTRL */ +#define OMAP4460_CLKSEL_ABE_DIV_MODE_SHIFT 25 +#define OMAP4460_CLKSEL_ABE_DIV_MODE_MASK (1 << 25) + /* Used by CM1_ABE_AESS_CLKCTRL */ #define OMAP4430_CLKSEL_AESS_FCLK_SHIFT24 #define OMAP4430_CLKSEL_AESS_FCLK_MASK (1 << 24) @@ -468,6 +480,10 @@ #define OMAP4430_CLKSEL_DIV_SHIFT 24 #define OMAP4430_CLKSEL_DIV_MASK (1 << 24) +/* Used by CM_MPU_MPU_CLKCTRL */ +#define OMAP4460_CLKSEL_EMIF_DIV_MODE_SHIFT24 +#define OMAP4460_CLKSEL_EMIF_DIV_MODE_MASK (1 << 24) + /* Used by CM_CAM_FDIF_CLKCTRL */ #define OMAP4430_CLKSEL_FCLK_SHIFT 24 #define OMAP4430_CLKSEL_FCLK_MASK (0x3 << 24) @@ -572,6 +588,14 @@ #define OMAP4430_D2D_STATDEP_SHIFT 18 #define OMAP4430_D2D_STATDEP_MASK (1 << 18) +/* Used by CM_CLKSEL_DPLL_MPU */ +#define OMAP4460_DCC_COUNT_MAX_SHIFT 24 +#define OMAP4460_DCC_COUNT_MAX_MASK(0xff << 24) + +/* Used by CM_CLKSEL_DPLL_MPU */ +#define OMAP4460_DCC_EN_SHIFT 22 +#define OMAP4460_DCC_EN_MASK (1 << 22) + /* * Used by CM_SSC_DELTAMSTEP_DPLL_ABE, CM_SSC_DELTAMSTEP_DPLL_CORE, * CM_SSC_DELTAMSTEP_DPLL_CORE_RESTORE, CM_SSC_DELTAMSTEP_DPLL_DDRPHY, @@ -1204,6 +1228,10 @@ #define OMAP4430_MODULEMODE_SHIFT 0 #define OMAP4430_MODULEMODE_MASK (0x3 << 0) +/* Used by CM_L4CFG_DYNAMICDEP */ +#define OMAP4460_MPU_DYNDEP_SHIFT 19 +#define OMAP4460_MPU_DYNDEP_MASK (1 << 19) + /* Used by CM_DSS_DSS_CLKCTRL */ #define OMAP4430_OPTFCLKEN_48MHZ_CLK_SHIFT 9 #define OMAP4430_OPTFCLKEN_48MHZ_CLK_MASK (1 << 9) @@ -1298,6 +1326,10 @@ #define OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT 10 #define OMAP4430_OPTFCLKEN_SYS_CLK_MASK(1 << 10) +/* Used by CM_WKUP_BANDGAP_CLKCTRL */ +#define OMAP4460_OPTFCLKEN_TS_FCLK_SHIFT 8 +#define OMAP4460_OPTFCLKEN_TS_FCLK_MASK(1 << 8) + /* Used by CM_DSS_DSS_CLKCTRL */ #define OMAP4430_OPTFCLKEN_TV_CLK_SHIFT11 #define OMAP4430_OPTFCLKEN_TV_CLK_MASK (1 << 11) diff --git a/arch/arm/mach-omap2/prm-regbits-44xx.h b/arch/arm/mach-omap2/prm-regbits-44xx.h index 6d2776f..2ae607e 100644 --- a/arch/arm/mach-omap2/prm-regbits-44xx.h +++ b/arch/arm/mach-omap2/prm-regbits-44xx.h @@ -1,7 +1,7 @@ /* * OMAP44xx Power Management register bits * - * Copyright (C) 2009-2010 Texas Instruments, Inc. + * Copyright (C) 2009-2011 Texas Instruments, Inc. * Copyright (C) 2009-2010 Nokia Corporation * * Paul Walmsley (p...@pwsan.com) @@ -283,6 +283,14 @@ #define OMAP4430_DUCATI_UNICACHE_STATEST_SHIFT 10 #define OMAP4430_DUCATI_UNICACHE_STATEST_MASK (0x3 << 10) +/* Used by PRM_
[RFC][PATCH 6/9] OMAP4: clocks: Update the clock tree with 4460 clock nodes
From: Rajendra Nayak
OMAP4460 platform has a few clock nodes which are added
and a few which are missing (compared to the 4430 platform)
Update the clock tree accordingly and handle these nodes
using the clock flags (CK_*).
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clock44xx_data.c | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 96c0e3e..b10649d 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1264,6 +1264,13 @@ static struct clk l4_wkup_clk_mux_ck = {
.recalc = &omap2_clksel_recalc,
};
+static struct clk div_ts_ck = {
+ .name = "div_ts_ck",
+ .parent = &l4_wkup_clk_mux_ck,
+ .ops= &clkops_null,
+ .recalc = &followparent_recalc,
+};
+
static const struct clksel per_abe_nc_fclk_div[] = {
{ .parent = &dpll_abe_m2_ck, .rates = div2_1to2_rates },
{ .parent = NULL },
@@ -1396,6 +1403,16 @@ static struct clk bandgap_fclk = {
.recalc = &followparent_recalc,
};
+static struct clk bandgap_ts_fclk = {
+ .name = "bandgap_ts_fclk",
+ .ops= &clkops_omap2_dflt,
+ .enable_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
+ .enable_bit = OMAP4460_OPTFCLKEN_TS_FCLK_SHIFT,
+ .clkdm_name = "l4_wkup_clkdm",
+ .parent = &div_ts_ck,
+ .recalc = &followparent_recalc,
+};
+
static struct clk des3des_fck = {
.name = "des3des_fck",
.ops= &clkops_omap2_dflt,
@@ -3098,6 +3115,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "l4_div_ck",&l4_div_ck,
CK_44XX),
CLK(NULL, "lp_clk_div_ck",&lp_clk_div_ck,
CK_44XX),
CLK(NULL, "l4_wkup_clk_mux_ck", &l4_wkup_clk_mux_ck,
CK_44XX),
+ CLK(NULL, "div_ts_ck",&div_ts_ck,
CK_446X),
CLK(NULL, "per_abe_nc_fclk", &per_abe_nc_fclk,
CK_44XX),
CLK(NULL, "mcasp2_fclk", &mcasp2_fclk,
CK_44XX),
CLK(NULL, "mcasp3_fclk", &mcasp3_fclk,
CK_44XX),
@@ -3109,7 +3127,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "aes1_fck", &aes1_fck,
CK_44XX),
CLK(NULL, "aes2_fck", &aes2_fck,
CK_44XX),
CLK(NULL, "aess_fck", &aess_fck,
CK_44XX),
- CLK(NULL, "bandgap_fclk", &bandgap_fclk,
CK_44XX),
+ CLK(NULL, "bandgap_fclk", &bandgap_fclk,
CK_443X),
+ CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk,
CK_446X),
CLK(NULL, "des3des_fck", &des3des_fck,
CK_44XX),
CLK(NULL, "dmic_sync_mux_ck", &dmic_sync_mux_ck,
CK_44XX),
CLK(NULL, "dmic_fck", &dmic_fck,
CK_44XX),
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 7/9] OMAP4: powerdomain: Update MPU powerdomain for 4460
From: Rajendra Nayak
The 4460 platform has changes in the MPU powerdomain,
hence model a new powerdomain for it and identify
is using the CHIP_IS_OMAP446X macro.
Also move all the common powerdomains to use
CHIP_IS_44XX so they are reused on OMAP4460.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/powerdomains44xx_data.c | 53 ++-
1 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains44xx_data.c
b/arch/arm/mach-omap2/powerdomains44xx_data.c
index c4222c7..034a4c7 100644
--- a/arch/arm/mach-omap2/powerdomains44xx_data.c
+++ b/arch/arm/mach-omap2/powerdomains44xx_data.c
@@ -35,7 +35,7 @@ static struct powerdomain core_44xx_pwrdm = {
.name = "core_pwrdm",
.prcm_offs= OMAP4430_PRM_CORE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 5,
@@ -61,7 +61,7 @@ static struct powerdomain gfx_44xx_pwrdm = {
.name = "gfx_pwrdm",
.prcm_offs= OMAP4430_PRM_GFX_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -78,7 +78,7 @@ static struct powerdomain abe_44xx_pwrdm = {
.name = "abe_pwrdm",
.prcm_offs= OMAP4430_PRM_ABE_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 2,
@@ -98,7 +98,7 @@ static struct powerdomain dss_44xx_pwrdm = {
.name = "dss_pwrdm",
.prcm_offs= OMAP4430_PRM_DSS_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF,
.banks= 1,
@@ -116,7 +116,7 @@ static struct powerdomain tesla_44xx_pwrdm = {
.name = "tesla_pwrdm",
.prcm_offs= OMAP4430_PRM_TESLA_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 3,
@@ -138,7 +138,7 @@ static struct powerdomain wkup_44xx_pwrdm = {
.name = "wkup_pwrdm",
.prcm_offs= OMAP4430_PRM_WKUP_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -154,7 +154,7 @@ static struct powerdomain cpu0_44xx_pwrdm = {
.name = "cpu0_pwrdm",
.prcm_offs= OMAP4430_PRCM_MPU_CPU0_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
@@ -171,7 +171,7 @@ static struct powerdomain cpu1_44xx_pwrdm = {
.name = "cpu1_pwrdm",
.prcm_offs= OMAP4430_PRCM_MPU_CPU1_INST,
.prcm_partition = OMAP4430_PRCM_MPU_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_RET_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 1,
@@ -188,7 +188,7 @@ static struct powerdomain emu_44xx_pwrdm = {
.name = "emu_pwrdm",
.prcm_offs= OMAP4430_PRM_EMU_INST,
.prcm_partition = OMAP4430_PRM_PARTITION,
- .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
.pwrsts = PWRSTS_OFF_ON,
.banks= 1,
.pwrsts_mem_ret = {
@@ -200,7 +200,7 @@ static struct powerdomain emu_44xx_pwrdm = {
};
/* mpu_44xx_pwrdm: Modena processor and the Neon coprocessor power domain */
-static struct powerdomain mpu_44xx_pwrdm = {
+static struct powerdomain mpu_443x_pwrdm = {
.name = "mpu_pwrdm",
.pr
[RFC][PATCH 8/9] OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460
From: Rajendra Nayak
The 4460 platform has no difference in the clockdomains
as compared to the 4430 platform.
Hence just update the .omap_chip field to make sure
the same clockdomains model data can be reused on the
4460 platform.
Signed-off-by: Rajendra Nayak
---
arch/arm/mach-omap2/clockdomains44xx_data.c | 200 +-
1 files changed, 100 insertions(+), 100 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index a607ec1..f9c980e 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -35,55 +35,55 @@
static struct clkdm_dep ducati_wkup_sleep_deps[] = {
{
.clkdm_name = "abe_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "ivahd_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_1_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_2_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_dss_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_emif_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_gfx_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_init_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l4_cfg_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l4_per_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l4_secure_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l4_wkup_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "tesla_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{ NULL },
};
@@ -91,15 +91,15 @@ static struct clkdm_dep ducati_wkup_sleep_deps[] = {
static struct clkdm_dep iss_wkup_sleep_deps[] = {
{
.clkdm_name = "ivahd_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_1_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_emif_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{ NULL },
};
@@ -107,11 +107,11 @@ static struct clkdm_dep iss_wkup_sleep_deps[] = {
static struct clkdm_dep ivahd_wkup_sleep_deps[] = {
{
.clkdm_name = "l3_1_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{
.clkdm_name = "l3_emif_clkdm",
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430)
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX)
},
{ NULL },
};
@@ -119,35 +119,35 @@ static struct clkdm_dep ivahd_wkup_sleep_deps[] = {
static struct clkdm_dep l3_d2d_wkup_sleep_deps[] = {
{
.clkdm_name = "abe_clkdm",
- .omap_chip = OMAP_CHIP_INI
[RFC][PATCH 9/9] OMAP4460: dpll: Support MPU frequencies > 1 Ghz
From: Rajendra Nayak
The OMAP4460 platform needs DCC (Duty cycle correction)
enabled for frequencies above 1GHz from the MPU DPLL.
Further, on OMAP4460 when the MPU Frequency is above 748Mhz,
the programmable divider for the Async bridge to ABE must be
set to MPU-Freq/8. For lower frequency, it should be MPU-Freq/4.
Similarly for MPU Frequency above 920Mhz, the programmable divider
for the async bridge to L3 and Memory Adapter interfaces of EMIF
must be MPU-Freq/4. For lower frequency, they should be MPU-Freq/2.
Also on 4460, the MPU clk for frequencies higher than 1Ghz
is sourced from CLKOUTX2_M3, instead of CLKOUT_M2, while
value of M3 is fixed to 1. Hence for frequencies higher
than 1 Ghz, lock the DPLL at half the rate so the CLKOUTX2_M3
then matches the requested rate.
Do all this as part of the DPLL control api.
Signed-off-by: Rajendra Nayak
Signed-off-by: Vishwanath BS
---
arch/arm/mach-omap2/dpll3xxx.c | 58
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..81d2f9f 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -34,6 +34,8 @@
#include "clock.h"
#include "cm2xxx_3xxx.h"
#include "cm-regbits-34xx.h"
+#include "cm-regbits-44xx.h"
+#include "cm1_44xx.h"
/* CM_AUTOIDLE_PLL*.AUTO_* bit values */
#define DPLL_AUTOIDLE_DISABLE 0x0
@@ -311,6 +313,42 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
__raw_writel(v, dd->control_reg);
}
+ /*
+* On OMAP4460, to obtain MPU DPLL frequency higher
+* than 1GHz, DCC (Duty Cycle Correction) needs to
+* be enabled.
+* Also the interconnect frequency to EMIF should
+* be switched between MPU clk divide by 4 (for
+* frequencies higher than 920Mhz) and MPU clk divide
+* by 2 (for frequencies lower than or equal to 920Mhz)
+* Lastly the async bridge to ABE must be MPU clk divide
+* by 8 for MPU clk > 748Mhz and MPU clk divide by 4
+* for lower frequencies.
+* TODO: For now use a strcmp, but need to find a
+* better way to identify the MPU dpll.
+*/
+ if (cpu_is_omap446x() && !strcmp(clk->name, "dpll_mpu_ck")) {
+ /* DCC control */
+ v = __raw_readl(dd->mult_div1_reg);
+ if (dd->last_rounded_rate > 10)
+ v |= OMAP4460_DCC_EN_MASK; /* Enable DCC */
+ else
+ v &= ~OMAP4460_DCC_EN_MASK; /* Disable DCC */
+ __raw_writel(v, dd->mult_div1_reg);
+
+ /* EMIF/ABE clock rate control */
+ v = __raw_readl(OMAP4430_CM_MPU_MPU_CLKCTRL);
+ if (dd->last_rounded_rate > 92000)
+ v |= OMAP4460_CLKSEL_EMIF_DIV_MODE_MASK;
+ else
+ v &= ~OMAP4460_CLKSEL_EMIF_DIV_MODE_MASK;
+ if (dd->last_rounded_rate > 74800)
+ v |= OMAP4460_CLKSEL_ABE_DIV_MODE_MASK;
+ else
+ v &= ~OMAP4460_CLKSEL_ABE_DIV_MODE_MASK;
+ __raw_writel(v, OMAP4430_CM_MPU_MPU_CLKCTRL);
+ }
+
/* Set DPLL multiplier, divider */
v = __raw_readl(dd->mult_div1_reg);
v &= ~(dd->mult_mask | dd->div1_mask);
@@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
+ unsigned long orig_rate = 0;
if (!clk || !rate)
return -EINVAL;
@@ -454,6 +493,19 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (!ret)
new_parent = dd->clk_bypass;
} else {
+ /*
+* On 4460, the MPU clk for frequencies higher than 1Ghz
+* is sourced from CLKOUTX2_M3, instead of CLKOUT_M2, while
+* value of M3 is fixed to 1. Hence for frequencies higher
+* than 1 Ghz, lock the DPLL at half the rate so the
+* CLKOUTX2_M3 then matches the requested rate.
+*/
+ if (cpu_is_omap446x() && !strcmp(clk->name, "dpll_mpu_ck")
+ && (rate > 10)) {
+ orig_rate = rate;
+ rate = rate/2;
+ }
+
if (dd->last_rounded_rate != rate)
omap2_dpll_round_rate(clk, rate);
@@ -468,6 +520,12 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
WARN_ON(1);
}
+ /* Set the rate back to original for book keeping*/
+ if (orig_rate) {
+ rate = orig_rate;
+ dd->last_rounded_rate = dd->la
Re: [RFC][PATCH 9/9] OMAP4460: dpll: Support MPU frequencies > 1 Ghz
On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
...
> @@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
> long rate)
> u16 freqsel = 0;
> struct dpll_data *dd;
> int ret;
> + unsigned long orig_rate = 0;
>
> if (!clk || !rate)
> return -EINVAL;
> @@ -454,6 +493,19 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
> unsigned long rate)
> if (!ret)
> new_parent = dd->clk_bypass;
> } else {
> + /*
> + * On 4460, the MPU clk for frequencies higher than 1Ghz
> + * is sourced from CLKOUTX2_M3, instead of CLKOUT_M2, while
> + * value of M3 is fixed to 1. Hence for frequencies higher
> + * than 1 Ghz, lock the DPLL at half the rate so the
> + * CLKOUTX2_M3 then matches the requested rate.
> + */
> + if (cpu_is_omap446x() && !strcmp(clk->name, "dpll_mpu_ck")
> + && (rate > 10)) {
> + orig_rate = rate;
> + rate = rate/2;
> + }
> +
> if (dd->last_rounded_rate != rate)
> omap2_dpll_round_rate(clk, rate);
>
> @@ -468,6 +520,12 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
> unsigned long rate)
> WARN_ON(1);
> }
>
> + /* Set the rate back to original for book keeping*/
> + if (orig_rate) {
> + rate = orig_rate;
> + dd->last_rounded_rate = dd->last_rounded_rate * 2;
Not sure why dd->last_rounded_rate is being adjusted here. Its
value was computed based on orig_rate/2, and this adjustment will
force the code above to call omap2_dpll_round_rate() every time
(because the * 2 value will never equal the / 2 value). I haven't
seen the value reported anywhere, so it doesn't seem necessary?
...
Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 10/9] OMAP4: HWMOD: differentiate 4430 and 4460 bandgap
OMAP4430 and 4460 have slightly different functional clocks.
we need to map this back into hwmod database as well to ensure
sanity.
Signed-off-by: Nishanth Menon
---
Depends on the series posted earlier for
http://marc.info/?l=linux-omap&m=130637503008641&w=2
missed tracking this down after a last min update :(
Boot tested on both SDP4430 and SDP4460
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 30 ++-
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 27319c4..9ac9cac 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -762,11 +762,11 @@ static struct omap_hwmod_class
omap44xx_bandgap_hwmod_class = {
};
/* bandgap */
-static struct omap_hwmod_opt_clk bandgap_opt_clks[] = {
+static struct omap_hwmod_opt_clk bandgap443x_opt_clks[] = {
{ .role = "fclk", .clk = "bandgap_fclk" },
};
-static struct omap_hwmod omap44xx_bandgap_hwmod = {
+static struct omap_hwmod omap443x_bandgap_hwmod = {
.name = "bandgap",
.class = &omap44xx_bandgap_hwmod_class,
.prcm = {
@@ -774,9 +774,26 @@ static struct omap_hwmod omap44xx_bandgap_hwmod = {
.clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
},
},
- .opt_clks = bandgap_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(bandgap_opt_clks),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
+ .opt_clks = bandgap443x_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(bandgap443x_opt_clks),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+static struct omap_hwmod_opt_clk bandgap446x_opt_clks[] = {
+ { .role = "fclk", .clk = "bandgap_ts_fclk" },
+};
+
+static struct omap_hwmod omap446x_bandgap_hwmod = {
+ .name = "bandgap",
+ .class = &omap44xx_bandgap_hwmod_class,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
+ },
+ },
+ .opt_clks = bandgap446x_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(bandgap446x_opt_clks),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
};
/*
@@ -5074,7 +5091,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* &omap44xx_aess_hwmod, */
/* bandgap class */
- &omap44xx_bandgap_hwmod,
+ &omap443x_bandgap_hwmod,
+ &omap446x_bandgap_hwmod,
/* counter class */
/* &omap44xx_counter_32k_hwmod, */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 10/9] OMAP4: HWMOD: differentiate 4430 and 4460 bandgap
On Wed, May 25, 2011 at 8:41 PM, Nishanth Menon wrote:
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +static struct omap_hwmod_opt_clk bandgap446x_opt_clks[] = {
> + { .role = "fclk", .clk = "bandgap_ts_fclk" },
> +};
> +
> +static struct omap_hwmod omap446x_bandgap_hwmod = {
> + .name = "bandgap",
> + .class = &omap44xx_bandgap_hwmod_class,
> + .prcm = {
> + .omap4 = {
> + .clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
> + },
> + },
> + .opt_clks = bandgap446x_opt_clks,
> + .opt_clks_cnt = ARRAY_SIZE(bandgap446x_opt_clks),
> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
Does it call for having CHIP_IS_OMAP446X instead of CHIP_IS_OMAP4460 ?
What happens when we get say es2.0 for 4460? how do you accommodate that?
Take care of that case when the new silicon arrives or fix it now :-)
--
To unsubscribe from this list: send the line "unsubscribe 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][PATCH 10/9] OMAP4: HWMOD: differentiate 4430 and 4460 bandgap
On Wed, May 25, 2011 at 20:46, Pandita, Vikram wrote:
> On Wed, May 25, 2011 at 8:41 PM, Nishanth Menon wrote:
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>
>> +static struct omap_hwmod_opt_clk bandgap446x_opt_clks[] = {
>> + { .role = "fclk", .clk = "bandgap_ts_fclk" },
>> +};
>> +
>> +static struct omap_hwmod omap446x_bandgap_hwmod = {
>> + .name = "bandgap",
>> + .class = &omap44xx_bandgap_hwmod_class,
>> + .prcm = {
>> + .omap4 = {
>> + .clkctrl_reg = OMAP4430_CM_WKUP_BANDGAP_CLKCTRL,
>> + },
>> + },
>> + .opt_clks = bandgap446x_opt_clks,
>> + .opt_clks_cnt = ARRAY_SIZE(bandgap446x_opt_clks),
>> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
>
> Does it call for having CHIP_IS_OMAP446X instead of CHIP_IS_OMAP4460 ?
>
> What happens when we get say es2.0 for 4460? how do you accommodate that?
> Take care of that case when the new silicon arrives or fix it now :-)
Probably Paul/Benoit can state their preference.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 9/9] OMAP4460: dpll: Support MPU frequencies > 1 Ghz
On 5/26/2011 8:46 AM, Todd Poynor wrote:
On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
...
@@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
u16 freqsel = 0;
struct dpll_data *dd;
int ret;
+ unsigned long orig_rate = 0;
if (!clk || !rate)
return -EINVAL;
@@ -454,6 +493,19 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
if (!ret)
new_parent = dd->clk_bypass;
} else {
+ /*
+* On 4460, the MPU clk for frequencies higher than 1Ghz
+* is sourced from CLKOUTX2_M3, instead of CLKOUT_M2, while
+* value of M3 is fixed to 1. Hence for frequencies higher
+* than 1 Ghz, lock the DPLL at half the rate so the
+* CLKOUTX2_M3 then matches the requested rate.
+*/
+ if (cpu_is_omap446x()&& !strcmp(clk->name, "dpll_mpu_ck")
+ && (rate> 10)) {
+ orig_rate = rate;
+ rate = rate/2;
+ }
+
if (dd->last_rounded_rate != rate)
omap2_dpll_round_rate(clk, rate);
@@ -468,6 +520,12 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned
long rate)
WARN_ON(1);
}
+ /* Set the rate back to original for book keeping*/
+ if (orig_rate) {
+ rate = orig_rate;
+ dd->last_rounded_rate = dd->last_rounded_rate * 2;
Not sure why dd->last_rounded_rate is being adjusted here. Its
value was computed based on orig_rate/2, and this adjustment will
force the code above to call omap2_dpll_round_rate() every time
(because the * 2 value will never equal the / 2 value). I haven't
seen the value reported anywhere, so it doesn't seem necessary?
Todd, I have to admit I have'nt even tested this patch myself on a 4460
(I don't even have one) and I did mention this to Nishanth when I sent
this out to him.
You are right that playing with the last_rounded_rate is not a good
idea, that was done thinking the omap3_noncore_dpll_program then uses
it and it needs the orig_rate and not the /2. But that certainly
causes the omap2_dpll_round_rate to get called every time.
I need to work some more on this patch and certainly *test* it to
work on a 4460.
...
Todd
--
To unsubscribe from this list: send the line "unsubscribe 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][PATCH 9/9] OMAP4460: dpll: Support MPU frequencies > 1 Ghz
On Wed, May 25, 2011 at 21:13, Rajendra Nayak wrote:
> On 5/26/2011 8:46 AM, Todd Poynor wrote:
>>
>> On Wed, May 25, 2011 at 06:56:56PM -0700, Nishanth Menon wrote:
>> ...
>>>
>>> @@ -427,6 +465,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
>>> unsigned long rate)
>>> u16 freqsel = 0;
>>> struct dpll_data *dd;
>>> int ret;
>>> + unsigned long orig_rate = 0;
>>>
>>> if (!clk || !rate)
>>> return -EINVAL;
>>> @@ -454,6 +493,19 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
>>> unsigned long rate)
>>> if (!ret)
>>> new_parent = dd->clk_bypass;
>>> } else {
>>> + /*
>>> + * On 4460, the MPU clk for frequencies higher than 1Ghz
>>> + * is sourced from CLKOUTX2_M3, instead of CLKOUT_M2,
>>> while
>>> + * value of M3 is fixed to 1. Hence for frequencies
>>> higher
>>> + * than 1 Ghz, lock the DPLL at half the rate so the
>>> + * CLKOUTX2_M3 then matches the requested rate.
>>> + */
>>> + if (cpu_is_omap446x()&& !strcmp(clk->name,
>>> "dpll_mpu_ck")
>>> + && (rate> 10)) {
>>> + orig_rate = rate;
>>> + rate = rate/2;
>>> + }
>>> +
>>> if (dd->last_rounded_rate != rate)
>>> omap2_dpll_round_rate(clk, rate);
>>>
>>> @@ -468,6 +520,12 @@ int omap3_noncore_dpll_set_rate(struct clk *clk,
>>> unsigned long rate)
>>> WARN_ON(1);
>>> }
>>>
>>> + /* Set the rate back to original for book keeping*/
>>> + if (orig_rate) {
>>> + rate = orig_rate;
>>> + dd->last_rounded_rate = dd->last_rounded_rate *
>>> 2;
>>
>> Not sure why dd->last_rounded_rate is being adjusted here. Its
>> value was computed based on orig_rate/2, and this adjustment will
>> force the code above to call omap2_dpll_round_rate() every time
>> (because the * 2 value will never equal the / 2 value). I haven't
>> seen the value reported anywhere, so it doesn't seem necessary?
>
> Todd, I have to admit I have'nt even tested this patch myself on a 4460
> (I don't even have one) and I did mention this to Nishanth when I sent
> this out to him.
> You are right that playing with the last_rounded_rate is not a good
> idea, that was done thinking the omap3_noncore_dpll_program then uses
> it and it needs the orig_rate and not the /2. But that certainly
> causes the omap2_dpll_round_rate to get called every time.
> I need to work some more on this patch and certainly *test* it to
> work on a 4460.
Hmm.. I apologize, I had expected the bootloader I was using was
supposed to boot at highest frequency - I might have been
mistaken(expectation was to test without a DVFS framework). However,
that said, the interest here in RFC itself (beyond the point that it
is done wrongly - thanks for confirming), is to know if this is the
right place to handle it. Looping in Paul and Benoit as well for their
views on the approach taken.
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: context_loss_count error value
On Wed, 2011-05-25 at 13:30 -0700, Kevin Hilman wrote:
> Tomi Valkeinen writes:
>
> > On Wed, 2011-05-25 at 11:34 -0700, Kevin Hilman wrote:
> >> Tomi Valkeinen writes:
> >>
> >> > +if (off_mode_enabled) {
> >> > +count = (count + 1) & 0x7fff;
> >> > +dummy_context_loss_counter = count;
> >> > +}
> >>
> >> Again, I don't think this masking is needed. count is already an
> >> 'int', so when it gets bigger than INT_MAX, it will wrap.
> >
> > When count is INT_MAX and one is added to it, it'll wrap to INT_MIN,
> > i.e. maximum negative value, which would be an error value. So by
> > masking out the highest bit we'll get nonnegative count range from 0 to
> > INT_MAX.
> >
> > Perhaps a comment would be justified here =).
>
> Indeed, and using INT_MAX instead of the hard-coded constants would help
> readability also.
It may be just me, but as I see it, INT_MAX is a number like any other,
and using it as a mask feels confusing to me.
Would this be ok to you:
/*
* Context loss count has to be a non-negative value. Clear the sign
* bit to get a value range from 0 to INT_MAX.
*/
count &= ~(1 << 31);
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
