[PATCH] OMAP: L3 interconnect: Error reporting cleanups

[Todd Poynor]

* Make variables static.

* Define L3 TARG instance offsets, and read/write STDERRLOG registers
  relative to those offsets, rather than defining STDERRLOG_MAIN
  instance offsets and accessing other registers via offsets from
  that register.

* Use ffs() to find error source from the L3_FLAGMUX_REGERRn
  register.

* Remove extra l3_base[] entry.

* Modify L3 custom error message for consistency with standard
  error message.

Signed-off-by: Todd Poynor 
---

V2 updated for feedback from Santosh (thanks!).

 arch/arm/mach-omap2/omap_l3_noc.c |   38 +-
 arch/arm/mach-omap2/omap_l3_noc.h |   82 ++--
 2 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_l3_noc.c 
b/arch/arm/mach-omap2/omap_l3_noc.c
index 7b9f190..3593279 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.c
+++ b/arch/arm/mach-omap2/omap_l3_noc.c
@@ -29,6 +29,7 @@
 
 #include "omap_l3_noc.h"
 
+
 /*
  * Interrupt Handler for L3 error detection.
  * 1) Identify the L3 clockdomain partition to which the error belongs to.
@@ -56,10 +57,10 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
 {
 
struct omap4_l3 *l3 = _l3;
-   int inttype, i, j;
+   int inttype, i;
int err_src = 0;
-   u32 std_err_main_addr, std_err_main, err_reg;
-   u32 base, slave_addr, clear;
+   u32 l3_targ_base, std_err_main, err_reg;
+   u32 base, clear;
char *source_name;
 
/* Get the Type of interrupt */
@@ -76,37 +77,36 @@ static irqreturn_t l3_interrupt_handler(int irq, void *_l3)
/* Get the corresponding error and analyse */
if (err_reg) {
/* Identify the source from control status register */
-   for (j = 0; !(err_reg & (1 << j)); j++)
-   ;
-
-   err_src = j;
+   err_src = __ffs(err_reg);
/* Read the stderrlog_main_source from clk domain */
-   std_err_main_addr = base + *(l3_targ[i] + err_src);
-   std_err_main = readl(std_err_main_addr);
+   l3_targ_base = base + (*(l3_targ[i] + err_src));
+   std_err_main =  readl(l3_targ_base +
+ L3_TARG_STDERRLOG_MAIN);
 
switch (std_err_main & CUSTOM_ERROR) {
case STANDARD_ERROR:
source_name =
-   l3_targ_stderrlog_main_name[i][err_src];
-
-   slave_addr = std_err_main_addr +
-   L3_SLAVE_ADDRESS_OFFSET;
+   l3_targ_inst_name[i][err_src];
WARN(true, "L3 standard error: SOURCE:%s at 
address 0x%x\n",
-   source_name, readl(slave_addr));
+source_name,
+readl(l3_targ_base +
+  L3_TARG_STDERRLOG_SLVOFSLSB));
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
-   writel(clear, std_err_main_addr);
+   writel(clear, l3_targ_base +
+  L3_TARG_STDERRLOG_MAIN);
break;
 
case CUSTOM_ERROR:
source_name =
-   l3_targ_stderrlog_main_name[i][err_src];
+   l3_targ_inst_name[i][err_src];
 
-   WARN(true, "CUSTOM SRESP error with 
SOURCE:%s\n",
-   source_name);
+   WARN(true, "L3 custom error: SOURCE:%s\n",
+source_name);
/* clear the std error log*/
clear = std_err_main | CLEAR_STDERR_LOG;
-   writel(clear, std_err_main_addr);
+   writel(clear, l3_targ_base +
+  L3_TARG_STDERRLOG_MAIN);
break;
 
default:
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h 
b/arch/arm/mach-omap2/omap_l3_noc.h
index 359b833..b553fa7 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -23,63 +23,63 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
 #define __ARCH_ARM_MACH_OMAP2_L3_INTERCONNECT_3XXX_H
 
-/*
- * L3 register offsets
- */
 #define L3_MODULES 3
 #define CLEAR_STDERR_LOG   (1 << 31)
 #define CUSTOM_ERROR   0x2
 #define STANDAR

[PATCH pm_wip/voltdm_nm] OMAP: VP: Explicitly mask VPVOLTAGE field

[Todd Poynor]

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 symbol
already defined, added as a new field in struct omap_vp_common.

Signed-off-by: Todd Poynor 
---

V2 based on Kevin's feedback (thanks!):

* Drop the shift field, use __ffs().
* Updated subject prefix.

 arch/arm/mach-omap2/vp.c  |3 ++-
 arch/arm/mach-omap2/vp.h  |2 ++
 arch/arm/mach-omap2/vp3xxx_data.c |2 ++
 arch/arm/mach-omap2/vp44xx_data.c |1 +
 4 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index e7d38f6..3807620 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)
+   >> __ffs(vp->common->vpvoltage_mask);
 
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..f78752b 100644
--- a/arch/arm/mach-omap2/vp.h
+++ b/arch/arm/mach-omap2/vp.h
@@ -63,6 +63,7 @@ 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
  */
 struct omap_vp_common {
u32 vpconfig_erroroffset_mask;
@@ -79,6 +80,7 @@ struct omap_vp_common {
u8 vlimitto_vddmin_shift;
u8 vlimitto_vddmax_shift;
u8 vlimitto_timeout_shift;
+   u8 vpvoltage_mask;
 
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..260c554 100644
--- a/arch/arm/mach-omap2/vp3xxx_data.c
+++ b/arch/arm/mach-omap2/vp3xxx_data.c
@@ -51,6 +51,8 @@ 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,
+
.ops = &omap3_vp_ops,
 };
 
diff --git a/arch/arm/mach-omap2/vp44xx_data.c 
b/arch/arm/mach-omap2/vp44xx_data.c
index 0daf2a4..b4e7704 100644
--- a/arch/arm/mach-omap2/vp44xx_data.c
+++ b/arch/arm/mach-omap2/vp44xx_data.c
@@ -51,6 +51,7 @@ 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,
.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

Re: [PATCH] OMAP: don't trace functions called from sched_clock

[Kevin Hilman]

Kevin Hilman  writes:

> Rabin Vincent  writes:
>
>> omap_readl() is used from the sched_clock() implementations and so must
>> be marked notrace to avoid recursion in ftrace.  Same thing with
>> mpu_read() for OMAP1.
>>
>> Signed-off-by: Rabin Vincent 
>
> Acked-by: Kevin Hilman 

I also meant to suggest this should probably queue for .40-rc series.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules

[Kevin Hilman]

Jean Pihet  writes:

> On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman  wrote:
>> 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.
> This is much cleaner! We need this pushed upstream.

OK, thanks.  I just sent it to linux-pm.

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] PM: export suspend_set_ops, suspend_valid_only_mem

[Kevin Hilman]

Some platforms wish to implement their PM core suspend code as
modules.  To do so, these functions need to be exported to modules.

