Re: [GIT PULL] omap updates for 2.6.40
* Koen Kooi [110526 19:02]: > > Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: > > > Hi Linus, > > > > Please pull omap updates for this merge window from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > > omap-for-linus > > > > This contains clean-up to shrink down omap specific code a bit. Also > > included > > are some fixes. But basically no new code at this point. > > What about updates to board files? Like adding support for the xM rev C to > board-omap3beagle.c. Sorry we're doing only code coalescing and fixes for this merge window as discussed on LAKML. Otherwise it's hard to see the code coalescing in the diffstats, so new code will need to wait a bit. I'll take a look and see if we can justify some fix like trivial patches like the revision detection patches during the -rc cycle. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On 5/27/2011 11:37 AM, Menon, Nishanth wrote: On Thu, May 26, 2011 at 22:06, Santosh Shilimkar wrote: On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. We are running only one instance and for the exact same reason as above. You are completely right and that's the whole intention of those CPUMASK two lines in the initialization code. What am I missing? Not at all. So not have cpufreq driver registered at all for CPU1? Life would be a lot simpler in omap2-cpufreq.c as a result. but that said, two views: a) future silicon somewhere ahead might need the current infrastructure to scale into different tables.. b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but* cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but .../cpu1/online is present). Keep in mind that userspace is usually written chip independent. IMHO registering drivers for both devices do make sense they reflect what the reality of the system is. 2 cpus scaling together - why do we want to OMAP "specific" stuff here? It's not OMAP specific Nishant. And this feature is supported by CPUFREQ driver. My Intel machine uses the same exact scheme for CPUFREQ. It's feature provided specifically for hardwares with individual CPU scaling limitation. Instead of CPU's, whole CPU cluster scales together. Both CPU's still have same consistent view of all CPUFREQ controls. But in back-ground, CPU1 is carrying only symbolic links. We make use of "related/affected cpu" feature which is supported by generic CPUFREQ driver. Nothing OMAP-specific here. And as I said i n other thread, if at all in future we get CPU's which can scale indepedently, we just need to change that one line where we specify the relation between CPU's. It's as trivial as that. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On Thu, May 26, 2011 at 22:06, Santosh Shilimkar wrote: > On 5/26/2011 11:40 PM, Kevin Hilman wrote: >> >> So here's a dumb question, being rather ignorant of CPUfreq on SMP. >> >> Should we be running a CPUfreq instance on both CPUs when they cannot be >> scaled independently? >> >> What is being scaled here is actually the cluster (the MPU SS via >> dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to >> have a an instance of the driver per scalable device, which in this case >> is a single MPU SS. >> > We are running only one instance and for the exact same reason as above. > You are completely right and that's the whole intention of those > CPUMASK two lines in the initialization code. > > >> What am I missing? >> > Not at all. So not have cpufreq driver registered at all for CPU1? Life would be a lot simpler in omap2-cpufreq.c as a result. but that said, two views: a) future silicon somewhere ahead might need the current infrastructure to scale into different tables.. b) as far as userspace sees it - cpu0 and cpu1 exists, cool, *but* cpu1 is not scalable(no /sys/devices/system/cpu/cpu1/cpufreq.. but .../cpu1/online is present). Keep in mind that userspace is usually written chip independent. IMHO registering drivers for both devices do make sense they reflect what the reality of the system is. 2 cpus scaling together - why do we want to OMAP "specific" stuff here? Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Some omap_device/hwmod/pwrdomain patches
On Thu, 2011-05-26 at 10:30 -0700, Kevin Hilman wrote: > Tomi Valkeinen writes: > > > I came up with these patches while implementing pm runtime adaptation for > > DSS > > driver. I'm not quite sure on who's turf they belong, or do they even belong > > together, but here they are anyway. > > > > get_context_loss_count patch was discussed on l-o with Kevin. > > > > The omap_device_reset patch I made as some parts of DSS currently presume > > that > > the HW module is reset when it is enabled, and the reset is better handled > > in > > hwmod code. > > > > can_ever_lose_context code I didn't strictly need, but as there's such a > > function I added that to the context save code in DSS while rewriting the > > code. > > Are any of the DSS blocks in power domains that can't lose context > (WKUP?) Probably not. I have to say I don't know when can_ever_lose_context returns false. I had some old code in DSS's context save functions which disabled context saving for OMAP2. I don't remember why that was put there, but probably either 1) OMAP2's DSS can't ever lose context 2) OMAP2's DSS couldn't lose context at the time the code was written. I guess 2) is more likely, but nevertheless when I noticed can_ever_lose_context I thought it'd be good to have that in the context save code. > This isn't something in general that drivers should be aware of, so I'd > rather not see this exposed to drivers (unless there's a real need.) Ok, I'll drop the patch. I don't think there's any need for this in DSS. > As soon as I finish the move to device power domains (hopefully for > 2.6.41), the driver's callbacks will only be called if the device has > lost context, so checking for context loss will not be needed at all at > the driver level. This sounds good. Runtime PM's suspend & resume callbacks or something else? Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: change get_context_loss_count ret value to int
On Thu, 2011-05-26 at 12:37 -0600, Paul Walmsley wrote:
> Hello Tomi, Kevin,
>
> On Thu, 26 May 2011, Tomi Valkeinen wrote:
>
> > 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.
>
> Thanks, I agree this makes more sense than the previous arrangement.
>
> One minor comment:
> > @@ -953,7 +953,13 @@ 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",
> > + /*
> > +* 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);
>
> Could you use INT_MAX here? It seems best not to have the implicit
> dependency on 32-bit ints, if it is not too inconvenient.
Heh, Kevin made the same comment.
I didn't want to use INT_MAX because I feel INT_MAX is just a number,
not a mask. But as that's just a gut feeling, I'm fine with changing it
to INT_MAX.
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 4/4] OMAP2: PM debug: move wakeup timer into clockevent code
On 5/27/2011 4:32 AM, Kevin Hilman wrote: Move suspend wakeup timer from suspend path to be triggered based on clockevent suspend path. When gptimers are eventually converted to be a driver, the wakeup timer feature can be made to be a driver-specific feature using the driver's suspend method. Excellent idea and patch. Never crossed my mind that we could have used "CLOCK_EVT_MODE_SHUTDOWN" instead of our long old hack. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq
On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. We are running only one instance and for the exact same reason as above. You are completely right and that's the whole intention of those CPUMASK two lines in the initialization code. What am I missing? Not at all. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] GPIO: OMAP: first round of cleanup
On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote: > Start moving SoC-specific register handling out of the driver by passing > in register offsets in via platform data. > > Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip. > > Applies on top of Tony's for-next branch (which include's the generic > IRQ chip work from tglx) and the OMAP GPIO driver move to > drivers/gpio. Hey Kevin, If you've got a branch with this series in it and tested, then I'd be happy to pull that instead of applying the patches myself. g. > > Charulatha V (1): > GPIO: OMAP: remove get_gpio_bank() > > Kevin Hilman (13): > GPIO: OMAP: _clear_gpio_irqbank: fix flushing of posted write > GPIO: OMAP: remove MPUIO handling from _clear_gpio_irqbank() > GPIO: OMAP: move bank width into struct gpio_bank > GPIO: OMAP: _get_gpio_irqbank_mask: replace hard-coded mask with > bank->width > GPIO: OMAP: replace get_gpio_index() by using bank width > GPIO: OMAP: consolidate direction, input, output, remove #ifdefs > GPIO: OMAP: consolidate IRQ status handling, remove #ifdefs > GPIO: OMAP: conslidate enable/disable of GPIO IRQs, remove ifdefs > GPIO: OMAP: convert MPUIO IRQ over to generic irq_chip > GPIO: OMAP: remove useless gpio_valid() & check_gpio() checks > GPIO: OMAP: cleanup _set_gpio_wakeup(), remove ifdefs > GPIO: OMAP: debounce remove SoC specific registers, use pdata > GPIO: OMAP: cleanup show revision, remove cpu_is checks, display only > once > > arch/arm/mach-omap1/gpio15xx.c | 22 + > arch/arm/mach-omap1/gpio16xx.c | 28 ++ > arch/arm/mach-omap1/gpio7xx.c | 27 ++ > arch/arm/mach-omap2/gpio.c | 32 ++ > arch/arm/plat-omap/include/plat/gpio.h | 20 + > drivers/gpio/gpio_omap.c | 723 > +++- > 6 files changed, 282 insertions(+), 570 deletions(-) > > -- > 1.7.3.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH pm_wip/voltdm_nm] ARM: OMAP: Explicitly mask VPVOLTAGE field
Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently
relies on a u32 -> u8 conversion to mask off the FORCEUPDATEWAIT field
in the upper bits. Make this explicit using the mask and shift symbols
already defined, added as new fields in struct omap_vp_common.
Signed-off-by: Todd Poynor
---
arch/arm/mach-omap2/vp.c |3 ++-
arch/arm/mach-omap2/vp.h |4
arch/arm/mach-omap2/vp3xxx_data.c |3 +++
arch/arm/mach-omap2/vp44xx_data.c |2 ++
4 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index e7d38f6..c3b7fde 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -227,7 +227,8 @@ unsigned long omap_vp_get_curr_volt(struct voltagedomain
*voltdm)
return 0;
}
- curr_vsel = voltdm->read(vp->voltage);
+ curr_vsel = (voltdm->read(vp->voltage) & vp->common->vpvoltage_mask)
+ >> vp->common->vpvoltage_shift;
if (!voltdm->pmic || !voltdm->pmic->vsel_to_uv) {
pr_warning("%s: PMIC function to convert vsel to voltage"
diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h
index 0d63267..cb62a7b 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -63,6 +63,8 @@ struct omap_vp_ops {
* @vlimitto_vddmin_shift: VDDMIN field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_vddmax_shift: VDDMAX field shift in PRM_VP*_VLIMITTO reg
* @vlimitto_timeout_shift: TIMEOUT field shift in PRM_VP*_VLIMITTO reg
+ * @vpvoltage_mask: VPVOLTAGE field mask in PRM_VP*_VOLTAGE reg
+ * @vpvoltage_shift: VPVOLTAGE field shift in PRM_VP*_VOLTAGE reg
*/
struct omap_vp_common {
u32 vpconfig_erroroffset_mask;
@@ -79,6 +81,8 @@ struct omap_vp_common {
u8 vlimitto_vddmin_shift;
u8 vlimitto_vddmax_shift;
u8 vlimitto_timeout_shift;
+ u8 vpvoltage_mask;
+ u8 vpvoltage_shift;
const struct omap_vp_ops *ops;
};
diff --git a/arch/arm/mach-omap2/vp3xxx_data.c
b/arch/arm/mach-omap2/vp3xxx_data.c
index d429c44..0b149e0 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -51,6 +51,9 @@ static const struct omap_vp_common omap3_vp_common = {
.vlimitto_vddmin_shift = OMAP3430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP3430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP3430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP3430_VPVOLTAGE_MASK,
+ .vpvoltage_shift = OMAP3430_VPVOLTAGE_SHIFT,
+
.ops = &omap3_vp_ops,
};
diff --git a/arch/arm/mach-omap2/vp44xx_data.c
b/arch/arm/mach-omap2/vp44xx_data.c
index 0daf2a4..174d6f7 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -51,6 +51,8 @@ static const struct omap_vp_common omap4_vp_common = {
.vlimitto_vddmin_shift = OMAP4430_VDDMIN_SHIFT,
.vlimitto_vddmax_shift = OMAP4430_VDDMAX_SHIFT,
.vlimitto_timeout_shift = OMAP4430_TIMEOUT_SHIFT,
+ .vpvoltage_mask = OMAP4430_VPVOLTAGE_MASK,
+ .vpvoltage_shift = OMAP4430_VPVOLTAGE_SHIFT,
.ops = &omap4_vp_ops,
};
--
1.7.3.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 v4 4/4] OMAP2+: cpufreq: fix freq_table leak
We use a single frequency table for multiple CPUs. But, with
OMAP4, since we have multiple CPUs, the cpu_init call for CPU1
causes freq_table previously allocated for CPU0 to be overwritten.
In addition, we dont free the table on exit path.
We solve this by maintaining an atomic type counter to ensure
just a single table exists at a given time.
Signed-off-by: Nishanth Menon
---
NOTE: Depends on: http://marc.info/?t=13063094702&r=1&w=2
arch/arm/mach-omap2/omap2plus-cpufreq.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 40b2a7c..e101737 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -39,6 +39,7 @@
#include
static struct cpufreq_frequency_table *freq_table;
+static atomic_t freq_table_users = ATOMIC_INIT(0);
static struct clk *mpu_clk;
static char *mpu_clk_name;
static struct device *mpu_dev;
@@ -153,6 +154,12 @@ skip_lpj:
return ret;
}
+static inline void freq_table_free(void)
+{
+ if (atomic_dec_and_test(&freq_table_users))
+ opp_free_cpufreq_table(mpu_dev, &freq_table);
+}
+
static int __cpuinit omap_cpu_init(struct cpufreq_policy *policy)
{
int result = 0;
@@ -168,7 +175,9 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
}
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
- result = opp_init_cpufreq_table(mpu_dev, &freq_table);
+
+ if (atomic_inc_return(&freq_table_users) == 1)
+ result = opp_init_cpufreq_table(mpu_dev, &freq_table);
if (result) {
dev_err(mpu_dev, "%s: cpu%d: failed creating freq table[%d]\n",
@@ -180,7 +189,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (!result)
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
else
- goto fail_ck;
+ goto fail_table;
policy->min = policy->cpuinfo.min_freq;
policy->max = policy->cpuinfo.max_freq;
@@ -204,6 +213,8 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
return 0;
+fail_table:
+ freq_table_free();
fail_ck:
clk_put(mpu_clk);
return result;
@@ -211,6 +222,7 @@ fail_ck:
static int omap_cpu_exit(struct cpufreq_policy *policy)
{
+ 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 v4 3/4] 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 | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index e10fcf8..40b2a7c 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -162,8 +162,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 fail_ck;
+ }
policy->cur = policy->min = policy->max = omap_getspeed(policy->cpu);
result = opp_init_cpufreq_table(mpu_dev, &freq_table);
@@ -171,12 +173,14 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
if (result) {
dev_err(mpu_dev, "%s: cpu%d: failed creating freq table[%d]\n",
__func__, policy->cpu, result);
- return result;
+ goto fail_ck;
}
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (!result)
cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
+ else
+ goto fail_ck;
policy->min = policy->cpuinfo.min_freq;
policy->max = policy->cpuinfo.max_freq;
@@ -199,6 +203,10 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy
*policy)
policy->cpuinfo.transition_latency = 300 * 1000;
return 0;
+
+fail_ck:
+ 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 v4 2/4] OMAP2+: cpufreq: use OPP library
OMAP2 is the only family using clk_[init|exit]_cpufreq_table, however,
the cpufreq code has does not use clk_init_cpufreq_table. As a result,
it is unusuable for OMAP2 and only usable only on platforms using OPP
library.
So move the compilation for cpufreq only if OPP is available for the
architecture and deny OMAP2 in multi-OMAP builds until OMAP2 is fixed.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/Makefile|4 ++--
arch/arm/mach-omap2/omap2plus-cpufreq.c | 12 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dcf5200..70c9fc7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -54,10 +54,10 @@ ifeq ($(CONFIG_PM_OPP),y)
obj-y += opp.o
obj-$(CONFIG_ARCH_OMAP3) += opp3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += opp4xxx_data.o
-endif
-
# CPUFREQ driver
obj-$(CONFIG_CPU_FREQ) += omap2plus-cpufreq.o
+endif
+
# Power Management
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index acf18e8..e10fcf8 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -1,7 +1,7 @@
/*
* OMAP2PLUS cpufreq driver
*
- * CPU frequency scaling for OMAP
+ * CPU frequency scaling for OMAP using OPP information
*
* Copyright (C) 2005 Nokia Corporation
* Written by Tony Lindgren
@@ -203,7 +203,6 @@ 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);
clk_put(mpu_clk);
return 0;
}
@@ -226,12 +225,15 @@ static struct cpufreq_driver omap_driver = {
static int __init omap_cpufreq_init(void)
{
- if (cpu_is_omap24xx())
+ if (cpu_is_omap24xx()) {
mpu_clk_name = "virt_prcm_set";
- else if (cpu_is_omap34xx())
+ pr_warning("%s: omap2 cpufreq needs fixing\n", __func__);
+ return -EINVAL;
+ } 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 v4 1/4] 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 | 67 +++
1 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 33a91ec..acf18e8 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;
@@ -47,20 +45,9 @@ static struct device *mpu_dev;
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)
@@ -78,22 +65,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)
@@ -166,19 +166,18 @@ 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 (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;
+ result = opp_init_cpufreq_table(mpu_dev, &freq_table);
+
+ if (result) {
+ dev_err(mpu_dev, "%s: cpu%d: failed creating 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);
+
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 v4 0/4] Cleanups for cpufreq
Rev 4 of cleanups for cpufreq to take care of the review comments on the remaining rev3 patches. Applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm-wip/cpufreq Tested on SDP4430 - with a TI internal loadgenerator controlled on each cpu while online/offline of cpu1 and using all governors. (Used a forked dvfs for testing purposes) Patch 4 Depends on: http://marc.info/?t=13063094702&r=1&w=2 v4: changes: * we drop omap2 code for clk_init/exit and expect omap2 be supported once we get OPP/wrapper function to give us that function (http://marc.info/?l=linux-omap&m=130644155723048&w=2) * Dropped the mutex infavor of atomic (http://marc.info/?l=linux-omap&m=130643487913294&w=2) v3: http://marc.info/?l=linux-omap&m=130636674200733&w=2 v2: http://marc.info/?l=linux-omap&m=130570427214357&w=2 V1: http://marc.info/?l=linux-omap&m=130532085617487&w=2 Nishanth Menon (4): OMAP2+: cpufreq: dont support !freq_table OMAP2+: cpufreq: use OPP library OMAP2+: cpufreq: put clk if cpu_init failed OMAP2+: cpufreq: fix freq_table leak arch/arm/mach-omap2/Makefile|4 +- arch/arm/mach-omap2/omap2plus-cpufreq.c | 103 ++ 2 files changed, 64 insertions(+), 43 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
Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On Thu, May 26, 2011 at 16:24, Kevin Hilman wrote:
> Nishanth Menon writes:
>
>> 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.
>
> ouch. I knew one of these days something like this was going to happen
> with GPIO resets.
>
> Re: $SUBJECT, hwmod is not an acronym. Please use lower case.
>
>> 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),
>> };
>
> This is a board-specific problem that you've "fixed" in a way that
> affects every 4460-based device.
>
> Rather than setting the flag in the hwmod data, you need to fix this
> in a board-specific way.
>
> The hwmod layer provides an API for this: omap_hwmod_no_setup_reset()
> which should be called by board-specific code.
>
aah - a better solution.. thanks.
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 1/9] OMAP: ID: introduce chip detection for OMAP4460
On Thu, May 26, 2011 at 16:15, Kevin Hilman wrote:
> Nishanth Menon writes:
>
>> On 14:03-20110526, Premi, Sanjeev wrote:
>>> > -Original Message-
>>> > From: linux-omap-ow...@vger.kernel.org
>>> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
>>> > Sent: Thursday, May 26, 2011 7:27 AM
>>> > To: linux-omap
>>> > Cc: V, Aneesh; Menon, Nishanth
>>> > Subject: [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?c
>>> > ontentId=53243&navigationId=12843&templateId=6123
>>> > Public TRM is available here as usual:
>>> > http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?t
>>> > emplateId=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;
>>>
>>> [sp] Why is this change required?
>> As explained in the commit message, using hawkeye will not be accurate
>> anymore for 4460 onwards. The variable naming is changed to prevent
>> confusion in
>> the future as we continue to use ramp_system. As far as I know, there is
>> no unique bit to differentiate between the two and so far have been
>> unique.
>
> So if the register is the same, and all the bit offsets are the same,
> what has changed? IOW, if there's no difference to the SW, then the
> variable rename is probably superfluous, and could be covered by a
> comment in the code.
OK. that'd be easier - I agree.
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 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
Nishanth Menon writes:
> 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.
ouch. I knew one of these days something like this was going to happen
with GPIO resets.
Re: $SUBJECT, hwmod is not an acronym. Please use lower case.
> 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),
> };
This is a board-specific problem that you've "fixed" in a way that
affects every 4460-based device.
Rather than setting the flag in the hwmod data, you need to fix this
in a board-specific way.
The hwmod layer provides an API for this: omap_hwmod_no_setup_reset()
which should be called by board-specific code.
Kevin
> /* 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,
--
To unsubscribe from this list: send the line "unsubscribe 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 1/9] OMAP: ID: introduce chip detection for OMAP4460
Nishanth Menon writes:
> On 14:03-20110526, Premi, Sanjeev wrote:
>> > -Original Message-
>> > From: linux-omap-ow...@vger.kernel.org
>> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
>> > Sent: Thursday, May 26, 2011 7:27 AM
>> > To: linux-omap
>> > Cc: V, Aneesh; Menon, Nishanth
>> > Subject: [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?c
>> > ontentId=53243&navigationId=12843&templateId=6123
>> > Public TRM is available here as usual:
>> > http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?t
>> > emplateId=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;
>>
>> [sp] Why is this change required?
> As explained in the commit message, using hawkeye will not be accurate
> anymore for 4460 onwards. The variable naming is changed to prevent confusion
> in
> the future as we continue to use ramp_system. As far as I know, there is
> no unique bit to differentiate between the two and so far have been
> unique.
So if the register is the same, and all the bit offsets are the same,
what has changed? IOW, if there's no difference to the SW, then the
variable rename is probably superfluous, and could be covered by a
comment in the code.
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/13] OMAP2+: PM: export suspend_set_ops to PM modules
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm
> generic code, under CONFIG_SUSPEND.
>
> Note -hack warning-: since the 'suspend_valid_only_mem' function is
> not exported to modules, fill the 'valid' field value of
> 'struct platform_suspend_ops' in the common code.
>
> Signed-off-by: Jean Pihet
Can you try the patch below instead?If that works, I'll submit to
Rafael/linux-pm.
Kevin
>From d3aca6317f5f92a5fd4fbaf1d039232c83cac4f4 Mon Sep 17 00:00:00 2001
From: Kevin Hilman
Date: Thu, 26 May 2011 16:10:13 -0700
Subject: [PATCH] PM: export suspend_set_ops, suspend_valid_only_mem
Some platforms wish to implement their PM core code as modules. To
do so, these functions need to be exported for modules.
Reported-by: Jean Pihet
Signed-off-by: Kevin Hilman
---
kernel/power/suspend.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 6275970..eca495d 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -44,6 +44,7 @@ void suspend_set_ops(const struct platform_suspend_ops *ops)
suspend_ops = ops;
mutex_unlock(&pm_mutex);
}
+EXPORT_SYMBOL(suspend_set_ops);
bool valid_state(suspend_state_t state)
{
@@ -65,6 +66,7 @@ int suspend_valid_only_mem(suspend_state_t state)
{
return state == PM_SUSPEND_MEM;
}
+EXPORT_SYMBOL(suspend_valid_only_mem);
static int suspend_test(int level)
{
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/13] OMAP2+: PM: provide the next timer event API to PM modules
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Provide omap_pm_tick_nohz_get_sleep_length_us so that the code
> from the OMAP PM modules can use it.
>
> Signed-off-by: Jean Pihet
This patch is doing more than mentioned in the changelog.
> ---
> arch/arm/mach-omap2/pm-debug.c |7 ---
> arch/arm/mach-omap2/pm.c | 15 +++
> arch/arm/mach-omap2/pm.h | 12
> 3 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 0b896d4..24e5c31 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -141,9 +141,10 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
> if (!resume)
> #ifdef CONFIG_NO_HZ
> printk(KERN_INFO
> -"--- Going to %s %s (next timer after %u ms)\n", s1, s2,
> -jiffies_to_msecs(get_next_timer_interrupt(jiffies) -
> - jiffies));
> +"--- Going to %s %s (next timer after %lu ms)\n", s1, s2,
> +DIV_ROUND_UP(omap_pm_tick_nohz_get_sleep_length_us(),
> + 1000)
> + );
> #else
> printk(KERN_INFO "--- Going to %s %s\n", s1, s2);
> #endif
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 37a4801..0c451e3 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -30,6 +32,7 @@ static struct omap_device_pm_latency *pm_lats;
> struct cpuidle_params *cpuidle_params_override_table;
> #endif
>
> +#ifdef CONFIG_PM_DEBUG
> u32 enable_off_mode;
> EXPORT_SYMBOL(enable_off_mode);
>
> @@ -37,6 +40,7 @@ int omap2_pm_debug;
> u32 sleep_while_idle;
> u32 wakeup_timer_seconds;
> u32 wakeup_timer_milliseconds;
> +#endif
>
> static struct device *mpu_dev;
> static struct device *iva_dev;
> @@ -292,6 +296,7 @@ void omap3_pm_init_cpuidle(struct cpuidle_params
> *cpuidle_board_params)
> }
> #endif
>
> +#ifdef CONFIG_PM_DEBUG
> void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
> {
> u32 tick_rate, cycles;
> @@ -308,4 +313,14 @@ void omap2_pm_wakeup_on_timer(u32 seconds, u32
> milliseconds)
> " (%d ticks at %d ticks/sec.)\n",
> seconds, milliseconds, cycles, tick_rate);
> }
> +EXPORT_SYMBOL(omap2_pm_wakeup_on_timer);
This doesn't seem related to $SUBJECT
> +#endif
> +
> +#ifdef CONFIG_NO_HZ
> +unsigned long omap_pm_tick_nohz_get_sleep_length_us(void)
> +{
> + return ktime_to_us(tick_nohz_get_sleep_length());
> +}
> +EXPORT_SYMBOL(omap_pm_tick_nohz_get_sleep_length_us);
> +#endif
Usage of this is OMAP2-specific and needed for this very old, debug-only
interface. I was inspired by some of what you did in this series, and
will attempt to make your life easier by just removing this code all
together. I just posted a series for that.
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 03da7f8..70eb80e 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -68,11 +68,15 @@ extern int omap2_pm_debug;
> extern u32 enable_off_mode;
> extern u32 sleep_while_idle;
> #else
> -#define omap2_pm_dump(mode, resume, us) do {} while (0);
> +#define omap2_pm_dump(mode, resume, us) do {} while (0);
> #define omap2_pm_wakeup_on_timer(seconds, milliseconds) do {} while (0);
> -#define omap2_pm_debug 0
> -#define enable_off_mode 0
> -#define sleep_while_idle 0
> +#define omap2_pm_debug 0
> +#define enable_off_mode 0
> +#define sleep_while_idle 0
> +#endif
Unrelated whitespace changes.
> +#ifdef CONFIG_NO_HZ
> +extern unsigned long omap_pm_tick_nohz_get_sleep_length_us(void);
> #endif
>
> #if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 4/4] OMAP2: PM debug: move wakeup timer into clockevent code
Move suspend wakeup timer from suspend path to be triggered based
on clockevent suspend path.
When gptimers are eventually converted to be a driver, the wakeup
timer feature can be made to be a driver-specific feature using the
driver's suspend method.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c| 19
arch/arm/mach-omap2/pm.h |3 --
arch/arm/mach-omap2/pm34xx.c |4 ---
arch/arm/mach-omap2/timer-gp.c| 33 ++--
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
5 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 7c72f29..72dee22 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -39,25 +39,6 @@
#include "pm.h"
u32 enable_off_mode;
-u32 wakeup_timer_seconds;
-u32 wakeup_timer_milliseconds;
-
-void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
-{
- u32 tick_rate, cycles;
-
- if (!seconds && !milliseconds)
- return;
-
- tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
- cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
- omap_dm_timer_stop(gptimer_wakeup);
- omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
-
- pr_info("PM: Resume timer in %u.%03u secs"
- " (%d ticks at %d ticks/sec.)\n",
- seconds, milliseconds, cycles, tick_rate);
-}
#ifdef CONFIG_DEBUG_FS
#include
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index dd1c2e4..803bf1c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -57,13 +57,10 @@ extern int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state);
extern u32 wakeup_timer_seconds;
extern u32 wakeup_timer_milliseconds;
-extern struct omap_dm_timer *gptimer_wakeup;
#ifdef CONFIG_PM_DEBUG
-extern void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds);
extern u32 enable_off_mode;
#else
-#define omap2_pm_wakeup_on_timer(seconds, milliseconds)do {} while (0);
#define enable_off_mode 0
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 991ade6..a9d9bb1c8 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -532,10 +532,6 @@ static int omap3_pm_suspend(void)
struct power_state *pwrst;
int state, ret = 0;
- if (wakeup_timer_seconds || wakeup_timer_milliseconds)
- omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
-wakeup_timer_milliseconds);
-
/* Read current next_pwrsts */
list_for_each_entry(pwrst, &pwrst_list, node)
pwrst->saved_state = pwrdm_read_next_pwrst(pwrst->pwrdm);
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 3b9cf85..4de51a1 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -44,7 +44,7 @@
#include
#include "timer-gp.h"
-
+#include "pm.h"
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -53,7 +53,30 @@ static struct omap_dm_timer *gptimer;
static struct clock_event_device clockevent_gpt;
static u8 __initdata gptimer_id = 1;
static u8 __initdata inited;
-struct omap_dm_timer *gptimer_wakeup;
+static struct omap_dm_timer *gptimer_wakeup;
+
+u32 wakeup_timer_seconds;
+u32 wakeup_timer_milliseconds;
+
+static void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
+{
+ u32 tick_rate, cycles;
+
+ if (!gptimer_wakeup)
+ return;
+
+ if (!seconds && !milliseconds)
+ return;
+
+ tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer_wakeup));
+ cycles = tick_rate * seconds + tick_rate * milliseconds / 1000;
+ omap_dm_timer_stop(gptimer_wakeup);
+ omap_dm_timer_set_load_start(gptimer_wakeup, 0, 0x - cycles);
+
+ pr_info("PM: Resume timer in %u.%03u secs"
+ " (%d ticks at %d ticks/sec.)\n",
+ seconds, milliseconds, cycles, tick_rate);
+}
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
@@ -95,8 +118,12 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
break;
case CLOCK_EVT_MODE_ONESHOT:
break;
- case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
+ if (wakeup_timer_seconds || wakeup_timer_milliseconds)
+ omap2_pm_wakeup_on_timer(wakeup_timer_seconds,
+wakeup_timer_milliseconds);
+ break;
+ case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_RESUME:
break;
}
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index d6c70d2..db230b3 100644
--- a/arch/arm/
[PATCH/RFC 3/4] OMAP3: PM debug: remove register dumping
Remove OMAP3-specific register dumping feature from PM debug layer.
This is removed because:
- it's ugly
- it's OMAP3-specific, and will obviously not scale to OMAP4+
- userspace /dev/mem-based tools (like omapconf) can do this much better
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c | 221
1 files changed, 0 insertions(+), 221 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 6fe1700..7c72f29 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -63,10 +63,6 @@ void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds)
#include
#include
-static void pm_dbg_regset_store(u32 *ptr);
-
-static struct dentry *pm_dbg_dir;
-
static int pm_dbg_init_done;
static int __init pm_dbg_init(void);
@@ -76,160 +72,6 @@ enum {
DEBUG_FILE_TIMERS,
};
-struct pm_module_def {
- char name[8]; /* Name of the module */
- short type; /* CM or PRM */
- unsigned short offset;
- int low; /* First register address on this module */
- int high; /* Last register address on this module */
-};
-
-#define MOD_CM 0
-#define MOD_PRM 1
-
-static const struct pm_module_def *pm_dbg_reg_modules;
-static const struct pm_module_def omap3_pm_reg_modules[] = {
- { "IVA2", MOD_CM, OMAP3430_IVA2_MOD, 0, 0x4c },
- { "OCP", MOD_CM, OCP_MOD, 0, 0x10 },
- { "MPU", MOD_CM, MPU_MOD, 4, 0x4c },
- { "CORE", MOD_CM, CORE_MOD, 0, 0x4c },
- { "SGX", MOD_CM, OMAP3430ES2_SGX_MOD, 0, 0x4c },
- { "WKUP", MOD_CM, WKUP_MOD, 0, 0x40 },
- { "CCR", MOD_CM, PLL_MOD, 0, 0x70 },
- { "DSS", MOD_CM, OMAP3430_DSS_MOD, 0, 0x4c },
- { "CAM", MOD_CM, OMAP3430_CAM_MOD, 0, 0x4c },
- { "PER", MOD_CM, OMAP3430_PER_MOD, 0, 0x4c },
- { "EMU", MOD_CM, OMAP3430_EMU_MOD, 0x40, 0x54 },
- { "NEON", MOD_CM, OMAP3430_NEON_MOD, 0x20, 0x48 },
- { "USB", MOD_CM, OMAP3430ES2_USBHOST_MOD, 0, 0x4c },
-
- { "IVA2", MOD_PRM, OMAP3430_IVA2_MOD, 0x50, 0xfc },
- { "OCP", MOD_PRM, OCP_MOD, 4, 0x1c },
- { "MPU", MOD_PRM, MPU_MOD, 0x58, 0xe8 },
- { "CORE", MOD_PRM, CORE_MOD, 0x58, 0xf8 },
- { "SGX", MOD_PRM, OMAP3430ES2_SGX_MOD, 0x58, 0xe8 },
- { "WKUP", MOD_PRM, WKUP_MOD, 0xa0, 0xb0 },
- { "CCR", MOD_PRM, PLL_MOD, 0x40, 0x70 },
- { "DSS", MOD_PRM, OMAP3430_DSS_MOD, 0x58, 0xe8 },
- { "CAM", MOD_PRM, OMAP3430_CAM_MOD, 0x58, 0xe8 },
- { "PER", MOD_PRM, OMAP3430_PER_MOD, 0x58, 0xe8 },
- { "EMU", MOD_PRM, OMAP3430_EMU_MOD, 0x58, 0xe4 },
- { "GLBL", MOD_PRM, OMAP3430_GR_MOD, 0x20, 0xe4 },
- { "NEON", MOD_PRM, OMAP3430_NEON_MOD, 0x58, 0xe8 },
- { "USB", MOD_PRM, OMAP3430ES2_USBHOST_MOD, 0x58, 0xe8 },
- { "", 0, 0, 0, 0 },
-};
-
-#define PM_DBG_MAX_REG_SETS 4
-
-static void *pm_dbg_reg_set[PM_DBG_MAX_REG_SETS];
-
-static int pm_dbg_get_regset_size(void)
-{
- static int regset_size;
-
- if (regset_size == 0) {
- int i = 0;
-
- while (pm_dbg_reg_modules[i].name[0] != 0) {
- regset_size += pm_dbg_reg_modules[i].high +
- 4 - pm_dbg_reg_modules[i].low;
- i++;
- }
- }
- return regset_size;
-}
-
-static int pm_dbg_show_regs(struct seq_file *s, void *unused)
-{
- int i, j;
- unsigned long val;
- int reg_set = (int)s->private;
- u32 *ptr;
- void *store = NULL;
- int regs;
- int linefeed;
-
- if (reg_set == 0) {
- store = kmalloc(pm_dbg_get_regset_size(), GFP_KERNEL);
- ptr = store;
- pm_dbg_regset_store(ptr);
- } else {
- ptr = pm_dbg_reg_set[reg_set - 1];
- }
-
- i = 0;
-
- while (pm_dbg_reg_modules[i].name[0] != 0) {
- regs = 0;
- linefeed = 0;
- if (pm_dbg_reg_modules[i].type == MOD_CM)
- seq_printf(s, "MOD: CM_%s (%08x)\n",
- pm_dbg_reg_modules[i].name,
- (u32)(OMAP3430_CM_BASE +
- pm_dbg_reg_modules[i].offset));
- else
- seq_printf(s, "MOD: PRM_%s (%08x)\n",
- pm_dbg_reg_modules[i].name,
- (u32)(OMAP3430_PRM_BASE +
- pm_dbg_reg_modules[i].offset));
-
- for (j = pm_dbg_reg_modules[i].low;
- j <= pm_dbg_reg_modules[i].high; j += 4) {
- val = *(ptr++);
- if (val != 0) {
- regs++;
- if (linefeed) {
- seq_printf(s, "\n");
- linefeed = 0;
- }
- seq_printf(s, "
[PATCH/RFC 2/4] OMAP2: PM debug: remove register dumping
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c | 119
arch/arm/mach-omap2/pm.h |4 -
arch/arm/mach-omap2/pm24xx.c |6 +-
3 files changed, 2 insertions(+), 127 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index cf9bc15..6fe1700 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -38,129 +38,10 @@
#include "prm2xxx_3xxx.h"
#include "pm.h"
-int omap2_pm_debug;
u32 enable_off_mode;
u32 wakeup_timer_seconds;
u32 wakeup_timer_milliseconds;
-#define DUMP_PRM_MOD_REG(mod, reg)\
- regs[reg_count].name = #mod "." #reg; \
- regs[reg_count++].val = omap2_prm_read_mod_reg(mod, reg)
-#define DUMP_CM_MOD_REG(mod, reg) \
- regs[reg_count].name = #mod "." #reg; \
- regs[reg_count++].val = omap2_cm_read_mod_reg(mod, reg)
-#define DUMP_PRM_REG(reg) \
- regs[reg_count].name = #reg; \
- regs[reg_count++].val = __raw_readl(reg)
-#define DUMP_CM_REG(reg) \
- regs[reg_count].name = #reg; \
- regs[reg_count++].val = __raw_readl(reg)
-#define DUMP_INTC_REG(reg, off) \
- regs[reg_count].name = #reg; \
- regs[reg_count++].val = \
-__raw_readl(OMAP2_L4_IO_ADDRESS(0x480fe000 + (off)))
-
-void omap2_pm_dump(int mode, int resume, unsigned int us)
-{
- struct reg {
- const char *name;
- u32 val;
- } regs[32];
- int reg_count = 0, i;
- const char *s1 = NULL, *s2 = NULL;
-
- if (!resume) {
-#if 0
- /* MPU */
- DUMP_PRM_MOD_REG(OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET);
- DUMP_CM_MOD_REG(MPU_MOD, OMAP2_CM_CLKSTCTRL);
- DUMP_PRM_MOD_REG(MPU_MOD, OMAP2_PM_PWSTCTRL);
- DUMP_PRM_MOD_REG(MPU_MOD, OMAP2_PM_PWSTST);
- DUMP_PRM_MOD_REG(MPU_MOD, PM_WKDEP);
-#endif
-#if 0
- /* INTC */
- DUMP_INTC_REG(INTC_MIR0, 0x0084);
- DUMP_INTC_REG(INTC_MIR1, 0x00a4);
- DUMP_INTC_REG(INTC_MIR2, 0x00c4);
-#endif
-#if 0
- DUMP_CM_MOD_REG(CORE_MOD, CM_FCLKEN1);
- if (cpu_is_omap24xx()) {
- DUMP_CM_MOD_REG(CORE_MOD, OMAP24XX_CM_FCLKEN2);
- DUMP_PRM_MOD_REG(OMAP24XX_GR_MOD,
- OMAP2_PRCM_CLKEMUL_CTRL_OFFSET);
- DUMP_PRM_MOD_REG(OMAP24XX_GR_MOD,
- OMAP2_PRCM_CLKSRC_CTRL_OFFSET);
- }
- DUMP_CM_MOD_REG(WKUP_MOD, CM_FCLKEN);
- DUMP_CM_MOD_REG(CORE_MOD, CM_ICLKEN1);
- DUMP_CM_MOD_REG(CORE_MOD, CM_ICLKEN2);
- DUMP_CM_MOD_REG(WKUP_MOD, CM_ICLKEN);
- DUMP_CM_MOD_REG(PLL_MOD, CM_CLKEN);
- DUMP_CM_MOD_REG(PLL_MOD, CM_AUTOIDLE);
- DUMP_PRM_MOD_REG(CORE_MOD, OMAP2_PM_PWSTST);
-#endif
-#if 0
- /* DSP */
- if (cpu_is_omap24xx()) {
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, CM_FCLKEN);
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, CM_ICLKEN);
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, CM_IDLEST);
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, CM_AUTOIDLE);
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, CM_CLKSEL);
- DUMP_CM_MOD_REG(OMAP24XX_DSP_MOD, OMAP2_CM_CLKSTCTRL);
- DUMP_PRM_MOD_REG(OMAP24XX_DSP_MOD, OMAP2_RM_RSTCTRL);
- DUMP_PRM_MOD_REG(OMAP24XX_DSP_MOD, OMAP2_RM_RSTST);
- DUMP_PRM_MOD_REG(OMAP24XX_DSP_MOD, OMAP2_PM_PWSTCTRL);
- DUMP_PRM_MOD_REG(OMAP24XX_DSP_MOD, OMAP2_PM_PWSTST);
- }
-#endif
- } else {
- DUMP_PRM_MOD_REG(CORE_MOD, PM_WKST1);
- if (cpu_is_omap24xx())
- DUMP_PRM_MOD_REG(CORE_MOD, OMAP24XX_PM_WKST2);
- DUMP_PRM_MOD_REG(WKUP_MOD, PM_WKST);
- DUMP_PRM_MOD_REG(OCP_MOD, OMAP2_PRCM_IRQSTATUS_MPU_OFFSET);
-#if 1
- DUMP_INTC_REG(INTC_PENDING_IRQ0, 0x0098);
- DUMP_INTC_REG(INTC_PENDING_IRQ1, 0x00b8);
- DUMP_INTC_REG(INTC_PENDING_IRQ2, 0x00d8);
-#endif
- }
-
- switch (mode) {
- case 0:
- s1 = "full";
- s2 = "retention";
- break;
- case 1:
- s1 = "MPU";
- s2 = "retention";
- break;
- case 2:
- s1 = "MPU";
- s2 = "idle";
- break;
- }
-
- if (!resume)
-#ifdef CONFIG_NO_HZ
- printk(KERN_INFO
- "--- Going to %s %s (next timer after %u ms)\n", s1, s2,
- jiffies_to_msecs(get_next_timer_interrupt(jiffies) -
- jiffies));
-#else
- printk(KERN_INFO "--- Goi
[PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature
Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is
currently available as an OMAP-specific debugfs entry.
This duplicates existing ARM-generic functionality available as a
boot-time option using the boot cmdline option 'hohlt'.
If runtime configuration of this is needed, then adding a debugfs
entry for the ARM-generic hlt/nohlt interface should be added.
Signed-off-by: Kevin Hilman
---
arch/arm/mach-omap2/pm-debug.c |3 ---
arch/arm/mach-omap2/pm.h |2 --
arch/arm/mach-omap2/pm34xx.c |2 --
3 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index a5a83b3..cf9bc15 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -40,7 +40,6 @@
int omap2_pm_debug;
u32 enable_off_mode;
-u32 sleep_while_idle;
u32 wakeup_timer_seconds;
u32 wakeup_timer_milliseconds;
@@ -639,8 +638,6 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
&enable_off_mode, &pm_dbg_option_fops);
- (void) debugfs_create_file("sleep_while_idle", S_IRUGO | S_IWUSR, d,
- &sleep_while_idle, &pm_dbg_option_fops);
(void) debugfs_create_file("wakeup_timer_seconds", S_IRUGO | S_IWUSR, d,
&wakeup_timer_seconds, &pm_dbg_option_fops);
(void) debugfs_create_file("wakeup_timer_milliseconds",
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 797bfd1..fc2377c 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -64,13 +64,11 @@ extern void omap2_pm_dump(int mode, int resume, unsigned
int us);
extern void omap2_pm_wakeup_on_timer(u32 seconds, u32 milliseconds);
extern int omap2_pm_debug;
extern u32 enable_off_mode;
-extern u32 sleep_while_idle;
#else
#define omap2_pm_dump(mode, resume, us)do {} while (0);
#define omap2_pm_wakeup_on_timer(seconds, milliseconds)do {} while (0);
#define omap2_pm_debug 0
#define enable_off_mode 0
-#define sleep_while_idle 0
#endif
#if defined(CONFIG_CPU_IDLE)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0c5e3a4..991ade6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -497,8 +497,6 @@ console_still_active:
int omap3_can_sleep(void)
{
- if (!sleep_while_idle)
- return 0;
if (!omap_uart_can_sleep())
return 0;
return 1;
--
1.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups
Inspired by Jean's work to move PM code to modules, I decided it's time to remove a bunch of ugly and difficult to maintain code from PM debug. The main chunk here is removing the register dump features for OMAP2/OMAP3 which are awful to read, and impossible to scale for OMAP4+. Also, there are now some userspace /dev/mem-based tools (like omapconf) that can handle this type of thing much better, and with a much better interface and display. Series applies to v2.6.39. Kevin Hilman (4): OMAP3: PM debug: remove sleep_while_idle feature OMAP2: PM debug: remove register dumping OMAP3: PM debug: remove register dumping OMAP2: PM debug: move wakeup timer into clockevent code arch/arm/mach-omap2/pm-debug.c| 362 - arch/arm/mach-omap2/pm.h |9 - arch/arm/mach-omap2/pm24xx.c |6 +- arch/arm/mach-omap2/pm34xx.c |6 - arch/arm/mach-omap2/timer-gp.c| 33 +++- arch/arm/plat-omap/include/plat/dmtimer.h |1 - 6 files changed, 32 insertions(+), 385 deletions(-) -- 1.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/13] OMAP2+: PM: move the powerdomains time stats to powerdomain code
jean.pi...@newoldbits.com writes:
> From: Jean Pihet
>
> Move the powerdomains time accounting code from in pm-debug to the
> powerdomain code. The pm-debug code only displays the information on
> request.
>
> This also cleans up the core PM code, in order to allow it to be used
> as a module.
>
> Signed-off-by: Jean Pihet
Acked-by: Kevin Hilman
This make sense to me, and probably can be merged separately from this
series, if Paul is OK with it.
Kevin
> ---
> arch/arm/mach-omap2/pm-debug.c| 26 +-
> arch/arm/mach-omap2/pm.h |2 --
> arch/arm/mach-omap2/powerdomain.c | 25 -
> arch/arm/mach-omap2/powerdomain.h |3 +++
> 4 files changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 98cc9ee..0b896d4 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -333,21 +333,6 @@ static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS]
> = {
> "ON"
> };
>
> -void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
> -{
> - s64 t;
> -
> - if (!pm_dbg_init_done)
> - return ;
> -
> - /* Update timer for previous state */
> - t = sched_clock();
> -
> - pwrdm->state_timer[prev] += t - pwrdm->timer;
> -
> - pwrdm->timer = t;
> -}
> -
> static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
> {
> struct seq_file *s = (struct seq_file *)user;
> @@ -410,7 +395,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain
> *pwrdm, void *user)
> seq_printf(s, "%s (%s)", pwrdm->name,
> pwrdm_state_names[pwrdm->state]);
>
> - for (i = 0; i < 4; i++)
> + for (i = 0; i < PWRDM_MAX_PWRSTS; i++)
> seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
> pwrdm->state_timer[i]);
>
> @@ -517,17 +502,8 @@ DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops,
> pwrdm_suspend_get,
>
> static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
> {
> - int i;
> - s64 t;
> struct dentry *d;
>
> - t = sched_clock();
> -
> - for (i = 0; i < 4; i++)
> - pwrdm->state_timer[i] = 0;
> -
> - pwrdm->timer = t;
> -
> if (strncmp(pwrdm->name, "dpll", 4) == 0)
> return 0;
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index f36f79c..03da7f8 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -76,11 +76,9 @@ extern u32 sleep_while_idle;
> #endif
>
> #if defined(CONFIG_PM_DEBUG) && defined(CONFIG_DEBUG_FS)
> -extern void pm_dbg_update_time(struct powerdomain *pwrdm, int prev);
> extern int pm_dbg_regset_save(int reg_set);
> extern int pm_dbg_regset_init(int reg_set);
> #else
> -#define pm_dbg_update_time(pwrdm, prev) do {} while (0);
> #define pm_dbg_regset_save(reg_set) do {} while (0);
> #define pm_dbg_regset_init(reg_set) do {} while (0);
> #endif /* CONFIG_PM_DEBUG */
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index 9af0847..93a17c8 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "cm2xxx_3xxx.h"
> @@ -77,6 +78,7 @@ static struct powerdomain *_pwrdm_lookup(const char *name)
> static int _pwrdm_register(struct powerdomain *pwrdm)
> {
> int i;
> + s64 t;
>
> if (!pwrdm || !pwrdm->name)
> return -EINVAL;
> @@ -100,6 +102,12 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
> for (i = 0; i < PWRDM_MAX_PWRSTS; i++)
> pwrdm->state_counter[i] = 0;
>
> + /* Initialize the powerdomain's state timing stats */
> + t = sched_clock();
> + for (i = 0; i < PWRDM_MAX_PWRSTS; i++)
> + pwrdm->state_timer[i] = 0;
> + pwrdm->timer = t;
> +
> pwrdm->ret_logic_off_counter = 0;
> for (i = 0; i < pwrdm->banks; i++)
> pwrdm->ret_mem_off_counter[i] = 0;
> @@ -171,7 +179,9 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
> int flag)
> if (state != prev)
> pwrdm->state_counter[state]++;
>
> - pm_dbg_update_time(pwrdm, prev);
> +#ifdef CONFIG_PM_DEBUG
> + pwrdm_update_state_timer(pwrdm, prev);
> +#endif
>
> pwrdm->state = state;
>
> @@ -999,3 +1009,16 @@ bool pwrdm_can_ever_lose_context(struct powerdomain
> *pwrdm)
>
> return 0;
> }
> +
> +#ifdef CONFIG_PM_DEBUG
> +void pwrdm_update_state_timer(struct powerdomain *pwrdm, int prev)
> +{
> + s64 t;
> +
> + /* Update timer for previous state */
> + t = sched_clock();
> + pwrdm->state_timer[prev] += t - pwrdm->timer;
> + pwrdm->timer = t;
> +}
> +#endif
> +
> diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
> index d23d979..abda68d 100644
> --- a/arch/arm/mach-omap2/powe
Re: [PATCH 03/13] OMAP2+: PM: clean up usage of SRAM functions
jean.pi...@newoldbits.com writes: > From: Jean Pihet > > Clean-up SRAM functions usage to better isolate PM code, in order > to allow it to be used as a module. Could use some more description as to why this is needed. e.g. SRAM code is built-in, but PM code pushed to SRAM is module, etc... > Signed-off-by: Jean Pihet > --- > arch/arm/mach-omap2/pm34xx.c |1 + > arch/arm/plat-omap/sram.c|2 -- > 2 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c > index 0c5e3a4..74169a2 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -456,6 +456,7 @@ void omap_sram_idle(void) > omap3_core_restore_context(); > omap3_cm_restore_context(); > omap3_sram_restore_context(); > + omap_push_sram_idle(); > omap2_sms_restore_context(); > } > omap_uart_resume_idle(0); > diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c > index a3f50b3..f1a54bb 100644 > --- a/arch/arm/plat-omap/sram.c > +++ b/arch/arm/plat-omap/sram.c > @@ -390,7 +390,6 @@ void omap3_sram_restore_context(void) > _omap3_sram_configure_core_dpll = > omap_sram_push(omap3_sram_configure_core_dpll, > omap3_sram_configure_core_dpll_sz); > - omap_push_sram_idle(); OK, this removal is replaced by the one above.. > } > #endif /* CONFIG_PM */ > > @@ -399,7 +398,6 @@ static int __init omap34xx_sram_init(void) > _omap3_sram_configure_core_dpll = > omap_sram_push(omap3_sram_configure_core_dpll, > omap3_sram_configure_core_dpll_sz); > - omap_push_sram_idle(); what replaces this one, which happens at init time? Looking closer at pm34xx, there's alrady a call in omap3_pm_init(), you should make that clear in the changelog too, otherwise it's a red flag to see two removals and only one addition. Kevin > return 0; > } > #else -- To unsubscribe from this list: send the line "unsubscribe 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 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
"Menon, Nishanth" writes: > On Thu, May 26, 2011 at 11:35, Menon, Nishanth wrote: >> On Thu, May 26, 2011 at 10:38, Kevin Hilman wrote: >>> >>> I'd prefer to see this even cleaner by dropping the clk_* versions all >>> together. Then, for those who want OMAP2 support (currently not working >>> or validated anyways), all that's needed is to add a function simlilar >>> to clk_init_cpufreq_table() which registers OPPs. >> >> yeah - that is better as well.. will do > > oops - missed asking - are you ok with just returning a warning and > not registering the cpufreq driver for OMAP2? s/OMAP2/platforms without OPPs/ -- To unsubscribe from this list: send the line "unsubscribe 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] free rev gpios when they are read, so others can read them later
A script of mine that reads the rev gpios on the beagleboard started failing
when I upgraded to .37, since board-omap3beagle.c doesn´t free the rev gpios
after using them.
Signed-off-by: Tasslehoff Kjappfot
---
arch/arm/mach-omap2/board-omap3beagle.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3ff3a2c..8a4ac43 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -106,6 +106,9 @@ static void __init omap3_beagle_init_rev(void)
beagle_rev = gpio_get_value(171) | (gpio_get_value(172) << 1)
| (gpio_get_value(173) << 2);
+gpio_free_array(omap3_beagle_rev_gpios,
+ARRAY_SIZE(omap3_beagle_rev_gpios));
+
switch (beagle_rev) {
case 7:
printk(KERN_INFO "OMAP3 Beagle Rev: Ax/Bx\n");
--
1.7.3.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
[PATCH] ARM: OMAP2: Add missing iounmap in omap4430_phy_init
!dev case needs iounmap before return.
Signed-off-by: Todd Poynor
---
arch/arm/mach-omap2/omap_phy_internal.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index ae97336..bd563cf 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -56,8 +56,10 @@ int omap4430_phy_init(struct device *dev)
/* Power down the phy */
__raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- if (!dev)
+ if (!dev) {
+ iounmap(ctrl_base);
return 0;
+ }
phyclk = clk_get(dev, "ocp2scp_usb_phy_ick");
if (IS_ERR(phyclk)) {
--
1.7.3.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 V3 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
On Thu, May 26, 2011 at 11:35, Menon, Nishanth wrote: > On Thu, May 26, 2011 at 10:38, Kevin Hilman wrote: >> >> I'd prefer to see this even cleaner by dropping the clk_* versions all >> together. Then, for those who want OMAP2 support (currently not working >> or validated anyways), all that's needed is to add a function simlilar >> to clk_init_cpufreq_table() which registers OPPs. > > yeah - that is better as well.. will do oops - missed asking - are you ok with just returning a warning and not registering the cpufreq driver for OMAP2? 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 0/6 V3] Cleanups for cpufreq
On Thu, May 26, 2011 at 11:10, Kevin Hilman wrote: > So here's a dumb question, being rather ignorant of CPUfreq on SMP. > > Should we be running a CPUfreq instance on both CPUs when they cannot be > scaled independently? > > What is being scaled here is actually the cluster (the MPU SS via > dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to > have a an instance of the driver per scalable device, which in this case > is a single MPU SS. > > What am I missing? my understanding from the code is that we have one instance of cpufreq controllable from either cpu0 or 1. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: change get_context_loss_count ret value to int
Hello Tomi, Kevin,
On Thu, 26 May 2011, Tomi Valkeinen wrote:
> 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.
Thanks, I agree this makes more sense than the previous arrangement.
One minor comment:
> Signed-off-by: Tomi Valkeinen
> ---
> arch/arm/mach-omap2/omap_hwmod.c |2 +-
> arch/arm/mach-omap2/powerdomain.c | 14 ++
> 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 | 24 +---
> arch/arm/plat-omap/omap_device.c |2 +-
> 8 files changed, 34 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..9281481 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,13 @@ 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",
> + /*
> + * 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);
Could you use INT_MAX here? It seems best not to have the implicit
dependency on 32-bit ints, if it is not too inconvenient.
> +
> + pr_debug("powerdomain: %s: context loss count = %d\n",
>pwrdm->name, count);
>
> return count;
> diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
> index d23d979..012827f 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -207,7 +207,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
> int pwrdm_pre_transition(void);
> int pwrdm_post_transition(void);
> int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
> -u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
> +int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
> bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
>
> extern void omap2xxx_powerdomains_init(void);
> diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
> b/arch/arm/plat-omap/include/plat/omap-pm.h
> index c0a7520..68df031 100644
> --- a/arch/arm/plat-omap/include/plat/omap-pm.h
> +++ b/arch/arm/plat-omap/include/plat/omap-pm.h
> @@ -350,9 +350,9 @@ unsigned long omap_pm_cpu_get_freq(void);
> * driver must restore device context. If the number of context losses
> * exceeds the maximum positive integer, the function will wrap to 0 and
> * continue counting. Returns the number of context losses for this device,
> - * or zero upon error.
> + * or negative value upon error.
> */
> -u32 omap_pm_get_dev_context_loss_count(struct device *dev);
> +int omap_pm_get_dev_context_loss_count(struct device *dev);
>
> void omap_pm_enable_off_mode(void);
> void
Re: [PM-WIP_CPUFREQ][PATCH V3 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
On Thu, May 26, 2011 at 10:38, Kevin Hilman wrote: > > I'd prefer to see this even cleaner by dropping the clk_* versions all > together. Then, for those who want OMAP2 support (currently not working > or validated anyways), all that's needed is to add a function simlilar > to clk_init_cpufreq_table() which registers OPPs. yeah - that is better as well.. will do 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 Thu, May 26, 2011 at 10:11, Kevin Hilman wrote: > > When you're talking about potentially concurrent modification of data, > that make sense. Here you're implementing a plugin for an existing > framework, and you can (and have to) make assumptions about when the > callbacks are used. ok, that is the one i was looking for. thanks. will use atomic ops and drop the mutex. Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
"Varadarajan, Charulatha" writes: > Kevin, > > On Thu, May 26, 2011 at 12:15, Kevin Hilman wrote: >> "Varadarajan, Charulatha" writes: >> >>> On Thu, May 26, 2011 at 03:04, Kevin Hilman wrote: 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? >>> >>> I am referring to Table 25-5. GPIO Channel Description at page no 3354 >>> OMAP3430 public TRM Version P. >>> >> >> Based on how I understand that, those non-wakeup GPIOs are non-wakeup >> because they're not actually mapped anywhere, and not available on >> external pins. Therefore, they should not need any special case >> handling for this triggering workaround. > > Okay. Thanks for clarifying. I will not do this for OMAP3. The special case > would be only for OMAP2420 against the current code which is handling > for OMAP24xx. > Great, 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: [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." Thanks, squashed. Kevin > 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 > * -- To unsubscribe from this list: send the line "unsubscribe 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 0/6 V3] Cleanups for cpufreq
So here's a dumb question, being rather ignorant of CPUfreq on SMP. Should we be running a CPUfreq instance on both CPUs when they cannot be scaled independently? What is being scaled here is actually the cluster (the MPU SS via dpll_mpu_ck), not an individual CPU. So to me, it only makes sense to have a an instance of the driver per scalable device, which in this case is a single MPU SS. What am I missing? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
Kevin, On Thu, May 26, 2011 at 12:15, Kevin Hilman wrote: > "Varadarajan, Charulatha" writes: > >> On Thu, May 26, 2011 at 03:04, Kevin Hilman wrote: >>> 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? >> >> I am referring to Table 25-5. GPIO Channel Description at page no 3354 >> OMAP3430 public TRM Version P. >> > > Based on how I understand that, those non-wakeup GPIOs are non-wakeup > because they're not actually mapped anywhere, and not available on > external pins. Therefore, they should not need any special case > handling for this triggering workaround. Okay. Thanks for clarifying. I will not do this for OMAP3. The special case would be only for OMAP2420 against the current code which is handling for OMAP24xx. -V Charulatha > > 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 3/8] OMAP2+: cpufreq: use opp/clk_*cpufreq_table based on silicon
Nishanth Menon writes:
> 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
I'd prefer to see this even cleaner by dropping the clk_* versions all
together. Then, for those who want OMAP2 support (currently not working
or validated anyways), all that's needed is to add a function simlilar
to clk_init_cpufreq_table() which registers OPPs.
Kevin
> ---
> 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__);
--
To unsubscribe from this list: send the line "unsubscribe 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 2/8] OMAP2+: cpufreq: deny initialization if no mpudev
Nishanth Menon writes: > 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 Thanks, applied. 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 1/8] OMAP2+: cpufreq: move clk name decision to init
Nishanth Menon writes: > 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 Applied. -- To unsubscribe from this list: send the line "unsubscribe 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 0/3] Some omap_device/hwmod/pwrdomain patches
Tomi Valkeinen writes: > I came up with these patches while implementing pm runtime adaptation for DSS > driver. I'm not quite sure on who's turf they belong, or do they even belong > together, but here they are anyway. > > get_context_loss_count patch was discussed on l-o with Kevin. > > The omap_device_reset patch I made as some parts of DSS currently presume that > the HW module is reset when it is enabled, and the reset is better handled in > hwmod code. > > can_ever_lose_context code I didn't strictly need, but as there's such a > function I added that to the context save code in DSS while rewriting the > code. Are any of the DSS blocks in power domains that can't lose context (WKUP?) This isn't something in general that drivers should be aware of, so I'd rather not see this exposed to drivers (unless there's a real need.) As soon as I finish the move to device power domains (hopefully for 2.6.41), the driver's callbacks will only be called if the device has lost context, so checking for context loss will not be needed at all at the driver level. Kevin > > Tomi > > Tomi Valkeinen (3): > OMAP: change get_context_loss_count ret value to int > OMAP: add omap_device_reset() > OMAP: Add (omap_device|omap_hwmod)_can_ever_lose_context functions > > arch/arm/mach-omap2/omap_hwmod.c | 24 - > arch/arm/mach-omap2/powerdomain.c | 14 +-- > 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 |4 ++- > arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +- > arch/arm/plat-omap/omap-pm-noop.c | 24 + > arch/arm/plat-omap/omap_device.c | 48 > - > 8 files changed, 105 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: change get_context_loss_count ret value to int
Tomi Valkeinen writes: > 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 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: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
"Varadarajan, Charulatha" writes: > On Thu, May 26, 2011 at 03:04, Kevin Hilman wrote: >> 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? > > I am referring to Table 25-5. GPIO Channel Description at page no 3354 > OMAP3430 public TRM Version P. > Based on how I understand that, those non-wakeup GPIOs are non-wakeup because they're not actually mapped anywhere, and not available on external pins. Therefore, they should not need any special case handling for this triggering workaround. 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
"Menon, Nishanth" writes:
> 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.
The table is not modifiable in two places. It's only modified once,
upon creation. After that the table contents are constant.
What is changable is simply the existence of the table. This can be
handled by simply checking the pointer (or using your counter.)
> What if there is a read path while free occurs -
Then the CPUfreq driver has a bug. If you want to be safe, check for a
valid pointer or use your counter.
> 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.
When you're talking about potentially concurrent modification of data,
that make sense. Here you're implementing a plugin for an existing
framework, and you can (and have to) make assumptions about when the
callbacks are used.
Kevin
>>
>> > 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
[PATCH 3/3] OMAP: Add (omap_device|omap_hwmod)_can_ever_lose_context functions
Add hwmod and omap_device versions of can_ever_lose_context functions
so that drivers are able to use it.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/omap_hwmod.c | 22 ++
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
arch/arm/plat-omap/omap_device.c | 23 +++
4 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4f0d554..210280e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2369,3 +2369,25 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+/**
+ * omap_hwmod_can_ever_lose_context - can this hwmod ever lose context?
+ * @oh: struct omap_hwmod *
+ *
+ * Finds the powerdomain associated with the given hwmod, and calls
+ * pwrdm_can_ever_lose_context for the powerdomain.
+ *
+ * Returns the return value from pwrdm_can_ever_lose_context, or true if no
+ * powerdomain is associated with the hwmod.
+ */
+bool omap_hwmod_can_ever_lose_context(struct omap_hwmod *oh)
+{
+ struct powerdomain *pwrdm;
+ int ret = true;
+
+ pwrdm = omap_hwmod_get_pwrdm(oh);
+ if (pwrdm)
+ ret = pwrdm_can_ever_lose_context(pwrdm);
+
+ return ret;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index bcf1b35..640c2eb 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -109,6 +109,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
int omap_device_get_context_loss_count(struct platform_device *pdev);
int omap_device_reset(struct platform_device *pdev);
+bool omap_device_can_ever_lose_context(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8658e2d..0d7435e 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -601,6 +601,7 @@ int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh,
u8 state);
int omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
int omap_hwmod_no_setup_reset(struct omap_hwmod *oh);
+bool omap_hwmod_can_ever_lose_context(struct omap_hwmod *oh);
/*
* Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 4e6fc1b..bcee8d3 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -347,6 +347,29 @@ int omap_device_reset(struct platform_device *pdev)
}
/**
+ * omap_device_can_ever_lose_context - can this device ever lose context?
+ * @pdev: struct platform_device *
+ *
+ * Calls omap_hwmod_can_ever_lose_context for all hwmods associated with the
+ * given device, and returns true if one of the hwmods returns true. Otherwise
+ * returns false.
+ */
+bool omap_device_can_ever_lose_context(struct platform_device *pdev)
+{
+ struct omap_device *od;
+ int i;
+
+ od = _find_by_pdev(pdev);
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ if (omap_hwmod_can_ever_lose_context(od->hwmods[i]))
+ return true;
+ }
+
+ return false;
+}
+
+/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
*
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] 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 | 14 ++
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 | 24 +---
arch/arm/plat-omap/omap_device.c |2 +-
8 files changed, 34 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..9281481 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,13 @@ 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",
+ /*
+* 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);
+
+ pr_debug("powerdomain: %s: context loss count = %d\n",
pwrdm->name, count);
return count;
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index d23d979..012827f 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -207,7 +207,7 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);
int pwrdm_pre_transition(void);
int pwrdm_post_transition(void);
int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
-u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
extern void omap2xxx_powerdomains_init(void);
diff --git a/arch/arm/plat-omap/include/plat/omap-pm.h
b/arch/arm/plat-omap/include/plat/omap-pm.h
index c0a7520..68df031 100644
--- a/arch/arm/plat-omap/include/plat/omap-pm.h
+++ b/arch/arm/plat-omap/include/plat/omap-pm.h
@@ -350,9 +350,9 @@ unsigned long omap_pm_cpu_get_freq(void);
* driver must restore device context. If the number of context losses
* exceeds the maximum positive integer, the function will wrap to 0 and
* continue counting. Returns the number of context losses for this device,
- * or zero upon error.
+ * or negative value upon error.
*/
-u32 omap_pm_get_dev_context_loss_count(struct device *dev);
+int omap_pm_get_dev_context_loss_count(struct device *dev);
void omap_pm_enable_off_mode(void);
void omap_pm_disable_off_mode(void);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..70d31d0 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -107,7 +107,7 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);
int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_
[PATCH 2/3] OMAP: add omap_device_reset()
Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.
Signed-off-by: Tomi Valkeinen
---
arch/arm/plat-omap/include/plat/omap_device.h |1 +
arch/arm/plat-omap/omap_device.c | 23 +++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 70d31d0..bcf1b35 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -108,6 +108,7 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
u32 new_wakeup_lat_limit);
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
int omap_device_get_context_loss_count(struct platform_device *pdev);
+int omap_device_reset(struct platform_device *pdev);
/* Other */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 9753f71..4e6fc1b 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -324,6 +324,29 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
}
/**
+ * omap_device_reset - reset hwmods of given device
+ * @pdev: struct platform_device *
+ *
+ * Reset all hwmods associated with the given device. If a reset of a hwmod
+ * fails the rest of the hwmods are skipped and the error is returned.
+ */
+int omap_device_reset(struct platform_device *pdev)
+{
+ struct omap_device *od;
+ int i, r;
+
+ od = _find_by_pdev(pdev);
+
+ for (i = 0; i < od->hwmods_cnt; i++) {
+ r = omap_hwmod_reset(od->hwmods[i]);
+ if (r)
+ return r;
+ }
+
+ return 0;
+}
+
+/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
*
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Some omap_device/hwmod/pwrdomain patches
I came up with these patches while implementing pm runtime adaptation for DSS driver. I'm not quite sure on who's turf they belong, or do they even belong together, but here they are anyway. get_context_loss_count patch was discussed on l-o with Kevin. The omap_device_reset patch I made as some parts of DSS currently presume that the HW module is reset when it is enabled, and the reset is better handled in hwmod code. can_ever_lose_context code I didn't strictly need, but as there's such a function I added that to the context save code in DSS while rewriting the code. Tomi Tomi Valkeinen (3): OMAP: change get_context_loss_count ret value to int OMAP: add omap_device_reset() OMAP: Add (omap_device|omap_hwmod)_can_ever_lose_context functions arch/arm/mach-omap2/omap_hwmod.c | 24 - arch/arm/mach-omap2/powerdomain.c | 14 +-- 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 |4 ++- arch/arm/plat-omap/include/plat/omap_hwmod.h |3 +- arch/arm/plat-omap/omap-pm-noop.c | 24 + arch/arm/plat-omap/omap_device.c | 48 - 8 files changed, 105 insertions(+), 18 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap updates for 2.6.40
Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: > Hi Linus, > > Please pull omap updates for this merge window from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > omap-for-linus > > This contains clean-up to shrink down omap specific code a bit. Also included > are some fixes. But basically no new code at this point. What about updates to board files? Like adding support for the xM rev C to board-omap3beagle.c.-- To unsubscribe from this list: send the line "unsubscribe 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 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);
>
Yes.
--
To unsubscribe from this list: send the line "unsubscribe 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 7/9] OMAP4: powerdomain: Update MPU powerdomain for 4460
On 14:22-20110526, Premi, Sanjeev wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> > Sent: Thursday, May 26, 2011 7:27 AM
> > To: linux-omap
> > Cc: Nayak, Rajendra
> > Subject: [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.
> >
> [snip]...[snip]
>
> > +static struct powerdomain mpu_446x_pwrdm = {
> > + .name = "mpu_pwrdm",
> > + .prcm_offs= OMAP4430_PRM_MPU_INST,
> > + .prcm_partition = OMAP4430_PRM_PARTITION,
> > + .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
>
> [sp] This change doesn't go with the description above.
> Shouldn't this be CHIP_IS_OMAP44XX or CHIP_IS_OMAP446X
> to be more future safe?
hmm.. similar to Vikram's comment as well. Will switch to using 6X
and 3X instead of 60 and 30 if there are no contrary opinions.
--
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 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
On 14:06-20110526, Premi, Sanjeev wrote: > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > > Sent: Thursday, May 26, 2011 7:27 AM > > To: linux-omap > > Cc: Sonasath, Moiz; Menon, Nishanth > > Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 > > during HWMOD init > > [sp] typo in the subject. "DO" -> "Do" > > Another nit: Are 2 HWMODs required in the subject? :) thanks. will fix. -- 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 1/9] OMAP: ID: introduce chip detection for OMAP4460
On 14:03-20110526, Premi, Sanjeev wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org
> > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> > Sent: Thursday, May 26, 2011 7:27 AM
> > To: linux-omap
> > Cc: V, Aneesh; Menon, Nishanth
> > Subject: [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?c
> > ontentId=53243&navigationId=12843&templateId=6123
> > Public TRM is available here as usual:
> > http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?t
> > emplateId=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;
>
> [sp] Why is this change required?
As explained in the commit message, using hawkeye will not be accurate
anymore for 4460 onwards. The variable naming is changed to prevent confusion in
the future as we continue to use ramp_system. As far as I know, there is
no unique bit to differentiate between the two and so far have been
unique.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
Why not do the following:
#define OMAP_GPIO_REV_0 0
#define OMAP_GPIO_REV_1 1
#define OMAP_GPIO_REV_2 2
#define OMAP_GPIO_REV_3 3
/*
OMAP_GPIO_REV_0:OMAP2420
OMAP_GPIO_REV_1:OMAP2430
OMAP_GPIO_REV_2:OMAP3, DMxxx
OMAP_GPIO_REV_3:OMAP4, OMAP5, DM816x
*/
+ switch (oh->class->rev) { ## This is auto-generated.
+ case 0: ## But this is our code.
I am recommending this to read as:
+ switch (oh->class->rev) { ## This is auto-generated.
+ case OMAP_GPIO_REV_0: ## More readable.
That approach solves both issues -- Revision -> Chip mapping in comment, no
magic numbers in the code, and no implied restriction of the rev number to a
specific SoC. Using the defines makes it easier to search the code for a
specific revision, since you would no longer get false positives for all the
other '0' and '1' constants that appear in the code. It also makes it indexible
by tools like LXR.
B.J. Buchalter
Metric Halo
http://www.mhlabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
On 5/26/2011 3:38 PM, B.J. Buchalter wrote:
Why not do the following:
#define OMAP_GPIO_REV_0 0
#define OMAP_GPIO_REV_1 1
#define OMAP_GPIO_REV_2 2
#define OMAP_GPIO_REV_3 3
/*
OMAP_GPIO_REV_0:OMAP2420
OMAP_GPIO_REV_1:OMAP2430
OMAP_GPIO_REV_2:OMAP3, DMxxx
OMAP_GPIO_REV_3:OMAP4, OMAP5, DM816x
*/
+switch (oh->class->rev) { ## This is auto-generated.
+case 0: ## But this is our code.
I am recommending this to read as:
+switch (oh->class->rev) { ## This is auto-generated.
+case OMAP_GPIO_REV_0: ## More readable.
That approach solves both issues -- Revision -> Chip mapping in comment, no
magic numbers in the code, and no implied restriction of the rev number to a
specific SoC. Using the defines makes it easier to search the code for a specific
revision, since you would no longer get false positives for all the other '0' and
'1' constants that appear in the code. It also makes it indexible by tools like
LXR.
This is indeed what was done for I2C recently.
The point is that this kind of define does not bring a lot of semantic.
But on the other hand it will definitively help the search aspect.
Thanks,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings
On 05/26/11 16:37, Tony Lindgren wrote: > * Santosh Shilimkar [110526 05:56]: >> On 5/26/2011 6:30 PM, Silesh C V wrote: >>> Get rid of the following and 8 other similar section mismatch >>> warnings >>> >> I send this [1] patch a month back. It's still not considered >> though even after reminder. >> >> [1] https://patchwork.kernel.org/patch/684831/ > Applying now into devel-fixes with additional fixes from Silesh. > Updated patch below. Can this [1] also be applied to the devel-fixes, please? It is a month old today... [1] https://patchwork.kernel.org/patch/733531/ Thanks -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe 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: omap2plus: fix ads7846 pendown gpio request
ping
On 05/11/11 10:35, Igor Grinberg wrote:
> Tony,
>
>
> You can fold this one to the original patch from Mike as well,
>
> or do you want it into the rc1?
>
>
>
> On 05/04/11 20:22, Thomas Weber wrote:
>
>> Am 04.05.2011 17:04, schrieb Igor Grinberg:
>>> introduced by: 96974a24
>>> (omap: consolidate touch screen initialization among different boards)
>>>
>>> ads7846 driver can use either gpio_pendown or get_pendown_state()
>>> callback. In case of gpio_pendown, it requests the provided gpio_pendown
>>> thus resulting in double requesting that gpio:
>>>
>>> ads7846 spi1.0: failed to request pendown GPIO57
>>> ads7846: probe of spi1.0 failed with error -16
>>>
>>> Fix this by restricting the gpio request to the case of
>>> get_pendown_state() callback is used.
>>>
>>> Signed-off-by: Igor Grinberg
>>> ---
>>> arch/arm/mach-omap2/common-board-devices.c | 20 ++--
>>> 1 files changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/common-board-devices.c
>>> b/arch/arm/mach-omap2/common-board-devices.c
>>> index d57c71d..61fee80 100644
>>> --- a/arch/arm/mach-omap2/common-board-devices.c
>>> +++ b/arch/arm/mach-omap2/common-board-devices.c
>>> @@ -83,17 +83,17 @@ void __init omap_ads7846_init(int bus_num, int
>>> gpio_pendown, int gpio_debounce,
>>> struct spi_board_info *spi_bi =&ads7846_spi_board_info;
>>> int err;
>>>
>>> -err = gpio_request(gpio_pendown, "TS PenDown");
>>> -if (err) {
>>> -pr_err("Could not obtain gpio for TS PenDown: %d\n", err);
>>> -return;
>>> -}
>>> -
>>> -gpio_direction_input(gpio_pendown);
>>> -gpio_export(gpio_pendown, 0);
>>> +if (board_pdata&& board_pdata->get_pendown_state) {
>>> +err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
>>> +if (err) {
>>> +pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
>>> +return;
>>> +}
>>> +gpio_export(gpio_pendown, 0);
>>>
>>> -if (gpio_debounce)
>>> -gpio_set_debounce(gpio_pendown, gpio_debounce);
>>> +if (gpio_debounce)
>>> +gpio_set_debounce(gpio_pendown, gpio_debounce);
>>> +}
>>>
>>> ads7846_config.gpio_pendown = gpio_pendown;
>>>
>> Tested-by: Thomas Weber
>>
>> On Devkit8000.
>>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe 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: Get rid of section mismatch warnings
On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote:
> * Santosh Shilimkar [110526 05:56]:
> > On 5/26/2011 6:30 PM, Silesh C V wrote:
> > >Get rid of the following and 8 other similar section mismatch
> > >warnings
> > >
> > I send this [1] patch a month back. It's still not considered
> > though even after reminder.
> >
> > [1] https://patchwork.kernel.org/patch/684831/
>
> Applying now into devel-fixes with additional fixes from Silesh.
> Updated patch below.
I also have this from a while back. There's also some nastyness in
twl4030-power.c which requires basically s/__init/__devinit/ to almost
the entire file.
8<
From: Russell King
Fix various section mismatch warnings:
WARNING: arch/arm/plat-omap/built-in.o(.devinit.text+0x46c): Section mismatch
in reference from the function omap_gpio_probe() to the function
.init.text:omap_gpio_chip_init()
The function __devinit omap_gpio_probe() references
a function __init omap_gpio_chip_init().
If omap_gpio_chip_init is only used by omap_gpio_probe then
annotate omap_gpio_chip_init with a matching annotation.
WARNING: arch/arm/mach-omap2/built-in.o(.text+0x423c): Section mismatch in
reference from the function pm_dbg_regset_init() to the function
.init.text:pm_dbg_init()
The function pm_dbg_regset_init() references
the function __init pm_dbg_init().
This is often because pm_dbg_regset_init lacks a __init
annotation or the annotation of pm_dbg_init is wrong.
Signed-off-by: Russell King
--
arch/arm/mach-omap2/pm-debug.c |4 ++--
arch/arm/plat-omap/gpio.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..3800ee0 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -1629,7 +1629,7 @@ static void omap_gpio_mod_init(struct gpio_bank *bank,
int id)
}
}
-static void __init omap_gpio_chip_init(struct gpio_bank *bank)
+static void __devinit omap_gpio_chip_init(struct gpio_bank *bank)
{
int j;
static int gpio;
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 125f565..169e930 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -189,7 +189,7 @@ static struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
-static int __init pm_dbg_init(void);
+static int pm_dbg_init(void);
enum {
DEBUG_FILE_COUNTERS = 0,
@@ -595,7 +595,7 @@ static int option_set(void *data, u64 val)
DEFINE_SIMPLE_ATTRIBUTE(pm_dbg_option_fops, option_get, option_set, "%llu\n");
-static int __init pm_dbg_init(void)
+static int pm_dbg_init(void)
{
int i;
struct dentry *d;
--
To unsubscribe from this list: send the line "unsubscribe 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: [GIT PULL] omap changes for v2.6.39 merge window
Hi! > There's a number of down-counting clocksources using various methods to > convert to an up-counting value - sometimes -readl(), sometimes > cs->mask - readl() and sometimes ~readl(). > > Then there's those which are either 16-bit or 32-bit, and some of those > 16-bit implementations must use readw() to avoid bus faults. > > Combining all those together you end up with something pretty disgusting, > and an initialization function taking 7 arguments (iomem pointer, name, > rating, tick rate, size, up/down counter, clocksource flags). Having structure with 7 fields describing the clock source seems completely sane... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings
* Santosh Shilimkar [110526 05:56]:
> On 5/26/2011 6:30 PM, Silesh C V wrote:
> >Get rid of the following and 8 other similar section mismatch
> >warnings
> >
> I send this [1] patch a month back. It's still not considered
> though even after reminder.
>
> [1] https://patchwork.kernel.org/patch/684831/
Applying now into devel-fixes with additional fixes from Silesh.
Updated patch below.
Regards,
Tony
From: Santosh Shilimkar
Date: Mon, 4 Apr 2011 10:02:05 +
Subject: [PATCH] OMAP2+: Fix 9 section mismatch(es) warnings from
mach-omap2/built-in.o
The serial*_data should have been marked as __initdata as per
it's usage in the board files. Fix the same to remove the
section mismatch warnings caused by it.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Silesh C V
[t...@atomide.com: updated with additional fixes from Silesh]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 52dbdf3..c710ad5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -622,19 +622,19 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ae3153c..da6c666 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -258,7 +258,7 @@ static struct gpio sdp4430_eth_gpios[] __initdata = {
{ ETH_KS8851_IRQ, GPIOF_IN, "eth_irq" },
};
-static int omap_ethernet_init(void)
+static int __init omap_ethernet_init(void)
{
int status;
@@ -672,19 +672,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5d7c0a3..2d52ee7 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -526,19 +526,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index ce53e82..d826242 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -26,7 +26,7 @@ static struct gpio zoom_lcd_gpios[] __initdata = {
{ LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, "lcd qvga" },
};
-static void zoom_lcd_panel_init(void)
+static void __init zoom_lcd_panel_init(void)
{
zoom_lcd_gpios[0].gpio = (omap_rev() > OMAP3430_REV_ES3_0) ?
LCD_PANEL_RESET_GPIO_PROD :
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
> -Original Message- > From: Cousson, Benoit > Sent: Thursday, May 26, 2011 6:17 PM > To: Premi, Sanjeev > Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; > Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > linux-arm-ker...@lists.infradead.org; Varadarajan, > Charulatha; Paul Walmsley > Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup > GPIO and rev_ids > > On 5/26/2011 2:38 PM, Premi, Sanjeev wrote: > >> -Original Message- > >> From: Cousson, Benoit > >> Sent: Thursday, May 26, 2011 5:41 PM > >> To: Premi, Sanjeev > >> Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; > >> Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > >> linux-arm-ker...@lists.infradead.org; Varadarajan, > >> Charulatha; Paul Walmsley > >> Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup > >> GPIO and rev_ids > >> > >> On 5/26/2011 1:47 PM, Premi, Sanjeev wrote: > -Original Message- > From: Cousson, Benoit > Sent: Thursday, May 26, 2011 3:41 PM > To: Premi, Sanjeev > Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org; > Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > linux-arm-ker...@lists.infradead.org; Varadarajan, > Charulatha; Paul Walmsley > Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup > GPIO and rev_ids > > On 5/26/2011 11:23 AM, Premi, Sanjeev wrote: > >> From: linux-omap-ow...@vger.kernel.org > >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > >> DebBarma, Tarun Kanti > >> Sent: Tuesday, May 24, 2011 7:55 PM > >> > >> 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)¬ for OMAP3 which is > incorrect. > >> > >> 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 > > > > [sp] Magic numbers should be avoided. > > Suggest using something like: > > #define GPIO_REV_2420 0 > > #define GPIO_REV_2430 1 > > #define GPIO_REV_34XX 2 > > #define GPIO_REV_44xx 3 > > Well, it is not a magic number, it is a revision id that is > incremented > each time there is a difference in the IP. [sp] Just to quote a definition: [quote]The term magic number or magic constant also refers to the programming practice of using numbers directly in source code. [/quote] It has no relation to whether/how it can signify something important. > The OMAP version -> IP version link is done at hwmod level. > The driver > does not have to know it is an OMAP3 or OMAP4. In that > case we did > change the IP version for every revisions, but OMAP5 will use > the OMAP4 > revision. [sp] I don't understand the confusion because IPs are anyways going to be used across. Many macros originally created for OMAP34XX are true/valid for OMAP36XX. And same holds good (probably) for OMAP24XX as well. But in each context, we are aware of the intended usage and can relate to the use and reuse better because it is quite evident. Use of OMAP2_CONTROL_GENERAL in OMAP34xx specific function is not accurate by your example below, but we all know the meaning and need for the same. > I'm not even considering all the Davinci variants that are > >> not named > OMAP but do use OMAP IPs... as you already know... > That can provide a rather confusing information for my > >> point of view. [sp] So now what happens when existing IP gets changed to fix an issue in existing OMAP3 design. Going by same logic will we add another id for the same? > > Whereas a comment like that will give you the exhaustive > >> information. > > 0: OMAP2420 > 1: OMAP2430 > 2: OMAP3, DMxxx > 3: OMAP4, OMAP5, DM816x > > That being said, some drivers already did that, so I'm not > >> opposed to > such change. I just think it is not the best approach. [sp] Taking same point further, if the IP from OMAP4 above gets used to create OMAP3699 (for example). How does this case get handled? OR we expect users to know about exceptions each time they read code? Leaving aside the fact the situation is hypothetical; design should be generic to handle such situations. > At least it gives a pointer to the TRM that contains the IP doc. > >>> > >>> [sp] Benoit, your are right from
Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings
On 5/26/2011 6:30 PM, Silesh C V wrote: Get rid of the following and 8 other similar section mismatch warnings I send this [1] patch a month back. It's still not considered though even after reminder. Regards Santosh [1] https://patchwork.kernel.org/patch/684831/ -- To unsubscribe from this list: send the line "unsubscribe 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] ARM: OMAP: Get rid of section mismatch warnings
Get rid of the following and 8 other similar section mismatch
warnings
WARNING: vmlinux.o(.text+0x2740c): Section mismatch in reference from the
function zoom_lcd_panel_init() to the (unknown reference) .init.data:(unknown)
The function zoom_lcd_panel_init() references
the (unknown reference) __initdata (unknown).
This is often because zoom_lcd_panel_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.
WARNING: vmlinux.o(.text+0x277fc): Section mismatch in reference from the
function omap_ethernet_init() to the (unknown reference) .init.data:(unknown)
The function omap_ethernet_init() references
the (unknown reference) __initdata (unknown).
This is often because omap_ethernet_init lacks a __initdata
annotation or the annotation of (unknown) is wrong.
WARNING: vmlinux.o(.data+0x2ff3c): Section mismatch in reference from the
variable serial1_data to the (unknown reference) .init.data:(unknown)
The variable serial1_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Silesh C V
---
arch/arm/mach-omap2/board-3430sdp.c |6 +++---
arch/arm/mach-omap2/board-4430sdp.c |8
arch/arm/mach-omap2/board-omap4panda.c |6 +++---
arch/arm/mach-omap2/board-zoom-display.c |2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 52dbdf3..c710ad5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -622,19 +622,19 @@ static struct omap_device_pad serial3_pads[] __initdata =
{
OMAP_MUX_MODE0),
};
-static struct omap_board_data serial1_data = {
+static struct omap_board_data serial1_data __initdata = {
.id = 0,
.pads = serial1_pads,
.pads_cnt = ARRAY_SIZE(serial1_pads),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ae3153c..da6c666 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -258,7 +258,7 @@ static struct gpio sdp4430_eth_gpios[] __initdata = {
{ ETH_KS8851_IRQ, GPIOF_IN, "eth_irq" },
};
-static int omap_ethernet_init(void)
+static int __init omap_ethernet_init(void)
{
int status;
@@ -672,19 +672,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5d7c0a3..2d52ee7 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -526,19 +526,19 @@ static struct omap_device_pad serial4_pads[] __initdata =
{
OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
};
-static struct omap_board_data serial2_data = {
+static struct omap_board_data serial2_data __initdata = {
.id = 1,
.pads = serial2_pads,
.pads_cnt = ARRAY_SIZE(serial2_pads),
};
-static struct omap_board_data serial3_data = {
+static struct omap_board_data serial3_data __initdata = {
.id = 2,
.pads = serial3_pads,
.pads_cnt = ARRAY_SIZE(serial3_pads),
};
-static struct omap_board_data serial4_data = {
+static struct omap_board_data serial4_data __initdata = {
.id = 3,
.pads = serial4_pads,
.pads_cnt = ARRAY_SIZE(serial4_pads),
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-displ
Re: [GIT PULL] omap updates for 2.6.40
* Igor Grinberg [110526 05:48]:
> On 05/26/11 15:24, Tony Lindgren wrote:
>
> > * Igor Grinberg [110526 05:10]:
> >> What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out
> >> of boards
> >>
> >> Why not include it? It is no new code, just generalize stuff and 11 lines
> >> off... not much but still.
> > Sorry I must have missed it.. Let's see if we can queue it
> > during the merge window as it's a trivial patch removing
> > duplicate defines.
>
> I'm failing to understand what do you mean by that...
> According to Linus ("probably Sunday - I'll be on airplanes next Monday"),
> the merge window will be closed soon.
>
> Do you mean, you will send an updated pull request?
Sorry I meant during the -rc cycle, I guess we're out of
time for the merge window to make changes.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap updates for 2.6.40
On 05/26/11 15:24, Tony Lindgren wrote:
> * Igor Grinberg [110526 05:10]:
>> What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of
>> boards
>>
>> Why not include it? It is no new code, just generalize stuff and 11 lines
>> off... not much but still.
> Sorry I must have missed it.. Let's see if we can queue it
> during the merge window as it's a trivial patch removing
> duplicate defines.
I'm failing to understand what do you mean by that...
According to Linus ("probably Sunday - I'll be on airplanes next Monday"),
the merge window will be closed soon.
Do you mean, you will send an updated pull request?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
On 5/26/2011 2:38 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 5:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 1:47 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
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)¬ for OMAP3 which is incorrect.
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
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
Well, it is not a magic number, it is a revision id that is
incremented
each time there is a difference in the IP.
The OMAP version -> IP version link is done at hwmod level.
The driver
does not have to know it is an OMAP3 or OMAP4. In that case we did
change the IP version for every revisions, but OMAP5 will use
the OMAP4
revision.
I'm not even considering all the Davinci variants that are
not named
OMAP but do use OMAP IPs... as you already know...
That can provide a rather confusing information for my
point of view.
Whereas a comment like that will give you the exhaustive
information.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
That being said, some drivers already did that, so I'm not
opposed to
such change. I just think it is not the best approach.
At least it gives a pointer to the TRM that contains the IP doc.
[sp] Benoit, your are right from generation perspectove where the
it is easier to increment numbers but when we use comparison
This is not even related to generation. A version number is a number.
If OMAP2 is using GPIO v1.6 and OMAP3 the version v2.2, only that IP
version is relevant for the driver.
For the documentation point of view, since we do not have a
per IP TRM,
then it can make sense to know where that IP is documented. But as I
said a comment is enough and will allow a much more relevant level of
details information than a define.
code - as in this patch, comparison against a number isn't
readable.
As example:
+switch (oh->class->rev) { ## This is auto-generated.
+case 0: ## But this is our code.
I am recommending this to read as:
+switch (oh->class->rev) { ## This is auto-generated.
+case GPIO_REV_2420: ## More readable.
More readable, maybe, but not necessarily relevant nor
accurate if the
same IP version is used in another chip or revision.
What IP version is used in a DM816x? GPIO_REV_3430, GPIO_REV_4430?
How is value 0 accurate?
0 is just the revision number that can give you the exact list of Soc
that does use that IP. Thanks to an exhaustive comment.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
BTW, I'm still waiting the answer for previous question...
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
> -Original Message-
> From: Cousson, Benoit
> Sent: Thursday, May 26, 2011 5:41 PM
> To: Premi, Sanjeev
> Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
> Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
> linux-arm-ker...@lists.infradead.org; Varadarajan,
> Charulatha; Paul Walmsley
> Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
> GPIO and rev_ids
>
> On 5/26/2011 1:47 PM, Premi, Sanjeev wrote:
> >> -Original Message-
> >> From: Cousson, Benoit
> >> Sent: Thursday, May 26, 2011 3:41 PM
> >> To: Premi, Sanjeev
> >> Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
> >> Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
> >> linux-arm-ker...@lists.infradead.org; Varadarajan,
> >> Charulatha; Paul Walmsley
> >> Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
> >> GPIO and rev_ids
> >>
> >> On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, May 24, 2011 7:55 PM
>
> 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.
>
> 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
> >>>
> >>> [sp] Magic numbers should be avoided.
> >>>Suggest using something like:
> >>>#define GPIO_REV_2420 0
> >>>#define GPIO_REV_2430 1
> >>>#define GPIO_REV_34XX 2
> >>>#define GPIO_REV_44xx 3
> >>
> >> Well, it is not a magic number, it is a revision id that is
> >> incremented
> >> each time there is a difference in the IP.
> >> The OMAP version -> IP version link is done at hwmod level.
> >> The driver
> >> does not have to know it is an OMAP3 or OMAP4. In that case we did
> >> change the IP version for every revisions, but OMAP5 will use
> >> the OMAP4
> >> revision.
> >> I'm not even considering all the Davinci variants that are
> not named
> >> OMAP but do use OMAP IPs... as you already know...
> >> That can provide a rather confusing information for my
> point of view.
> >>
> >> Whereas a comment like that will give you the exhaustive
> information.
> >>
> >> 0: OMAP2420
> >> 1: OMAP2430
> >> 2: OMAP3, DMxxx
> >> 3: OMAP4, OMAP5, DM816x
> >>
> >> That being said, some drivers already did that, so I'm not
> opposed to
> >> such change. I just think it is not the best approach.
> >> At least it gives a pointer to the TRM that contains the IP doc.
> >
> > [sp] Benoit, your are right from generation perspectove where the
> > it is easier to increment numbers but when we use comparison
>
> This is not even related to generation. A version number is a number.
> If OMAP2 is using GPIO v1.6 and OMAP3 the version v2.2, only that IP
> version is relevant for the driver.
> For the documentation point of view, since we do not have a
> per IP TRM,
> then it can make sense to know where that IP is documented. But as I
> said a comment is enough and will allow a much more relevant level of
> details information than a define.
>
> > code - as in this patch, comparison against a number isn't
> > readable.
> >
> > As example:
> >
> > + switch (oh->class->rev) { ## This is auto-generated.
> > + case 0: ## But this is our code.
> >
> > I am recommending this to read as:
> >
> > + switch (oh->class->rev) { ## This is auto-generated.
> > + case GPIO_REV_2420: ## More readable.
>
> More readable, maybe, but not necessarily relevant nor
> accurate if the
> same IP version is used in another chip or revision.
>
> What IP version is used in a DM816x? GPIO_REV_3430, GPIO_REV_4430?
How is value 0 accurate?
>
> Benoit
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap updates for 2.6.40
* Igor Grinberg [110526 05:10]: > > What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of > boards > > Why not include it? It is no new code, just generalize stuff and 11 lines > off... not much but still. Sorry I must have missed it.. Let's see if we can queue it during the merge window as it's a trivial patch removing duplicate defines. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap updates for 2.6.40
Tony, What about this one: [PATCH v2] arm: omap2plus: move NAND_BLOCK_SIZE out of boards Why not include it? It is no new code, just generalize stuff and 11 lines off... not much but still. On 05/26/11 14:39, Tony Lindgren wrote: > Hi Linus, > > Please pull omap updates for this merge window from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > omap-for-linus > > This contains clean-up to shrink down omap specific code a bit. Also included > are some fixes. But basically no new code at this point. > > Regards, > > Tony > > > Aaro Koskinen (5): > OMAP3+: smartreflex: fix sr_late_init() error path in probe > OMAP3+: smartreflex: request the memory region > OMAP3+: smartreflex: fix ioremap leak on probe error > OMAP3+: smartreflex: delete instance from sr_list on probe error > OMAP3+: smartreflex: delete debugfs entries on probe error > > Felipe Balbi (1): > usb: musb: am35x: fix compile error when building am35x > > Hema HK (3): > usb: musb: OMAP4430: Power down the PHY during board init > usb: otg: OMAP4430: Fixing the omap4430_phy_init function > usb: otg: OMAP4430: Powerdown the internal PHY when USB is disabled > > Igor Grinberg (2): > arm: omap: gpmc-smsc911x: minor style fixes > arm: omap2plus: GPIO cleanup > > Jean Pihet (5): > OMAP3 cpuidle: remove useless SDP specific timings > OMAP3: clean-up mach specific cpuidle data structures > OMAP3: cpuidle: re-organize the C-states data > OMAP3: cpuidle: code rework for improved readability > OMAP3: cpuidle: change the power domains modes determination logic > > Mike Rapoport (10): > omap: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL > omap: convert boards that use SMSC911x to use gpmc-smsc911x > omap: consolidate touch screen initialization among different boards > omap: use common initialization for PMIC i2c bus > omap: move detection of NAND CS to common-board-devices > omap: musb: introduce default board config > omap: igep0020: name refactoring for future merge with IGEP3 > omap: igep0020: minor refactoring > omap: igep0020: add support for IGEP3 > omap: drop board-igep0030.c > > Nishanth Menon (2): > OMAP4: PM: remove redundant #ifdef CONFIG_PM > OMAP3+: voltage: remove spurious pr_notice for debugfs > > Sanjeev Premi (1): > OMAP3: PM: Boot message is not an error, and not helpful, remove it > > Tony Lindgren (5): > omap: Run make savedefconfig on omap2plus_defconfig to shrink it > omap: Remove support for omap2evm > Merge branches 'devel-fixes', 'devel-cleanup' and 'devel-genirq' into > for-next > Merge branch 'for-tony' of master.kernel.org:/.../balbi/usb into > omap-for-linus > Merge branch 'for_2.6.40/pm-cleanup' of > ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus > > omar ramirez (2): > OMAP3/4: l3: fix omap3_l3_probe error path > OMAP3/4: l3: minor cleanup for parenthesis and extra spaces > > arch/arm/configs/omap2plus_defconfig| 83 + > arch/arm/mach-omap2/Kconfig |1 + > arch/arm/mach-omap2/Makefile|4 +- > arch/arm/mach-omap2/board-2430sdp.c | 27 +-- > arch/arm/mach-omap2/board-3430sdp.c | 151 ++--- > arch/arm/mach-omap2/board-4430sdp.c | 114 ++- > arch/arm/mach-omap2/board-am3517crane.c | 10 +- > arch/arm/mach-omap2/board-am3517evm.c | 56 +-- > arch/arm/mach-omap2/board-apollon.c | 29 +- > arch/arm/mach-omap2/board-cm-t35.c | 236 ++-- > arch/arm/mach-omap2/board-cm-t3517.c|9 +- > arch/arm/mach-omap2/board-devkit8000.c | 131 +-- > arch/arm/mach-omap2/board-igep0020.c| 449 +++--- > arch/arm/mach-omap2/board-igep0030.c| 458 > --- > arch/arm/mach-omap2/board-ldp.c | 138 +--- > arch/arm/mach-omap2/board-n8x0.c| 28 +- > arch/arm/mach-omap2/board-omap3beagle.c | 194 +++--- > arch/arm/mach-omap2/board-omap3evm.c| 242 +++-- > arch/arm/mach-omap2/board-omap3logic.c | 14 +- > arch/arm/mach-omap2/board-omap3pandora.c| 90 + > arch/arm/mach-omap2/board-omap3stalker.c| 133 +-- > arch/arm/mach-omap2/board-omap3touchbook.c | 121 +-- > arch/arm/mach-omap2/board-omap4panda.c | 79 ++--- > arch/arm/mach-omap2/board-overo.c | 265 +++--- > arch/arm/mach-omap2/board-rm680.c | 21 +- > arch/arm/mach-omap2/board-rx51-peripherals.c| 42 +-- > arch/arm/mach-omap2/board-rx51-video.c |5 +- > arch/arm/mach-omap2/board-rx51.c| 18 +- > arch/arm/mach-omap2/board-zoom-debugboard.c | 65 +--
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
On 5/26/2011 1:47 PM, Premi, Sanjeev wrote:
-Original Message-
From: Cousson, Benoit
Sent: Thursday, May 26, 2011 3:41 PM
To: Premi, Sanjeev
Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
linux-arm-ker...@lists.infradead.org; Varadarajan,
Charulatha; Paul Walmsley
Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
GPIO and rev_ids
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
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.
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
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_24200
#define GPIO_REV_24301
#define GPIO_REV_34XX2
#define GPIO_REV_44xx3
Well, it is not a magic number, it is a revision id that is
incremented
each time there is a difference in the IP.
The OMAP version -> IP version link is done at hwmod level.
The driver
does not have to know it is an OMAP3 or OMAP4. In that case we did
change the IP version for every revisions, but OMAP5 will use
the OMAP4
revision.
I'm not even considering all the Davinci variants that are not named
OMAP but do use OMAP IPs... as you already know...
That can provide a rather confusing information for my point of view.
Whereas a comment like that will give you the exhaustive information.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
That being said, some drivers already did that, so I'm not opposed to
such change. I just think it is not the best approach.
At least it gives a pointer to the TRM that contains the IP doc.
[sp] Benoit, your are right from generation perspectove where the
it is easier to increment numbers but when we use comparison
This is not even related to generation. A version number is a number.
If OMAP2 is using GPIO v1.6 and OMAP3 the version v2.2, only that IP
version is relevant for the driver.
For the documentation point of view, since we do not have a per IP TRM,
then it can make sense to know where that IP is documented. But as I
said a comment is enough and will allow a much more relevant level of
details information than a define.
code - as in this patch, comparison against a number isn't
readable.
As example:
+ switch (oh->class->rev) { ## This is auto-generated.
+ case 0: ## But this is our code.
I am recommending this to read as:
+ switch (oh->class->rev) { ## This is auto-generated.
+ case GPIO_REV_2420: ## More readable.
More readable, maybe, but not necessarily relevant nor accurate if the
same IP version is used in another chip or revision.
What IP version is used in a DM816x? GPIO_REV_3430, GPIO_REV_4430?
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
> -Original Message-
> From: Cousson, Benoit
> Sent: Thursday, May 26, 2011 3:41 PM
> To: Premi, Sanjeev
> Cc: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org;
> Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
> linux-arm-ker...@lists.infradead.org; Varadarajan,
> Charulatha; Paul Walmsley
> Subject: Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup
> GPIO and rev_ids
>
> On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
> >> From: linux-omap-ow...@vger.kernel.org
> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> >> DebBarma, Tarun Kanti
> >> Sent: Tuesday, May 24, 2011 7:55 PM
> >>
> >> 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.
> >>
> >> 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
> >
> > [sp] Magic numbers should be avoided.
> > Suggest using something like:
> > #define GPIO_REV_2420 0
> > #define GPIO_REV_2430 1
> > #define GPIO_REV_34XX 2
> > #define GPIO_REV_44xx 3
>
> Well, it is not a magic number, it is a revision id that is
> incremented
> each time there is a difference in the IP.
> The OMAP version -> IP version link is done at hwmod level.
> The driver
> does not have to know it is an OMAP3 or OMAP4. In that case we did
> change the IP version for every revisions, but OMAP5 will use
> the OMAP4
> revision.
> I'm not even considering all the Davinci variants that are not named
> OMAP but do use OMAP IPs... as you already know...
> That can provide a rather confusing information for my point of view.
>
> Whereas a comment like that will give you the exhaustive information.
>
> 0: OMAP2420
> 1: OMAP2430
> 2: OMAP3, DMxxx
> 3: OMAP4, OMAP5, DM816x
>
> That being said, some drivers already did that, so I'm not opposed to
> such change. I just think it is not the best approach.
> At least it gives a pointer to the TRM that contains the IP doc.
[sp] Benoit, your are right from generation perspectove where the
it is easier to increment numbers but when we use comparison
code - as in this patch, comparison against a number isn't
readable.
As example:
+ switch (oh->class->rev) { ## This is auto-generated.
+ case 0: ## But this is our code.
I am recommending this to read as:
+ switch (oh->class->rev) { ## This is auto-generated.
+ case GPIO_REV_2420: ## More readable.
~sanjeev
>
> > We don't have to refer back to this comment while
> reading the code.
> > I also believed that HWMODs were auto generated.
> > Can the changes to structures in this patch recreated
> using current
> > scripts?
>
> Only OMAP4 & 5 are generated today, and in anycase this
> information is
> some custom data added by driver owner. So we just have to
> update that
> information.
> I cannot really use the real HW IP version because it is
> irrelevant most
> of the time. Maybe in the future we will be able to force the
> HW team to
> provide relevant data in that field :-)
>
> Regards,
> Benoit
>
>
> >
> > ~sanjeev
> >
> >>
> >> 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 B
[GIT PULL] omap updates for 2.6.40
Hi Linus, Please pull omap updates for this merge window from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus This contains clean-up to shrink down omap specific code a bit. Also included are some fixes. But basically no new code at this point. Regards, Tony Aaro Koskinen (5): OMAP3+: smartreflex: fix sr_late_init() error path in probe OMAP3+: smartreflex: request the memory region OMAP3+: smartreflex: fix ioremap leak on probe error OMAP3+: smartreflex: delete instance from sr_list on probe error OMAP3+: smartreflex: delete debugfs entries on probe error Felipe Balbi (1): usb: musb: am35x: fix compile error when building am35x Hema HK (3): usb: musb: OMAP4430: Power down the PHY during board init usb: otg: OMAP4430: Fixing the omap4430_phy_init function usb: otg: OMAP4430: Powerdown the internal PHY when USB is disabled Igor Grinberg (2): arm: omap: gpmc-smsc911x: minor style fixes arm: omap2plus: GPIO cleanup Jean Pihet (5): OMAP3 cpuidle: remove useless SDP specific timings OMAP3: clean-up mach specific cpuidle data structures OMAP3: cpuidle: re-organize the C-states data OMAP3: cpuidle: code rework for improved readability OMAP3: cpuidle: change the power domains modes determination logic Mike Rapoport (10): omap: gpmc-smsc911x: always set irq flags to IORESOURCE_IRQ_LOWLEVEL omap: convert boards that use SMSC911x to use gpmc-smsc911x omap: consolidate touch screen initialization among different boards omap: use common initialization for PMIC i2c bus omap: move detection of NAND CS to common-board-devices omap: musb: introduce default board config omap: igep0020: name refactoring for future merge with IGEP3 omap: igep0020: minor refactoring omap: igep0020: add support for IGEP3 omap: drop board-igep0030.c Nishanth Menon (2): OMAP4: PM: remove redundant #ifdef CONFIG_PM OMAP3+: voltage: remove spurious pr_notice for debugfs Sanjeev Premi (1): OMAP3: PM: Boot message is not an error, and not helpful, remove it Tony Lindgren (5): omap: Run make savedefconfig on omap2plus_defconfig to shrink it omap: Remove support for omap2evm Merge branches 'devel-fixes', 'devel-cleanup' and 'devel-genirq' into for-next Merge branch 'for-tony' of master.kernel.org:/.../balbi/usb into omap-for-linus Merge branch 'for_2.6.40/pm-cleanup' of ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus omar ramirez (2): OMAP3/4: l3: fix omap3_l3_probe error path OMAP3/4: l3: minor cleanup for parenthesis and extra spaces arch/arm/configs/omap2plus_defconfig| 83 + arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile|4 +- arch/arm/mach-omap2/board-2430sdp.c | 27 +-- arch/arm/mach-omap2/board-3430sdp.c | 151 ++--- arch/arm/mach-omap2/board-4430sdp.c | 114 ++- arch/arm/mach-omap2/board-am3517crane.c | 10 +- arch/arm/mach-omap2/board-am3517evm.c | 56 +-- arch/arm/mach-omap2/board-apollon.c | 29 +- arch/arm/mach-omap2/board-cm-t35.c | 236 ++-- arch/arm/mach-omap2/board-cm-t3517.c|9 +- arch/arm/mach-omap2/board-devkit8000.c | 131 +-- arch/arm/mach-omap2/board-igep0020.c| 449 +++--- arch/arm/mach-omap2/board-igep0030.c| 458 --- arch/arm/mach-omap2/board-ldp.c | 138 +--- arch/arm/mach-omap2/board-n8x0.c| 28 +- arch/arm/mach-omap2/board-omap3beagle.c | 194 +++--- arch/arm/mach-omap2/board-omap3evm.c| 242 +++-- arch/arm/mach-omap2/board-omap3logic.c | 14 +- arch/arm/mach-omap2/board-omap3pandora.c| 90 + arch/arm/mach-omap2/board-omap3stalker.c| 133 +-- arch/arm/mach-omap2/board-omap3touchbook.c | 121 +-- arch/arm/mach-omap2/board-omap4panda.c | 79 ++--- arch/arm/mach-omap2/board-overo.c | 265 +++--- arch/arm/mach-omap2/board-rm680.c | 21 +- arch/arm/mach-omap2/board-rx51-peripherals.c| 42 +-- arch/arm/mach-omap2/board-rx51-video.c |5 +- arch/arm/mach-omap2/board-rx51.c| 18 +- arch/arm/mach-omap2/board-zoom-debugboard.c | 65 +--- arch/arm/mach-omap2/board-zoom-display.c| 31 +-- arch/arm/mach-omap2/board-zoom-peripherals.c| 29 +-- arch/arm/mach-omap2/common-board-devices.c | 163 arch/arm/mach-omap2/common-board-devices.h | 35 ++ arch/arm/mach-omap2/cpuidle34xx.c | 436 +++-- arch/arm/mach-omap2/gpmc-smc91x.c | 11 +- arch/arm/mach-omap2/gpmc-smsc911x.c
[PATCH] OMAP: clockdomain: Remove redundant call to pwrdm_wait_transition()
The call to pwrdm_wait_transition() in clkdm_clk_enable() is redundant since the function pwrdm_clkdm_state_switch() which is called next also does the same thing. Signed-off-by: Vaibhav Bedia --- arch/arm/mach-omap2/clockdomain.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c index 6cb6c03..4fbbbfc 100644 --- a/arch/arm/mach-omap2/clockdomain.c +++ b/arch/arm/mach-omap2/clockdomain.c @@ -834,7 +834,6 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk) clk->name); arch_clkdm->clkdm_clk_enable(clkdm); - pwrdm_wait_transition(clkdm->pwrdm.ptr); pwrdm_clkdm_state_switch(clkdm); return 0; -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
On 5/26/2011 11:23 AM, Premi, Sanjeev wrote:
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Tuesday, May 24, 2011 7:55 PM
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.
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
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
Well, it is not a magic number, it is a revision id that is incremented
each time there is a difference in the IP.
The OMAP version -> IP version link is done at hwmod level. The driver
does not have to know it is an OMAP3 or OMAP4. In that case we did
change the IP version for every revisions, but OMAP5 will use the OMAP4
revision.
I'm not even considering all the Davinci variants that are not named
OMAP but do use OMAP IPs... as you already know...
That can provide a rather confusing information for my point of view.
Whereas a comment like that will give you the exhaustive information.
0: OMAP2420
1: OMAP2430
2: OMAP3, DMxxx
3: OMAP4, OMAP5, DM816x
That being said, some drivers already did that, so I'm not opposed to
such change. I just think it is not the best approach.
At least it gives a pointer to the TRM that contains the IP doc.
We don't have to refer back to this comment while reading the code.
I also believed that HWMODs were auto generated.
Can the changes to structures in this patch recreated using current
scripts?
Only OMAP4 & 5 are generated today, and in anycase this information is
some custom data added by driver owner. So we just have to update that
information.
I cannot really use the real HW IP version because it is irrelevant most
of the time. Maybe in the future we will be able to force the HW team to
provide relevant data in that field :-)
Regards,
Benoit
~sanjeev
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;
[sp] Where is the description on non-wakeup GPIOs in OMAP3?
Here is text from AM37x TRM:
[quote ...only relevant text]
Each GPIO module provides 32 dedicated general-purpose pins with input
and output capabilities; These pins can be configured for the
following applications:
- Data input (capture)/output (drive)
- Keyboard interface with a debounce cell
- Interrupt generation in
- Wake-up request generation in idle mode
[/quote]
Otherwise, what are the GPIO2_WAKEUPENABLE (0x4905 0020) and
GPIO6_WAKEUPENABLE (0x4905 8020) meant for?
+ default:
+ /* No non-wakeup GPIO pins for other SoCs */
+ break;
+ }
+
~sanjeev
[snip]...[snip]
--
To unsubscribe from this list: send the line "unsubscribe 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
On Thu, May 26, 2011 at 15:28, Premi, Sanjeev wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of >> DebBarma, Tarun Kanti >> Sent: Tuesday, May 24, 2011 7:55 PM >> To: linux-omap@vger.kernel.org >> Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; >> linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha >> Subject: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of >> gpio_bank structure >> >> 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 > > [sp] Should this TODO be part of commit? Probably this could be moved into diff section. <<> -- To unsubscribe from this list: send the line "unsubscribe 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
Kevin,
On Thu, May 26, 2011 at 04:27, Kevin Hilman wrote:
> 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;
>>
RE: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of gpio_bank structure
> -Original Message- > From: Premi, Sanjeev > Sent: Thursday, May 26, 2011 3:29 PM > To: DebBarma, Tarun Kanti; linux-omap@vger.kernel.org > Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha > Subject: RE: [PATCH 05/15] OMAP: GPIO: Make gpio_context part > of gpio_bank structure > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > > DebBarma, Tarun Kanti > > Sent: Tuesday, May 24, 2011 7:55 PM > > To: linux-omap@vger.kernel.org > > Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > > linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha > > Subject: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of > > gpio_bank structure > > > > 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 > > [sp] Should this TODO be part of commit? > BTW, this is the last patch in the series. > Sorry, mistake... This showed up last on my mailbox. ~sanjeev > ~sanjeev > -- To unsubscribe from this list: send the line "unsubscribe 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
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of > DebBarma, Tarun Kanti > Sent: Tuesday, May 24, 2011 7:55 PM > To: linux-omap@vger.kernel.org > Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com; > linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha > Subject: [PATCH 05/15] OMAP: GPIO: Make gpio_context part of > gpio_bank structure > > 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 [sp] Should this TODO be part of commit? BTW, this is the last patch in the series. ~sanjeev -- To unsubscribe from this list: send the line "unsubscribe 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
Kevin,
On Thu, May 26, 2011 at 04:57, Kevin Hilman wrote:
> 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..e
Re: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets in ctxt save/restore
Sanjeev,
On Thu, May 26, 2011 at 15:12, Premi, Sanjeev wrote:
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org
>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>> DebBarma, Tarun Kanti
>> Sent: Tuesday, May 24, 2011 7:55 PM
>> To: linux-omap@vger.kernel.org
>> Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
>> linux-arm-ker...@lists.infradead.org; DebBarma, Tarun Kanti;
>> Varadarajan, Charulatha
>> Subject: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets
>> in ctxt save/restore
>>
>> 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
>> ---
>> arch/arm/mach-omap2/gpio.c | 2 +
>> arch/arm/plat-omap/include/plat/gpio.h | 1 +
>> drivers/gpio/gpio_omap.c | 123
>> ++--
>> 3 files changed, 40 insertions(+), 86 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
>> index 0f8782f..5c888dd 100644
>
> [snip]...[snip]
>> diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
>> index 28390a9..05c2857 100644
>> --- a/drivers/gpio/gpio_omap.c
>> +++ b/drivers/gpio/gpio_omap.c
>> @@ -1395,96 +1395,47 @@ restore_gpio_ctx:
>>
>> void omap_gpio_save_context(struct gpio_bank *bank)
>> {
>
> [sp] The [PATCH 06/15] OMAP4: GPIO: Save/restore context
> seems to be doing exactly opposite:
> It introduces the checks for
> [quote]
> + if (bank->method == METHOD_GPIO_24XX) {
> ...
> ...
> + } else if (bank->method == METHOD_GPIO_44XX) {
> [/quote]
>
> and this patch removes the same checks.
>
> Am I missing something?
Patch 6 introduces the save/restore context code for OMAP4 and this patch
tries to replace all the macro usage with the reg offset values which is nothing
but cleanup.
Based on your comments and Kevin's I understand that I should make cleanups
first and then any fixes/functionality changes to avoid confusions.
Will do that and send a revised series next week.
-V Charulatha
>
> ~sanjeev
>
>
>> - if (bank->method == METHOD_GPIO_24XX) {
>> - bank->context.irqenable1 = __raw_readl(
>> - bank->base +
>> OMAP24XX_GPIO_IRQENABLE1);
>> - bank->context.irqenable2 = __raw_readl(
>> - bank->base +
>> OMAP24XX_GPIO_IRQENABLE2);
>> - bank->context.wake_en = __raw_readl(
>> - bank->base +
>> OMAP24XX_GPIO_WAKE_EN);
>> - bank->context.ctrl = __raw_readl(
>> - bank->base +
>> OMAP24XX_GPIO_CTRL);
>> - bank->context.oe = __raw_readl(
>> - bank->base + OMAP24XX_GPIO_OE);
>> - bank->context.leveldetect0 = __raw_readl(bank->base +
>> - OMAP24XX_GPIO_LEVELDETECT0);
>> - bank->context.leveldetect1 = __raw_readl(bank->base +
>> - OMAP24XX_GPIO_LEVELDETECT1);
>> - bank->context.risingdetect = __raw_readl(bank->base +
>> - OMAP24XX_GPIO_RISINGDETECT);
>> - bank->context.fallingdetect = __raw_readl(bank->base +
>> - OMAP24XX_GPIO_FALLINGDETECT);
>> - bank->context.dataout = __raw_readl(
>> - bank->base +
>> OMAP24XX_GPIO_DATAOUT);
>> - } else if (bank->method == METHOD_GPIO_44XX) {
>> - bank->context.irqenable1 = __raw_readl(
>> - bank->base +
>> OMAP4_GPIO_IRQSTATUSSET0);
>> - bank->context.irqenable2 = __raw_readl(
>> - bank->base +
>> OMAP4_GPIO_IRQSTATUSSET1);
>> - bank->context.wake_en = __raw_readl(
>> - bank->base +
>> OMAP4_GPIO_IRQWAKEN0);
>> - bank->context.ctrl = __raw_readl(
>> - bank->base + OMAP4_GPIO_CTRL);
>> - bank->context.oe = __raw_readl(
>> - bank->base + OMAP24XX_GPIO_OE);
>> - bank->context.leveldetect0 = __raw_readl(bank->base +
>> - OMAP4_GPIO_LEVELDETECT0);
>> - bank->context.leveldetect1 = __raw_readl(bank->base +
>> - OMAP4_GPIO_LEVELDETECT1);
>> - bank->context.risingdetect = __raw_readl(bank->base +
>> - OMAP4_GPIO_RISINGDETECT);
>> - bank->context.fallingdetect = __raw_readl(bank->base +
>> - OMAP4_GPIO_FALLINGDETECT);
>> - bank->context.dataout = __raw_readl(
>> -
[OFF TOPIC] away on business travel
Hi all, I'll be away until 31st of May on a business travel. Don't expect me to look into patches during that period. Thanks :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
Sanjeev,
Thanks for the comments.
On Thu, May 26, 2011 at 14:53, Premi, Sanjeev wrote:
>
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org
>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>> DebBarma, Tarun Kanti
>> Sent: Tuesday, May 24, 2011 7:55 PM
>> To: linux-omap@vger.kernel.org
>> Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
>> linux-arm-ker...@lists.infradead.org; Varadarajan,
>> Charulatha; Cousson, Benoit; Paul Walmsley
>> Subject: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO
>> and rev_ids
>>
>> 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.
>>
>> 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
>
> [sp] Magic numbers should be avoided.
> Suggest using something like:
> #define GPIO_REV_2420 0
> #define GPIO_REV_2430 1
> #define GPIO_REV_34XX 2
> #define GPIO_REV_44xx 3
>
> We don't have to refer back to this comment while reading the code.
Okay.
> I also believed that HWMODs were auto generated.
> Can the changes to structures in this patch recreated using current
> scripts?
Benoit's and Paul's ack is required for this change.
>
> ~sanjeev
>
>>
>> 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;
>
> [sp] Where is the description on non-wakeup GPIOs in OMAP3?
As mentioned in other reply, I am referring to
Table 25-5. GPIO Channel Description at page no 3354
OMAP3430 public TRM Version P. Please correct me if I am wrong.
> Here is text from AM37x TRM:
> [quote ...only relevant text]
> Each GPIO module provides 32 dedicated general-purpose pins with input
> and output capabilities; These pins can be configured for the
> following applications:
> - Data input (capture)/output (drive)
> - Keyboard interface with a debounce cell
> - Interrupt generation in
> - Wake-up request generation in idle mode
> [/quote]
> Otherwise, what are the GPIO2_WAKEUPENABLE (0x4905 0020) and
> GPIO6_WAKEUPENABLE (0x4905 8020) meant for?
>
>> + default:
>> + /* No non-wakeup GPIO pins for other SoCs */
>> + break;
>> + }
>> +
>
> ~sanjeev
>
> [snip]...[snip]
>
--
To unsubscribe from this list: send the line "unsubscribe 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
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, May 24, 2011 7:55 PM
> To: linux-omap@vger.kernel.org
> Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
> linux-arm-ker...@lists.infradead.org; DebBarma, Tarun Kanti;
> Varadarajan, Charulatha
> Subject: [PATCH 11/15] OMAP: GPIO: Remove hardcoded offsets
> in ctxt save/restore
>
> 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
> ---
> arch/arm/mach-omap2/gpio.c |2 +
> arch/arm/plat-omap/include/plat/gpio.h |1 +
> drivers/gpio/gpio_omap.c | 123
> ++--
> 3 files changed, 40 insertions(+), 86 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> index 0f8782f..5c888dd 100644
[snip]...[snip]
> diff --git a/drivers/gpio/gpio_omap.c b/drivers/gpio/gpio_omap.c
> index 28390a9..05c2857 100644
> --- a/drivers/gpio/gpio_omap.c
> +++ b/drivers/gpio/gpio_omap.c
> @@ -1395,96 +1395,47 @@ restore_gpio_ctx:
>
> void omap_gpio_save_context(struct gpio_bank *bank)
> {
[sp] The [PATCH 06/15] OMAP4: GPIO: Save/restore context
seems to be doing exactly opposite:
It introduces the checks for
[quote]
+ if (bank->method == METHOD_GPIO_24XX) {
...
...
+ } else if (bank->method == METHOD_GPIO_44XX) {
[/quote]
and this patch removes the same checks.
Am I missing something?
~sanjeev
> - if (bank->method == METHOD_GPIO_24XX) {
> - bank->context.irqenable1 = __raw_readl(
> - bank->base +
> OMAP24XX_GPIO_IRQENABLE1);
> - bank->context.irqenable2 = __raw_readl(
> - bank->base +
> OMAP24XX_GPIO_IRQENABLE2);
> - bank->context.wake_en = __raw_readl(
> - bank->base +
> OMAP24XX_GPIO_WAKE_EN);
> - bank->context.ctrl = __raw_readl(
> - bank->base +
> OMAP24XX_GPIO_CTRL);
> - bank->context.oe = __raw_readl(
> - bank->base + OMAP24XX_GPIO_OE);
> - bank->context.leveldetect0 = __raw_readl(bank->base +
> - OMAP24XX_GPIO_LEVELDETECT0);
> - bank->context.leveldetect1 = __raw_readl(bank->base +
> - OMAP24XX_GPIO_LEVELDETECT1);
> - bank->context.risingdetect = __raw_readl(bank->base +
> - OMAP24XX_GPIO_RISINGDETECT);
> - bank->context.fallingdetect = __raw_readl(bank->base +
> - OMAP24XX_GPIO_FALLINGDETECT);
> - bank->context.dataout = __raw_readl(
> - bank->base +
> OMAP24XX_GPIO_DATAOUT);
> - } else if (bank->method == METHOD_GPIO_44XX) {
> - bank->context.irqenable1 = __raw_readl(
> - bank->base +
> OMAP4_GPIO_IRQSTATUSSET0);
> - bank->context.irqenable2 = __raw_readl(
> - bank->base +
> OMAP4_GPIO_IRQSTATUSSET1);
> - bank->context.wake_en = __raw_readl(
> - bank->base +
> OMAP4_GPIO_IRQWAKEN0);
> - bank->context.ctrl = __raw_readl(
> - bank->base + OMAP4_GPIO_CTRL);
> - bank->context.oe = __raw_readl(
> - bank->base + OMAP24XX_GPIO_OE);
> - bank->context.leveldetect0 = __raw_readl(bank->base +
> - OMAP4_GPIO_LEVELDETECT0);
> - bank->context.leveldetect1 = __raw_readl(bank->base +
> - OMAP4_GPIO_LEVELDETECT1);
> - bank->context.risingdetect = __raw_readl(bank->base +
> - OMAP4_GPIO_RISINGDETECT);
> - bank->context.fallingdetect = __raw_readl(bank->base +
> - OMAP4_GPIO_FALLINGDETECT);
> - bank->context.dataout = __raw_readl(
> - bank->base +
> OMAP4_GPIO_DATAOUT);
> - }
> + bank->context.irqenable1 =
> + __raw_readl(bank->base + bank->regs->irqenable);
> + bank->context.irqenable2 =
> + __raw_readl(bank->base +
> bank->regs->irqenable2);
> + bank->context.wake_en =
> + __raw_readl(bank->base +
> bank->regs->wkupstatus);
> + bank->context.ctrl = __raw_readl(bank->base + bank->regs->ctrl);
> + bank->context.oe = __raw_readl(bank->base +
> bank->regs->directi
Re: [PATCH 01/15] OMAP: GPIO: Avoid cpu_is checks during module ena/disable
On Thu, May 26, 2011 at 02:49, Kevin Hilman wrote:
> 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.
Is it safe to assume that zero offset is always for revision register only?
IMHO I feel that it is safe to assume an offset of 0x as invalid.
Pls add your thoughts on this.
>
> 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
Re: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
On Thu, May 26, 2011 at 03:04, Kevin Hilman wrote:
> 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?
I am referring to Table 25-5. GPIO Channel Description at page no 3354
OMAP3430 public TRM Version P.
>
> 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.
Okay.
>
> 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.
Okay.
>
> 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
Re: [PATCH 06/15] OMAP4: GPIO: Save/restore context
Kevin, Thanks for the comments on this series. On Thu, May 26, 2011 at 03:13, Kevin Hilman wrote: > 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. Okay. > > 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
On Thu, May 26, 2011 at 04:09, Kevin Hilman wrote: > 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. Okay, will check and do the needful. > > 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
On Thu, May 26, 2011 at 04:31, Kevin Hilman wrote: > 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. okay. > > 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
On Thu, May 26, 2011 at 04:44, Kevin Hilman wrote:
> 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.
Okay.
>
> Subject: GPIO: OMAP: IRQ triggering: use wake set/clear regs
Okay.
>
>> 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.
Okay.
>
> 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 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO and rev_ids
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> DebBarma, Tarun Kanti
> Sent: Tuesday, May 24, 2011 7:55 PM
> To: linux-omap@vger.kernel.org
> Cc: Hilman, Kevin; Shilimkar, Santosh; t...@atomide.com;
> linux-arm-ker...@lists.infradead.org; Varadarajan,
> Charulatha; Cousson, Benoit; Paul Walmsley
> Subject: [PATCH 02/15] OMAP2PLUS: GPIO: Fix non-wakeup GPIO
> and rev_ids
>
> 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.
>
> 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
[sp] Magic numbers should be avoided.
Suggest using something like:
#define GPIO_REV_2420 0
#define GPIO_REV_2430 1
#define GPIO_REV_34XX 2
#define GPIO_REV_44xx 3
We don't have to refer back to this comment while reading the code.
I also believed that HWMODs were auto generated.
Can the changes to structures in this patch recreated using current
scripts?
~sanjeev
>
> 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;
[sp] Where is the description on non-wakeup GPIOs in OMAP3?
Here is text from AM37x TRM:
[quote ...only relevant text]
Each GPIO module provides 32 dedicated general-purpose pins with input
and output capabilities; These pins can be configured for the
following applications:
- Data input (capture)/output (drive)
- Keyboard interface with a debounce cell
- Interrupt generation in
- Wake-up request generation in idle mode
[/quote]
Otherwise, what are the GPIO2_WAKEUPENABLE (0x4905 0020) and
GPIO6_WAKEUPENABLE (0x4905 8020) meant for?
> + default:
> + /* No non-wakeup GPIO pins for other SoCs */
> + break;
> + }
> +
~sanjeev
[snip]...[snip]
--
To unsubscribe from this list: send the line "unsubscribe 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 7/9] OMAP4: powerdomain: Update MPU powerdomain for 4460
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, May 26, 2011 7:27 AM
> To: linux-omap
> Cc: Nayak, Rajendra
> Subject: [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.
>
[snip]...[snip]
> +static struct powerdomain mpu_446x_pwrdm = {
> + .name = "mpu_pwrdm",
> + .prcm_offs= OMAP4430_PRM_MPU_INST,
> + .prcm_partition = OMAP4430_PRM_PARTITION,
> + .omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP4460),
[sp] This change doesn't go with the description above.
Shouldn't this be CHIP_IS_OMAP44XX or CHIP_IS_OMAP446X
to be more future safe?
~sanjeev
--
To unsubscribe from this list: send the line "unsubscribe 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 8/9] OMAP4: clockdomain: Use CHIP_IS_44XX to reuse all CD's on 4460
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth > Sent: Thursday, May 26, 2011 7:27 AM > To: linux-omap > Cc: Nayak, Rajendra > Subject: [RFC][PATCH 8/9] OMAP4: clockdomain: Use > CHIP_IS_44XX to reuse all CD's on 4460 [sp] Is CD as standard nomenclature? In any case "CD's" is different from "CDs". ~sanjeev > > 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. [snip]...[snip] -- To unsubscribe from this list: send the line "unsubscribe 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 4/9] OMAP4: clocks: distinguish 4430 and 4460
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, May 26, 2011 7:27 AM
> To: linux-omap
> Cc: Nayak, Rajendra
> Subject: [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.
[sp] Since you are changing it, it should read:
Copyright (C) 2009-2011 Texas Instruments Incorporated
> * Copyright (C) 2009-2010 Nokia Corporation
> *
> * Paul Walmsley (p...@pwsan.com)
> @@ -127,42 +127,42 @@ static struct clk virt_3840_ck = {
> };
>
[snip]...[snip]
>
> int __init omap4xxx_clk_init(void)
> {
> struct omap_clk *c;
> - u32 cpu_clkflg;
> + u32 cpu_clkflg = 0;
>
> - if (cpu_is_omap44xx()) {
> + if (cpu_is_omap443x()) {
> cpu_mask = RATE_IN_4430;
> cpu_clkflg = CK_443X;
> + } else if (cpu_is_omap446x()) {
> + cpu_mask = RATE_IN_4460;
> + cpu_clkflg = CK_446X;
> }
>
> clk_init(&omap2_clk_functions);
> diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h
> b/arch/arm/plat-omap/include/plat/clkdev_omap.h
> index f1899a3..324446b 100644
> --- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
> +++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
> @@ -39,11 +39,13 @@ struct omap_clk {
> #define CK_36XX (1 << 10) /*
> 36xx/37xx-specific clocks */
> #define CK_443X (1 << 11)
> #define CK_TI816X(1 << 12)
> +#define CK_446X (1 << 13)
>
>
> #define CK_34XX (CK_3430ES1 | CK_3430ES2PLUS)
> #define CK_AM35XX(CK_3505 | CK_3517) /* all Sitara AM35xx */
> #define CK_3XXX (CK_34XX | CK_AM35XX | CK_36XX)
> +#define CK_44XX (CK_443X | CK_446X)
>
[sp] Unrelated to this change, but extra whitespacing can be corrected.
>
> #endif
> diff --git a/arch/arm/plat-omap/include/plat/clock.h
> b/arch/arm/plat-omap/include/plat/clock.h
> index 006e599..21b1beb 100644
> --- a/arch/arm/plat-omap/include/plat/clock.h
> +++ b/arch/arm/plat-omap/include/plat/clock.h
> @@ -58,10 +58,12 @@ struct clkops {
> #define RATE_IN_36XX (1 << 4)
> #define RATE_IN_4430 (1 << 5)
> #define RATE_IN_TI816X (1 << 6)
> +#define RATE_IN_4460 (1 << 7)
>
> #define RATE_IN_24XX (RATE_IN_242X | RATE_IN_243X)
> #define RATE_IN_34XX (RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
> #define RATE_IN_3XXX (RATE_IN_34XX | RATE_IN_36XX)
> +#define RATE_IN_44XX (RATE_IN_4430 | RATE_IN_4460)
>
> /* RATE_IN_3430ES2PLUS_36XX includes 34xx/35xx with ES >=2,
> and all 36xx/37xx */
> #define RATE_IN_3430ES2PLUS_36XX (RATE_IN_3430ES2PLUS |
> RATE_IN_36XX)
> --
> 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
> --
To unsubscribe from this list: send the line "unsubscribe 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 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, May 26, 2011 7:27 AM
> To: linux-omap
> Cc: Sonasath, Moiz; Menon, Nishanth
> Subject: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1
> during HWMOD init
[sp] typo in the subject. "DO" -> "Do"
Another nit: Are 2 HWMODs required in the subject?
~sanjeev
>
> 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=52ae
> 4f0de03b17c064d9ce90a580230f1a596ec1
>
> [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
> --
To unsubscribe from this list: send the line "unsubscribe 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 1/9] OMAP: ID: introduce chip detection for OMAP4460
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, May 26, 2011 7:27 AM
> To: linux-omap
> Cc: V, Aneesh; Menon, Nishanth
> Subject: [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?c
> ontentId=53243&navigationId=12843&templateId=6123
> Public TRM is available here as usual:
> http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?t
> emplateId=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;
[sp] Why is this change required?
> u8 rev;
>
~sanjeev
[snip]...[snip]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
