Re: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c

[Santosh Shilimkar]

On Wednesday 28 November 2012 12:16 PM, Igor Grinberg wrote:

On 11/28/12 08:28, Santosh Shilimkar wrote:

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

When compiling the kernel with configuration options ...

   # CONFIG_ARCH_OMAP2 is not set
   # CONFIG_ARCH_OMAP3 is not set
   # CONFIG_ARCH_OMAP4 is not set
   # CONFIG_SOC_OMAP5 is not set
   CONFIG_SOC_AM33XX=y

   ... the following build warning is seen.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:395:19: warning: 
‘omap2_sync32k_clocksource_init’
defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by only including the omap2_sync32k_clocksource_init() function
if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.

Cc: Igor Grinberg 

Signed-off-by: Jon Hunter 
---
   arch/arm/mach-omap2/timer.c |3 +++
   1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index eb96712..085c7e7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
   return 0;
   }

+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)

#ifndef CONFIG_SOC_AM33XX ?

#ifdef things are really ugly and needs constant patching and
hence something like CONFIG_HAS_32K kind of feature flags are
better. But that will undo certain part of f80b3b
(ARM: OMAP2+: timer: remove  CONFIG_OMAP_32K_TIMER).


Agreed on ugliness of ifdefs.
What about adding __maybe_unused to the function signature?
That will cover any future SoC also w/o the need to extend the ifdefs.


Sounds good to me.

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

Re: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c

[Igor Grinberg]

On 11/28/12 08:28, Santosh Shilimkar wrote:
> On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:
>> When compiling the kernel with configuration options ...
>>
>>   # CONFIG_ARCH_OMAP2 is not set
>>   # CONFIG_ARCH_OMAP3 is not set
>>   # CONFIG_ARCH_OMAP4 is not set
>>   # CONFIG_SOC_OMAP5 is not set
>>   CONFIG_SOC_AM33XX=y
>>
>>   ... the following build warning is seen.
>>
>>CC  arch/arm/mach-omap2/timer.o
>>arch/arm/mach-omap2/timer.c:395:19: warning: 
>> ‘omap2_sync32k_clocksource_init’
>>defined but not used [-Wunused-function]
>>
>> This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
>> CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
>> longer referenced by the timer initialisation function for the AM335x
>> device as it has no 32k-sync timer.
>>
>> Fix this by only including the omap2_sync32k_clocksource_init() function
>> if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.
>>
>> Cc: Igor Grinberg 
>>
>> Signed-off-by: Jon Hunter 
>> ---
>>   arch/arm/mach-omap2/timer.c |3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index eb96712..085c7e7 100644
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
>>   return 0;
>>   }
>>
>> +#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
>> +defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
> #ifndef CONFIG_SOC_AM33XX ?
> 
> #ifdef things are really ugly and needs constant patching and
> hence something like CONFIG_HAS_32K kind of feature flags are
> better. But that will undo certain part of f80b3b
> (ARM: OMAP2+: timer: remove  CONFIG_OMAP_32K_TIMER).

Agreed on ugliness of ifdefs.
What about adding __maybe_unused to the function signature?
That will cover any future SoC also w/o the need to extend the ifdefs. 

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

Re: [PATCH 2/3] ARM: OMAP4: Fix build error and warning in timer.c

[Igor Grinberg]

On 11/28/12 04:15, Jon Hunter wrote:
> When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
> enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
> warning is seen.
> 
>   CC  arch/arm/mach-omap2/timer.o
>   arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
>   arch/arm/mach-omap2/timer.c:630:2: error: implicit declaration of
>   function ‘omap4_sync32_timer_init’
>   [-Werror=implicit-function-declaration]
>   arch/arm/mach-omap2/timer.c: At top level:
>   arch/arm/mach-omap2/timer.c:607:1: warning: ‘omap4_sync32k_timer_init’
>   defined but not used [-Wunused-function]
>   cc1: some warnings being treated as errors
>   make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
> 
> This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
> CONFIG_OMAP_32K_TIMER) where the "k" is missing from the "sync32k" in
> the function name "omap4_sync32_timer_init". Therefore, correct this
> typo to resolve the above error and warning.

Yeah ;-( sorry for this...

> 
> Cc: Igor Grinberg 
> 
> Reported-by: Tony Lindgren 
> Signed-off-by: Jon Hunter 

Acked-by: Igor Grinberg 

> ---
>  arch/arm/mach-omap2/timer.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index a9f99e3..eb96712 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -627,7 +627,7 @@ static void __init omap4_local_timer_init(void)
>  #else /* CONFIG_LOCAL_TIMERS */
>  static inline void omap4_local_timer_init(void)
>  {
> - omap4_sync32_timer_init();
> + omap4_sync32k_timer_init();
>  }
>  #endif /* CONFIG_LOCAL_TIMERS */
>  OMAP_SYS_TIMER(4, local);

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

Re: [PATCH 3/3] ARM: AM335x: Fix warning in timer.c

[Santosh Shilimkar]

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

When compiling the kernel with configuration options ...

  # CONFIG_ARCH_OMAP2 is not set
  # CONFIG_ARCH_OMAP3 is not set
  # CONFIG_ARCH_OMAP4 is not set
  # CONFIG_SOC_OMAP5 is not set
  CONFIG_SOC_AM33XX=y

  ... the following build warning is seen.

   CC  arch/arm/mach-omap2/timer.o
   arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by only including the omap2_sync32k_clocksource_init() function
if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.

Cc: Igor Grinberg 

Signed-off-by: Jon Hunter 
---
  arch/arm/mach-omap2/timer.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index eb96712..085c7e7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
  }

+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+   defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)

#ifndef CONFIG_SOC_AM33XX ?

#ifdef things are really ugly and needs constant patching and
hence something like CONFIG_HAS_32K kind of feature flags are
better. But that will undo certain part of f80b3b
(ARM: OMAP2+: timer: remove  CONFIG_OMAP_32K_TIMER).

Regards
santosh




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

Re: [PATCH 1/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c

[Santosh Shilimkar]

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

   CC  arch/arm/mach-omap2/timer.o
   arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
   defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
really needed because ...

1. For non-OMAP5 devices, there is no realtime counter and so
realtime_counter_init() function is not used.
2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always selected
and cannot be disabled, so the stub function for realtime_counter_init()
is never used.

Fix this warning by removing the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

Cc: Santosh Shilimkar 

Reported-by: Tony Lindgren 
Signed-off-by: Jon Hunter 
---
The #ifdef was avoided because the real-time counter can be used on 
other future SOCs. And the those SOCs just select

SOC_HAS_REALTIME_COUNTER. And that stub was added because OMAP5 can
work without real-time counter configuration enabled using 32K counter.
But since we are any way have that SOC_HAS_REALTIME_COUNTER always
set for SOC which wants to use it, we can actually remove the stub
and hence avoid the warning. Let me know if below patch is ok
with you ? attached the same for mailer issues

From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar 
Date: Wed, 28 Nov 2012 11:28:57 +0530
Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
defined but not used [-Wunused-function]

It is because of the stub init function which was added for the cases
where realtime_counter_init() is called with 
!CONFIG_SOC_HAS_REALTIME_COUNTER.

This is actually not necessary since the SOC which need this feature
will explicitly select the configuration.

So just drop the unused stub to avoid the build warning.

Patch is made after seeing Jon's patch which was wrapping the
real-time counter code under needed SOC #ifdef

Cc: Jon Hunter 

Reported-by: Tony Lindgren 
Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/timer.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69e4663..79d8e6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -428,9 +428,6 @@ static void __init realtime_counter_init(void)

iounmap(base);
 }
-#else
-static inline void __init realtime_counter_init(void)
-{}
 #endif

 #define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src, \
--
1.7.9.5








>From e000aa13e47e29fbe3473bfd0277cb057c3160cc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar 
Date: Wed, 28 Nov 2012 11:28:57 +0530
Subject: [PATCH] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
defined but not used [-Wunused-function]

It is because of the stub init function which was added for the cases
where realtime_counter_init() is called with !CONFIG_SOC_HAS_REALTIME_COUNTER.
This is actually not necessary since the SOC which need this feature
will explicitly select the configuration.

So just drop the unused stub to avoid the build warning.

Patch is made after seeing Jon's patch which was wrapping the
real-time counter code under needed SOC #ifdef

Cc: Jon Hunter 

Reported-by: Tony Lindgren 
Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/timer.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 69e4663..79d8e6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/ar

Re: [PATCH 2/3] ARM: OMAP4: Fix build error and warning in timer.c

[Santosh Shilimkar]

On Wednesday 28 November 2012 07:45 AM, Jon Hunter wrote:

When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
warning is seen.

   CC  arch/arm/mach-omap2/timer.o
   arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
   arch/arm/mach-omap2/timer.c:630:2: error: implicit declaration of
function ‘omap4_sync32_timer_init’
[-Werror=implicit-function-declaration]
   arch/arm/mach-omap2/timer.c: At top level:
   arch/arm/mach-omap2/timer.c:607:1: warning: ‘omap4_sync32k_timer_init’
defined but not used [-Wunused-function]
   cc1: some warnings being treated as errors
   make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the "k" is missing from the "sync32k" in
the function name "omap4_sync32_timer_init". Therefore, correct this
typo to resolve the above error and warning.

Cc: Igor Grinberg 

Reported-by: Tony Lindgren 
Signed-off-by: Jon Hunter 
---

Acked-by: Santosh Shilimkar 

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

RE: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

[Philip, Avinash]

On Tue, Nov 27, 2012 at 19:30:54, Daniel Mack wrote:
> Hi Avinash,
> Hi Peter,
> 
> On 23.11.2012 11:43, Philip, Avinash wrote:
> > On Wed, Nov 21, 2012 at 15:45:23, Daniel Mack wrote:
> >> On 20.11.2012 16:59, Peter Korsgaard wrote:
>  "Daniel" == Daniel Mack  writes:
> 
> > Peter,
> > 
> > In patch [1], mtd: nand: omap2: Support for hardware BCH
> > 
> > ecc_layout made compatible with Rom Boot Loader ECC layout for am335x.
> > 
> > This action is based on is_elm_used flag.
> > 
> > Requirement of this flag is to identify the whether the platform
> > ELM module & based on this configure ELM module if present.
> > 
> > But ideally BCH8 ecc lay out didn't have a dependency on ELM, it
> > can work with software BCH ecc. RBL compatibility is missing
> > in software BCH because of addition of constant polynomial to
> > ecc vector. If we remove the dependency on erased page handling
> > by ecc vector with constant polynomial, software BCH can do the
> > job of RBL compatibility.
> > 
> > Ivan,
> > Do you have any suggestions?
> > Discussion for RBL compatibility found at [2].
> > 
> > It is good that software BCH also support RBL compatibility by suppressing
> > constant polynomial modification. Then ecc layout can be selected from
> > DT entry and error correction can be chosen between software/hardware
> > depending on the availability of ELM hardware.
> > Currently RBL BCH8 compatibility depends on the availability of ELM
> > hardware. Later once software BCH start supporting RBL compatibility,
> > we can remove  the check.
> > 
> >>
> >> That is what I experienced, yes. The kernel was unable to parse NAND
> >> pages that were written from U-Boot with bch8 hardware mode when the elm
> >> module was not active. Maybe someone from TI can explain that? Giving it
> >> a dedicated name would also solve the problem with the extra DT property.
> > 
> > Daniel,
> > 
> > Currently BCH8 is supported with software ecc error correction in mainline.
> > The layout for BCH8 ECC layout is
> > 0-1 -> BAD block markers
> > 2-11-> oob free area
> > 12-63-> BCH8 ECC.
> > 
> > RBL ECC layout is
> > 0-1 -> BAD block markers
> > 2-57-> BCH8 ecc layout
> > 58-63-> OOB free area
> > 
> > As u-boot also maintain RBL ecc layout, write from U-boot
> > and read from Linux requires compatibility with RBL ecc layout.
> > The same is achieved in the patch [1], with by setting is_elm_used
> > to true.
> > 
> > 1. https://lkml.org/lkml/2012/10/31/87
> > 2. https://lkml.org/lkml/2012/10/11/20
> 
> So, after reading this, I'm still uncertain what's your preferred way of
> handling the bindings here. Are you saying we should stick with the
> is_elm_used flag, and subsequently care for BCH8 software mode
> compatibility?

Ideally RBL compatibility didn't depend on the availability of ELM module. So
from am335x perspective, RBL compatibility is achieved with ECC error correction
with ELM module. I would submit one more revision of BCH8 ELM error correction
support which would check for bch8-am335xrbl-compatible.
Note: RBL ecc layout can vary from SOC to SOC

Daniel,

So can you start supporting "bch8-am335xrbl-compatible" and remove usage of
is_elm_used in dt. This should come in ecc_opt field.

In omap2 NAND driver, AM335x RBL compatibility is achieved depending on 
ecc_layout
and runtime detection of elm module. So options related to can be
1. bch8-am335xrbl-compatible is enabled and run time detection of
   Of elm module passed, RBL compatibility achieved.
2. bch8-am335xrbl-compatible is enabled and run time detection of
   of elm module failed, RBL compatibility sacrificed but continue with
   software BCH8 error correction. Sacrificing RBL compatibility
   because of constant polynomial addition and usage of 14 byte instead of 13 
byte.

Ivan,
Do you have any plan of removing addition of constant polynomial to ecc data
and go for extra byte checking to find erased pages?
This way we can start support BCH8 with RBL compatible and kernel
Didn't put any restriction of the ecc layout.

Thanks
Avinash

> 
> I would like to submit a new version soon, so it can be queued up for
> the next merge window, and that decision is the last blocker currently
> for sending out a new series.
> 
> 
> Many thanks,
> Daniel
> 
> 

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green]

On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:

On Wed, 28 Nov 2012, Andy Green wrote:


OK.  So I try to sketch it out iteractively to try to get in sync:

device.h:

enum asset_event {
AE_PROBED,
AE_REMOVED
};

struct device_asset {
char *name; /* name of regulator, clock, etc */
void *asset; /* regulator, clock, etc */
int (*handler)(struct device *dev_owner, enum asset_event 
asset_event,
struct device_asset *asset);
};


Another possibility is to have two handlers: one for pre-probe and the
other for post-remove.  Then of course asset_event wouldn't be needed.
Linus tends to prefer this strategy -- separate functions for separate
events.  That's why struct dev_pm_ops has so many method pointers.


OK.

I wonder if this needs extending to PM ops passing in to the assets. 
Regulator is usually self-sufficient but sometimes clocks at least need 
meddling in suspend paths.


Maybe it's enough instead to offer a standalone api for drivers that 
want to meddle with assets, like enable / disable an asset clock...


void *device_find_asset(struct device *device, const char *name);

...if it wants to touch anything like that it needs to mandate a 
nonambiguous name for the asset like "reg-mydriver-ehci-omap.0".


This is also handy since the driver can then adapt around absence or 
presence of optional assets if it wants.



struct device {
...
struct device_asset *assets;


Or a list instead of a NULL-terminated array.  It depends on whether
people will want to add or remove assets dynamically.  For now an array
would be fine.


OK.


...
};


drivers/base/dd.c | really_probe():

...
struct device_asset *asset;
...
asset = dev->assets;
while (asset && asset->name) {


Maybe it would be better to test asset->handler.  Some assets might not
need names.


Good point.


if (asset->handler(dev, AE_PROBED, asset)) {
/* clean up and bail */
}
asset++;
}

/* do probe */
...


drivers/base/dd.c | __device_release_driver:  (is this really the best
place to oppose probe()?)


The right place is just after the remove method is called, so yes.


...
struct device_asset *asset;
...

/* call device ->remove() */
...
asset = dev->assets;
while (asset && asset->name) {
asset->handler(dev, AE_REMOVED, asset);
asset++;
}


It would be slightly safer to iterate in reverse order.


Good point.


...


board file:

static struct regulator myreg = {
.name = "mydevice-regulator",
};

static struct device_asset mydevice_assets[] = {
{
.name = "mydevice-regulator",
.handler = regulator_default_asset_handler,
},
{ }
};

static struct platform_device mydevice = {
...
.dev = {
.assets = mydevice_assets,
},
...
};


regulator code:

int regulator_default_asset_handler(struct device *dev_owner, enum
asset_event asset_event, struct device_asset *asset)
{
struct regulator **reg = &asset->asset;
int n;

switch (asset_event) {
case AE_PROBED:
*reg = regulator_get(dev_owner, asset->name);
if (IS_ERR(*reg))
return *reg;


PTR_ERR.


Right.

I'll offer a series with these adaptations shortly.

-Andy


n = regulator_enable(*reg);
if (n < 0)
regulator_put(*reg);
return n;

case AE_REMOVED:
regulator_put(*reg);
break;
}

return 0;
}
EXPORT_SYMBOL_GPL(regulator_default_asset_handler);


The subsystems that can expect to get used (clock...) might each want to
define a default handler like the one for regulator.  That'll be an end
to the code duplication issue.  The user can still do his own handler if
he wants.

I put a name field in so we can use regulator_get() nicely, we don't
need access to the object pointer or that it exists at boardfile-time
that way either.  But I can see it's arguable.


It hadn't occurred to me, but it seems like a good idea.

Yes, overall this is almost exactly what I had in mind.


Throwing out the path stuff and limiting this to platform_device means
you cannot bind to dynamically created objects like hub or anything
downstream of a hub.  So Felipe's identification of the hub as the
happening place to do this is out of luck.


Greg pointed out that this could be useful for arbitrary devices, not
just platform devices, so it could be applied to dynamically created
objects.


Well that is cool, but to exploit that in the dy

[PATCH 3/3] ARM: AM335x: Fix warning in timer.c

[Jon Hunter]

When compiling the kernel with configuration options ...

 # CONFIG_ARCH_OMAP2 is not set
 # CONFIG_ARCH_OMAP3 is not set
 # CONFIG_ARCH_OMAP4 is not set
 # CONFIG_SOC_OMAP5 is not set
 CONFIG_SOC_AM33XX=y

 ... the following build warning is seen.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by only including the omap2_sync32k_clocksource_init() function
if either OMAP2, OMAP3, OMAP4 or OMAP5 devices are enabled.

Cc: Igor Grinberg 

Signed-off-by: Jon Hunter 
---
 arch/arm/mach-omap2/timer.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index eb96712..085c7e7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -386,6 +386,8 @@ static u32 notrace dmtimer_read_sched_clock(void)
return 0;
 }
 
+#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
+   defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct of_device_id omap_counter_match[] __initdata = {
{ .compatible = "ti,omap-counter32k", },
{ }
@@ -451,6 +453,7 @@ static int __init omap2_sync32k_clocksource_init(void)
 
return ret;
 }
+#endif
 
 static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
-- 
1.7.10.4

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

[PATCH 2/3] ARM: OMAP4: Fix build error and warning in timer.c

[Jon Hunter]

When compiling the kernel with configuration option CONFIG_ARCH_OMAP4
enabled and CONFIG_LOCAL_TIMERS disabled, the following build error and
warning is seen.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c: In function ‘omap4_local_timer_init’:
  arch/arm/mach-omap2/timer.c:630:2: error: implicit declaration of
function ‘omap4_sync32_timer_init’
[-Werror=implicit-function-declaration]
  arch/arm/mach-omap2/timer.c: At top level:
  arch/arm/mach-omap2/timer.c:607:1: warning: ‘omap4_sync32k_timer_init’
defined but not used [-Wunused-function]
  cc1: some warnings being treated as errors
  make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1