Reported-by: Jean Pihet 
Signed-off-by: Kevin Hilman 
---
Applies against v2.6.39

 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 pm_wip/voltdm_nm] ARM: OMAP: Explicitly mask VPVOLTAGE field

[Kevin Hilman]

Hi Todd,

Todd Poynor  writes:

> 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 

Thanks for the patch.  Indeed it's better to make this explict.

Minor nit: we don't need both the mask and the shift defined.  Just add
the mask, and the code can use __ffs(mask) to get the shift value.  This
is what I've done in the rest of the VC/VP code.

Also, can you make the subject prefix 'OMAP: VP: ...' 

Thanks,

Kevin

> ---
>  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,
>  };
--
To unsubscribe from this list: send the line "unsubscribe 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

[Kevin Hilman]

"Turquette, Mike"  writes:

> On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar
>  wrote:
>> 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.
>
> Santosh is referring to this code in our cpufreq driver:
>
> /*
>  * On OMAP SMP configuartion, both processors share the voltage
>  * and clock. So both CPUs needs to be scaled together and hence
>  * needs software co-ordination. Use cpufreq affected_cpus
>  * interface to handle this scenario. Additional is_smp() check
>  * is to keep SMP_ON_UP build working.
>  */
> if (is_smp()) {
> policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
> cpumask_or(cpumask, cpumask_of(policy->cpu), cpumask);
> cpumask_copy(policy->cpus, cpumask);
> }
>
> policy->cpus knows about each CPU now (in fact, due to this you will
> see /sys/devices/system/cpu/cpu1/cpufreq is in fact a symlink to its
> cpu0 sibling!)
>
> This is pretty good in fact, since governors like ondemand take into
> consideration *all* of the CPUs in policy->cpus:
>
> /* Get Absolute Load - in terms of freq */
> max_load_freq = 0; <- tracks greatest need across all CPUs
>
> for_each_cpu(j, policy->cpus) {
> ... find max_load_freq ...
>
> Ultimate effect is that we run a single workqueue only on CPU0
> (kondemand or whatever) that takes the load characteristics of both
> CPU0 and CPU1 into account.

OK, makes sense.  Thanks for the description.

All of this came up because this series is going through contortions to
make two CPUfreq registrations only using one freq_table, protect
against concurrent access from different CPUs etc.,  which led me to
wonder why we need two registrations.

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

boot hang using OMAP for-next + Russell's for-linus

[Kevin Hilman]

FYI... I just found this, but won't be able to look into it until next
week, so if anyone needs a weekend debug project...

Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+
busybox initramfs) kernel on my 3430/n900 just fine.   I then tried to
merge in Russell's for-linus branch and it hangs during boot.

It appears to hang in the init/registration of i2c busses.  Commenting
out the i2c bus registration from board-rx51-peripherals and disabling a
few of the users of i2c, I was able to boot.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings

[Kevin Hilman]

Tony Lindgren  writes:

> * Russell King - ARM Linux  [110526 16:51]:
>> 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.
>
> OK thanks. Kevin, can you queue this fix? Assuming the move of omap
> gpio to drivers/gpio happens this merge window, this needs to be
> updated for the path.

Yeah, I'll take care of this.

GPIO move is now merged for 2.6.40, so I'll queue this as a fix for
the first -rc cycle.

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] OMAP: don't trace functions called from sched_clock

[Kevin Hilman]

Rabin Vincent  writes:

> omap_readl() is used from the sched_clock() implementations and so must
> be marked notrace to avoid recursion in ftrace.  Same thing with
> mpu_read() for OMAP1.
>
> Signed-off-by: Rabin Vincent 

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 2/2] GPIO: OMAP: move to drivers/gpio

[Grant Likely]

On Fri, May 27, 2011 at 09:04:37AM -0700, Kevin Hilman wrote:
> Kevin Hilman  writes:
> 
> [...]
> 
> >
> > OK, I rebased onto RMK's for-linus branch (already pulled by Linus),
> > which contained some other changes touching gpio.c.I also s/_/-/ in
> > the filename.
> >
> > Below is pull request.
> 
> BTW, apologies for the ssh URL.  I used it because I just pushed it, and
> wanted to be sure you didn't have to wait for the mirrors.
> 
> Kevin

Merged, thanks.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

[Kevin Hilman]

"Cousson, Benoit"  writes:

[...]

> In general we do not want to reset nor idle an IP that was potentially
> already properly configured by bootloader or early Linux boot code.

Actually, the opposite is true.

The kernel should not make any assumptions about what the bootloader has
or has not done.  We need to have a kernel that can boot from any
bootloader (or none, like using kexec) and be able to start from a known
hardware state.

Any use of HWMOD_INIT_NO_IDLE, HWMOD_INIT_NO_RESET should be a rare
exception and well documented.

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: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

[Kevin Hilman]

"Cousson, Benoit"  writes:

> Hi Kevin,
>
> On 5/27/2011 4:59 PM, Hilman, Kevin wrote:
>> Govindraj  writes:
>
> [...]
>
>>> uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
>>>
>>
>> This is a hack (written by me) because the UART driver is not runtime PM
>> adapted.  When UART driver is runtime PM adapted, this will not be
>> needed.
>
> The UART can support reset and idle? There is no assumption for the
> UART used during the early debug phase?

No.  As long as the UART driver is doing runtime PM properly, there are
no assumptions required.

Kevin

> Don't we have to maintain its state?
> It will be indeed better if we don't have to.
>
> 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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Tomi Valkeinen]

On Fri, 2011-05-27 at 16:43 +0200, Cousson, Benoit wrote:
> On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:
> > On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:
> >> Hi Tomi,
> >>
> >> On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:
> >>> Add omap_device_reset() function which can be used to reset the hwmods
> >>> associated with the given platform device.
> >>
> >> We've never exposed it because we are trying to avoid that any driver
> >> play with asynchronous HW reset. That can lead to undefined HW behavior :-(
> >>
> >> Do you have some strong need for that?
> >
> > DSS driver has been designed so that it resets the HW before it begins
> > programming it. That way we get the HW into known state. Otherwise we
> > need to be extra careful to program all possible registers to a sane
> > value. Not impossible, of course, but requires extra work.
> >
> > I noticed the problem with DSI driver, it didn't work anymore if I
> > didn't reset it.
> >
> > Why does it lead to undefined HW behaviour? Isn't it much better to
> > reset the HW before starting to use it to be 100% sure it's in known and
> > valid state?
> 
> In theory, but since your are resetting only the DSS IP, it can leads to 
> side effect at SoC level. Especially wrt to clock management.

Out of interest, can you tell more what problems it could cause? Can
they be solved in the hwmod reset code?

Also one thing to note, VENC needs a softreset after changing certain
configurations, as per TRM. However, VENC doesn't use the standard
syscontrol mechanism, so that cannot be done via omap_device interface
anyway.

> > Especially in error situations it may be difficult (even impossible) to
> > recover without reset. DISPC has been known to froze in some sync lost
> > situations, and, if I recall right, if DSI transfer is aborted the only
> > way to recover is to reset the DSI block (on OMAP3).
> 
> In case of recovery error it makes sense. What we did with hardreset is 
> to re-assert the reset upon disable of the module and then the next 
> enable will de-assert it. Softreset does not do that today.
> 
> My only concern is that people might start abusing that kind of API to 
> use that for funtionnal purpose instead of error recovery.

Why do you see it's abusing? I think it's a good driver design to reset
the HW before starting operation. Perhaps it's true that in some cases
reset could hide (or fix, in a way) a bug in the driver, but in the end
what we want is a driver that works in every situation. And doing a HW
reset sounds a good way to make the driver more robust.

> This other issue is that it will add another OMAP specific IP to the driver.

I presume IP == API. And that is true. But isn't reset functionality
present in most HW blocks, and thus would it make a good addition to the
generic API?

 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 2/2] GPIO: OMAP: move to drivers/gpio