This issue was introduced by commit 6f80b3b (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the "k" is missing from the "sync32k" in
the function name "omap4_sync32_timer_init". Therefore, correct this
typo to resolve the above error and warning.

Cc: Igor Grinberg 

Reported-by: Tony Lindgren 
Signed-off-by: Jon Hunter 
---
 arch/arm/mach-omap2/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a9f99e3..eb96712 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -627,7 +627,7 @@ static void __init omap4_local_timer_init(void)
 #else /* CONFIG_LOCAL_TIMERS */
 static inline void omap4_local_timer_init(void)
 {
-   omap4_sync32_timer_init();
+   omap4_sync32k_timer_init();
 }
 #endif /* CONFIG_LOCAL_TIMERS */
 OMAP_SYS_TIMER(4, local);
-- 
1.7.10.4

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

[PATCH 1/3] ARM: OMAP2+: Fix realtime_counter_init warning in timer.c

[Jon Hunter]

In commit fa6d79d (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

  CC  arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
  defined but not used [-Wunused-function]

Commit fa6d79d also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

The option CONFIG_SOC_HAS_REALTIME_COUNTER and stub function are not
really needed because ...

1. For non-OMAP5 devices, there is no realtime counter and so
   realtime_counter_init() function is not used.
2. For OMAP5 devices, CONFIG_SOC_HAS_REALTIME_COUNTER is always selected
   and cannot be disabled, so the stub function for realtime_counter_init()
   is never used.

Fix this warning by removing the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER and stub function, and only include
the function realtime_counter_init() if CONFIG_SOC_OMAP5 is selected.

Cc: Santosh Shilimkar 

Reported-by: Tony Lindgren 
Signed-off-by: Jon Hunter 
---
 arch/arm/mach-omap2/Kconfig |4 
 arch/arm/mach-omap2/timer.c |7 ++-
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 813c267..ea88b7d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,9 +24,6 @@ config ARCH_OMAP2PLUS_TYPICAL
 config SOC_HAS_OMAP2_SDRC
bool "OMAP2 SDRAM Controller support"
 
-config SOC_HAS_REALTIME_COUNTER
-   bool "Real time free running counter"
-
 config ARCH_OMAP2
bool "TI OMAP2"
depends on ARCH_OMAP2PLUS
@@ -79,7 +76,6 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_SMP
-   select SOC_HAS_REALTIME_COUNTER
select COMMON_CLK
 
 comment "OMAP Core Type"
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b9cff72..a9f99e3 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -476,7 +476,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
gptimer_id, clksrc.rate);
 }
 
-#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+#ifdef CONFIG_SOC_OMAP5
 /*
  * The realtime counter also called master counter, is a free-running
  * counter, which is related to real time. It produces the count used
@@ -549,10 +549,7 @@ static void __init realtime_counter_init(void)
 
iounmap(base);
 }
-#else
-static inline void __init realtime_counter_init(void)
-{}
-#endif
+#endif /* CONFIG_SOC_OMAP5 */
 
 #define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
   clksrc_nr, clksrc_src)   \
-- 
1.7.10.4

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

[PATCH 0/3] ARM: OMAP2+: Timer build warnings and error fixes

[Jon Hunter]

Fixes for build warnings and errors seen with various kernel
configuration combinations.

Jon Hunter (3):
  ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
  ARM: OMAP4: Fix build error and warning in timer.c
  ARM: AM335x: Fix warning in timer.c

 arch/arm/mach-omap2/Kconfig |4 
 arch/arm/mach-omap2/timer.c |   12 ++--
 2 files changed, 6 insertions(+), 10 deletions(-)

-- 
1.7.10.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: [RFC PATCH 1/5] drivers : introduce device_path api

[Ming Lei]

On Wed, Nov 28, 2012 at 7:06 AM, Ming Lei  wrote:
>>> Also from my intuition, power domain should be involved in the problem,
>>> because these hard-wired and self-powered USB devices should have
>>> its own power domains, and the ehci-omap driver may enable/disable
>>> these power domains before adding the bus.
>>
>>
>> I don't know enough to have an opinion, but the arrangement on Panda is
>> literally a linear regulator is being controlled by a gpio, which fits into
>> struct regulator model.  What else would a power domain for that buy us?
>
> One problem is that you are addressing to, another is that we may extend
> Tianyu's per port power off/on mechanism into non-acpi world.
>
> Considered that our discussion has been extended to general case instead
> of pandaboard only, there might be several bus devices which have different
> power control method, which should be the idea of power domain.
>
> I have a draft idea and let me describe it by a pseudo_patch, see below:

Sorry, looks sending it too quick, the below pseudo_patch may be
more readable about the idea.

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ac17a7c..c187a11 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -184,6 +184,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
int irq;
int i;
charsupply[7];
+   struct port_power_domain*ppd;

if (usb_disabled())
return -ENODEV;
@@ -220,6 +221,17 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
goto err_io;
}

+   /*
+* register usb per port power domain and enable power on
+* this port, to which only hardwired and self-powered device
+* attached. And the platform code should provide the
+* port power domain list to the usb host controller driver.
+*/
+   list_for_each_entry(ppd, &pdata->port_power_domain, list) {
+   usb_register_port_pm_domain(&hcd->self, ppd);
+   usb_enable_port_pm_domain(&hcd->self, ppd);
+   }
+
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
@@ -289,6 +301,12 @@ static int ehci_hcd_omap_remove(struct
platform_device *pdev)
struct device *dev  = &pdev->dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_hcd_omap_platform_data *pdata   = dev->platform_data;
+   struct port_power_domain*ppd;
+
+   list_for_each_entry(ppd, &pdata->port_power_domain, list) {
+   usb_disable_port_pm_domain(&hcd->self, ppd);
+   usb_unregister_port_pm_domain(&hcd->self, ppd);
+   }

usb_remove_hcd(hcd);
disable_put_regulator(dev->platform_data);
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..30516c9 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -47,6 +47,8 @@ struct ehci_hcd_omap_platform_data {
int reset_gpio_port[OMAP3_HS_USB_PORTS];
struct regulator*regulator[OMAP3_HS_USB_PORTS];
unsignedphy_reset:1;
+
+   struct list_headport_power_domain;
 };

 struct ohci_hcd_omap_platform_data {
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 608050b..6b86d01 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -448,6 +448,39 @@ extern void usb_disconnect(struct usb_device **);
 extern int usb_get_configuration(struct usb_device *dev);
 extern void usb_destroy_configuration(struct usb_device *dev);

+/*
+ * Only used for describing power domain which provide power to
+ * hardwired self-powered devices
+ */
+struct port_power_domain {
+   struct list_head list;
+   struct usb_bus *bus;
+
+   /*
+* physical port path, and the power domain of 'port_power' provides
+* power on the device attatched to the last non-zero port(Pn-1) of
+* the n-1 tier hub, the first number(P1) is the root hub port in
+* the path, and the second number(P2) is the port number on the
+* second tier hub, ..., until the last number Pn which is zero always.
+*/
+   char port_path[32]; /* P1-P2-..Pn-1-Pn */
+
+   /*
+* struct power_domain should be generic power thing, and should be
+* defined in device power core, maybe it can reuse some kind of
+* current power domain structure.
+*
+* Many ports can share one same power domain, so make the below field
+* as pointer.
+*/
+   struct power_domain *port_power;
+};
+
+extern int usb_register_port_pm_doma

Re: [rtc-linux] [PATCH v3 1/5] rtc: OMAP: Add system pm_power_off to rtc driver

[Andrew Morton]

On Tue, 20 Nov 2012 15:18:43 +0530
AnilKumar Ch  wrote:

> From: Colin Foe-Parker 
> 
> Add system power off control to rtc driver which is the in-charge
> of controlling the BeagleBone system power. The power_off routine
> can be hooked up to "pm_power_off" system call.
> 
> System power off sequence:-
> * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
> * Enable PMIC_POWER_EN in rtc module
> * Set rtc ALARM2 time
> * Enable ALARM2 interrupt
> 
> Added while (1); after the above steps to make sure that no other
> process acquire cpu. Otherwise we might see an unexpected behaviour
> because we are shutting down all the power rails of SoC except RTC.
> 
> Signed-off-by: Colin Foe-Parker 
> [anilku...@ti.com: move poweroff additions to rtc driver]
> Signed-off-by: AnilKumar Ch 
>
> ...
>
> +/*
> + * rtc_power_off: Set the pmic power off sequence. The RTC generates
> + * pmic_pwr_enable control, which can be used to control an external
> + * PMIC.
> + */
> +static void rtc_power_off(void)
> +{
> + u32 val;
> + struct rtc_time tm;
> + spinlock_t lock;

What on earth?

> + unsigned long flags, time;
> +
> + spin_lock_init(&lock);
> +
> + /* Set PMIC power enable */
> + val = readl(rtc_base + OMAP_RTC_PMIC_REG);
> + writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
> +
> + /* Read rtc time */
> + omap_rtc_read_time(NULL, &tm);
> +
> + /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
> + rtc_tm_to_time(&tm, &time);
> +
> + /* Add shutdown time to the current value */
> + time += SHUTDOWN_TIME_SEC;
> +
> + /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
> + rtc_time_to_tm(time, &tm);
> +
> + if (tm2bcd(&tm) < 0)
> + return;
> +
> + pr_info("System will go to power_off state in approx. %d secs\n",
> + SHUTDOWN_TIME_SEC);
> +
> + /*
> +  * pmic_pwr_enable is controlled by means of ALARM2 event. So here
> +  * programming alarm2 expiry time and enabling alarm2 interrupt
> +  */
> + rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
> + rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
> + rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
> + rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
> + rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
> + rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
> +
> + /* Enable alarm2 interrupt */
> + val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
> + writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
> + rtc_base + OMAP_RTC_INTERRUPTS_REG);
> +
> + /* Do not allow to execute any other task */
> + spin_lock_irqsave(&lock, flags);
> + while (1);

I suspect this doesn't do what you want it to do.

Firstly, please provide adequate code comments here so that code
readers do not also need to be mind readers.

If you want to stop this CPU dead in its tracks (why?) then

local_irq_disable();
while (1)
;   /* Note correct code layout */

will do it.  But it means that the NMI watchdog (if present) will come
along and whack the machine in the head a few seconds later.  And this
does nothing to stop other CPUs.

But not being a mind reader, I'm really at a loss to suggest what
should be done here.  

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Ming Lei]

On Wed, Nov 28, 2012 at 1:55 AM, Andy Green  wrote:
> On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
>
>> On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern 
>> wrote:
>>>
>>> On Tue, 27 Nov 2012, Ming Lei wrote:
>>>
 IMO, all matches mean the devices are inside the ehci-omap bus, so
 the direct/simple way is to enable/disable the regulators in the probe()
 and
 remove() of ehci-omap controller driver.
>>>
>>>
>>> When this discussion started, Felipe argued against such an approach.
>>> He pointed out that the same chip could be used in other platforms, and
>>> then the code added to ehci-omap.c would have to be duplicated in
>>> several other places.
>>
>>
>>  From Andy's implementation, the 'general' code is to enable/disable
>> the regulators(patch 3/5), I am wondering if it is general enough, so the
>> 'duplicated' code are just several lines of
>> regulator_enable/regulator_disable,
>> which should be implemented in many platform drivers.
>
>
> Fair enough; my main interest was in the device path side when writing the
> patches.  I stuck enough in one place to confirm the series works on Panda
> case for power control.  So long as it doesn't get obsessed with just
> regulators some common implementation that seems to be discussed will be
> better.
>
> (BTW let me take this opportunity to thank you for your great urbs-in-flight
> limiting patch on smsc95xx a while back)
>
>
>> Also from my intuition, power domain should be involved in the problem,
>> because these hard-wired and self-powered USB devices should have
>> its own power domains, and the ehci-omap driver may enable/disable
>> these power domains before adding the bus.
>
>
> I don't know enough to have an opinion, but the arrangement on Panda is
> literally a linear regulator is being controlled by a gpio, which fits into
> struct regulator model.  What else would a power domain for that buy us?

One problem is that you are addressing to, another is that we may extend
Tianyu's per port power off/on mechanism into non-acpi world.

Considered that our discussion has been extended to general case instead
of pandaboard only, there might be several bus devices which have different
power control method, which should be the idea of power domain.

I have a draft idea and let me describe it by a pseudo_patch, see below:

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index ac17a7c..c97538f 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -220,6 +220,11 @@ static int ehci_hcd_omap_probe(struct
platform_device *pdev)
goto err_io;
}

+   list_for_each_entry(ppd, pdata, port_power_domain) {
+   usb_unregister_port_pm_domain(&hcd->self, ppd);
+   ppd->port_power.power_on(ppd, on)
+   }
+
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
@@ -290,6 +295,11 @@ static int ehci_hcd_omap_remove(struct
platform_device *pdev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct ehci_hcd_omap_platform_data *pdata   = dev->platform_data;

+   list_for_each_entry(ppd, pdata, port_power_domain) {
+   usb_unregister_port_pm_domain(&hcd->self, ppd);
+   ppd->port_power.power_off(ppd, on)
+   }
+
usb_remove_hcd(hcd);
disable_put_regulator(dev->platform_data);
iounmap(hcd->regs);
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..30516c9 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -47,6 +47,8 @@ struct ehci_hcd_omap_platform_data {
int reset_gpio_port[OMAP3_HS_USB_PORTS];
struct regulator*regulator[OMAP3_HS_USB_PORTS];
unsignedphy_reset:1;
+
+   struct list_headport_power_domain;
 };

 struct ohci_hcd_omap_platform_data {
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 608050b..89c31c0 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -448,6 +448,30 @@ extern void usb_disconnect(struct usb_device **);
 extern int usb_get_configuration(struct usb_device *dev);
 extern void usb_destroy_configuration(struct usb_device *dev);

+/*
+ * Only apply in hardwired self-powered devices in bus
+ */
+struct port_power_domain {
+   struct usb_bus *bus;
+   /*
+* physical port location in which the power domain provides power on 
it,
+* the first number is the root hub port, and the second number is the
+* port number on the second layer hub, ...
+*/
+   char port_info[32]; /*N-N-N...*/
+
+   /*
+* struct power_domain should be generic power thing, and should be
+* defined in power core
+*/
+   struct power_domain port_power;
+};
+
+extern i

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Wed, 28 Nov 2012, Andy Green wrote:

> OK.  So I try to sketch it out iteractively to try to get in sync:
> 
> device.h:
> 
>   enum asset_event {
>   AE_PROBED,
>   AE_REMOVED
>   };
> 
>   struct device_asset {
>   char *name; /* name of regulator, clock, etc */
>   void *asset; /* regulator, clock, etc */
>   int (*handler)(struct device *dev_owner, enum asset_event 
> asset_event, 
> struct device_asset *asset);
>   };

Another possibility is to have two handlers: one for pre-probe and the
other for post-remove.  Then of course asset_event wouldn't be needed.  
Linus tends to prefer this strategy -- separate functions for separate
events.  That's why struct dev_pm_ops has so many method pointers.

>   struct device {
>   ...
>   struct device_asset *assets;

Or a list instead of a NULL-terminated array.  It depends on whether
people will want to add or remove assets dynamically.  For now an array
would be fine.

>   ...
>   };
> 
> 
> drivers/base/dd.c | really_probe():
> 
> ...
>   struct device_asset *asset;
> ...
>   asset = dev->assets;
>   while (asset && asset->name) {

Maybe it would be better to test asset->handler.  Some assets might not 
need names.

>   if (asset->handler(dev, AE_PROBED, asset)) {
>   /* clean up and bail */
>   }
>   asset++;
>   }
> 
>   /* do probe */
> ...
> 
> 
> drivers/base/dd.c | __device_release_driver:  (is this really the best 
> place to oppose probe()?)

The right place is just after the remove method is called, so yes.

> ...
>   struct device_asset *asset;
> ...
> 
>   /* call device ->remove() */
> ...
>   asset = dev->assets;
>   while (asset && asset->name) {
>   asset->handler(dev, AE_REMOVED, asset);
>   asset++;
>   }

It would be slightly safer to iterate in reverse order.

> ...
> 
> 
> board file:
> 
>   static struct regulator myreg = {
>   .name = "mydevice-regulator",
>   };
> 
>   static struct device_asset mydevice_assets[] = {
>   {
>   .name = "mydevice-regulator",
>   .handler = regulator_default_asset_handler,
>   },
>   { }
>   };
> 
>   static struct platform_device mydevice = {
>   ...
>   .dev = {
>   .assets = mydevice_assets,
>   },
>   ...
>   };
> 
> 
> regulator code:
> 
> int regulator_default_asset_handler(struct device *dev_owner, enum 
> asset_event asset_event, struct device_asset *asset)
> {
>   struct regulator **reg = &asset->asset;
>   int n;
> 
>   switch (asset_event) {
>   case AE_PROBED:
>   *reg = regulator_get(dev_owner, asset->name);
>   if (IS_ERR(*reg))
>   return *reg;

PTR_ERR.

>   n = regulator_enable(*reg);
>   if (n < 0)
>   regulator_put(*reg);
>   return n;
> 
>   case AE_REMOVED:
>   regulator_put(*reg);
>   break;
>   }
> 
>   return 0;
> }
> EXPORT_SYMBOL_GPL(regulator_default_asset_handler);
> 
> 
> The subsystems that can expect to get used (clock...) might each want to 
> define a default handler like the one for regulator.  That'll be an end 
> to the code duplication issue.  The user can still do his own handler if 
> he wants.
> 
> I put a name field in so we can use regulator_get() nicely, we don't 
> need access to the object pointer or that it exists at boardfile-time 
> that way either.  But I can see it's arguable.

It hadn't occurred to me, but it seems like a good idea.

Yes, overall this is almost exactly what I had in mind.

> >> Throwing out the path stuff and limiting this to platform_device means
> >> you cannot bind to dynamically created objects like hub or anything
> >> downstream of a hub.  So Felipe's identification of the hub as the
> >> happening place to do this is out of luck.
> >
> > Greg pointed out that this could be useful for arbitrary devices, not
> > just platform devices, so it could be applied to dynamically created
> > objects.
> 
> Well that is cool, but to exploit that in the dynamic object case 
> arrangements for identifying the appropriate object has appeared are 
> needed.

For example, this scheme wouldn't lend itself easily to associating the
regulator with the particular root-hub port that the LAN95xx is
attached to.  I can't think of any reasonable way to do that other than
the approaches we have already considered.

>  We have a nice array of platform_devices nicely there in the 
> board file we can attach assets to like "pdev[1].dev.assets = xxx;" but 
> that's not there in dynamic device case.  Anyway this sounds like what 
> we're discussing can be well worth establishing and might lead to that 
> later.

Agreed.

Alan Ste

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green]

On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:

On Wed, 28 Nov 2012, Andy Green wrote:


Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone.  That leaves plenty of other ways to approach
this problem.


It's sage advice, but there is zero code provided in my patches that
"relies on pathnames in sysfs".


In your 1/5 patch, _device_path_generate() concatenates device name
strings, starting from a device root and separating elements with '/'
characters.  Isn't that the same as a sysfs pathname?


It's nothing to do with sysfs... yes some unrelated bits of sysfs also 
walk the device path.  If we want to talk about how fragile the device 
path is as an id scheme over time we need to talk about likelihood of 
individual device names changing, not "sysfs".  Anyway -->



Basically, what you want is for something related to device A (the
regulator or the GPIO) to happen whenever device B (the ehci-omap.0
platform device) is bound to a driver.  The most straightforward way to
arrange this is for A's driver to have a callback that is invoked
whenever B is bound or unbound.  The most straightforward way to
arrange _that_ is to allow each platform_device to have a list of
callbacks.


Sorry I didn't really understand this proposal yet.  You want "A", the
regulator, driver to grow a callback function that gets called when the
targeted platform_device ("B", ehci-omap.0) probe happens.  Could you
expand what the callback prototype or new members in the struct might
look like?  It's your tuple thing or we pass it an opaque pointer that
is the struct regulator * or suchlike?


Well, it won't be exactly the same as the tuple thing because no
strings will be involved, but it would be similar.  The callback would
receive an opaque pointer (presumably to the regulator) and a device
pointer (the B device).


OK.  So I try to sketch it out iteractively to try to get in sync:

device.h:

enum asset_event {
AE_PROBED,
AE_REMOVED
};

struct device_asset {
char *name; /* name of regulator, clock, etc */
void *asset; /* regulator, clock, etc */
		int (*handler)(struct device *dev_owner, enum asset_event asset_event, 
struct device_asset *asset);

};

struct device {
...
struct device_asset *assets;
...
};


drivers/base/dd.c | really_probe():

...
struct device_asset *asset;
...
asset = dev->assets;
while (asset && asset->name) {
if (asset->handler(dev, AE_PROBED, asset)) {
/* clean up and bail */
}
asset++;
}

/* do probe */
...


drivers/base/dd.c | __device_release_driver:  (is this really the best 
place to oppose probe()?)


...
struct device_asset *asset;
...

/* call device ->remove() */
...
asset = dev->assets;
while (asset && asset->name) {
asset->handler(dev, AE_REMOVED, asset);
asset++;
}
...


board file:

static struct regulator myreg = {
.name = "mydevice-regulator",
};

static struct device_asset mydevice_assets[] = {
{
.name = "mydevice-regulator",
.handler = regulator_default_asset_handler,
},
{ }
};

static struct platform_device mydevice = {
...
.dev = {
.assets = mydevice_assets,
},
...
};


regulator code:

int regulator_default_asset_handler(struct device *dev_owner, enum 
asset_event asset_event, struct device_asset *asset)

{
struct regulator **reg = &asset->asset;
int n;

switch (asset_event) {
case AE_PROBED:
*reg = regulator_get(dev_owner, asset->name);
if (IS_ERR(*reg))
return *reg;
n = regulator_enable(*reg);
if (n < 0)
regulator_put(*reg);
return n;

case AE_REMOVED:
regulator_put(*reg);
break;
}

return 0;
}
EXPORT_SYMBOL_GPL(regulator_default_asset_handler);


The subsystems that can expect to get used (clock...) might each want to 
define a default handler like the one for regulator.  That'll be an end 
to the code duplication issue.  The user can still do his own handler if 
he wants.


I put a name field in so we can use regulator_get() nicely, we don't 
need access to the object pointer or that it exists at boardfile-time 
that way either.  But I can see it's arguable.



Throwing out the path stuff and limiting this to platform_device means
you cannot bind to dynamically created objects like hub or anything
downstream of a hub.  So Felipe's identification of the hub as

Re: omap DSS fails with tft410 driver panel?

[Steve Sakoman]

On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen  wrote:

> Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?

That was my guess too, and after some digging I am fairly certain this
is the case.

> Anyway, I guess it's a valid thing to configure the overlay with
> paddr == 0 when the overlay is disabled. In fact, paddr == 0 check
> is in any case quite limited, as if the board's physical memory
> doesn't contain the given paddr, the DSS HW will fail just as it
> would for paddr 0. So the paddr == 0 check is more of a sanity check
> than a comprehensive test.
>
> Can you try the following patch:
>
> diff --git a/drivers/video/omap2/dss/overlay.c 
> b/drivers/video/omap2/dss/overlay.c
> index 45f4994..e271e28 100644
> --- a/drivers/video/omap2/dss/overlay.c
> +++ b/drivers/video/omap2/dss/overlay.c
> @@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
>  int dss_ovl_simple_check(struct omap_overlay *ovl,
> const struct omap_overlay_info *info)
>  {
> -   if (info->paddr == 0) {
> -   DSSERR("check_overlay: paddr cannot be 0\n");
> -   return -EINVAL;
> -   }
> -
> if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
> if (info->out_width != 0 && info->width != info->out_width) {
> DSSERR("check_overlay: overlay %d doesn't support "


I tried something similar over the weekend (just removed the return so
I still got the error printout) and found that the simple_check failed
in 2 more places.

Here is the patch I ended up with to get a successful simple_check:

--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -610,7 +610,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
 {
 if (info->paddr == 0) {
 DSSERR("check_overlay: paddr cannot be 0\n");
-return -EINVAL;
+//return -EINVAL;
 }

 if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
@@ -630,7 +630,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
 if ((ovl->supported_modes & info->color_mode) == 0) {
 DSSERR("check_overlay: overlay %d doesn't support mode %d\n",
 ovl->id, info->color_mode);
-return -EINVAL;
+//return -EINVAL;
 }

 if (info->zorder >= omap_dss_get_num_overlays()) {
@@ -641,7 +641,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
 if (dss_feat_rotation_type_supported(info->rotation_type) == 0) {
 DSSERR("check_overlay: rotation type %d not supported\n",
 info->rotation_type);
-return -EINVAL;
+//return -EINVAL;
 }

 return 0;

After digging a little more it turned out that the continual
restarting of X wasn't due to the above error, but to a build system
glitch.  So the above issue doesn't block a basic X session.

I checked XVideo both with and without the above patch and it is
broken in both cases.  I'm beginning to suspect that this might be a
user space bug and will do a little investigation.

Because of this I don't think any dss changes should be made at this point.

During my testing I think I uncovered another issue :-(

I set omapdss.def_disp=lcd43 on the kernel command line to see if the
behavior changed with the LCD as the default device.

What I encountered was a null pointer crash:

[3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R
[3.488250] Unable to handle kernel NULL pointer dereference at
virtual address 0028
[3.496765] pgd = c0004000
[3.499603] [0028] *pgd=
[3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM
[3.508605] Modules linked in:
[3.511810] CPU: 0Not tainted  (3.6.0 #1)
[3.516357] PC is at dss_mgr_check_timings+0x4/0x30
[3.521484] LR is at dpi_check_timings+0x18/0xb8
[3.526336] pc : []lr : []psr: 4013
[3.526336] sp : dec2bd88  ip :   fp : def7e180
[3.538330] r10: def951c0  r9 : def61000  r8 : de41b858
[3.543823] r7 : dec2bdfc  r6 : c06c0a50  r5 : dec2be00  r4 : deea1cd4
[3.550659] r3 : dec1ba40  r2 : dec2bdc8  r1 : dec2be00  r0 : 
[3.557495] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[3.565155] Control: 10c5387d  Table: 80004019  DAC: 0015
[3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0)
[3.577270] Stack: (0xdec2bd88 to 0xdec2c000)
[3.581848] bd80:   dec1ba40 c0260dc0 
deea1cd4 def7e180 c046a7d0
[3.590423] bda0:     deea1cd4
c06c0a50 dec2be00 dec2bdfc
[3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50
 de41b800 c046749c
[3.607513] bde0: 003d c0495788 0018  0010
def98640 dec00140 
[3.616088] be00: 03000400 dac0 00300020 00040050 0003000f
0001  
[3.624664] be20: 0001   c0459380 deea257c
c06c0d00 dec2be50 
[3.633209] be40: c025cc10 c029a98c  c029ae80 de

Re: [PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected

[Richard Cochran]

On Tue, Nov 27, 2012 at 11:23:40PM +0530, Mugunthan V N wrote:
>   CC  drivers/net/ethernet/ti/cpsw.o
> drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
> drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'
> 
> The build warning is generated when CPTS is not selected in Kernel Build.
> Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv
> 
> Signed-off-by: Mugunthan V N 

Thanks for this fix.

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Wed, 28 Nov 2012, Andy Green wrote:

> > Greg's advice was simply not to rely on pathnames in sysfs because they
> > aren't fixed in stone.  That leaves plenty of other ways to approach
> > this problem.
> 
> It's sage advice, but there is zero code provided in my patches that 
> "relies on pathnames in sysfs".

In your 1/5 patch, _device_path_generate() concatenates device name
strings, starting from a device root and separating elements with '/'
characters.  Isn't that the same as a sysfs pathname?

> > Basically, what you want is for something related to device A (the
> > regulator or the GPIO) to happen whenever device B (the ehci-omap.0
> > platform device) is bound to a driver.  The most straightforward way to
> > arrange this is for A's driver to have a callback that is invoked
> > whenever B is bound or unbound.  The most straightforward way to
> > arrange _that_ is to allow each platform_device to have a list of
> > callbacks.
> 
> Sorry I didn't really understand this proposal yet.  You want "A", the 
> regulator, driver to grow a callback function that gets called when the 
> targeted platform_device ("B", ehci-omap.0) probe happens.  Could you 
> expand what the callback prototype or new members in the struct might 
> look like?  It's your tuple thing or we pass it an opaque pointer that 
> is the struct regulator * or suchlike?

Well, it won't be exactly the same as the tuple thing because no 
strings will be involved, but it would be similar.  The callback would 
receive an opaque pointer (presumably to the regulator) and a device 
pointer (the B device).

> Throwing out the path stuff and limiting this to platform_device means 
> you cannot bind to dynamically created objects like hub or anything 
> downstream of a hub.  So Felipe's identification of the hub as the 
> happening place to do this is out of luck.

Greg pointed out that this could be useful for arbitrary devices, not
just platform devices, so it could be applied to dynamically created
objects.

As for what Felipe said...  He suggested doing this when the hub driver 
binds to the controller's root hub.  The root hub is created when the 
controller's driver registers the new USB bus.  This happens as part of 
the driver's probe routine.  So what I have been talking about is very 
similar (in terms of when it happens) to what Felipe wanted.

Besides, Felipe wasn't thinking in the most general terms.  (In fact,
at first he confused the root hub with the LAN95xx's hub.)  There's no
reason to restrict this sort of thing to USB hubs (or to regulators,
for that matter).  The driver core is the right place for it.

Alan Stern

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green]

On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:

On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern  wrote:

On Tue, 27 Nov 2012, Ming Lei wrote:


IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the probe() and
remove() of ehci-omap controller driver.


When this discussion started, Felipe argued against such an approach.
He pointed out that the same chip could be used in other platforms, and
then the code added to ehci-omap.c would have to be duplicated in
several other places.


 From Andy's implementation, the 'general' code is to enable/disable
the regulators(patch 3/5), I am wondering if it is general enough, so the
'duplicated' code are just several lines of regulator_enable/regulator_disable,
which should be implemented in many platform drivers.


Fair enough; my main interest was in the device path side when writing 
the patches.  I stuck enough in one place to confirm the series works on 
Panda case for power control.  So long as it doesn't get obsessed with 
just regulators some common implementation that seems to be discussed 
will be better.


(BTW let me take this opportunity to thank you for your great 
urbs-in-flight limiting patch on smsc95xx a while back)



Also from my intuition, power domain should be involved in the problem,
because these hard-wired and self-powered USB devices should have
its own power domains, and the ehci-omap driver may enable/disable
these power domains before adding the bus.


I don't know enough to have an opinion, but the arrangement on Panda is 
literally a linear regulator is being controlled by a gpio, which fits 
into struct regulator model.  What else would a power domain for that 
buy us?



We should have a more generic solution in a more central location, like
the device core.

For example, each struct platform_device could have a list of resources
to be enabled when the device is bound to a driver and disabled when
the device is unbound.  Such a list could include regulators, clocks,
and whatever else people can invent.

In this case, when it is created the ehci-omap.0 platform device could
get an entry pointing to the LAN95xx's regulator.  Then the regulator
would automatically be turned on when the platform device is bound to
the ehci-omap driver.


The LAN95xx's regulator is still platform dependent(even for same LAN95xx
USB devices on different platforms(omap, tegra, ..)) , so I am wondering
why we don't enable it directly in probe() of ehci-omap.0 platform device?


I didn't get this point, ehci-omap doesn't help if it's non-omap platform.

-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

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

[PATCH 1/1] net: ethernet: cpsw: fix build warnings for CPSW when CPTS not selected

[Mugunthan V N]

  CC  drivers/net/ethernet/ti/cpsw.o
drivers/net/ethernet/ti/cpsw.c: In function 'cpsw_ndo_ioctl':
drivers/net/ethernet/ti/cpsw.c:881:20: warning: unused variable 'priv'

The build warning is generated when CPTS is not selected in Kernel Build.
Fixing by passing the net_device pointer to cpts IOCTL instead of passing priv

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpsw.c |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 02c2477..c9714e1 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -812,8 +812,9 @@ static void cpsw_hwtstamp_v2(struct cpsw_priv *priv)
__raw_writel(ETH_P_1588, &priv->regs->ts_ltype);
 }
 
-static int cpsw_hwtstamp_ioctl(struct cpsw_priv *priv, struct ifreq *ifr)
+static int cpsw_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
 {
+   struct cpsw_priv *priv = netdev_priv(dev);
struct cpts *cpts = &priv->cpts;
struct hwtstamp_config cfg;
 
@@ -878,14 +879,12 @@ static int cpsw_hwtstamp_ioctl(struct cpsw_priv *priv, 
struct ifreq *ifr)
 
 static int cpsw_ndo_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
 {
-   struct cpsw_priv *priv = netdev_priv(dev);
-
if (!netif_running(dev))
return -EINVAL;
 
 #ifdef CONFIG_TI_CPTS
if (cmd == SIOCSHWTSTAMP)
-   return cpsw_hwtstamp_ioctl(priv, req);
+   return cpsw_hwtstamp_ioctl(dev, req);
 #endif
return -ENOTSUPP;
 }
-- 
1.7.0.4

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

Re: [PATCH] Don't mark shared helper functions as inline

[Russ Dill]

On Mon, Nov 26, 2012 at 11:57 AM, Mike Turquette  wrote:
>
> Quoting Russ Dill (2012-11-26 11:20:09)
> > The helper functions that access the opaque struct clk should
> > not be marked inline since they are contained in clk.c, but expected
> > to be used by other compilation units. This causes compile errors
> > under gcc-4.7
> >
> > In file included from arch/arm/mach-omap2/clockdomain.c:25:0:
> > arch/arm/mach-omap2/clockdomain.c: In function ‘clkdm_clk_disable’:
> > include/linux/clk-provider.h:338:12: error: inlining failed in call to 
> > always_inline ‘__clk_get_enable_count’: function body not available
> > arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here
> > make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
> > make: *** [arch/arm/mach-omap2] Error 2
> >
>
> Hi Russ,
>
> A fix for this was merged into rc7.  See 93532c8a, "clk: remove inline
> usage from clk-provider.h".
>
> Regardless, I'm still considering this patch.  I've heard many times
> that we should trust the compiler to optimize for us and some folks look
> down on inlining in general.  If anyone has an opinion on removing
> inlines from the common clk core then please do speak up.
>
> Russ, can you update to the latest rc and verify if that fix is enough
> for you?

Yes, that commit fixes the compile issue too. I'd go with the more
complete removal of inlines though. If you have a declaration in a
header, it makes no sense to call it inline in the .c

> Regards,
> Mike
>
> >
> > Signed-off-by: Russ Dill 
> > ---
> >  drivers/clk/clk.c| 14 +++---
> >  include/linux/clk-provider.h |  4 ++--
> >  2 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 56e4495e..ed01746 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -249,32 +249,32 @@ late_initcall(clk_disable_unused);
> >
> >  /***helper functions   ***/
> >
> > -inline const char *__clk_get_name(struct clk *clk)
> > +const char *__clk_get_name(struct clk *clk)
> >  {
> > return !clk ? NULL : clk->name;
> >  }
> >
> > -inline struct clk_hw *__clk_get_hw(struct clk *clk)
> > +struct clk_hw *__clk_get_hw(struct clk *clk)
> >  {
> > return !clk ? NULL : clk->hw;
> >  }
> >
> > -inline u8 __clk_get_num_parents(struct clk *clk)
> > +u8 __clk_get_num_parents(struct clk *clk)
> >  {
> > return !clk ? -EINVAL : clk->num_parents;
> >  }
> >
> > -inline struct clk *__clk_get_parent(struct clk *clk)
> > +struct clk *__clk_get_parent(struct clk *clk)
> >  {
> > return !clk ? NULL : clk->parent;
> >  }
> >
> > -inline int __clk_get_enable_count(struct clk *clk)
> > +int __clk_get_enable_count(struct clk *clk)
> >  {
> > return !clk ? -EINVAL : clk->enable_count;
> >  }
> >
> > -inline int __clk_get_prepare_count(struct clk *clk)
> > +int __clk_get_prepare_count(struct clk *clk)
> >  {
> > return !clk ? -EINVAL : clk->prepare_count;
> >  }
> > @@ -300,7 +300,7 @@ out:
> > return ret;
> >  }
> >
> > -inline unsigned long __clk_get_flags(struct clk *clk)
> > +unsigned long __clk_get_flags(struct clk *clk)
> >  {
> > return !clk ? -EINVAL : clk->flags;
> >  }
> > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > index c127315..f9f5e9e 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk);
> >  struct clk_hw *__clk_get_hw(struct clk *clk);
> >  u8 __clk_get_num_parents(struct clk *clk);
> >  struct clk *__clk_get_parent(struct clk *clk);
> > -inline int __clk_get_enable_count(struct clk *clk);
> > -inline int __clk_get_prepare_count(struct clk *clk);
> > +int __clk_get_enable_count(struct clk *clk);
> > +int __clk_get_prepare_count(struct clk *clk);
> >  unsigned long __clk_get_rate(struct clk *clk);
> >  unsigned long __clk_get_flags(struct clk *clk);
> >  int __clk_is_enabled(struct clk *clk);
> > --
> > 1.8.0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green]

On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:

On Tue, 27 Nov 2012, Andy Green wrote:


I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.


We can get a notification about device creation and do things there.
But the cost of that is like the tuple suggestion, they'll only be able
to do a fixed thing like operate on regulators.


I'm not quite sure what you mean by that.  _Any_ function is capable of
doing only a fixed thing.


Actually the targeted device may have arbitrary associated assets like
generic GPIO to turn on a "flash" for built-in webcam controlled
out-of-band.  These also can be reached by known names.  And the driver
may wish to do things with them that are more complex than enable /
disable or follow logical lifecycle of the hub or whatever.


Let's worry about that when it arises.


However when the guidance from Greg is that we can do nothing except
complain at hardware designers for some reason I failed to quite
identify, I fear we are moving deckchairs on the titanic.


Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone.  That leaves plenty of other ways to approach
this problem.


It's sage advice, but there is zero code provided in my patches that 
"relies on pathnames in sysfs".



Basically, what you want is for something related to device A (the
regulator or the GPIO) to happen whenever device B (the ehci-omap.0
platform device) is bound to a driver.  The most straightforward way to
arrange this is for A's driver to have a callback that is invoked
whenever B is bound or unbound.  The most straightforward way to
arrange _that_ is to allow each platform_device to have a list of
callbacks.


Sorry I didn't really understand this proposal yet.  You want "A", the 
regulator, driver to grow a callback function that gets called when the 
targeted platform_device ("B", ehci-omap.0) probe happens.  Could you 
expand what the callback prototype or new members in the struct might 
look like?  It's your tuple thing or we pass it an opaque pointer that 
is the struct regulator * or suchlike?


Throwing out the path stuff and limiting this to platform_device means 
you cannot bind to dynamically created objects like hub or anything 
downstream of a hub.  So Felipe's identification of the hub as the 
happening place to do this is out of luck.


-Andy

--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Ming Lei]

On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern  wrote:
> On Tue, 27 Nov 2012, Ming Lei wrote:
>
>> IMO, all matches mean the devices are inside the ehci-omap bus, so
>> the direct/simple way is to enable/disable the regulators in the probe() and
>> remove() of ehci-omap controller driver.
>
> When this discussion started, Felipe argued against such an approach.
> He pointed out that the same chip could be used in other platforms, and
> then the code added to ehci-omap.c would have to be duplicated in
> several other places.

>From Andy's implementation, the 'general' code is to enable/disable
the regulators(patch 3/5), I am wondering if it is general enough, so the
'duplicated' code are just several lines of regulator_enable/regulator_disable,
which should be implemented in many platform drivers.

Also from my intuition, power domain should be involved in the problem,
because these hard-wired and self-powered USB devices should have
its own power domains, and the ehci-omap driver may enable/disable
these power domains before adding the bus.

>
> We should have a more generic solution in a more central location, like
> the device core.
>
> For example, each struct platform_device could have a list of resources
> to be enabled when the device is bound to a driver and disabled when
> the device is unbound.  Such a list could include regulators, clocks,
> and whatever else people can invent.
>
> In this case, when it is created the ehci-omap.0 platform device could
> get an entry pointing to the LAN95xx's regulator.  Then the regulator
> would automatically be turned on when the platform device is bound to
> the ehci-omap driver.

The LAN95xx's regulator is still platform dependent(even for same LAN95xx
USB devices on different platforms(omap, tegra, ..)) , so I am wondering
why we don't enable it directly in probe() of ehci-omap.0 platform device?


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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Greg KH]

On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
> On Tue, 27 Nov 2012, Ming Lei wrote:
> 
> > IMO, all matches mean the devices are inside the ehci-omap bus, so
> > the direct/simple way is to enable/disable the regulators in the probe() and
> > remove() of ehci-omap controller driver.
> 
> When this discussion started, Felipe argued against such an approach.  
> He pointed out that the same chip could be used in other platforms, and
> then the code added to ehci-omap.c would have to be duplicated in
> several other places.
> 
> We should have a more generic solution in a more central location, like 
> the device core.
> 
> For example, each struct platform_device could have a list of resources
> to be enabled when the device is bound to a driver and disabled when
> the device is unbound.  Such a list could include regulators, clocks,
> and whatever else people can invent.
> 
> In this case, when it is created the ehci-omap.0 platform device could
> get an entry pointing to the LAN95xx's regulator.  Then the regulator 
> would automatically be turned on when the platform device is bound to 
> the ehci-omap driver.
> 
> How does this sound?

That sounds much better, and it might come in handy for other types of
devices than platform devices, so feel free to put this on the core
'struct device' instead if needed.

thanks,

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

Re: [PATCH 1/1] ARM: OMAP: fix build error in arch/arm/mach-omap2/timer.c

[Jon Hunter]

On 11/27/2012 04:24 AM, Mugunthan V N wrote:
>   CC  arch/arm/mach-omap2/timer.o
> arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
> arch/arm/mach-omap2/timer.c:195:3: error: implicit declaration of function 
> 'prom_add_property'
> make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2

Thanks for sending. You may wish to mentioned that this is seen on
today's linux-next (I am seeing the same problem).

> fix for build break as the functions "prom_*_property" is renamed to
> of_*_property by the below patch
> 
> commit 79d1c712958f94372482ad74578b00f44e744c12
> Author: Nathan Fontenot 
> Date:   Tue Oct 2 16:58:46 2012 +
> 
> powerpc+of: Rename the drivers/of prom_* functions to of_*
> 
> Rename the prom_*_property routines of the generic OF code to 
> of_*_property.
> This brings them in line with the naming used by the rest of the OF code.
> 
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/mach-omap2/timer.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 099e406..5fd5e23 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -192,7 +192,7 @@ static struct device_node * __init 
> omap_get_timer_dt(struct of_device_id *match,
>   continue;
>   }
>  
> - prom_add_property(np, &device_disabled);
> + of_add_property(np, &device_disabled);
>   return np;
>   }

I tested this on the AM335x device and it is working fine. So ...

Acked-by: Jon Hunter 
Tested-by: Jon Hunter 

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

Re: need help debugging ISP problem

[Laurent Pinchart]

Hi Adam,

On Monday 05 November 2012 16:02:08 Adam Wozniak wrote:
> I'm working with a custom board based on an Overo WaterStorm com. The
> processor is a DM3730.  The kernel is 2.6.32 based.

2.6.32 very probably means you're using the old TI driver. Please don't. 
That's buggy and totally unsupported. I advice upgrading to the latest 
mainline kernel.

> I'm trying to stress test the camera ISP by rapidly opening and closing
> the video device with ( while true; do gst-launch v4l2src
> device=/dev/video0 ! video/x-raw-yuv,width=320,height=240 !
> ffmpegcolorspace ! pngenc snapshot=true ! fakesink; done )
> 
> After many iterations, I will see the kernel spit out:
> 
> [ 2502.802795] Unhandled fault: external abort on non-linefetch (0x1028)
> at 0xfa0bce04
> [ 2502.810516] Internal error: : 1028 [#1]
> [ ... ]
> [ 2502.846893] PC is at isp_reg_readl+0x18/0x20
> [ 2502.851196] LR is at isp_reg_readl+0x10/0x20
> [ ... ]
> [ 2503.296447] [] (isp_reg_readl+0x18/0x20) from []
> (isp_reg_and_or+0x1c/0x38)
> [ 2503.305206] [] (isp_reg_and_or+0x1c/0x38) from []
> (isppreview_config_cfa+0x38/0x90)
> [ 2503.314666] [] (isppreview_config_cfa+0x38/0x90) from
> [] (isppreview_config_datapath+0x134/0x330)
> [ 2503.325347] [] (isppreview_config_datapath+0x134/0x330)
> from [] (isppreview_s_pipeline+0x10/0xd0)
> [ 2503.336029] [] (isppreview_s_pipeline+0x10/0xd0) from
> [] (isp_s_pipeline+0x1d8/0x280)
> [ 2503.345672] [] (isp_s_pipeline+0x1d8/0x280) from
> [] (cammux_streamon+0x218/0xa28 [cammux])
> [ ... ]
> 
> 
> The register we're trying to access here is the ISP PRV_PCR.  If I try
> to add debug code to read ISP_CTRL right before the fault, the ISP_CTRL
> access faults in the same way (i.e. the whole ISP is borked, not just
> the previewer).
> 
> At first I thought the clocks were being disabled somehow, but tracking
> them seems to indicate that's not the case.  Adding an early return in
> arch/arm/mach/omap2/clock.c omap2_dflt_clk_disable() (i.e. to disable
> disabling of clocks) does NOT help.
> 
> What else might I be missing?  What is necessary to be able to read the
> ISP registers?

-- 
Regards,

Laurent Pinchart

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Tue, 27 Nov 2012, Andy Green wrote:

> > I don't know if such an approach would be sufficiently general for
> > future requirements, but it would solve the problem at hand.
> 
> We can get a notification about device creation and do things there. 
> But the cost of that is like the tuple suggestion, they'll only be able 
> to do a fixed thing like operate on regulators.

I'm not quite sure what you mean by that.  _Any_ function is capable of 
doing only a fixed thing.

> Actually the targeted device may have arbitrary associated assets like 
> generic GPIO to turn on a "flash" for built-in webcam controlled 
> out-of-band.  These also can be reached by known names.  And the driver 
> may wish to do things with them that are more complex than enable / 
> disable or follow logical lifecycle of the hub or whatever.

Let's worry about that when it arises.

> However when the guidance from Greg is that we can do nothing except 
> complain at hardware designers for some reason I failed to quite 
> identify, I fear we are moving deckchairs on the titanic.

Greg's advice was simply not to rely on pathnames in sysfs because they 
aren't fixed in stone.  That leaves plenty of other ways to approach 
this problem.

Basically, what you want is for something related to device A (the
regulator or the GPIO) to happen whenever device B (the ehci-omap.0
platform device) is bound to a driver.  The most straightforward way to
arrange this is for A's driver to have a callback that is invoked
whenever B is bound or unbound.  The most straightforward way to 
arrange _that_ is to allow each platform_device to have a list of 
callbacks.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe 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/16] OMAP USB Host cleanup

[Felipe Balbi]

On Tue, Nov 27, 2012 at 04:42:47PM +0200, Roger Quadros wrote:
> On 11/20/2012 01:22 AM, Kevin Hilman wrote:
> > Roger Quadros  writes:
> > 
> >> Kevin,
> >>
> >> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
> >>> Roger Quadros  writes:
> >>>
>  Hi,
> 
>  This patchset addresses the following
> 
>  - Avoid addressing clocks one by one by name and use a for loop + bunch
>    of cleanups.
>  - Get number of channels/ports dynamically either from revision register
>    or from platform data. Avoids getting clocks that are not present.
>  - Add OMAP5 and HSIC mode (Not tested)
>  - Save power on Panda when EHCI driver is not loaded.
> 
> >>>
> >>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
> >>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
> >>> fixed up the problem where CORE does not hit retention in idle when USB
> >>> host is enabled, even with no devices attached.
> >>>
> >>> Unfortunately, it didn't help. :(
> >>
> >> oh that's bad. But this series wasn't meant to fix that ;).
> > 
> > Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> > complain to the maintainers that a long-standing issue needs to be
> > addressed.
> > 
> 
> Kevin,
> 
> I gave a quick look at the issue. It seems that the High Speed USB Host
> module is kept in Software forced wakeup mode as a quick fix workaround
> to a bunch of silicon erratas. And we do nothing on USB global suspend.
> That's why CORE does not hit retention.
> 
> If we runtime_suspend the USB host module on USB global suspend then it
> will be put in Force Idle mode. This will allow CORE to hit retention
> but then we will no longer be able to detect USB device connect events.
> 
> So, till we have a better solution I will suggest to keep EHCI_HCD as a
> module in omap2plus_defconfig.

I guess that "better solution" would be I/O pads wakeup interrupts ? But
I don't think that's already in mainline, is it ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Tue, 27 Nov 2012, Ming Lei wrote:

> IMO, all matches mean the devices are inside the ehci-omap bus, so
> the direct/simple way is to enable/disable the regulators in the probe() and
> remove() of ehci-omap controller driver.

When this discussion started, Felipe argued against such an approach.  
He pointed out that the same chip could be used in other platforms, and
then the code added to ehci-omap.c would have to be duplicated in
several other places.

We should have a more generic solution in a more central location, like 
the device core.

For example, each struct platform_device could have a list of resources
to be enabled when the device is bound to a driver and disabled when
the device is unbound.  Such a list could include regulators, clocks,
and whatever else people can invent.

In this case, when it is created the ehci-omap.0 platform device could
get an entry pointing to the LAN95xx's regulator.  Then the regulator 
would automatically be turned on when the platform device is bound to 
the ehci-omap driver.

How does this sound?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe 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] usb: musb: dsps: header movement build error fix

[Afzal Mohammed]

"54db6ee ARM: OMAP2+: Introduce local usb.h" moved control module bit
definitions from plat/usb.h (which dsps glue was using) to a local
header in mach-omap2. And in parallel,
"c68bb4c usb: musb: dsps: control module handling (quirk)" added
control module handling capability to dsps glue driver that used
those control module bit definitions.

Integration of above two changes would cause build error in musb dsps
glue driver (they go through different trees upstream) as is seen now
in linux-next. Fix it by adding necessary definitions in dsps glue
driver.

Signed-off-by: Afzal Mohammed 
---

Hi Felipe,

This applies on top of your musb branch, please help this reach
mainline along with other musb dsps changes for coming merge window
so that they would not cause build error and so that we can have a
working usb in mainline for am335x (beaglebone) at the earliest.

Regards
Afzal

 drivers/usb/musb/musb_dsps.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e6f2ae8..f7d764d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -134,6 +134,11 @@ static const resource_size_t dsps_control_module_phys[] = {
DSPS_AM33XX_CONTROL_MODULE_PHYS_1,
 };
 
+#define USBPHY_CM_PWRDN(1 << 0)
+#define USBPHY_OTG_PWRDN   (1 << 1)
+#define USBPHY_OTGVDET_EN  (1 << 19)
+#define USBPHY_OTGSESSEND_EN   (1 << 20)
+
 /**
  * musb_dsps_phy_control - phy on/off
  * @glue: struct dsps_glue *
-- 
1.7.12

--
To unsubscribe from this list: send the line "unsubscribe 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/16] OMAP USB Host cleanup

[Roger Quadros]

On 11/20/2012 01:22 AM, Kevin Hilman wrote:
> Roger Quadros  writes:
> 
>> Kevin,
>>
>> On 11/16/2012 10:08 PM, Kevin Hilman wrote:
>>> Roger Quadros  writes:
>>>
 Hi,

 This patchset addresses the following

 - Avoid addressing clocks one by one by name and use a for loop + bunch
   of cleanups.
 - Get number of channels/ports dynamically either from revision register
   or from platform data. Avoids getting clocks that are not present.
 - Add OMAP5 and HSIC mode (Not tested)
 - Save power on Panda when EHCI driver is not loaded.

>>>
>>> Seeing the clock changes/cleanups, I gave this a spin on OMAP3
>>> (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it
>>> fixed up the problem where CORE does not hit retention in idle when USB
>>> host is enabled, even with no devices attached.
>>>
>>> Unfortunately, it didn't help. :(
>>
>> oh that's bad. But this series wasn't meant to fix that ;).
> 
> Oh, sorry.  Yeah, I didn't mean this as a nak.  Just an opportunity to
> complain to the maintainers that a long-standing issue needs to be
> addressed.
> 

Kevin,

I gave a quick look at the issue. It seems that the High Speed USB Host
module is kept in Software forced wakeup mode as a quick fix workaround
to a bunch of silicon erratas. And we do nothing on USB global suspend.
That's why CORE does not hit retention.

If we runtime_suspend the USB host module on USB global suspend then it
will be put in Force Idle mode. This will allow CORE to hit retention
but then we will no longer be able to detect USB device connect events.

So, till we have a better solution I will suggest to keep EHCI_HCD as a
module in omap2plus_defconfig.

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

Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

[Paul Walmsley]

On Tue, 27 Nov 2012, Mugunthan V N wrote:

>   CC  drivers/net/ethernet/ti/cpts.o
> drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file 
> or directory
> compilation terminated.
> make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> make[3]: *** [drivers/net/ethernet/ti] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
> 
> fix for build break as the header file is removed from plat-omap as part of
> the below patch
> 
> commit a135eaae524acba1509a3b19c97fae556e4da7cd
> Author: Paul Walmsley 
> Date:   Thu Sep 27 10:33:34 2012 -0600
> 
> ARM: OMAP: remove plat/clock.h
> 
> Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
> arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
> The goal here is to facilitate ARM single image kernels by removing
> includes via the "plat/" symlink.
> 
> Signed-off-by: Mugunthan V N 

Acked-by: Paul Walmsley 


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

Re: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support

[Peter Korsgaard]

> "Thierry" == Thierry Reding  writes:

Hi,

 >> There's several different situations:
 >> 
 >> - Platform without pinctrl support
 >> - Platform with pinctrl support but no pinmux specified in dt for device
 >> (E.G. pinmux setup in bootloader)
 >> - Pinmux specified in dt
 >> - Some kind of misconfiguration in dt
 >> 
 >> You could argue that devm_pinctrl_get_select_default() shouldn't return
 >> an error for the first situation, but how should it be able to know the
 >> difference between 2 and 4?

 Thierry> In case where the platform supports pinctrl but no pinmux is specified
 Thierry> for the device it should just assume that no pinmuxing is needed. That
 Thierry> sounds like the most logical behaviour to me. In those cases pinctrl
 Thierry> could just assume that the default has already been selected and not
 Thierry> return an error.

Agreed.

 Thierry> But you can't reasonably expect to cope with misconfigured DT
 Thierry> content.  Heck, there's no way for you to even know if it is
 Thierry> misconfigured.

With 'misconfigured DT' I just mean any kind of real error.


 Thierry> That said, I'm not sure how much of an issue this really
 Thierry> is. Pinmuxing is only used for functions local to a given
 Thierry> chip, right? So if an SoC supports pinctrl and a given
 Thierry> peripheral needs pinmuxing then we can reasonably assume that
 Thierry> your second case can't happen, can't we?

Well, peripherals only need pinmuxing if the bootloader didn't already
set it up in advance. We could naturally enforce people to add
"redundant" pinmux info to their .dts files, but I'm not sure I like
that idea.

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

Re: [PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

[Daniel Mack]

Hi Avinash,
Hi Peter,

On 23.11.2012 11:43, Philip, Avinash wrote:
> On Wed, Nov 21, 2012 at 15:45:23, Daniel Mack wrote:
>> On 20.11.2012 16:59, Peter Korsgaard wrote:
 "Daniel" == Daniel Mack  writes:

> Peter,
> 
> In patch [1], mtd: nand: omap2: Support for hardware BCH
> 
> ecc_layout made compatible with Rom Boot Loader ECC layout for am335x.
> 
> This action is based on is_elm_used flag.
> 
> Requirement of this flag is to identify the whether the platform
> ELM module & based on this configure ELM module if present.
> 
> But ideally BCH8 ecc lay out didn't have a dependency on ELM, it
> can work with software BCH ecc. RBL compatibility is missing
> in software BCH because of addition of constant polynomial to
> ecc vector. If we remove the dependency on erased page handling
> by ecc vector with constant polynomial, software BCH can do the
> job of RBL compatibility.
> 
> Ivan,
> Do you have any suggestions?
> Discussion for RBL compatibility found at [2].
> 
> It is good that software BCH also support RBL compatibility by suppressing
> constant polynomial modification. Then ecc layout can be selected from
> DT entry and error correction can be chosen between software/hardware
> depending on the availability of ELM hardware.
> Currently RBL BCH8 compatibility depends on the availability of ELM
> hardware. Later once software BCH start supporting RBL compatibility,
> we can remove  the check.
> 
>>
>> That is what I experienced, yes. The kernel was unable to parse NAND
>> pages that were written from U-Boot with bch8 hardware mode when the elm
>> module was not active. Maybe someone from TI can explain that? Giving it
>> a dedicated name would also solve the problem with the extra DT property.
> 
> Daniel,
> 
> Currently BCH8 is supported with software ecc error correction in mainline.
> The layout for BCH8 ECC layout is
> 0-1 -> BAD block markers
> 2-11-> oob free area
> 12-63-> BCH8 ECC.
> 
> RBL ECC layout is
> 0-1 -> BAD block markers
> 2-57-> BCH8 ecc layout
> 58-63-> OOB free area
> 
> As u-boot also maintain RBL ecc layout, write from U-boot
> and read from Linux requires compatibility with RBL ecc layout.
> The same is achieved in the patch [1], with by setting is_elm_used
> to true.
> 
> 1. https://lkml.org/lkml/2012/10/31/87
> 2. https://lkml.org/lkml/2012/10/11/20

So, after reading this, I'm still uncertain what's your preferred way of
handling the bindings here. Are you saying we should stick with the
is_elm_used flag, and subsequently care for BCH8 software mode
compatibility?

I would like to submit a new version soon, so it can be queued up for
the next merge window, and that decision is the last blocker currently
for sending out a new series.


Many thanks,
Daniel

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

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

On 11/27/2012 03:28 PM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
>>> in fact, I would convert this construct into a switch which would look
>>> like:
>>>
>>> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
>>>
>>> switch (port_mode[i]) {
>>> case OMAP4_P1_MODE_TLL:
>>> reg |= OMAP4_P1_MODE_TLL << i * 2;
>>> break;
>>> case OMAP_P1_MODE_HSIC:
>>> reg |= OMAP4_P1_MODE_HSIC << i * 2;
>>> break;
>>> }
>>>
>>
>> Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
>> it the way it was with if statement.
> 
> fair enough.
> 
>>> Also, it looks like the whoel for loop with port mode settings could be
>>> re-factored to a separate function to aid readability.
>>>
>>
>> it seems that the purpose of omap_usbhs_init() is to initialize
>> HOSTCONFIG so I see no point in adding another function for it. I can
>> clean it up for better readability though.
> 
> when functions get too big, it starts to become a little difficult to
> see bugs. Re-factoring parts of a bigger function, into smaller
> functions helps with that as long as the new functions are
> self-contained and logical. At the end of the day, GCC will inline the
> new smaller functions anyway.
> 

OK. I'll split the initialization of different revisions into different
functions.

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

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Felipe Balbi]

Hi,

On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
> > in fact, I would convert this construct into a switch which would look
> > like:
> > 
> > reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> > 
> > switch (port_mode[i]) {
> > case OMAP4_P1_MODE_TLL:
> > reg |= OMAP4_P1_MODE_TLL << i * 2;
> > break;
> > case OMAP_P1_MODE_HSIC:
> > reg |= OMAP4_P1_MODE_HSIC << i * 2;
> > break;
> > }
> > 
> 
> Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
> it the way it was with if statement.

fair enough.

> > Also, it looks like the whoel for loop with port mode settings could be
> > re-factored to a separate function to aid readability.
> > 
> 
> it seems that the purpose of omap_usbhs_init() is to initialize
> HOSTCONFIG so I see no point in adding another function for it. I can
> clean it up for better readability though.

when functions get too big, it starts to become a little difficult to
see bugs. Re-factoring parts of a bigger function, into smaller
functions helps with that as long as the new functions are
self-contained and logical. At the end of the day, GCC will inline the
new smaller functions anyway.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

[Richard Cochran]

On Tue, Nov 27, 2012 at 03:57:14PM +0530, Mugunthan V N wrote:
>   CC  drivers/net/ethernet/ti/cpts.o
> drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file 
> or directory
> compilation terminated.
> make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> make[3]: *** [drivers/net/ethernet/ti] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
> 
> fix for build break as the header file is removed from plat-omap as part of
> the below patch

Acked-by: Richard Cochran 
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP4430 produces boot warnings

[Tero Kristo]

On Tue, 2012-11-27 at 14:21 +0200, Tomi Valkeinen wrote:
> On 2012-11-27 13:56, Archit Taneja wrote:
> > On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:
> 
> >> Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
> >> modules are arranged, which module belongs to which power domain, etc.
> >>
> >> If it cannot be fixed in the arch code, I guess we could just have
> >> dss_get_ctx_loss_count(void) function which always returns the
> >> dss_core's ctx loss count, and define that on all the platforms omapdss
> >> is used, the dss_core's ctx loss count is the same as ctx loss count for
> >> all the dss submodules.
> >>
> >> I think the above is true for all OMAPs. But it feels like a hack too,
> >> but not as bad as the above patch.
> > 
> > Yes, a function taking in no platform device in dss's core.c would be
> > less hacky. I guess we would need this for now, because a solution in
> > omap_hwmod would be more complex and it may not be ready by the merge
> > window.
> 
> Ok. Can you cook up a patch and test it?
> 
> PM guys, does the above sound like an acceptable work-around?

This sounds like a good approach to me at least.

-Tero


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

Re: OMAP4430 produces boot warnings

[Tomi Valkeinen]

On 2012-11-27 13:56, Archit Taneja wrote:
> On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:

>> Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
>> modules are arranged, which module belongs to which power domain, etc.
>>
>> If it cannot be fixed in the arch code, I guess we could just have
>> dss_get_ctx_loss_count(void) function which always returns the
>> dss_core's ctx loss count, and define that on all the platforms omapdss
>> is used, the dss_core's ctx loss count is the same as ctx loss count for
>> all the dss submodules.
>>
>> I think the above is true for all OMAPs. But it feels like a hack too,
>> but not as bad as the above patch.
> 
> Yes, a function taking in no platform device in dss's core.c would be
> less hacky. I guess we would need this for now, because a solution in
> omap_hwmod would be more complex and it may not be ready by the merge
> window.

Ok. Can you cook up a patch and test it?

PM guys, does the above sound like an acceptable work-around?

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 10/16] mfd: omap-usb-host: Intialize all available ports

[Roger Quadros]

On 11/21/2012 03:52 PM, Felipe Balbi wrote:
> On Thu, Nov 15, 2012 at 04:34:08PM +0200, Roger Quadros wrote:
>> OMAPs till date can have upto 3 ports. We need to initialize
> 
> s/upto/up to/
> 
>> the port mode in HOSTCONFIG register for all of them.
> 
> why *all* of them ? Isn't it enough to initialize only the ones we're
> going to use ? If not, why ?
> 
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/mfd/omap-usb-host.c |   31 ---
>>  1 files changed, 12 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index c20234b..0d39bd7 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -67,12 +67,9 @@
>>  #define OMAP4_UHH_SYSCONFIG_NOSTDBY (1 << 4)
>>  #define OMAP4_UHH_SYSCONFIG_SOFTRESET   (1 << 0)
>>  
>> -#define OMAP4_P1_MODE_CLEAR (3 << 16)
>> +#define OMAP4_P1_MODE_MASK  (3 << 16)
> 
> changing this name isn't part of $SUBJECT.
> 
>>  #define OMAP4_P1_MODE_TLL   (1 << 16)
>>  #define OMAP4_P1_MODE_HSIC  (3 << 16)
>> -#define OMAP4_P2_MODE_CLEAR (3 << 18)
>> -#define OMAP4_P2_MODE_TLL   (1 << 18)
>> -#define OMAP4_P2_MODE_HSIC  (3 << 18)
> 
> why do you delete these ? Also not part of $SUBJECT.
> 
>>  
>>  #define OMAP_UHH_DEBUG_CSR  (0x44)
>>  
>> @@ -343,6 +340,7 @@ static void omap_usbhs_init(struct device *dev)
>>  struct usbhs_omap_platform_data *pdata = omap->pdata;
>>  unsigned long   flags;
>>  unsignedreg;
>> +int i;
>>  
>>  dev_dbg(dev, "starting TI HSUSB Controller\n");
>>  
>> @@ -403,21 +401,16 @@ static void omap_usbhs_init(struct device *dev)
>>  reg |= OMAP_UHH_HOSTCONFIG_ULPI_P3_BYPASS;
>>  }
>>  } else if (is_omap_usbhs_rev2(omap)) {
>> -/* Clear port mode fields for PHY mode*/
>> -reg &= ~OMAP4_P1_MODE_CLEAR;
>> -reg &= ~OMAP4_P2_MODE_CLEAR;
>> -
>> -if (is_ehci_tll_mode(pdata->port_mode[0]) ||
>> -(is_ohci_port(pdata->port_mode[0])))
>> -reg |= OMAP4_P1_MODE_TLL;
>> -else if (is_ehci_hsic_mode(pdata->port_mode[0]))
>> -reg |= OMAP4_P1_MODE_HSIC;
>> -
>> -if (is_ehci_tll_mode(pdata->port_mode[1]) ||
>> -(is_ohci_port(pdata->port_mode[1])))
>> -reg |= OMAP4_P2_MODE_TLL;
>> -else if (is_ehci_hsic_mode(pdata->port_mode[1]))
>> -reg |= OMAP4_P2_MODE_HSIC;
>> +for (i = 0; i < omap->nports; i++) {
>> +/* Clear port mode fields for PHY mode*/
>> +reg &= ~(OMAP4_P1_MODE_MASK << 2*i);
> 
> add spaces around '*' operator.
> 
>> +if (is_ehci_tll_mode(pdata->port_mode[i]) ||
>> +(is_ohci_port(pdata->port_mode[i])))
>> +reg |= OMAP4_P1_MODE_TLL << 2*i;
> 
> ditto
> 
>> +else if (is_ehci_hsic_mode(pdata->port_mode[i]))
>> +reg |= OMAP4_P1_MODE_HSIC << 2*i;
> 
> ditto
> 
> in fact, I would convert this construct into a switch which would look
> like:
> 
> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
> 
> switch (port_mode[i]) {
> case OMAP4_P1_MODE_TLL:
>   reg |= OMAP4_P1_MODE_TLL << i * 2;
>   break;
> case OMAP_P1_MODE_HSIC:
>   reg |= OMAP4_P1_MODE_HSIC << i * 2;
>   break;
> }
> 

Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
it the way it was with if statement.

> Also, it looks like the whoel for loop with port mode settings could be
> re-factored to a separate function to aid readability.
> 

it seems that the purpose of omap_usbhs_init() is to initialize
HOSTCONFIG so I see no point in adding another function for it. I can
clean it up for better readability though.

--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP4430 produces boot warnings

[Archit Taneja]

On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:

On 2012-11-26 14:14, Archit Taneja wrote:


So Rajendra and I found the problem.

The function _omap4_update_context_lost() reads the register
RM_DSS_DSS_CONTEXT for all DSS hwmods, and increments the count if we
read a non zero value. The issue is that the DSS's parent platform
device (tied to dss_core hwmod) is called first when resuming, it
correctly reads the register and observes that DSS lost context, and
then clears the register.

When the children hwmods are enabled, the see that the registers are
cleared, and hence never increment their count.

One option is to make the DSS driver use the context lost count of the
hwmod corresponding to the parent platform device. It sort of makes a
bit of sense as all the DSS platform devices belong to the same power
domain, so considering only the parent's context lost count is not so bad.

The second option would be to have some usecounting mechanism in
omap_hwmod where different hwmods belonging to the same power domain
don't have their PM_CONTEXT registers cleared until all the hwmods are
enabled.

The first option is easier to implement, here is a patch for the DISPC
driver:


 From 619276fa0e62b90875475eb345a310f1223e82f6 Mon Sep 17 00:00:00 2001
From: Archit Taneja 
Date: Mon, 26 Nov 2012 17:22:27 +0530
Subject: [PATCH] OMAPDSS: DISPC: Use DISPC's parent device to get context
  lost count

When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then
clears
the register.

All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as
context_offs.
When DSS is enabled, the first hwmod to be enabled is the "dss_core"
hwmod since
it's the parent platform device. The dss_core hwmod updates it's context
lost
count correctly and clears the register. When the hwmods corresponding
to the
children platform devices are enabled. They see that the register is
clear, and
don't increment their context lost count. Therefore, all the children
platfrom
devices never report a change in context.

The DISPC driver currently gets the context lost count for DSS from it's
corresponsing platform device instance. The DISPC platform device is one
of the
child devices, and doesn't report the context lost count correctly.

Make the DISPC driver get the context lost count from it's parent. The
parent
platform device's hwmod is the only one which correctly updates the
context lost
count.

Signed-off-by: Archit Taneja 
---
  drivers/video/omap2/dss/dispc.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index a5ab354..d9dfc4ad 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -374,7 +374,7 @@ static void dispc_save_context(void)
  if (dss_has_feature(FEAT_CORE_CLK_DIV))
  SR(DIVISOR);

-dispc.ctx_loss_cnt = dss_get_ctx_loss_count(&dispc.pdev->dev);
+dispc.ctx_loss_cnt = dss_get_ctx_loss_count(dispc.pdev->dev.parent);
  dispc.ctx_valid = true;

  DSSDBG("context saved, ctx_loss_count %d\n", dispc.ctx_loss_cnt);
@@ -389,7 +389,7 @@ static void dispc_restore_context(void)
  if (!dispc.ctx_valid)
  return;

-ctx = dss_get_ctx_loss_count(&dispc.pdev->dev);
+ctx = dss_get_ctx_loss_count(dispc.pdev->dev.parent);

  if (ctx >= 0 && ctx == dispc.ctx_loss_cnt)
  return;


Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
modules are arranged, which module belongs to which power domain, etc.

If it cannot be fixed in the arch code, I guess we could just have
dss_get_ctx_loss_count(void) function which always returns the
dss_core's ctx loss count, and define that on all the platforms omapdss
is used, the dss_core's ctx loss count is the same as ctx loss count for
all the dss submodules.

I think the above is true for all OMAPs. But it feels like a hack too,
but not as bad as the above patch.


Yes, a function taking in no platform device in dss's core.c would be 
less hacky. I guess we would need this for now, because a solution in 
omap_hwmod would be more complex and it may not be ready by the merge 
window.


Archit

--
To unsubscribe from this list: send the line "unsubscribe 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: omap DSS fails with tft410 driver panel?

[Tomi Valkeinen]

On 2012-11-23 17:20, Steve Sakoman wrote:
> On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen  
> wrote:
> 
> 
>> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you
>> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and
>> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at
>> the point where it sets info.paddr, as I think that's the only place
>> where omapfb sets paddr.
> 
> OK, did that and here is what I get when starting up gdm, prior to
> that all is normal
> 
> root@omap3-multi:~# systemctl start gdm.service
> Starting Gnome Display Manager...
> Started Gnome Display Manager  [  OK  
> ]
> root@omap3-multi:~# [   83.475128] omapfb_setup_plane entry
> [   83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768
> [   83.485809] omapfb_setup_overlay: setting info.paddr = 9f40
> [   83.492431] dss_ovl_set_info entry
> [   83.496307] ovl->id = 0
> [   83.499267] info->paddr = 9f40
> [   83.503601] omapfb_setup_plane: return success
> [   83.508697] omapfb_setup_plane entry
> [   83.513153] dss_ovl_set_info entry
> [   83.516723] ovl->id = 2
> [   83.520111] info->paddr = 0
> [   83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> [   83.530426] omapfb_setup_plane: !pi->enabled & ovl->set_overlay_info
> [   83.537414] dss_ovl_set_info entry
> [   83.540985] ovl->id = 2
> [   83.544250] info->paddr = 0
> [   83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0
> 
> 
> 
>> I don't know what's going on there, why the paddr is suddenly zero.
>> Looking at the log from Enric, SETUP_PLANE works fine just fine, and
>> then, for no reason, next SETUP_PLANE fails, and the log doesn't show
>> anything much happening between.
>>
>> However, I think omapdss may have been more permissive in the past,
>> allowing paddr 0 if the overlay is disabled. I could add that back, but
>> I'd rather first understand what's happening here.
> 
> From the above it seems that the first SETUP_PLANE is for ovl->id = 0
> and then those that fail are for ovl->id =2.
> 
> No idea what is going on in user space, but maybe this will mean
> something to you :-)

Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps?

Anyway, I guess it's a valid thing to configure the overlay with
paddr == 0 when the overlay is disabled. In fact, paddr == 0 check 
is in any case quite limited, as if the board's physical memory
doesn't contain the given paddr, the DSS HW will fail just as it 
would for paddr 0. So the paddr == 0 check is more of a sanity check
than a comprehensive test.

Can you try the following patch:

diff --git a/drivers/video/omap2/dss/overlay.c 
b/drivers/video/omap2/dss/overlay.c
index 45f4994..e271e28 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev)
 int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info)
 {
-   if (info->paddr == 0) {
-   DSSERR("check_overlay: paddr cannot be 0\n");
-   return -EINVAL;
-   }
-
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) {
if (info->out_width != 0 && info->width != info->out_width) {
DSSERR("check_overlay: overlay %d doesn't support "


 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

[Mugunthan V N]

On 11/27/2012 3:57 PM, Mugunthan V N wrote:

   CC  drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file 
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: *** [drivers/net/ethernet/ti] Error 2
make[2]: *** [drivers/net/ethernet] Error 2
make[1]: *** [drivers/net] Error 2

fix for build break as the header file is removed from plat-omap as part of
the below patch

commit a135eaae524acba1509a3b19c97fae556e4da7cd
Author: Paul Walmsley 
Date:   Thu Sep 27 10:33:34 2012 -0600

 ARM: OMAP: remove plat/clock.h

 Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
 arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
 The goal here is to facilitate ARM single image kernels by removing
 includes via the "plat/" symlink.

The header removal patch can be found in linux-next git repo.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe 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: OMAP4430 produces boot warnings

[Tomi Valkeinen]

On 2012-11-26 14:14, Archit Taneja wrote:

> So Rajendra and I found the problem.
> 
> The function _omap4_update_context_lost() reads the register
> RM_DSS_DSS_CONTEXT for all DSS hwmods, and increments the count if we
> read a non zero value. The issue is that the DSS's parent platform
> device (tied to dss_core hwmod) is called first when resuming, it
> correctly reads the register and observes that DSS lost context, and
> then clears the register.
> 
> When the children hwmods are enabled, the see that the registers are
> cleared, and hence never increment their count.
> 
> One option is to make the DSS driver use the context lost count of the
> hwmod corresponding to the parent platform device. It sort of makes a
> bit of sense as all the DSS platform devices belong to the same power
> domain, so considering only the parent's context lost count is not so bad.
> 
> The second option would be to have some usecounting mechanism in
> omap_hwmod where different hwmods belonging to the same power domain
> don't have their PM_CONTEXT registers cleared until all the hwmods are
> enabled.
> 
> The first option is easier to implement, here is a patch for the DISPC
> driver:
> 
> 
> From 619276fa0e62b90875475eb345a310f1223e82f6 Mon Sep 17 00:00:00 2001
> From: Archit Taneja 
> Date: Mon, 26 Nov 2012 17:22:27 +0530
> Subject: [PATCH] OMAPDSS: DISPC: Use DISPC's parent device to get context
>  lost count
> 
> When enabling a hwmod, omap_hwmod refers to the register mentioned in the
> hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
> lost or not. It increments the context lost count for the hwmod and then
> clears
> the register.
> 
> All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as
> context_offs.
> When DSS is enabled, the first hwmod to be enabled is the "dss_core"
> hwmod since
> it's the parent platform device. The dss_core hwmod updates it's context
> lost
> count correctly and clears the register. When the hwmods corresponding
> to the
> children platform devices are enabled. They see that the register is
> clear, and
> don't increment their context lost count. Therefore, all the children
> platfrom
> devices never report a change in context.
> 
> The DISPC driver currently gets the context lost count for DSS from it's
> corresponsing platform device instance. The DISPC platform device is one
> of the
> child devices, and doesn't report the context lost count correctly.
> 
> Make the DISPC driver get the context lost count from it's parent. The
> parent
> platform device's hwmod is the only one which correctly updates the
> context lost
> count.
> 
> Signed-off-by: Archit Taneja 
> ---
>  drivers/video/omap2/dss/dispc.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index a5ab354..d9dfc4ad 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -374,7 +374,7 @@ static void dispc_save_context(void)
>  if (dss_has_feature(FEAT_CORE_CLK_DIV))
>  SR(DIVISOR);
> 
> -dispc.ctx_loss_cnt = dss_get_ctx_loss_count(&dispc.pdev->dev);
> +dispc.ctx_loss_cnt = dss_get_ctx_loss_count(dispc.pdev->dev.parent);
>  dispc.ctx_valid = true;
> 
>  DSSDBG("context saved, ctx_loss_count %d\n", dispc.ctx_loss_cnt);
> @@ -389,7 +389,7 @@ static void dispc_restore_context(void)
>  if (!dispc.ctx_valid)
>  return;
> 
> -ctx = dss_get_ctx_loss_count(&dispc.pdev->dev);
> +ctx = dss_get_ctx_loss_count(dispc.pdev->dev.parent);
> 
>  if (ctx >= 0 && ctx == dispc.ctx_loss_cnt)
>  return;

Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
modules are arranged, which module belongs to which power domain, etc.

If it cannot be fixed in the arch code, I guess we could just have
dss_get_ctx_loss_count(void) function which always returns the
dss_core's ctx loss count, and define that on all the platforms omapdss
is used, the dss_core's ctx loss count is the same as ctx loss count for
all the dss submodules.

I think the above is true for all OMAPs. But it feels like a hack too,
but not as bad as the above patch.

 Tomi




signature.asc
Description: OpenPGP digital signature

[PATCH 1/1] net: cpts: fix for build break after ARM SoC integration

[Mugunthan V N]

  CC  drivers/net/ethernet/ti/cpts.o
drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file 
or directory
compilation terminated.
make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
make[3]: *** [drivers/net/ethernet/ti] Error 2
make[2]: *** [drivers/net/ethernet] Error 2
make[1]: *** [drivers/net] Error 2

fix for build break as the header file is removed from plat-omap as part of
the below patch

commit a135eaae524acba1509a3b19c97fae556e4da7cd
Author: Paul Walmsley 
Date:   Thu Sep 27 10:33:34 2012 -0600

ARM: OMAP: remove plat/clock.h

Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the "plat/" symlink.

Signed-off-by: Mugunthan V N 
---
 drivers/net/ethernet/ti/cpts.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 3377667..5e62c1a 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -27,8 +27,6 @@
 #include 
 #include 
 
-#include 
-
 #include "cpts.h"
 
 #ifdef CONFIG_TI_CPTS
-- 
1.7.0.4

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

[PATCH 1/1] ARM: OMAP: fix build error in arch/arm/mach-omap2/timer.c

[Mugunthan V N]

  CC  arch/arm/mach-omap2/timer.o
arch/arm/mach-omap2/timer.c: In function 'omap_get_timer_dt':
arch/arm/mach-omap2/timer.c:195:3: error: implicit declaration of function 
'prom_add_property'
make[1]: *** [arch/arm/mach-omap2/timer.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2

fix for build break as the functions "prom_*_property" is renamed to
of_*_property by the below patch

commit 79d1c712958f94372482ad74578b00f44e744c12
Author: Nathan Fontenot 
Date:   Tue Oct 2 16:58:46 2012 +

powerpc+of: Rename the drivers/of prom_* functions to of_*

Rename the prom_*_property routines of the generic OF code to of_*_property.
This brings them in line with the naming used by the rest of the OF code.

Signed-off-by: Mugunthan V N 
---
 arch/arm/mach-omap2/timer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 099e406..5fd5e23 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -192,7 +192,7 @@ static struct device_node * __init omap_get_timer_dt(struct 
of_device_id *match,
continue;
}
 
-   prom_add_property(np, &device_disabled);
+   of_add_property(np, &device_disabled);
return np;
}
 
-- 
1.7.0.4

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

[PATCH v4 1/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs

[Peter Ujfalusi]

The driver supports the following PWM outputs:
TWL4030 PWM0 and PWM1
TWL6030 PWM1 and PWM2

On TWL4030 the PWM signals are muxed. Upon requesting the PWM the driver
will select the correct mux so the PWM can be used. When the PWM has been
freed the original configuration is going to be restored.

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/pwm/ti,twl-pwm.txt |  17 +
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-twl.c  | 357 +
 4 files changed, 384 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
 create mode 100644 drivers/pwm/pwm-twl.c

diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt 
b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
new file mode 100644
index 000..2943ee5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
@@ -0,0 +1,17 @@
+Texas Instruments TWL series PWM drivers
+
+Supported PWMs:
+On TWL4030 series: PWM1 and PWM2
+On TWL6030 series: PWM0 and PWM1
+
+Required properties:
+- compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+
+Example:
+
+twl_pwm: pwm {
+   compatible = "ti,twl6030-pwm";
+   #pwm-cells = <2>;
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..8ed64dd 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -151,6 +151,15 @@ config PWM_TWL6030
  To compile this driver as a module, choose M here: the module
  will be called pwm-twl6030.
 
+config PWM_TWL
+   tristate "TWL4030/6030 PWM support"
+   depends on TWL4030_CORE
+   help
+ Generic PWM framework driver for TWL4030/6030.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl.
+
 config PWM_VT8500
tristate "vt8500 pwm support"
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index acfe482..49fabfa 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_PWM_TEGRA)   += pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL6030)  += pwm-twl6030.o
+obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl.c b/drivers/pwm/pwm-twl.c
new file mode 100644
index 000..3274177
--- /dev/null
+++ b/drivers/pwm/pwm-twl.c
@@ -0,0 +1,357 @@
+/*
+ * Driver for TWL4030/6030 Generic Pulse Width Modulator
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This driver handles the PWMs of TWL4030 and TWL6030.
+ * The TRM names for the PWMs on TWL4030 are: PWM0, PWM1
+ * TWL6030 also have two PWMs named in the TRM as PWM1, PWM2
+ */
+
+#define TWL_PWM_MAX0x7f
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_GPBR1_REG  0x0c
+#define TWL4030_PMBR1_REG  0x0d
+
+/* GPBR1 register bits */
+#define TWL4030_PWMXCLK_ENABLE (1 << 0)
+#define TWL4030_PWMX_ENABLE(1 << 2)
+#define TWL4030_PWMX_BITS  (TWL4030_PWMX_ENABLE | TWL4030_PWMXCLK_ENABLE)
+#define TWL4030_PWM_TOGGLE(pwm, x) ((x) << (pwm))
+
+/* PMBR1 register bits */
+#define TWL4030_GPIO6_PWM0_MUTE_MASK   (0x03 << 2)
+#define TWL4030_GPIO6_PWM0_MUTE_PWM0   (0x01 << 2)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_MASK  (0x03 << 4)
+#define TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1  (0x03 << 4)
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_TOGGLE3_REG0x92
+
+#define TWL6030_PWMXR  (1 << 0)
+#define TWL6030_PWMXS  (1 << 1)
+#define TWL6030_PWMXEN (1 << 2)
+#define TWL6030_PWM_TOGGLE(pwm, x) ((x) << (pwm * 3))
+
+struct twl_pwm_chip {
+   struct pwm_chip chip;
+   struct mutex mutex;
+   u8 twl6030_toggle3;
+   u8 twl4030_pwm_mux;
+};
+
+static inline struct twl_pwm_chip *to_twl(struct pwm_chip *chip)
+{
+   return container_of(chip, struct twl_pwm_chip, chip);
+}
+
+static int twl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+

[PATCH v4 2/3] pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs

[Peter Ujfalusi]

The driver supports the following LED outputs as generic PWM driver:
TWL4030 LEDA and LEDB (PWMA and PWMB)
TWL6030 Charging indicator LED (PWM LED)

On TWL6030 when the PWM requested LED is configured to be controlled by SW.
In this case the user can enable/disable and set the duty period freely.
When the PWM has been freed, the LED driver is put back to HW control.

Signed-off-by: Peter Ujfalusi 
---
 .../devicetree/bindings/pwm/ti,twl-pwmled.txt  |  17 +
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-twl-led.c  | 342 +
 4 files changed, 369 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
 create mode 100644 drivers/pwm/pwm-twl-led.c

diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt 
b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
new file mode 100644
index 000..cb64f3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
@@ -0,0 +1,17 @@
+Texas Instruments TWL series PWM drivers connected to LED terminals
+
+Supported PWMs:
+On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
+On TWL6030 series: LED PWM (mainly used as charging indicator LED)
+
+Required properties:
+- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+
+Example:
+
+twl_pwmled: pwmled {
+   compatible = "ti,twl6030-pwmled";
+   #pwm-cells = <2>;
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 8ed64dd..aa89354 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -160,6 +160,15 @@ config PWM_TWL
  To compile this driver as a module, choose M here: the module
  will be called pwm-twl.
 
+config PWM_TWL_LED
+   tristate "TWL4030/6030 PWM support for LED drivers"
+   depends on TWL4030_CORE
+   help
+ Generic PWM framework driver for TWL4030/6030 LED terminals.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-twl-led.
+
 config PWM_VT8500
tristate "vt8500 pwm support"
depends on ARCH_VT8500
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 49fabfa..82a92c7 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -13,4 +13,5 @@ obj-$(CONFIG_PWM_TIECAP)  += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TWL6030)  += pwm-twl6030.o
 obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
+obj-$(CONFIG_PWM_TWL_LED)  += pwm-twl-led.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl-led.c b/drivers/pwm/pwm-twl-led.c
new file mode 100644
index 000..c8fb47f
--- /dev/null
+++ b/drivers/pwm/pwm-twl-led.c
@@ -0,0 +1,342 @@
+/*
+ * Driver for TWL4030/6030 Pulse Width Modulator used as LED driver
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Peter Ujfalusi 
+ *
+ * This driver is a complete rewrite of the former pwm-twl6030.c authorded by:
+ * Hemanth V 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This driver handles the PWM driven LED terminals of TWL4030 and TWL6030.
+ * To generate the signal on TWL4030:
+ *  - LEDA uses PWMA
+ *  - LEDB uses PWMB
+ * TWL6030 has one LED pin with dedicated LEDPWM
+ */
+
+#define TWL4030_LED_MAX0x7f
+#define TWL6030_LED_MAX0xff
+
+/* Registers, bits and macro for TWL4030 */
+#define TWL4030_LEDEN_REG  0x00
+#define TWL4030_PWMA_REG   0x01
+
+#define TWL4030_LEDXON (1 << 0)
+#define TWL4030_LEDXPWM(1 << 4)
+#define TWL4030_LED_PINS   (TWL4030_LEDXON | TWL4030_LEDXPWM)
+#define TWL4030_LED_TOGGLE(led, x) ((x) << (led))
+
+/* Register, bits and macro for TWL6030 */
+#define TWL6030_LED_PWM_CTRL1  0xf4
+#define TWL6030_LED_PWM_CTRL2  0xf5
+
+#define TWL6040_LED_MODE_HW0x00
+#define TWL6040_LED_MODE_ON0x01
+#define TWL6040_LED_MODE_OFF   0x02
+#define TWL6040_LED_MODE_MASK  0x03
+
+struct twl_pwmled_chip {
+   struct pwm_chip chip;
+   struct mutex mutex;
+};
+
+static inline struct twl_pwmled_chip *to_twl(struct pwm_chip *chip)
+{
+   return container_of(chip, struct twl_pwmled_chip, chip

[PATCH v4 0/3] pwm: Drivers for twl4030/6030 PWMs and LEDs

[Peter Ujfalusi]

Hello,

Changes since v3:
- pwm-twl-led driver's comment fix patch squashed to the original patch
- Documentation for the DT bindings of the PWM drivers
Comments from Thierry Reding addressed:
- pwm-twl6030 has been removed in the last patch
- macro for twl_pwm_chip/twl_pwmled_chip lookup
- locking for read-modify-write sequences
- separate pwm_ops strictures for twl4030 and twl6030 class
- _devexit_P() removed
- Do not select HAVE_PWM in Kconfig file since it is going away AFAIK:
  https://patchwork.kernel.org/patch/1544851/
- Remaining (smaller) comments from Thierry also has been addressed.

Changes since v2:
- New PWM cycle calculation for twl-pwm driver and twl4030's pwm-twl-led with
  comment to document the expected behaviour.

Changes cince v1:
- The turn on/off sequence has been corrected for twl4030 PWMs as suggested by
  Grazvydas Ignotas
- Comment section added to the new drivers to describe what they are controlling

The series has been tested (with additional, pending patches):
Zoom2 for twl4030 PWM0 (keypad light), PWM1 (LCD backlight)
BeagleBoard for twl4030 LEDB (PWMB - pmu_stat led)
OMAP4 Blaze (SDP4430) for twl6030 PWM1 (keypad light), PWM2 (LCD backlight) and
LED (charging indication led).

Intro mail from v1:

The currently available pwm-twl6030.c driver only supports TWL6030's Charging
indication LED.
Remove this driver and add two new ones which implements support for all PWM
driven outputs:
pwm-twl driver supports twl4030 (PWM 0/1) and twl6030 (PWM 1/2) instances
pwm-twl-led driver supports twl4030 (PWM driven LED A/B ports) and twl6030's
Charging indication LED (PWM driven).

Regards,
Peter
---
Peter Ujfalusi (3):
  pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
  pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of
PMICs
  pwm: Remove pwm-twl6030 driver

 .../devicetree/bindings/pwm/ti,twl-pwm.txt |  17 +
 .../devicetree/bindings/pwm/ti,twl-pwmled.txt  |  17 +
 drivers/pwm/Kconfig|  17 +-
 drivers/pwm/Makefile   |   3 +-
 drivers/pwm/pwm-twl-led.c  | 342 
 drivers/pwm/pwm-twl.c  | 357 +
 drivers/pwm/pwm-twl6030.c  | 184 ---
 7 files changed, 748 insertions(+), 189 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
 create mode 100644 drivers/pwm/pwm-twl-led.c
 create mode 100644 drivers/pwm/pwm-twl.c
 delete mode 100644 drivers/pwm/pwm-twl6030.c

-- 
1.8.0

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

[PATCH v4 3/3] pwm: Remove pwm-twl6030 driver

[Peter Ujfalusi]

This driver only supported the Charging indicator LED.
New set of drivers going to provide support for both PWMs and LEDs for twl4030
and twl6030 series of PMICs.

Signed-off-by: Peter Ujfalusi 
---
 drivers/pwm/Kconfig   |   9 ---
 drivers/pwm/Makefile  |   1 -
 drivers/pwm/pwm-twl6030.c | 184 --
 3 files changed, 194 deletions(-)
 delete mode 100644 drivers/pwm/pwm-twl6030.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index aa89354..43cd93a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -142,15 +142,6 @@ config  PWM_TIEHRPWM
  To compile this driver as a module, choose M here: the module
  will be called pwm-tiehrpwm.
 
-config PWM_TWL6030
-   tristate "TWL6030 PWM support"
-   depends on TWL4030_CORE
-   help
- Generic PWM framework driver for TWL6030.
-
- To compile this driver as a module, choose M here: the module
- will be called pwm-twl6030.
-
 config PWM_TWL
tristate "TWL4030/6030 PWM support"
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 82a92c7..5f26134 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
 obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
 obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
-obj-$(CONFIG_PWM_TWL6030)  += pwm-twl6030.o
 obj-$(CONFIG_PWM_TWL)  += pwm-twl.o
 obj-$(CONFIG_PWM_TWL_LED)  += pwm-twl-led.o
 obj-$(CONFIG_PWM_VT8500)   += pwm-vt8500.o
diff --git a/drivers/pwm/pwm-twl6030.c b/drivers/pwm/pwm-twl6030.c
deleted file mode 100644
index 8e63878..000
--- a/drivers/pwm/pwm-twl6030.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * twl6030_pwm.c
- * Driver for PHOENIX (TWL6030) Pulse Width Modulator
- *
- * Copyright (C) 2010 Texas Instruments
- * Author: Hemanth V 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define LED_PWM_CTRL1  0xF4
-#define LED_PWM_CTRL2  0xF5
-
-/* Max value for CTRL1 register */
-#define PWM_CTRL1_MAX  255
-
-/* Pull down disable */
-#define PWM_CTRL2_DIS_PD   (1 << 6)
-
-/* Current control 2.5 milli Amps */
-#define PWM_CTRL2_CURR_02  (2 << 4)
-
-/* LED supply source */
-#define PWM_CTRL2_SRC_VAC  (1 << 2)
-
-/* LED modes */
-#define PWM_CTRL2_MODE_HW  (0 << 0)
-#define PWM_CTRL2_MODE_SW  (1 << 0)
-#define PWM_CTRL2_MODE_DIS (2 << 0)
-
-#define PWM_CTRL2_MODE_MASK0x3
-
-struct twl6030_pwm_chip {
-   struct pwm_chip chip;
-};
-
-static int twl6030_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   int ret;
-   u8 val;
-
-   /* Configure PWM */
-   val = PWM_CTRL2_DIS_PD | PWM_CTRL2_CURR_02 | PWM_CTRL2_SRC_VAC |
- PWM_CTRL2_MODE_HW;
-
-   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
-   if (ret < 0) {
-   dev_err(chip->dev, "%s: Failed to configure PWM, Error %d\n",
-   pwm->label, ret);
-   return ret;
-   }
-
-   return 0;
-}
-
-static int twl6030_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
-{
-   u8 duty_cycle = (duty_ns * PWM_CTRL1_MAX) / period_ns;
-   int ret;
-
-   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, duty_cycle, LED_PWM_CTRL1);
-   if (ret < 0) {
-   pr_err("%s: Failed to configure PWM, Error %d\n",
-   pwm->label, ret);
-   return ret;
-   }
-
-   return 0;
-}
-
-static int twl6030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   int ret;
-   u8 val;
-
-   ret = twl_i2c_read_u8(TWL6030_MODULE_ID1, &val, LED_PWM_CTRL2);
-   if (ret < 0) {
-   dev_err(chip->dev, "%s: Failed to enable PWM, Error %d\n",
-   pwm->label, ret);
-   return ret;
-   }
-
-   /* Change mode to software control */
-   val &= ~PWM_CTRL2_MODE_MASK;
-   val |= PWM_CTRL2_MODE_SW;
-
-   ret = twl_i2c_write_u8(TWL6030_MODULE_ID1, val, LED_PWM_CTRL2);
-   if (ret < 0) {
-   dev_err(chip->dev, "%s: Failed to enable PWM, Error %d\n",
-   pwm->label, ret);
-   return ret;
-   }
-
-   twl_i2c_read_u8(TWL6

Re: [PATCHv2] OMAP: board-files: fix i2c_bus for tfp410

[Thomas Weber]

Hello Tomi,

> The i2c handling in tfp410 driver, which handles converting parallel RGB
> to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
> (OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
> driver considers as invalid/undefined.  Before the patch, 0 was the
> invalid value, but as 0 is a valid bus number, the patch changed this to
> -1.
>
> However, the fact was missed that many board files do not define the bus
> number at all, thus it's left to 0. This causes the driver to fail to
> get the i2c bus, exiting from the driver's probe with an error, meaning
> that the DVI output does not work for those boards.
>
> This patch fixes the issue by changing the i2c_bus number field in the
> driver's platform data from u16 to int, and setting the bus number to -1
> in the board files for the boards that did not define the bus. The
> exception is devkit8000, for which the bus is set to 1, which is the
> correct bus for that board.
>
> The bug exists in v3.5+ kernels.
>
> Signed-off-by: Tomi Valkeinen 
> Reported-by: Thomas Weber 
> Cc: Thomas Weber 
> Cc:  # v3.5+

I have tested the patch on Devkit8000.
Tested-by: Thomas Weber 

Thanks.

Thomas


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

Re: [PATCH 1/1] ARM: OMAP2+: omap2plus_defconfig: enable twl4030 SoC audio

[Peter Ujfalusi]

On 11/27/2012 02:21 AM, Javier Martinez Canillas wrote:
> Many TI OMAP SoC based boards that uses twl4030 as codec have
> been updated to use the unified audio driver (omap-twl4030)
> since they have similar audio setup.
> 
> So, is good to have it built to add audio support to these boards.
> 
> Signed-off-by: Javier Martinez Canillas 

I also agree that it is a good practice to enable this in the defconfig.

Acked-by: Peter Ujfalusi 

> ---
>  arch/arm/configs/omap2plus_defconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/configs/omap2plus_defconfig 
> b/arch/arm/configs/omap2plus_defconfig
> index 7c6cbdf..022212c 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -172,6 +172,7 @@ CONFIG_SND_DEBUG=y
>  CONFIG_SND_USB_AUDIO=m
>  CONFIG_SND_SOC=m
>  CONFIG_SND_OMAP_SOC=m
> +CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
>  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
>  CONFIG_USB=y
>  CONFIG_USB_DEBUG=y
> 


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

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Roger Quadros]

On 11/26/2012 10:02 PM, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
>> Felipe,
>>
>> On 11/21/2012 03:39 PM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
 All ports have similarly named port clocks so we can
 bunch them into a port data structure and use for loop
 to enable/disable the clocks.

 Signed-off-by: Roger Quadros 
 ---
  drivers/mfd/omap-usb-host.c |  208 
 +--
  1 files changed, 101 insertions(+), 107 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 23cec57..7303c41 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -76,6 +76,8 @@
  
  #define   OMAP_UHH_DEBUG_CSR  (0x44)
  
 +#define MAX_HS_USB_PORTS  3   /* Increase this if any chip has more */
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV1   0x0010  /* OMAP3 */
  #define OMAP_USBHS_REV2   0x50700100  /* OMAP4 */
 @@ -87,14 +89,15 @@
  #define is_ehci_tll_mode(x)   (x == OMAP_EHCI_PORT_MODE_TLL)
  #define is_ehci_hsic_mode(x)  (x == OMAP_EHCI_PORT_MODE_HSIC)
  
 +struct usbhs_port {
 +  struct clk  *utmi_clk;
 +};
>>>
>>> I rather not since this will make it a lot more difficult to use
>>> pm_clk_add() :-s Also, this sort of thing should be dynamically
>>> allocated anyway ;-)
>>>
>>
>> Why do you say so? The whole point of this patch is to group similarly
>> named clocks so that we can use a for loop and set number of ports (or
>> clocks) dynamically. I suppose it would be just a matter of replacing
>> clk_enable/disable() with pm_clk_add() later, right?
>>
>> If you see patch 11, we are adding 2 HSIC related clocks to this
>> structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
>> managed using a simple for loop instead of coding each clock name by hand.
> 
> that's usually not what you want, actually. You want clock management to
> be explicit so you can have micro-power optimizations. I fear that the
> time omap-usb-host.c gets *truly* stabilized and we move to more
> aggressive PM, we will undo these changes just to have a more granular
> control of the clocks, at which point your patch would be rendered
> useless.
> 

The granularity is still there, just that port clocks are grouped
together. Do you think it is better if I get rid of 'struct usbhs_port'
and keep the clocks in the main structure instead?

e.g.

struct usbhs_hcd_omap {
struct clk  **utmi_clk;
struct clk  **hsic1_clk;
struct clk  **hsic2_clk;
...
}

The clocks can then be accessed as follows

omap->utmi_clk[i];  /* i is port number */

Does this sound OK to you?

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

Re: [PATCH 1/1] ARM: OMAP2+: enable devtmpfs and devtmpfs automount

[Javier Martinez Canillas]

On 11/27/2012 09:34 AM, Sekhar Nori wrote:
> On 11/21/2012 6:56 PM, Javier Martinez Canillas wrote:
>> Since udev-182, udev no longer creates device nodes under /dev
> 
> Nit: Looks like this happened from udev-176 onward.
> 
> http://permalink.gmane.org/gmane.linux.hotplug.devel/17230
> 
> Whoever is taking the patch can _probably_ fix it up while applying.
> 

Hi Sekhar,

Thanks for clarifying this, I read that it was udev-182 from the Linux from
scratch documentation:
http://www.linuxfromscratch.org/lfs/view/jh/chapter07/udev.html

>> and this has to be managed by the kernel devtmpfs filesystem.
>> 
>> This means that a kernel built with the current OMAP2+ config
>> will not boot on a system with a recent udev.
> 
>> Also, it is good to have /dev automatically mounted since some
>> non-initramfs based setups assumes this and don't manually mount it.
> 
> For curiosity sake, any examples of such setups? I am using fedora 17 on
> DaVinci and that doesn't seem to need it. Anyway, agreed that its better
> to keep it enabled.
> 
> Thanks,
> Sekhar
> 

I'm using an IGEPv2 (TI OMAP3 DM3735) with an openembedded build and the oe udev
init script from the recipe I use seems to assume this.

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe 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 v5 12/12] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

[Philip, Avinash]

PWM output from ecap2 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales with
inverse polarity.

Signed-off-by: Philip, Avinash 
Reviewed-by: Thierry Reding 
---
Changes since v4:
- Replaced usage of tab with space in compatible field

 arch/arm/boot/dts/am335x-evmsk.dts |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index f5a6162..a50f286 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -51,6 +51,12 @@
0x9c 0x27   /* gpmc_ben0_cle.gpio2_5, INPUT 
| MODE7 */
>;
};
+
+   ecap2_pins: backlight_pins {
+   pinctrl-single,pins = <
+   0x19c 0x4   /* 
mcasp0_ahclkr.ecap2_in_pwm2_out MODE4 */
+   >;
+   };
};
 
ocp {
@@ -94,6 +100,16 @@
st,max-limit-z = <750>;
};
};
+
+   epwmss2: epwmss@48304000 {
+   status = "okay";
+
+   ecap2: ecap@48304100 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&ecap2_pins>;
+   };
+   };
};
 