[Kevin Hilman]

Kevin Hilman  writes:

[...]

>
> OK, I rebased onto RMK's for-linus branch (already pulled by Linus),
> which contained some other changes touching gpio.c.I also s/_/-/ in
> the filename.
>
> Below is pull request.

BTW, apologies for the ssh URL.  I used it because I just pushed it, and
wanted to be sure you didn't have to wait for the mirrors.

Kevin

> The following changes since commit 9a55d9752d8abfc62f1ab05ccc790d22a0c8e7c0:
>
>   Merge branch 'devel-stable' into for-linus (2011-05-23 19:28:04 +0100)
>
> are available in the git repository at:
>
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
> for_2.6.40/gpio-move
>
> Kevin Hilman (2):
>   GPIO: OMAP: move register offset defines into 
>   GPIO: OMAP: move to drivers/gpio
>
>  arch/arm/plat-omap/Makefile|2 +-
>  arch/arm/plat-omap/include/plat/gpio.h |  103 +++
>  drivers/gpio/Makefile  |1 +
>  .../plat-omap/gpio.c => drivers/gpio/gpio-omap.c   |  105 
> 
>  4 files changed, 105 insertions(+), 106 deletions(-)
>  rename arch/arm/plat-omap/gpio.c => drivers/gpio/gpio-omap.c (93%)
--
To unsubscribe from this list: send the line "unsubscribe 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 1/4] OMAP3: PM debug: remove sleep_while_idle feature

[Jean Pihet]

On Fri, May 27, 2011 at 5:26 PM, Kevin Hilman  wrote:
> Jean Pihet  writes:
>
>> On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman  wrote:
>>> 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'.
>> 'nohlt' is only for the default arch idle handler (pm_idle). It does
>> not apply to the cpuidle handler (omap3_enter_idle) which depends on
>> CONFIG_CPU_IDLE.
>
> AFAICT, it affects CPUidle also, since CPUidle replaces pm_idle, which
> is protected by the hlt_counter check.
That is correct, please ignore my comment.

> I think the CPUidle folks are looking for a way to replace using
> pm_idle though.  After that happens, there are a couple options.  1) add
> a check for hlt_counter in the CPUidle path, or 2) just disable CPUidle
> at Kconfig level.
1) makes sense if the kernel parameter is used to enable/disable idle.

>
>>> If runtime configuration of this is needed, then adding a debugfs
>>> entry for the ARM-generic hlt/nohlt interface should be added.
>> Is there a need for it?
>
> I don't think so.    But my point was that if anyone wants this feature
> back, this would be the way to add it.
>
> Kevin
>
>

Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/14] GPIO: OMAP: first round of cleanup

[Kevin Hilman]

Hi Grant,

Grant Likely  writes:

> 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.
>

Being very late in the cycle, I'd prefer to save this for 2.6.41.  Let's
just do the move for 2.6.40, and I'll (re)submit this early in the
2.6.41 cycle.  

Thanks,

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

[Kevin Hilman]

Grant Likely  writes:

> On Fri, May 27, 2011 at 1:35 AM, Grant Likely  
> wrote:
>> On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote:
>>> Move OMAP GPIO driver to drivers/gpio.  Builds whenever
>>> CONFIG_ARCH_OMAP=y.
>>>
>>> Signed-off-by: Kevin Hilman 
>>
>> Patch unfortunately doesn't apply cleanly to Linus' tree.  There's
>> been some changes to gpio.c compared to the tree this patch was
>> prepared against.
>>
>> Also, if you use the -M flag when preparing the patch, then I'll be
>> able to see what the changes are during the move, and fix things up
>> intelligently if anything breaks.
>>
>> Can you respin and repost the series quickly?
>
> While you're at it, can you name the moved file
> drivers/gpio/gpio-omap.c?  ('-' instead of '_'.  Why, yes, I am a
> nitpicker.)

OK, I rebased onto RMK's for-linus branch (already pulled by Linus),
which contained some other changes touching gpio.c.I also s/_/-/ in
the filename.

Below is pull request.

Thanks,

Kevin


The following changes since commit 9a55d9752d8abfc62f1ab05ccc790d22a0c8e7c0:

  Merge branch 'devel-stable' into for-linus (2011-05-23 19:28:04 +0100)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
for_2.6.40/gpio-move

Kevin Hilman (2):
  GPIO: OMAP: move register offset defines into 
  GPIO: OMAP: move to drivers/gpio

 arch/arm/plat-omap/Makefile|2 +-
 arch/arm/plat-omap/include/plat/gpio.h |  103 +++
 drivers/gpio/Makefile  |1 +
 .../plat-omap/gpio.c => drivers/gpio/gpio-omap.c   |  105 
 4 files changed, 105 insertions(+), 106 deletions(-)
 rename arch/arm/plat-omap/gpio.c => drivers/gpio/gpio-omap.c (93%)


--
To unsubscribe from this list: send the line "unsubscribe 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] OMAP: don't trace functions called from sched_clock

[Rabin Vincent]

Tony,

On Sun, May 8, 2011 at 14:51, Rabin Vincent  wrote:
> omap_readl() is used from the sched_clock() implementations and so must
> be marked notrace to avoid recursion in ftrace.  Same thing with
> mpu_read() for OMAP1.
>
> Signed-off-by: Rabin Vincent 

Comments on this patch?  This is a bugfix; the function graph tracer
will crash and burn on OMAP without this.