vbat: fixedregulator@0 {
@@ -170,6 +186,13 @@
gpios = <&gpio3 5 0>;
};
};
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = <&ecap2 0 5 1>;
+   brightness-levels = <0 58 61 66 75 90 125 170 255>;
+   default-brightness-level = <8>;
+   };
 };
 
 /include/ "tps65910.dtsi"
-- 
1.7.0.4

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

[PATCH v5 11/12] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm

[Philip, Avinash]

PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.

Signed-off-by: Philip, Avinash 
Reviewed-by: Thierry Reding 
---
Changes since v4:
- Replaced usage of tab with space in compatible field

Changes since v3:
- Add epwmss parent status="okay" field.

 arch/arm/boot/dts/am335x-evm.dts |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9f65f17..73a035b 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,12 @@
0x154 0x27  /* spi0_d0.gpio0_3, INPUT | 
MODE7 */
>;
};
+
+   ecap0_pins: backlight_pins {
+   pinctrl-single,pins = <
+   0x164 0x0   /* 
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+   >;
+   };
};
 
ocp {
@@ -102,6 +108,16 @@
reg = <0x48>;
};
};
+
+   epwmss0: epwmss@4830 {
+   status = "okay";
+
+   ecap0: ecap@48300100 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <&ecap0_pins>;
+   };
+   };
};
 
vbat: fixedregulator@0 {
@@ -158,6 +174,13 @@
gpio-key,wakeup;
};
};
+
+   backlight {
+   compatible = "pwm-backlight";
+   pwms = <&ecap0 0 5 0>;
+   brightness-levels = <0 51 53 56 62 75 101 152 255>;
+   default-brightness-level = <8>;
+   };
 };
 
 /include/ "tps65910.dtsi"
-- 
1.7.0.4

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

[PATCH v5 10/12] ARM: dts: AM33XX: Add PWMSS device tree nodes

[Philip, Avinash]

Add PWMSS device tree nodes in relation with ECAP & EHRPWM DT nodes to
AM33XX SoC family. Also populates device tree nodes for ECAP & EHRPWM by
adding necessary properties like pwm-cells, base reg & set disabled as
status.

Signed-off-by: Philip, Avinash 
Reviewed-by: Thierry Reding 
---
Changes since v2:
- ranges property populated to handle child devices address range

 arch/arm/boot/dts/am33xx.dtsi |   84 +
 1 files changed, 84 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 20a3f29..4393161 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -338,5 +338,89 @@
power = <250>;
ti,hwmods = "usb_otg_hs";
};
+
+   epwmss0: epwmss@4830 {
+   compatible = "ti,am33xx-pwmss";
+   reg = <0x4830 0x10>;
+   ti,hwmods = "epwmss0";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   ranges = <0x48300100 0x48300100 0x80   /* ECAP */
+ 0x48300180 0x48300180 0x80   /* EQEP */
+ 0x48300200 0x48300200 0x80>; /* EHRPWM */
+
+   ecap0: ecap@48300100 {
+   compatible = "ti,am33xx-ecap";
+   #pwm-cells = <3>;
+   reg = <0x48300100 0x80>;
+   ti,hwmods = "ecap0";
+   status = "disabled";
+   };
+
+   ehrpwm0: ehrpwm@48300200 {
+   compatible = "ti,am33xx-ehrpwm";
+   #pwm-cells = <3>;
+   reg = <0x48300200 0x80>;
+   ti,hwmods = "ehrpwm0";
+   status = "disabled";
+   };
+   };
+
+   epwmss1: epwmss@48302000 {
+   compatible = "ti,am33xx-pwmss";
+   reg = <0x48302000 0x10>;
+   ti,hwmods = "epwmss1";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   ranges = <0x48302100 0x48302100 0x80   /* ECAP */
+ 0x48302180 0x48302180 0x80   /* EQEP */
+ 0x48302200 0x48302200 0x80>; /* EHRPWM */
+
+   ecap1: ecap@48302100 {
+   compatible = "ti,am33xx-ecap";
+   #pwm-cells = <3>;
+   reg = <0x48302100 0x80>;
+   ti,hwmods = "ecap1";
+   status = "disabled";
+   };
+
+   ehrpwm1: ehrpwm@48302200 {
+   compatible = "ti,am33xx-ehrpwm";
+   #pwm-cells = <3>;
+   reg = <0x48302200 0x80>;
+   ti,hwmods = "ehrpwm1";
+   status = "disabled";
+   };
+   };
+
+   epwmss2: epwmss@48304000 {
+   compatible = "ti,am33xx-pwmss";
+   reg = <0x48304000 0x10>;
+   ti,hwmods = "epwmss2";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   ranges = <0x48304100 0x48304100 0x80   /* ECAP */
+ 0x48304180 0x48304180 0x80   /* EQEP */
+ 0x48304200 0x48304200 0x80>; /* EHRPWM */
+
+   ecap2: ecap@48304100 {
+   compatible = "ti,am33xx-ecap";
+   #pwm-cells = <3>;
+   reg = <0x48304100 0x80>;
+   ti,hwmods = "ecap2";
+   status = "disabled";
+   };
+
+   ehrpwm2: ehrpwm@48304200 {
+   compatible = "ti,am33xx-ehrpwm";
+   #pwm-cells = <3>;
+   reg = <0x48304200 0x80>;
+   ti,hwmods = "ehrpwm2";
+   status = "disabled";
+   };
+   };
};
 };