> ---
>  arch/arm/mach-omap1/io.c   |    2 +-
>  arch/arm/mach-omap1/time.c |    2 +-
>  arch/arm/mach-omap2/io.c   |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
> index 870886a..36ec2d7 100644
> --- a/arch/arm/mach-omap1/io.c
> +++ b/arch/arm/mach-omap1/io.c
> @@ -158,7 +158,7 @@ u16 omap_readw(u32 pa)
>  }
>  EXPORT_SYMBOL(omap_readw);
>
> -u32 omap_readl(u32 pa)
> +u32 notrace omap_readl(u32 pa)
>  {
>        return __raw_readl(OMAP1_IO_ADDRESS(pa));
>  }
> diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
> index 6885d2f..88c5c5e 100644
> --- a/arch/arm/mach-omap1/time.c
> +++ b/arch/arm/mach-omap1/time.c
> @@ -203,7 +203,7 @@ static struct irqaction omap_mpu_timer2_irq = {
>        .handler        = omap_mpu_timer2_interrupt,
>  };
>
> -static cycle_t mpu_read(struct clocksource *cs)
> +static cycle_t notrace mpu_read(struct clocksource *cs)
>  {
>        return ~omap_mpu_timer_read(1);
>  }
> diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> index 441e79d..f1987b1 100644
> --- a/arch/arm/mach-omap2/io.c
> +++ b/arch/arm/mach-omap2/io.c
> @@ -441,7 +441,7 @@ u16 omap_readw(u32 pa)
>  }
>  EXPORT_SYMBOL(omap_readw);
>
> -u32 omap_readl(u32 pa)
> +u32 notrace omap_readl(u32 pa)
>  {
>        return __raw_readl(OMAP2_L4_IO_ADDRESS(pa));
>  }
> --
> 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: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq

[Turquette, Mike]

On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar
 wrote:
> 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.

Santosh is referring to this code in our cpufreq driver:

/*
 * On OMAP SMP configuartion, both processors share the voltage
 * and clock. So both CPUs needs to be scaled together and hence
 * needs software co-ordination. Use cpufreq affected_cpus
 * interface to handle this scenario. Additional is_smp() check
 * is to keep SMP_ON_UP build working.
 */
if (is_smp()) {
policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
cpumask_or(cpumask, cpumask_of(policy->cpu), cpumask);
cpumask_copy(policy->cpus, cpumask);
}

policy->cpus knows about each CPU now (in fact, due to this you will
see /sys/devices/system/cpu/cpu1/cpufreq is in fact a symlink to its
cpu0 sibling!)

This is pretty good in fact, since governors like ondemand take into
consideration *all* of the CPUs in policy->cpus:

/* Get Absolute Load - in terms of freq */
max_load_freq = 0; <- tracks greatest need across all CPUs

for_each_cpu(j, policy->cpus) {
... find max_load_freq ...

Ultimate effect is that we run a single workqueue only on CPU0
(kondemand or whatever) that takes the load characteristics of both
CPU0 and CPU1 into account.

Regards,
Mike


> 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
>
--
To unsubscribe from this list: send the line "unsubscribe 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 1/4] OMAP3: PM debug: remove sleep_while_idle feature

[Kevin Hilman]

Jean Pihet  writes:

> On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman  wrote:
>> 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'.
> 'nohlt' is only for the default arch idle handler (pm_idle). It does
> not apply to the cpuidle handler (omap3_enter_idle) which depends on
> CONFIG_CPU_IDLE.

AFAICT, it affects CPUidle also, since CPUidle replaces pm_idle, which
is protected by the hlt_counter check.

I think the CPUidle folks are looking for a way to replace using
pm_idle though.  After that happens, there are a couple options.  1) add
a check for hlt_counter in the CPUidle path, or 2) just disable CPUidle
at Kconfig level.

>> If runtime configuration of this is needed, then adding a debugfs
>> entry for the ARM-generic hlt/nohlt interface should be added.
> Is there a need for it?

I don't think so.But my point was that if anyone wants this feature
back, this would be the way to add it.

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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Santosh Shilimkar]

On 5/27/2011 8:30 PM, Cousson, Benoit wrote:

On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote:

On 5/27/2011 8:13 PM, Cousson, Benoit wrote:

On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:

Hi Tomi,

On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:

Add omap_device_reset() function which can be used to reset the
hwmods
associated with the given platform device.


We've never exposed it because we are trying to avoid that any driver
play with asynchronous HW reset. That can lead to undefined HW
behavior :-(

Do you have some strong need for that?


DSS driver has been designed so that it resets the HW before it begins
programming it. That way we get the HW into known state. Otherwise we
need to be extra careful to program all possible registers to a sane
value. Not impossible, of course, but requires extra work.

I noticed the problem with DSI driver, it didn't work anymore if I
didn't reset it.

Why does it lead to undefined HW behaviour? Isn't it much better to
reset the HW before starting to use it to be 100% sure it's in known
and
valid state?


In theory, but since your are resetting only the DSS IP, it can leads to
side effect at SoC level. Especially wrt to clock management.


Especially in error situations it may be difficult (even impossible) to
recover without reset. DISPC has been known to froze in some sync lost
situations, and, if I recall right, if DSI transfer is aborted the only
way to recover is to reset the DSI block (on OMAP3).


In case of recovery error it makes sense. What we did with hardreset is
to re-assert the reset upon disable of the module and then the next
enable will de-assert it. Softreset does not do that today.


I didn't notice this patch but Paul reported an issue on beagle
which was making L3 error handling driver hang.

Later on after debugging we noticed, that DSS initiator
was throwing timeout error.

As a temporary fix, we removed the timeout error from
the handler since root-cause was not known. [1]

I am not sure but may be a proper DSS reset might fix
that issue as well.


Yeah, but this is the issue... people will start abusing that to fix any
kind of problems instead of finding the root cause.


May be you are right. But shouldn't we do a proper reset of the IP.
On this same topic, I have a patch for timer IP too. As per
TRM, soft reset is not enough to properly reset the timer IP
and expecting the additional register to be used for
reseting the timer IP.


That should be use only to fix real HW issue that cannot be solve
properly by SW.


I agree but TRM doesn't say the softreset is enough to ensure
the certain IP's are properly reseted.

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: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

[Cousson, Benoit]

Hi Kevin,

On 5/27/2011 4:59 PM, Hilman, Kevin wrote:

Govindraj  writes:


[...]


uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;



This is a hack (written by me) because the UART driver is not runtime PM
adapted.  When UART driver is runtime PM adapted, this will not be
needed.


The UART can support reset and idle? There is no assumption for the UART 
used during the early debug phase?

Don't we have to maintain its state?
It will be indeed better if we don't have to.

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/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups

[Kevin Hilman]

Jean Pihet  writes:

> On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman  wrote:
>> 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.
> Indeed this code is a spaghetti mess and makes pm-debug difficult to
> be modularized.
>
>> 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.
>
> Agree. However we still need the equivalent of [1] to retrieve the
> PRCM registers just before and after the WFI instructions.

Correct, but as that patch is not upstream, I'm not considering it 
as support that needs to be maintained.

> I would like to propose some replacement when the current code
> clean-up is settled down a bit.

Great!  

Kevin

> [1] 
> http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=5dd36389eb6ef4837a2aad128e4bd0226468c171
>
> Regards,
> Jean
>
>> 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
>>
--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Cousson, Benoit]

On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote:

On 5/27/2011 8:13 PM, Cousson, Benoit wrote:

On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:

Hi Tomi,

On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:

Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.


We've never exposed it because we are trying to avoid that any driver
play with asynchronous HW reset. That can lead to undefined HW
behavior :-(

Do you have some strong need for that?


DSS driver has been designed so that it resets the HW before it begins
programming it. That way we get the HW into known state. Otherwise we
need to be extra careful to program all possible registers to a sane
value. Not impossible, of course, but requires extra work.

I noticed the problem with DSI driver, it didn't work anymore if I
didn't reset it.

Why does it lead to undefined HW behaviour? Isn't it much better to
reset the HW before starting to use it to be 100% sure it's in known and
valid state?


In theory, but since your are resetting only the DSS IP, it can leads to
side effect at SoC level. Especially wrt to clock management.


Especially in error situations it may be difficult (even impossible) to
recover without reset. DISPC has been known to froze in some sync lost
situations, and, if I recall right, if DSI transfer is aborted the only
way to recover is to reset the DSI block (on OMAP3).


In case of recovery error it makes sense. What we did with hardreset is
to re-assert the reset upon disable of the module and then the next
enable will de-assert it. Softreset does not do that today.


I didn't notice this patch but Paul reported an issue on beagle
which was making L3 error handling driver hang.

Later on after debugging we noticed, that DSS initiator
was throwing timeout error.

As a temporary fix, we removed the timeout error from
the handler since root-cause was not known. [1]

I am not sure but may be a proper DSS reset might fix
that issue as well.


Yeah, but this is the issue... people will start abusing that to fix any 
kind of problems instead of finding the root cause.


That should be use only to fix real HW issue that cannot be solve 
properly by SW.


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: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

[Kevin Hilman]

Govindraj  writes:

> On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit  wrote:
>
> On 5/27/2011 1:24 AM, Hilman, Kevin 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.
>
>
> BTW, don't we have the same kind of issue with the debug UART? I remember
> that you had to do some hacks at some point to change these hwmod flags in
> the UART code.
>
>
> Yes. we use below flags.
>
> uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
>

This is a hack (written by me) because the UART driver is not runtime PM
adapted.  When UART driver is runtime PM adapted, this will not be
needed.

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 0/3] Some omap_device/hwmod/pwrdomain patches

[Kevin Hilman]

Tomi Valkeinen  writes:

[...]

>
>> 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? 

Runtime PM callbacks.

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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Santosh Shilimkar]

On 5/27/2011 8:13 PM, Cousson, Benoit wrote:

On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:

Hi Tomi,

On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:

Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.