-- 
1.7.0.4

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

[PATCH v5 06/12] ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK

[Philip, Avinash]

EHRPWM module requires explicit clock gating of TBCLK from control
module. Hence add TBCLK clock node in clock tree for EHRPWM modules.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Add dev_id field in clcok tree for TBCLK to remove support
  for optional HWMOD clock support for EHRPWM.

 arch/arm/mach-omap2/clock33xx_data.c |   37 ++
 arch/arm/mach-omap2/control.h|8 +++
 2 files changed, 45 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
b/arch/arm/mach-omap2/clock33xx_data.c
index 1a45d6b..d08cd9a 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -996,6 +996,40 @@ static struct clk wdt1_fck = {
 };
 
 /*
+ * PWMSS Time based module clock node. This node is
+ * requred to enable clock gating for EHRPWM TBCLK.
+ */
+static struct clk ehrpwm0_tbclk = {
+   .name   = "ehrpwm0_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS0_TBCLKEN_SHIFT,
+   .ops= &clkops_omap2_dflt,
+   .parent = &l4ls_gclk,
+   .recalc = &followparent_recalc,
+};
+
+static struct clk ehrpwm1_tbclk = {
+   .name   = "ehrpwm1_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS1_TBCLKEN_SHIFT,
+   .ops= &clkops_omap2_dflt,
+   .parent = &l4ls_gclk,
+   .recalc = &followparent_recalc,
+};
+
+static struct clk ehrpwm2_tbclk = {
+   .name   = "ehrpwm2_tbclk",
+   .clkdm_name = "l4ls_clkdm",
+   .enable_reg = AM33XX_CTRL_REGADDR(AM33XX_PWMSS_TBCLK_CLKCTRL),
+   .enable_bit = AM33XX_PWMSS2_TBCLKEN_SHIFT,
+   .ops= &clkops_omap2_dflt,
+   .parent = &l4ls_gclk,
+   .recalc = &followparent_recalc,
+};
+
+/*
  * clkdev
  */
 static struct omap_clk am33xx_clks[] = {
@@ -1075,6 +1109,9 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   "clkout2_ck",   &clkout2_ck,CK_AM33XX),
CLK(NULL,   "timer_32k_ck", &clkdiv32k_ick, CK_AM33XX),
CLK(NULL,   "timer_sys_ck", &sys_clkin_ck,  CK_AM33XX),
+   CLK("48300200.ehrpwm",  "tbclk",&ehrpwm0_tbclk, CK_AM33XX),
+   CLK("48302200.ehrpwm",  "tbclk",&ehrpwm1_tbclk, CK_AM33XX),
+   CLK("48304200.ehrpwm",  "tbclk",&ehrpwm2_tbclk, CK_AM33XX),
 };
 
 int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a89e825..c0e34e6 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -357,6 +357,14 @@
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH   0x2
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 << 22)
 