We've never exposed it because we are trying to avoid that any driver
play with asynchronous HW reset. That can lead to undefined HW
behavior :-(

Do you have some strong need for that?


DSS driver has been designed so that it resets the HW before it begins
programming it. That way we get the HW into known state. Otherwise we
need to be extra careful to program all possible registers to a sane
value. Not impossible, of course, but requires extra work.

I noticed the problem with DSI driver, it didn't work anymore if I
didn't reset it.

Why does it lead to undefined HW behaviour? Isn't it much better to
reset the HW before starting to use it to be 100% sure it's in known and
valid state?


In theory, but since your are resetting only the DSS IP, it can leads to
side effect at SoC level. Especially wrt to clock management.


Especially in error situations it may be difficult (even impossible) to
recover without reset. DISPC has been known to froze in some sync lost
situations, and, if I recall right, if DSI transfer is aborted the only
way to recover is to reset the DSI block (on OMAP3).


In case of recovery error it makes sense. What we did with hardreset is
to re-assert the reset upon disable of the module and then the next
enable will de-assert it. Softreset does not do that today.


I didn't notice this patch but Paul reported an issue on beagle
which was making L3 error handling driver hang.

Later on after debugging we noticed, that DSS initiator
was throwing timeout error.

As a temporary fix, we removed the timeout error from
the handler since root-cause was not known. [1]

I am not sure but may be a proper DSS reset might fix
that issue as well.

Regards
Santosh
[1] https://patchwork.kernel.org/patch/769482/





--
To unsubscribe from this list: send the line "unsubscribe 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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Cousson, Benoit]

On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote:

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:

Hi Tomi,

On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:

Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.


We've never exposed it because we are trying to avoid that any driver
play with asynchronous HW reset. That can lead to undefined HW behavior :-(

Do you have some strong need for that?


DSS driver has been designed so that it resets the HW before it begins
programming it. That way we get the HW into known state. Otherwise we
need to be extra careful to program all possible registers to a sane
value. Not impossible, of course, but requires extra work.

I noticed the problem with DSI driver, it didn't work anymore if I
didn't reset it.

Why does it lead to undefined HW behaviour? Isn't it much better to
reset the HW before starting to use it to be 100% sure it's in known and
valid state?


In theory, but since your are resetting only the DSS IP, it can leads to 
side effect at SoC level. Especially wrt to clock management.



Especially in error situations it may be difficult (even impossible) to
recover without reset. DISPC has been known to froze in some sync lost
situations, and, if I recall right, if DSI transfer is aborted the only
way to recover is to reset the DSI block (on OMAP3).


In case of recovery error it makes sense. What we did with hardreset is 
to re-assert the reset upon disable of the module and then the next 
enable will de-assert it. Softreset does not do that today.


My only concern is that people might start abusing that kind of API to 
use that for funtionnal purpose instead of error recovery.


This other issue is that it will add another OMAP specific IP to the driver.

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: Error while rotating LCD fb - detected fb_set_par error, error code: -22

[Mohamed Thalib H]

On Friday 27 May 2011 03:40 PM, Mohamed Thalib H wrote:

Hi,

I am using a omap3530 
 
based board. I am trying to rotate the LCD 
using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 
degree and 270 degrees.


When trying to rotate for 90 or 180 degree it give error message 
*detected fb_set_par error, error code: -22 *and does not rotate.


The log output is below.*
*

/ # cat /proc/cmdline
omapdss.def_disp=lcd30 console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw 
rootfstype=ext3
 rootwait lpj=1949696 omapfb.rotate=1 omapfb.rotate_type=1 
omap_vout.vid1_static_vrf

b_alloc=y omapfb.vrfb=y
/ # echo "0" > /sys/class/graphics/fb0/rotate
detected fb_set_par error, error code: -22
/ # echo "1" > /sys/class/graphics/fb0/rotate
/ # echo "2" > /sys/class/graphics/fb0/rotate
detected fb_set_par error, error code: -22
/ # echo "3" > /sys/class/graphics/fb0/rotate
/ # echo "1" > /sys/class/graphics/fb0/rotate

Can some one help me in solving this issue.

Regards,
HM Thalib



For you info I am using 2.6.34 kernel. LCD size is 240x480

While tracing though the source code I have found out that in file 
*drivers/video/omap2/dss/overlay.c *function *dss_check_overlay() *it is 
checking if *dw < info->pos_x + outw *which is *(240 < 0 + 400)*


that is if my overlay width is smaller than screen size, if so return 
error.


Have any one faced the same scenario.  If I am doing something wrong, 
Please let me know the correct steps to rotate the screen.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

[Koen Kooi]

Op 27 mei 2011, om 15:20 heeft Igor Grinberg het volgende geschreven:

> Hi Koen,
> 
> 
> Please CC LAKML for patches like this,
> 
> otherwise Tony, will have to post all of them before pull requesting.
> 
> 
> 
> On 05/27/11 15:40, Koen Kooi wrote:
> 
>> The USB enable GPIO has been inverted again and the USER button moved.
>> 
>> Future revisions will now fall back to xM rev C instead of unknown.
>> 
>> Signed-off-by: Koen Kooi 
>> ---
>> 
>> Changes since v1:
>>  * updated against mainline to take Igors gpio cleanup into account
>>  * removed xM rev B checks, no boards with that ID were ever produced, 
>> rev B boards show up as rev A
>>  * double checked whitespace:
>> 
>>  total: 0 errors, 0 warnings, 89 lines checked
>>  
>> patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has 
>> no obvious style problems and is ready for submission.
>> 
>> arch/arm/mach-omap2/board-omap3beagle.c |   31 
>> +++
>> 1 files changed, 23 insertions(+), 8 deletions(-)
>> 
>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
>> b/arch/arm/mach-omap2/board-omap3beagle.c
>> index be71426..177769b 100644
>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> 
> [...]
> 
>> @@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
>>  omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>>  omap3_beagle_init_rev();
>>  omap3_beagle_i2c_init();
>> +
>> +if (cpu_is_omap3630())
>> +gpio_buttons[0].gpio = 4;
> 
> Don't get me wrong, I want this patch in mainline as soon as possible.
> Just curious, what the hell happened to indentation here? :)

Thanks for spotting that! Copy/paste with a non tab aware terminal.

> checkpatch.pl does not spot things like this... interesting...
> If you want to leave this as is, go ahead, I don't mind, just curious.

I sent a new one, but screwed up the subject, I'll see if someone objects to 
that and resend as needed.

regards,

Koen--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP3: beagle: add support for beagleboard xM revision C

[Koen Kooi]

That was meant to say '[PATCH v3]', sorry about that.

Op 27 mei 2011, om 15:32 heeft Koen Kooi het volgende geschreven:

> The USB enable GPIO has been inverted again and the USER button moved
> 
> Signed-off-by: Koen Kooi 
> ---
> Changes since v2:
>* fixed indentation error checkpatch missed
> 
> Changes since v1:
>* updated against mainline to take Igors gpio cleanup into account
>* removed xM rev B checks, no boards with that ID were ever produced, rev 
> B boards show up as rev A
>* double checked whitespace:
> 
>total: 0 errors, 0 warnings, 89 lines checked
>
> patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has 
> no obvious style problems and is ready for submission.
> 
> arch/arm/mach-omap2/board-omap3beagle.c |   31 +++
> 1 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index be71426..81fff9d 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -63,7 +63,9 @@
>  *AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
>  *C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
>  *C4  = GPIO173, GPIO172, GPIO171: 1 0 1
> - *   XM  = GPIO173, GPIO172, GPIO171: 0 0 0
> + *   XMA = GPIO173, GPIO172, GPIO171: 0 0 0
> + *   XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
> + *   XMC = GPIO173, GPIO172, GPIO171: 0 1 0
>  */
> enum {
>   OMAP3BEAGLE_BOARD_UNKN = 0,
> @@ -71,6 +73,7 @@ enum {
>   OMAP3BEAGLE_BOARD_C1_3,
>   OMAP3BEAGLE_BOARD_C4,
>   OMAP3BEAGLE_BOARD_XM,
> + OMAP3BEAGLE_BOARD_XMC,
> };
> 
> static u8 omap3_beagle_version;
> @@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
>   printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
>   omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
>   break;
> + case 2:
> + printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
> + break;
>   default:
>   printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
> - omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
> + omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
>   }
> }
> 
> @@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
> {
>   int r, usb_pwr_level;
> 
> - if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + if (cpu_is_omap3630()) {
>   mmc[0].gpio_wp = -EINVAL;
>   } else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
>   (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
> @@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
>* high / others active low)
>* DVI reset GPIO is different between beagle revisions
>*/
> - if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> - usb_pwr_level = GPIOF_OUT_INIT_HIGH;
> + if (cpu_is_omap3630()) {
>   beagle_dvi_device.reset_gpio = 129;
>   /*
> -  * gpio + 1 on Xm controls the TFP410's enable line (active low)
> +  * gpio + 1 on xM controls the TFP410's enable line (active low)
>* gpio + 2 control varies depending on the board rev as below:
>* P7/P8 revisions(prototype): Camera EN
>* A2+ revisions (production): LDO (DVI, serial, led blocks)
> @@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
>   pr_err("%s: unable to configure DVI_LDO_EN\n",
>   __func__);
>   } else {
> - usb_pwr_level = GPIOF_OUT_INIT_LOW;
>   beagle_dvi_device.reset_gpio = 170;
>   /*
>* REVISIT: need ehci-omap hooks for external VBUS
> @@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
>   pr_err("%s: unable to configure EHCI_nOC\n", __func__);
>   }
> 
> + /* Only xM rev A and xM rev B use active high */
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
> + usb_pwr_level = GPIOF_OUT_INIT_HIGH;
> + else
> + usb_pwr_level = GPIOF_OUT_INIT_LOW;
> +
>   gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, "nEN_USB_PWR");
> 
>   /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
> @@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
>   }
> 
>   /* Custom OPP enabled for XM */
> - if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + if (cpu_is_omap3630()) {
>   struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
>   struct omap_hwmod *dh = omap_hwmod_lookup("iva");
>   struct device *dev;
> @@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
>   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>   omap3_b

[PATCH] OMAP3: beagle: add support for beagleboard xM revision C

[Koen Kooi]

The USB enable GPIO has been inverted again and the USER button moved

Signed-off-by: Koen Kooi 
---
Changes since v2:
* fixed indentation error checkpatch missed

Changes since v1:
* updated against mainline to take Igors gpio cleanup into account
* removed xM rev B checks, no boards with that ID were ever produced, rev B 
boards show up as rev A
* double checked whitespace:

total: 0 errors, 0 warnings, 89 lines checked
patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch 
has no obvious style problems and is ready for submission.

 arch/arm/mach-omap2/board-omap3beagle.c |   31 +++
 1 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..81fff9d 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -63,7 +63,9 @@
  * AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
  * C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
  * C4  = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM  = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
  */
 enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -71,6 +73,7 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+   OMAP3BEAGLE_BOARD_XMC,
 };
 
 static u8 omap3_beagle_version;
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+   case 2:
+   printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
+   omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+   break;
default:
printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
-   omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+   omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
 }
 
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
 {
int r, usb_pwr_level;
 
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
 * high / others active low)
 * DVI reset GPIO is different between beagle revisions
 */
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
-   usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+   if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
-* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 1 on xM controls the TFP410's enable line (active low)
 * gpio + 2 control varies depending on the board rev as below:
 * P7/P8 revisions(prototype): Camera EN
 * A2+ revisions (production): LDO (DVI, serial, led blocks)
@@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err("%s: unable to configure DVI_LDO_EN\n",
__func__);
} else {
-   usb_pwr_level = GPIOF_OUT_INIT_LOW;
beagle_dvi_device.reset_gpio = 170;
/*
 * REVISIT: need ehci-omap hooks for external VBUS
@@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err("%s: unable to configure EHCI_nOC\n", __func__);
}
 
+   /* Only xM rev A and xM rev B use active high */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+   usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+   else
+   usb_pwr_level = GPIOF_OUT_INIT_LOW;
+
gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, "nEN_USB_PWR");
 
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
@@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
}
 
/* Custom OPP enabled for XM */
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
struct omap_hwmod *dh = omap_hwmod_lookup("iva");
struct device *dev;
@@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+   if (cpu_is_omap3630())
+   gpio_buttons[0].gpio = 4;
+
platform_add_devices(omap3_beagle_devices,

Re: [PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

[Igor Grinberg]

Hi Koen,


Please CC LAKML for patches like this,

otherwise Tony, will have to post all of them before pull requesting.



On 05/27/11 15:40, Koen Kooi wrote:

> The USB enable GPIO has been inverted again and the USER button moved.
>
> Future revisions will now fall back to xM rev C instead of unknown.
>
> Signed-off-by: Koen Kooi 
> ---
>
> Changes since v1:
>   * updated against mainline to take Igors gpio cleanup into account
>   * removed xM rev B checks, no boards with that ID were ever produced, 
> rev B boards show up as rev A
>   * double checked whitespace:
>
>   total: 0 errors, 0 warnings, 89 lines checked
>   
> patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has 
> no obvious style problems and is ready for submission.
>
>  arch/arm/mach-omap2/board-omap3beagle.c |   31 
> +++
>  1 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
> b/arch/arm/mach-omap2/board-omap3beagle.c
> index be71426..177769b 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c

[...]

> @@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
>   omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>   omap3_beagle_init_rev();
>   omap3_beagle_i2c_init();
> +
> + if (cpu_is_omap3630())
> + gpio_buttons[0].gpio = 4;

Don't get me wrong, I want this patch in mainline as soon as possible.
Just curious, what the hell happened to indentation here? :)
checkpatch.pl does not spot things like this... interesting...
If you want to leave this as is, go ahead, I don't mind, just curious.

-- 
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: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Tomi Valkeinen]

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote:
> Hi Tomi,
> 
> On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:
> > Add omap_device_reset() function which can be used to reset the hwmods
> > associated with the given platform device.
> 
> We've never exposed it because we are trying to avoid that any driver 
> play with asynchronous HW reset. That can lead to undefined HW behavior :-(
> 
> Do you have some strong need for that?

DSS driver has been designed so that it resets the HW before it begins
programming it. That way we get the HW into known state. Otherwise we
need to be extra careful to program all possible registers to a sane
value. Not impossible, of course, but requires extra work.

I noticed the problem with DSI driver, it didn't work anymore if I
didn't reset it.

Why does it lead to undefined HW behaviour? Isn't it much better to
reset the HW before starting to use it to be 100% sure it's in known and
valid state?

Especially in error situations it may be difficult (even impossible) to
recover without reset. DISPC has been known to froze in some sync lost
situations, and, if I recall right, if DSI transfer is aborted the only
way to recover is to reset the DSI block (on OMAP3).

 Tomi


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

[Koen Kooi]

The USB enable GPIO has been inverted again and the USER button moved.

Future revisions will now fall back to xM rev C instead of unknown.

Signed-off-by: Koen Kooi 
---

Changes since v1:
* updated against mainline to take Igors gpio cleanup into account
* removed xM rev B checks, no boards with that ID were ever produced, 
rev B boards show up as rev A
* double checked whitespace:

total: 0 errors, 0 warnings, 89 lines checked

patches/0001-OMAP3-beagle-add-support-for-beagleboard-xM-revision.patch has no 
obvious style problems and is ready for submission.

 arch/arm/mach-omap2/board-omap3beagle.c |   31 +++
 1 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..177769b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -63,7 +63,9 @@
  * AXBX= GPIO173, GPIO172, GPIO171: 1 1 1
  * C1_3= GPIO173, GPIO172, GPIO171: 1 1 0
  * C4  = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM  = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMB = GPIO173, GPIO172, GPIO171: 0 0 1 - unused
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
  */
 enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -71,6 +73,7 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+   OMAP3BEAGLE_BOARD_XMC,
 };
 
 static u8 omap3_beagle_version;
@@ -123,9 +126,13 @@ static void __init omap3_beagle_init_rev(void)
printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
break;
+   case 2:
+   printk(KERN_INFO "OMAP3 Beagle Rev: xM\n");
+   omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
+   break;
default:
printk(KERN_INFO "OMAP3 Beagle Rev: unknown %hd\n", beagle_rev);
-   omap3_beagle_version = OMAP3BEAGLE_BOARD_UNKN;
+   omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
}
 }
 