+/* AM33XX PWMSS Control register */
+#define AM33XX_PWMSS_TBCLK_CLKCTRL 0x664
+
+/* AM33XX  PWMSS Control bitfields */
+#define AM33XX_PWMSS0_TBCLKEN_SHIFT0
+#define AM33XX_PWMSS1_TBCLKEN_SHIFT1
+#define AM33XX_PWMSS2_TBCLKEN_SHIFT2
+
 /* CONTROL OMAP STATUS register to identify OMAP3 features */
 #define OMAP3_CONTROL_OMAP_STATUS  0x044c
 
-- 
1.7.0.4

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

[PATCH v5 05/12] pwm: pwm-tiecap: pinctrl support

[Philip, Avinash]

Enable pinctrl for pwm-tiecap if pinctrl driver available, else
bail out with warning message.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Changes warning message.

 drivers/pwm/pwm-tiecap.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 0f541c5..b4f9d47 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pwm-tipwmss.h"
 
@@ -200,6 +201,11 @@ static int __devinit ecap_pwm_probe(struct platform_device 
*pdev)
struct clk *clk;
struct ecap_pwm_chip *pc;
u16 status;
+   struct pinctrl *pinctrl;
+
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(&pdev->dev, "unable to select pin group\n");
 
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
-- 
1.7.0.4

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

[PATCH v5 04/12] pwm: tiecap: Add device-tree binding

[Philip, Avinash]

This patch
1. Add support for device-tree binding for ECAP APWM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
   period & polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in platform_driver structure to
   THIS_MODULE.

Signed-off-by: Philip, Avinash 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Rob Landley 
---
Changes since v4:
- Made dt match property in single line for consistency
- Corrected commit subject for consistency.

Changes since v3:
- Replace pwmss.h with pwm-tipwmss.h

Changes since v2:
- Add of_pwm_xlate_with_flags function support

Changes since v1:
- Add separate patch for pinctrl support
- Add conditional check for PWM subsystem clock enable.
- Combined with HWMOD changes & DT bindings.
- Remove the custom of_xlate support.

 .../devicetree/bindings/pwm/pwm-tiecap.txt |   23 +++
 drivers/pwm/pwm-tiecap.c   |   42 +++-
 2 files changed, 64 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
new file mode 100644
index 000..131e8c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -0,0 +1,23 @@
+TI SOC ECAP based APWM controller
+
+Required properties:
+- compatible: Must be "ti,am33xx-ecap"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period in nanoseconds and bit 0 in the third cell is used to
+  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+  to 1 for inverse polarity & set to 0 for normal polarity.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the ECAP:
+  "ecap",  being the 0-based instance number from the HW spec
+
+Example:
+
+ecap0: ecap@0 {
+   compatible = "ti,am33xx-ecap";
+   #pwm-cells = <3>;
+   reg = <0x48300100 0x80>;
+   ti,hwmods = "ecap0";
+};
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index d6d4cf0..0f541c5 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "pwm-tipwmss.h"
 
 /* ECAP registers and bits definitions */
 #define CAP1   0x08
@@ -184,12 +187,19 @@ static const struct pwm_ops ecap_pwm_ops = {
.owner  = THIS_MODULE,
 };
 