@@ -253,7 +260,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
 {
int r, usb_pwr_level;
 
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   if (cpu_is_omap3630()) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
(omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
@@ -275,11 +282,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
 * high / others active low)
 * DVI reset GPIO is different between beagle revisions
 */
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
-   usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+   if (cpu_is_omap3630()) {
beagle_dvi_device.reset_gpio = 129;
/*
-* gpio + 1 on Xm controls the TFP410's enable line (active low)
+* gpio + 1 on xM controls the TFP410's enable line (active low)
 * gpio + 2 control varies depending on the board rev as below:
 * P7/P8 revisions(prototype): Camera EN
 * A2+ revisions (production): LDO (DVI, serial, led blocks)
@@ -295,7 +301,6 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err("%s: unable to configure DVI_LDO_EN\n",
__func__);
} else {
-   usb_pwr_level = GPIOF_OUT_INIT_LOW;
beagle_dvi_device.reset_gpio = 170;
/*
 * REVISIT: need ehci-omap hooks for external VBUS
@@ -305,6 +310,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
pr_err("%s: unable to configure EHCI_nOC\n", __func__);
}
 
+   /* Only xM rev A and xM rev B use active high */
+   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+   usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+   else
+   usb_pwr_level = GPIOF_OUT_INIT_LOW;
+
gpio_request_one(gpio + TWL4030_GPIO_MAX, usb_pwr_level, "nEN_USB_PWR");
 
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
@@ -525,7 +536,7 @@ static void __init beagle_opp_init(void)
}
 
/* Custom OPP enabled for XM */
-   if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+   if (cpu_is_omap3630()) {
struct omap_hwmod *mh = omap_hwmod_lookup("mpu");
struct omap_hwmod *dh = omap_hwmod_lookup("iva");
struct device *dev;
@@ -565,6 +576,10 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+   if (cpu_is_omap3630())
+   gpio_buttons[0].gpio = 4;
+
platform_add_devices(o

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

[Cousson, Benoit]

Hi Tomi,

On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote:

Add omap_device_reset() function which can be used to reset the hwmods
associated with the given platform device.


We've never exposed it because we are trying to avoid that any driver 
play with asynchronous HW reset. That can lead to undefined HW behavior :-(


Do you have some strong need for that?

Regards,
Benoit



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 *
   *


--
To unsubscribe from this list: send the line "unsubscribe 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

[Koen Kooi]

Op 27 mei 2011, om 13:04 heeft Tony Lindgren het volgende geschreven:

> * Tony Lindgren  [110527 09:29]:
>> * 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.
> 
> Koen, the patch above needs to be refreshed to apply to current mainline
> kernel. It also seems to contain some whitespace errors.
> 
> Care to refresh it and repost?

I'm refreshing it right now and will after testing.

regards,

Koen--
To unsubscribe from this list: send the line "unsubscribe 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

[Cousson, Benoit]

On 5/27/2011 9:26 AM, Govindraj wrote:


On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit mailto:b-cous...@ti.com>> wrote:

On 5/27/2011 1:24 AM, Hilman, Kevin wrote:

Nishanth Menonmailto:n...@ti.com>>  writes:

From: Moiz Sonasathmailto:m-sonas...@ti.com>>

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.


BTW, don't we have the same kind of issue with the debug UART? I
remember that you had to do some hacks at some point to change these
hwmod flags in the UART code.


Yes. we use below flags.

uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;


Yeah, that's ugly... we do have to get rid of that as well using some 
board settings / API.


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] free rev gpios when they are read, so others can read them later

[Igor Grinberg]

Hi Tasslehoff,

On 05/26/11 22:59, Tasslehoff Kjappfot wrote:
> 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));
> +

To be consistent with the rest of the file,
can the white space here be "tabs" instead of spaces?


-- 
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: [GIT PULL] omap updates for 2.6.40

[Tony Lindgren]

* Tony Lindgren  [110527 09:29]:
> * 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.

Koen, the patch above needs to be refreshed to apply to current mainline
kernel. It also seems to contain some whitespace errors.

Care to refresh it and repost?

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings

[Tony Lindgren]

* Igor Grinberg  [110526 17:05]:
> 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...

Applying thanks.

Regards,

Tony
 
> [1] https://patchwork.kernel.org/patch/733531/
--
To unsubscribe from this list: send the line "unsubscribe 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

[Tony Lindgren]

* Russell King - ARM Linux  [110526 16:51]:
> 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.

OK thanks. Kevin, can you queue this fix? Assuming the move of omap
gpio to drivers/gpio happens this merge window, this needs to be
updated for the path.

Regards,

Tony
 
> 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

Error while rotating LCD fb - detected fb_set_par error, error code: -22

[Mohamed Thalib H]

Hi,

I am using a omap3530 
 
based board. I am trying to rotate the LCD 
using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 
degree and 270 degrees.


When trying to rotate for 90 or 180 degree it give error message 
*detected fb_set_par error, error code: -22 *and does not rotate.


The log output is below.*
*

/ # cat /proc/cmdline
omapdss.def_disp=lcd30 console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw 
rootfstype=ext3
 rootwait lpj=1949696 omapfb.rotate=1 omapfb.rotate_type=1 
omap_vout.vid1_static_vrf

b_alloc=y omapfb.vrfb=y
/ # echo "0" > /sys/class/graphics/fb0/rotate
detected fb_set_par error, error code: -22
/ # echo "1" > /sys/class/graphics/fb0/rotate
/ # echo "2" > /sys/class/graphics/fb0/rotate
detected fb_set_par error, error code: -22
/ # echo "3" > /sys/class/graphics/fb0/rotate
/ # echo "1" > /sys/class/graphics/fb0/rotate

Can some one help me in solving this issue.

Regards,
HM Thalib

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

[Grant Likely]

On Fri, May 27, 2011 at 1:35 AM, Grant Likely  wrote:
> On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote:
>> Move OMAP GPIO driver to drivers/gpio.  Builds whenever
>> CONFIG_ARCH_OMAP=y.
>>
>> Signed-off-by: Kevin Hilman 
>
> Patch unfortunately doesn't apply cleanly to Linus' tree.  There's
> been some changes to gpio.c compared to the tree this patch was
> prepared against.
>
> Also, if you use the -M flag when preparing the patch, then I'll be
> able to see what the changes are during the move, and fix things up
> intelligently if anything breaks.
>
> Can you respin and repost the series quickly?

While you're at it, can you name the moved file
drivers/gpio/gpio-omap.c?  ('-' instead of '_'.  Why, yes, I am a
nitpicker.)

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules

[Jean Pihet]

On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman  wrote:
> 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.
This is much cleaner! We need this pushed upstream.

Acked-by: Jean Pihet 

Thanks,
Jean

>
> 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 Pihet]

On Fri, May 27, 2011 at 1:00 AM, Kevin Hilman  wrote:
> 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.
Agree, there is a bit of clean-up/rework as well. Will re-organize.

...

>
>> +#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.
Only OMAP2 uses it currently but I think it is useful to have the time
to next tick available for debug purpose.
BTW this change implements it in a more generic way:
tick_nohz_get_sleep_length is generic and also used by e.g. cpuidle to
determine the next state to enter.

Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 2/2] OMAP: add omap_device_reset()

[Tomi Valkeinen]

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

[PATCHv2 1/2] OMAP: change get_context_loss_count ret value to int

[Tomi Valkeinen]

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 
---
 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..9d53a34 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 &= INT_MAX;
+
+   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,
   

[PATCHv2 0/2] Some omap_device/hwmod/pwrdomain patches

[Tomi Valkeinen]

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.

Changes in v2
* Dropped can-ever-lose-context patch
* Use INT_MAX instead of ~(1 << 31) when masking the ctx loss count

 Tomi

Tomi Valkeinen (2):
  OMAP: change get_context_loss_count ret value to int
  OMAP: add omap_device_reset()

 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 |3 ++-
 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  |   25 -
 8 files changed, 58 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: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature

[Jean Pihet]

On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman  wrote:
> 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'.
'nohlt' is only for the default arch idle handler (pm_idle). It does
not apply to the cpuidle handler (omap3_enter_idle) which depends on
CONFIG_CPU_IDLE.

> If runtime configuration of this is needed, then adding a debugfs
> entry for the ARM-generic hlt/nohlt interface should be added.
Is there a need for it?

Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups

[Jean Pihet]

On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman  wrote:
> 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.
Indeed this code is a spaghetti mess and makes pm-debug difficult to
be modularized.

> 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.
Agree. However we still need the equivalent of [1] to retrieve the
PRCM registers just before and after the WFI instructions.
I would like to propose some replacement when the current code
clean-up is settled down a bit.

[1] 
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=commitdiff;h=5dd36389eb6ef4837a2aad128e4bd0226468c171

Regards,
Jean

> 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
>
--
To unsubscribe from this list: send the line "unsubscribe 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

[Cousson, Benoit]

On 5/27/2011 1:24 AM, Hilman, Kevin 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.


BTW, don't we have the same kind of issue with the debug UART? I 
remember that you had to do some hacks at some point to change these 
hwmod flags in the UART code.


In general we do not want to reset nor idle an IP that was potentially 
already properly configured by bootloader or early Linux boot code.


Regards,
Benoit



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


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html