+static const struct of_device_id ecap_of_match[] = {
+   { .compatible   = "ti,am33xx-ecap" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ecap_of_match);
+
 static int __devinit ecap_pwm_probe(struct platform_device *pdev)
 {
int ret;
struct resource *r;
struct clk *clk;
struct ecap_pwm_chip *pc;
+   u16 status;
 
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
@@ -211,6 +221,8 @@ static int __devinit ecap_pwm_probe(struct platform_device 
*pdev)
 
pc->chip.dev = &pdev->dev;
pc->chip.ops = &ecap_pwm_ops;
+   pc->chip.of_xlate = of_pwm_xlate_with_flags;
+   pc->chip.of_pwm_n_cells = 3;
pc->chip.base = -1;
pc->chip.npwm = 1;
 
@@ -231,14 +243,40 @@ static int __devinit ecap_pwm_probe(struct 
platform_device *pdev)
}
 
pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+
+   status = pwmss_submodule_state_change(pdev->dev.parent,
+   PWMSS_ECAPCLK_EN);
+   if (!(status & PWMSS_ECAPCLK_EN_ACK)) {
+   dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
+   ret = -EINVAL;
+   goto pwmss_clk_failure;
+   }
+
+   pm_runtime_put_sync(&pdev->dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+pwmss_clk_failure:
+   pm_runtime_put_sync(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+   pwmchip_remove(&pc->chip);
+   return ret;
 }
 
 static int __devexit ecap_pwm_remove(struct platform_device *pdev)
 {
struct ecap_pwm_chip *pc = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(&pdev->dev);
+   /*
+* Due to hardware misbehaviour, acknowledge of the stop_req
+* is missing. Hence checking of the status bit skipped.
+*/
+   pwmss_submodule_state_change(pdev->dev.parent, PWMSS_ECAPCLK_STOP_REQ);
+   pm_runtime_put_sync(&pdev->dev);
+
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return pwmchip_remove(&pc->chip);
@@ -246,7 +284,9 @@ static int __devexit ecap_pwm_remove(struct platform_device 
*pdev)
 
 static struct platform_driver ecap_pwm_driver = {
.driver = {

[PATCH v5 09/12] pwm: pwm-tiehrpwm: pinctrl support

[Philip, Avinash]

Enable pinctrl for pwm-tiehrpwm if pinctrl driver available, else
bail out with warning message.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Changes warning message.

 drivers/pwm/pwm-tiehrpwm.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index d3194c0..e8683bc 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pwm-tipwmss.h"
 
@@ -415,6 +416,11 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
struct clk *clk;
struct ehrpwm_pwm_chip *pc;
u16 status;
+   struct pinctrl *pinctrl;
+
+   pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(&pdev->dev, "unable to select pin group\n");
 
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
-- 
1.7.0.4

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

[PATCH v5 08/12] pwm: tiehrpwm: Add device-tree binding

[Philip, Avinash]

This patch
1. Add support for device-tree binding for EHRWPM driver.
2. Set size of pwm-cells set to 3 to support PWM channel number, PWM
   period & polarity configuration from device tree.
3. Add enable/disable clock gating in PWM subsystem common config space.
4. When here set .owner member in platform_driver structure to
   THIS_MODULE.

Signed-off-by: Philip, Avinash 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Rob Landley 
---
Changes since v4:
- Made dt match property in single line for consistency
- Corrected commit subject for consistency.

Changes since v3:
- Replace pwmss.h with pwm-tipwmss.h

Changes since v2:
- Add of_pwm_xlate_with_flags function support

Changes since v1:
- Add separate patch for pinctrl support
- Add conditional check for PWM subsystem clock enable.
- Combined with HWMOD changes & DT bindings.
- Remove the custom of_xlate support.

 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |   23 +++
 drivers/pwm/pwm-tiehrpwm.c |   42 +++-
 2 files changed, 64 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
new file mode 100644
index 000..4fc7079
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -0,0 +1,23 @@
+TI SOC EHRPWM based PWM controller
+
+Required properties:
+- compatible : Must be "ti,am33xx-ehrpwm"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period in nanoseconds and bit 0 in the third cell is used to
+  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+  to 1 for inverse polarity & set to 0 for normal polarity.
+- reg: physical base address and size of the registers map.
+
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the EHRPWM:
+  "ehrpwm",  being the 0-based instance number from the HW spec
+
+Example:
+
+ehrpwm0: ehrpwm@0 {
+   compatible = "ti,am33xx-ehrpwm";
+   #pwm-cells = <3>;
+   reg = <0x48300200 0x100>;
+   ti,hwmods = "ehrpwm0";
+};
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 56a1325..d3194c0 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -25,6 +25,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "pwm-tipwmss.h"
 
 /* EHRPWM registers and bits definitions */
 
@@ -399,12 +402,19 @@ static const struct pwm_ops ehrpwm_pwm_ops = {
.owner  = THIS_MODULE,
 };
 
+static const struct of_device_id ehrpwm_of_match[] = {
+   { .compatible   = "ti,am33xx-ehrpwm" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ehrpwm_of_match);
+
 static int __devinit ehrpwm_pwm_probe(struct platform_device *pdev)
 {
int ret;
struct resource *r;
struct clk *clk;
struct ehrpwm_pwm_chip *pc;
+   u16 status;
 
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
if (!pc) {
@@ -426,6 +436,8 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
 
pc->chip.dev = &pdev->dev;
pc->chip.ops = &ehrpwm_pwm_ops;
+   pc->chip.of_xlate = of_pwm_xlate_with_flags;
+   pc->chip.of_pwm_n_cells = 3;
pc->chip.base = -1;
pc->chip.npwm = NUM_PWM_CHANNEL;
 
@@ -454,14 +466,40 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
}
 
pm_runtime_enable(&pdev->dev);
+   pm_runtime_get_sync(&pdev->dev);
+
+   status = pwmss_submodule_state_change(pdev->dev.parent,
+   PWMSS_EPWMCLK_EN);
+   if (!(status & PWMSS_EPWMCLK_EN_ACK)) {
+   dev_err(&pdev->dev, "PWMSS config space clock enable failed\n");
+   ret = -EINVAL;
+   goto pwmss_clk_failure;
+   }
+
+   pm_runtime_put_sync(&pdev->dev);
+
platform_set_drvdata(pdev, pc);
return 0;
+
+pwmss_clk_failure:
+   pm_runtime_put_sync(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+   pwmchip_remove(&pc->chip);
+   return ret;
 }
 
 static int __devexit ehrpwm_pwm_remove(struct platform_device *pdev)
 {
struct ehrpwm_pwm_chip *pc = platform_get_drvdata(pdev);
 
+   pm_runtime_get_sync(&pdev->dev);
+   /*
+* Due to hardware misbehaviour, acknowledge of the stop_req
+* is missing. Hence checking of the status bit skipped.
+*/
+   pwmss_submodule_state_change(pdev->dev.parent, PWMSS_EPWMCLK_STOP_REQ);
+   pm_runtime_put_sync(&pdev->dev);
+
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return pwmchip_remove(&pc->chip);
@@ -469,7 +507,9 @@ static int __devexit ehrpwm_pwm_remove(struct 
platform_device *pdev)
 
 static struct platform_driver ehrpw

[PATCH v5 07/12] pwm: pwm-tiehrpwm: Adding TBCLK gating support.

[Philip, Avinash]

Some platforms (like AM33XX) requires clock gating from control module
explicitly for TBCLK. Enabling of this clock required for the
functioning of the time base sub module in EHRPWM module. Adding support
for handling by enabling the clock on PWM device enable & disable on PWM
device disable. Platforms don't have explicit TBCLK gating has to add
dummy TBCLK node.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Made TBCLK gating as a must clock for EHRPWM. Platforms don't
  have explicit TBCLK gating, has to populate dummy clock node for
  TBCLK.

 drivers/pwm/pwm-tiehrpwm.c |   14 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index d3c1dff..56a1325 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -115,6 +115,7 @@ struct ehrpwm_pwm_chip {
void __iomem*mmio_base;
unsigned long period_cycles[NUM_PWM_CHANNEL];
enum pwm_polarity polarity[NUM_PWM_CHANNEL];
+   struct  clk *tbclk;
 };
 
 static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -335,6 +336,9 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
/* Channels polarity can be configured from action qualifier module */
configure_polarity(pc, pwm->hwpwm);
 
+   /* Enable TBCLK before enabling PWM device */
+   clk_enable(pc->tbclk);
+
/* Enable time counter for free_run */
ehrpwm_modify(pc->mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_FREE_RUN);
return 0;
@@ -363,6 +367,9 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 
ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
 
+   /* Disabling TBCLK on PWM disable */
+   clk_disable(pc->tbclk);
+
/* Stop Time base counter */
ehrpwm_modify(pc->mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_STOP_NEXT);
 
@@ -432,6 +439,13 @@ static int __devinit ehrpwm_pwm_probe(struct 
platform_device *pdev)
if (!pc->mmio_base)
return  -EADDRNOTAVAIL;
 
+   /* Acquire tbclk for Time Base EHRPWM submodule */
+   pc->tbclk = devm_clk_get(&pdev->dev, "tbclk");
+   if (IS_ERR(pc->tbclk)) {
+   dev_err(&pdev->dev, "Failed to get tbclk\n");
+   return PTR_ERR(pc->tbclk);
+   }
+
ret = pwmchip_add(&pc->chip);
if (ret < 0) {
dev_err(&pdev->dev, "pwmchip_add() failed: %d\n", ret);
-- 
1.7.0.4

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

[PATCH v5 03/12] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem

[Philip, Avinash]

As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM). To handle
resource sharing & IP integration  rework on parent child relation
between PWMSS and ECAP, EQEP & EHRPWM child devices to support runtime PM.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Split HWMOD patch to handle Parent<->child relation

 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  434 +---
 1 files changed, 203 insertions(+), 231 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 9ed0bcf..426ca9b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -768,9 +768,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
},
 };
 
-/*
- * 'epwmss' class: ehrpwm0,1,2 eqep0,1,2 ecap0,1,2
- */
+/* pwmss  */
 static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs   = 0x0,
.sysc_offs  = 0x4,
@@ -786,67 +784,44 @@ static struct omap_hwmod_class am33xx_epwmss_hwmod_class 
= {
.sysc   = &am33xx_epwmss_sysc,
 };
 
-/* ehrpwm0 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
-   { .name = "int", .irq = 86 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 58 + OMAP_INTC_START, },
-   { .irq = -1 },
+static struct omap_hwmod_class am33xx_ecap_hwmod_class = {
+   .name   = "ecap",
 };
 
-static struct omap_hwmod am33xx_ehrpwm0_hwmod = {
-   .name   = "ehrpwm0",
-   .class  = &am33xx_epwmss_hwmod_class,
-   .clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm0_irqs,
-   .main_clk   = "l4ls_gclk",
-   .prcm   = {
-   .omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
+static struct omap_hwmod_class am33xx_eqep_hwmod_class = {
+   .name   = "eqep",
 };
 
-/* ehrpwm1 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm1_irqs[] = {
-   { .name = "int", .irq = 87 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 59 + OMAP_INTC_START, },
-   { .irq = -1 },
+static struct omap_hwmod_class am33xx_ehrpwm_hwmod_class = {
+   .name   = "ehrpwm",
 };
 
-static struct omap_hwmod am33xx_ehrpwm1_hwmod = {
-   .name   = "ehrpwm1",
+/* epwmss0 */
+static struct omap_hwmod am33xx_epwmss0_hwmod = {
+   .name   = "epwmss0",
.class  = &am33xx_epwmss_hwmod_class,
.clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm1_irqs,
.main_clk   = "l4ls_gclk",
.prcm   = {
.omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
+   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
 };
 
-/* ehrpwm2 */
-static struct omap_hwmod_irq_info am33xx_ehrpwm2_irqs[] = {
-   { .name = "int", .irq = 39 + OMAP_INTC_START, },
-   { .name = "tzint", .irq = 60 + OMAP_INTC_START, },
+/* ecap0 */
+static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
+   { .irq = 31 + OMAP_INTC_START, },
{ .irq = -1 },
 };
 
-static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
-   .name   = "ehrpwm2",
-   .class  = &am33xx_epwmss_hwmod_class,
+static struct omap_hwmod am33xx_ecap0_hwmod = {
+   .name   = "ecap0",
+   .class  = &am33xx_ecap_hwmod_class,
.clkdm_name = "l4ls_clkdm",
-   .mpu_irqs   = am33xx_ehrpwm2_irqs,
+   .mpu_irqs   = am33xx_ecap0_irqs,
.main_clk   = "l4ls_gclk",
-   .prcm   = {
-   .omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
 };
 
 /* eqep0 */
@@ -857,29 +832,32 @@ static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
 
 static struct omap_hwmod am33xx_eqep0_hwmod = {
.name   = "eqep0",
-   .class  = &am33xx_epwmss_hwmod_class,
+   .class  = &am33xx_eqep_hwmod_class,
.clkdm_name = "l4ls_clkdm",
.mpu_irqs   = am33xx_eqep0_irqs,
.main_clk   = "l4ls_gclk",
-   .prcm   = {
-   .omap4  = {
-   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
-   .modulemode = MODULEMODE_SWCTRL,
-   },
-   },
 };
 
-/* eqep1 */
-static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
-   { .irq = 88 + OMAP_INTC_START, },
+/* ehrpwm0 */
+static struct omap_hwmod_irq_info am33xx_ehrpwm0_irqs[] = {
+   { .name = "int", .irq = 86 + OMAP_INTC_START, 

[PATCH v5 02/12] ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries

[Philip, Avinash]

EQEP entry is HWMOD entry is not present in HWMOD entry. Also address
ranges specified for EACP & EHRPWM is not correct & HWMOD flags of
ADDR_TYPE_RT is added to PWM subsystem register address space. This
patch
1. Corrects register address mapping for ECAP & EHRPWM
2. Removes  HWMOD flags in PWM submodule register address space.
3. Adds EQEP HWMOD entries.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Split the HWMOD patches to handle correction of PWMi
  subsystem correction.

 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  158 +---
 1 files changed, 145 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..9ed0bcf 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -769,7 +769,7 @@ static struct omap_hwmod am33xx_elm_hwmod = {
 };
 
 /*
- * 'epwmss' class: ecap0,1,2,  ehrpwm0,1,2
+ * 'epwmss' class: ehrpwm0,1,2 eqep0,1,2 ecap0,1,2
  */
 static struct omap_hwmod_class_sysconfig am33xx_epwmss_sysc = {
.rev_offs   = 0x0,
@@ -849,6 +849,66 @@ static struct omap_hwmod am33xx_ehrpwm2_hwmod = {
},
 };
 
+/* eqep0 */
+static struct omap_hwmod_irq_info am33xx_eqep0_irqs[] = {
+   { .irq = 79 + OMAP_INTC_START, },
+   { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep0_hwmod = {
+   .name   = "eqep0",
+   .class  = &am33xx_epwmss_hwmod_class,
+   .clkdm_name = "l4ls_clkdm",
+   .mpu_irqs   = am33xx_eqep0_irqs,
+   .main_clk   = "l4ls_gclk",
+   .prcm   = {
+   .omap4  = {
+   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS0_CLKCTRL_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* eqep1 */
+static struct omap_hwmod_irq_info am33xx_eqep1_irqs[] = {
+   { .irq = 88 + OMAP_INTC_START, },
+   { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep1_hwmod = {
+   .name   = "eqep1",
+   .class  = &am33xx_epwmss_hwmod_class,
+   .clkdm_name = "l4ls_clkdm",
+   .mpu_irqs   = am33xx_eqep1_irqs,
+   .main_clk   = "l4ls_gclk",
+   .prcm   = {
+   .omap4  = {
+   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS1_CLKCTRL_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* eqep2 */
+static struct omap_hwmod_irq_info am33xx_eqep2_irqs[] = {
+   { .irq = 89 + OMAP_INTC_START, },
+   { .irq = -1 },
+};
+
+static struct omap_hwmod am33xx_eqep2_hwmod = {
+   .name   = "eqep2",
+   .class  = &am33xx_epwmss_hwmod_class,
+   .clkdm_name = "l4ls_clkdm",
+   .mpu_irqs   = am33xx_eqep2_irqs,
+   .main_clk   = "l4ls_gclk",
+   .prcm   = {
+   .omap4  = {
+   .clkctrl_offs   = AM33XX_CM_PER_EPWMSS2_CLKCTRL_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
 /* ecap0 */
 static struct omap_hwmod_irq_info am33xx_ecap0_irqs[] = {
{ .irq = 31 + OMAP_INTC_START, },
@@ -2530,8 +2590,7 @@ static struct omap_hwmod_addr_space 
am33xx_ehrpwm0_addr_space[] = {
},
{
.pa_start   = 0x48300200,
-   .pa_end = 0x48300200 + SZ_256 - 1,
-   .flags  = ADDR_TYPE_RT
+   .pa_end = 0x48300200 + SZ_128 - 1,
},
{ }
 };
@@ -2556,8 +2615,7 @@ static struct omap_hwmod_addr_space 
am33xx_ehrpwm1_addr_space[] = {
},
{
.pa_start   = 0x48302200,
-   .pa_end = 0x48302200 + SZ_256 - 1,
-   .flags  = ADDR_TYPE_RT
+   .pa_end = 0x48302200 + SZ_128 - 1,
},
{ }
 };
@@ -2582,8 +2640,7 @@ static struct omap_hwmod_addr_space 
am33xx_ehrpwm2_addr_space[] = {
},
{
.pa_start   = 0x48304200,
-   .pa_end = 0x48304200 + SZ_256 - 1,
-   .flags  = ADDR_TYPE_RT
+   .pa_end = 0x48304200 + SZ_128 - 1,
},
{ }
 };
@@ -2600,6 +2657,81 @@ static struct omap_hwmod_ocp_if am33xx_l4_ls__ehrpwm2 = {
  * Splitting the resources to handle access of PWMSS config space
  * and module specific part independently
  */
+static struct omap_hwmod_addr_space am33xx_eqep0_addr_space[] = {
+   {
+   .pa_start   = 0x4830,
+   .pa_end = 0x4830 + SZ_16 - 1,
+   .flags  = ADDR_TYPE_RT
+   },
+   {
+   .pa_start   = 0x48300180,
+   .pa_end = 0x48300180 + SZ_128 - 1,
+   },
+   { }
+};
+
+static struct omap_hwmod_ocp_if am33xx_l4_ls__eqep0 = {
+   .master = &am33xx_l4_ls_hwmod,
+  

[PATCH v5 01/12] PWMSS: Add PWM Subsystem driver for parent<->child relationship

[Philip, Avinash]

In some platforms (like am33xx), PWM sub modules (ECAP, EHRPWM, EQEP)
are integrated to PWM subsystem. These PWM submodules has resources
shared and only one register bit-field is provided to control
module/clock enable/disable, makes it difficult to handle common
resources from independent PWMSS submodule drivers.

So the solution here implemented in this patch is, to create driver for
PWMSS and take the role of parent driver for PWM submodules. PWMSS
parent driver enumerates all the child nodes under PWMSS module. Also
symbol "pwmss_submodule_state_change" exported to enable clock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.

As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM & ECAP as a child to PWMSS node.

Signed-off-by: Philip, Avinash 
---
Changes since v4:
- Made dt match property in single line for consistency
- Use SIMPLE_DEV_PM_OPS

Changes since v3:
- Corrected the usage of ranges property in documentation.
- Add pwm prefix to tipwmss.h file

Changes since v2:
- Set build attribute to bool type.
- Add pwm prefix to tipwmss.c file
- Span mutex protection for read modify approach.
- Use SET_SYSTEM_SLEEP_PM_OPS
- Add PWM subsystem bit fields to tipwmss.h
- Remove devinit & devexit attributes.
- Left out adding of child node's DT property in Documentation
  as those definitions are part of later patches.

Changes since v1:
- Add conditional check for PWM subsystem clock enabling.
- Add context save/restore for PWM subsystem clock config register.

 .../devicetree/bindings/pwm/pwm-tipwmss.txt|   31 +
 drivers/pwm/Kconfig|   11 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-tipwmss.c  |  139 
 drivers/pwm/pwm-tipwmss.h  |   39 ++
 5 files changed, 221 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
 create mode 100644 drivers/pwm/pwm-tipwmss.c
 create mode 100644 drivers/pwm/pwm-tipwmss.h

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
new file mode 100644
index 000..f7eae77
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
@@ -0,0 +1,31 @@
+TI SOC based PWM Subsystem
+
+Required properties:
+- compatible: Must be "ti,am33xx-pwmss";
+- reg: physical base address and size of the registers map.
+- address-cells: Specify the number of u32 entries needed in child nodes.
+ Should set to 1.
+- size-cells: specify number of u32 entries needed to specify child nodes size
+   in reg property. Should set to 1.
+- ranges: describes the address mapping of a memory-mapped bus. Should set to
+  physical address map of child's base address, physical address within
+  parent's address  space and length of the address map. For am33xx,
+  3 set of child register maps present, ECAP register space, EQEP
+  register space, EHRPWM register space.
+
+Also child nodes should also populated under PWMSS DT node.
+
+Example:
+pwmss0: pwmss@4830 {
+   compatible = "ti,am33xx-pwmss";
+   reg = <0x4830 0x10>;
+   ti,hwmods = "epwmss0";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   status = "disabled";
+   ranges = <0x48300100 0x48300100 0x80   /* ECAP */
+ 0x48300180 0x48300180 0x80   /* EQEP */
+ 0x48300200 0x48300200 0x80>; /* EHRPWM */
+
+   /* child nodes go here */
+};
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index ed81720..1dc32a8 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -125,6 +125,7 @@ config PWM_TEGRA
 config  PWM_TIECAP
tristate "ECAP PWM support"
depends on SOC_AM33XX
+   select PWM_TIPWMSS
help
  PWM driver support for the ECAP APWM controller found on AM33XX
  TI SOC
@@ -135,6 +136,7 @@ config  PWM_TIECAP
 config  PWM_TIEHRPWM
tristate "EHRPWM PWM support"
depends on SOC_AM33XX
+   select PWM_TIPWMSS
help
  PWM driver support for the EHRPWM controller found on AM33XX
  TI SOC
@@ -142,6 +144,15 @@ config  PWM_TIEHRPWM
  To compile this driver as a module, choose M here: the module
  will be called pwm-tiehrpwm.
 
+config  PWM_TIPWMSS
+   bool
+   depends on SOC_AM33XX && (PWM_TIEHRPWM || PWM_TIECAP)
+   help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
 config PWM_TWL6030
trista

[PATCH v5 00/12] Support for AM33xx PWM Subsystem

[Philip, Avinash]

In AM33xx PWM sub modules like ECAP, EHRPWM & EQEP are  integrated to
PWM subsystem. All these submodules shares the resources (clock) & has
a clock gating register in PWM Subsystem. This patch series creates a
parent PWM Subsystem driver to handle access synchronization of shared
resources & clock gating from PWM Subsystem configuration space.
Also Device tree nodes populated to support parent child relation
between PWMSS, ECAP & EHRPWM submodules.
In addition EHRPWM module requires explicit clock gating from control
module & is handled by patch #6 & 7.

As suggested by  Thierry for handling clock gating for PWM submodules
should handle with a global function. This requires config space
handling done independent from driver and is done at parent driver.

So the parent<->child relation adopted to handle
1. pm runtime synchronization
2. PWM subsystem common config space clock gating for PWM submodules.

Patches supports
- Driver support for parent child relation handled patch #1
- HWMOD data correction in EPWMSS at patch #2
- Parent child in HWMOD relation handled at patch #3
- Optional EHRPWM tb clock in patch #6
- Support for TBCLK clock gating at patch #7.
- Device tree binding support handled in patch #4,8 
- Pinctrl support in patch #5 & 9.
- DT node populated in patch #10 ,11 & 12.

This patch series based on omap_dt/for_3.8/dts_part2 and tested
on am335x-evm & am335x-evmsk.

This patch series will come under 3 subsystem basically. But sent
it in single patch series to have a clearer picture of why the
OMAP subsystem changes required.

Patches come under PWM (1,4,5,7,8,9)
Patches come under OMAP (2,3,6)
Patches come under DT (10,11,12).

It depends on [1]
1. 
https://gitorious.org/linux-pwm/linux-pwm/commit/83af24027b3df1af5c5a9aa9adcdcfeb3429d3be
pwm: Device tree support for PWM polarity

Changes since v3:
- Rebased on top of omap_dt/for_3.8/dts_part2
- Add pwm backlight for am335xevm_sk
- Moved tipwmss.h to pwm-tipwmss.h

Philip, Avinash (12):
  PWMSS: Add PWM Subsystem driver for parent<->child relationship
  ARM: OMAP: AM33xx hwmod: Corrects PWM subsystem HWMOD entries
  ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM
subsystem
  pwm: tiecap: Add device-tree binding
  pwm: pwm-tiecap: pinctrl support
  ARM: AM33XX: clk: Add clock node for EHRPWM TBCLK
  pwm: pwm-tiehrpwm: Adding TBCLK gating support.
  pwm: tiehrpwm: Add device-tree binding
  pwm: pwm-tiehrpwm: pinctrl support
  ARM: dts: AM33XX: Add PWMSS device tree nodes
  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
  ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk

 .../devicetree/bindings/pwm/pwm-tiecap.txt |   23 ++
 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |   23 ++
 .../devicetree/bindings/pwm/pwm-tipwmss.txt|   31 ++
 arch/arm/boot/dts/am335x-evm.dts   |   23 ++
 arch/arm/boot/dts/am335x-evmsk.dts |   23 ++
 arch/arm/boot/dts/am33xx.dtsi  |   84 +
 arch/arm/mach-omap2/clock33xx_data.c   |   37 ++
 arch/arm/mach-omap2/control.h  |8 +
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c |  388 +---
 drivers/pwm/Kconfig|   11 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-tiecap.c   |   48 +++-
 drivers/pwm/pwm-tiehrpwm.c |   62 +++-
 drivers/pwm/pwm-tipwmss.c  |  139 +++
 drivers/pwm/pwm-tipwmss.h  |   39 ++
 15 files changed, 797 insertions(+), 144 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
 create mode 100644 drivers/pwm/pwm-tipwmss.c
 create mode 100644 drivers/pwm/pwm-tipwmss.h

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

Re: [PATCH 1/1] ARM: OMAP2+: enable devtmpfs and devtmpfs automount

[Sekhar Nori]

On 11/21/2012 6:56 PM, Javier Martinez Canillas wrote:
> Since udev-182, udev no longer creates device nodes under /dev

Nit: Looks like this happened from udev-176 onward.

http://permalink.gmane.org/gmane.linux.hotplug.devel/17230

Whoever is taking the patch can _probably_ fix it up while applying.

> and this has to be managed by the kernel devtmpfs filesystem.
> 
> This means that a kernel built with the current OMAP2+ config
> will not boot on a system with a recent udev.

> Also, it is good to have /dev automatically mounted since some
> non-initramfs based setups assumes this and don't manually mount it.

For curiosity sake, any examples of such setups? I am using fedora 17 on
DaVinci and that doesn't seem to need it. Anyway, agreed that its better
to keep it enabled.

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