Re: [PATCH] MMC/omap_hsmmc: handle failure of regulator_get better.

[NeilBrown]

On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayak rna...@ti.com wrote:

 On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
 
  1/ if regulator_get fails, return an error.  This is important
  if it failed with EPROBE_DEFER, as the probe needs to be
  deferred.
 
  2/ Don't set .set_power until the regulator has been found, or
  the deferred probe will not bother calling omap_hsmmc_reg_get().
 
 I am not very sure, but aren't the data structures re-allocated on a
 re-probe (after it was deferred) causing .set_power to be lost anyway?
 

Apparently not - as I needed to make that change before the re-probe would
work.

Looking at the code to remind myself:

#define mmc_slot(host)  (host-pdata-slots[host-slot_id])

so the slot is inside the platform data which is allocated in
omap_hsmmc_init_one, called from omap_hsmmc_init.
This is all prior to the probing of the device.

So no: once set_power is set, it stays set.

Thanks,
NeilBrown

 
  Signed-off-by: NeilBrownne...@suse.de
 
  diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
  index 389a3ee..f052c29 100644
  --- a/drivers/mmc/host/omap_hsmmc.c
  +++ b/drivers/mmc/host/omap_hsmmc.c
  @@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
  *host)
  struct regulator *reg;
  int ocr_value = 0;
 
  -   mmc_slot(host).set_power = omap_hsmmc_set_power;
  -
  reg = regulator_get(host-dev, vmmc);
  if (IS_ERR(reg)) {
  dev_dbg(host-dev, vmmc regulator missing\n);
  +   return PTR_ERR(reg);
  } else {
  +   mmc_slot(host).set_power = omap_hsmmc_set_power;
  host-vcc = reg;
  ocr_value = mmc_regulator_get_ocrmask(reg);
  if (!mmc_slot(host).ocr_mask) {



signature.asc
Description: PGP signature

Re: [PATCH] MMC/omap_hsmmc: handle failure of regulator_get better.

[Rajendra Nayak]

On Monday 30 July 2012 11:54 AM, NeilBrown wrote:

On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayakrna...@ti.com  wrote:


On Monday 30 July 2012 05:42 AM, NeilBrown wrote:


1/ if regulator_get fails, return an error.  This is important
 if it failed with EPROBE_DEFER, as the probe needs to be
 deferred.

2/ Don't set .set_power until the regulator has been found, or
 the deferred probe will not bother calling omap_hsmmc_reg_get().


I am not very sure, but aren't the data structures re-allocated on a
re-probe (after it was deferred) causing .set_power to be lost anyway?



Apparently not - as I needed to make that change before the re-probe would
work.

Looking at the code to remind myself:

#define mmc_slot(host)  (host-pdata-slots[host-slot_id])

so the slot is inside the platform data which is allocated in
omap_hsmmc_init_one, called from omap_hsmmc_init.
This is all prior to the probing of the device.

So no: once set_power is set, it stays set.


Thanks for the explanation, makes sense.

Acked-by: Rajendra Nayak rna...@ti.com

Btw, is the support for re-probe/deferred probe already merged
now? or are you testing this with some out of tree patches.



Thanks,
NeilBrown



Signed-off-by: NeilBrownne...@suse.de

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 389a3ee..f052c29 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host 
*host)
struct regulator *reg;
int ocr_value = 0;

-   mmc_slot(host).set_power = omap_hsmmc_set_power;
-
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
+   return PTR_ERR(reg);
} else {
+   mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {




--
To unsubscribe from this list: send the line unsubscribe 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] MMC/omap_hsmmc: handle failure of regulator_get better.

[NeilBrown]

On Mon, 30 Jul 2012 12:07:09 +0530 Rajendra Nayak rna...@ti.com wrote:

 On Monday 30 July 2012 11:54 AM, NeilBrown wrote:
  On Mon, 30 Jul 2012 10:50:36 +0530 Rajendra Nayakrna...@ti.com  wrote:
 
  On Monday 30 July 2012 05:42 AM, NeilBrown wrote:
 
  1/ if regulator_get fails, return an error.  This is important
   if it failed with EPROBE_DEFER, as the probe needs to be
   deferred.
 
  2/ Don't set .set_power until the regulator has been found, or
   the deferred probe will not bother calling omap_hsmmc_reg_get().
 
  I am not very sure, but aren't the data structures re-allocated on a
  re-probe (after it was deferred) causing .set_power to be lost anyway?
 
 
  Apparently not - as I needed to make that change before the re-probe would
  work.
 
  Looking at the code to remind myself:
 
  #define mmc_slot(host)  (host-pdata-slots[host-slot_id])
 
  so the slot is inside the platform data which is allocated in
  omap_hsmmc_init_one, called from omap_hsmmc_init.
  This is all prior to the probing of the device.
 
  So no: once set_power is set, it stays set.
 
 Thanks for the explanation, makes sense.
 
 Acked-by: Rajendra Nayak rna...@ti.com

Thanks.

 
 Btw, is the support for re-probe/deferred probe already merged
 now? or are you testing this with some out of tree patches.

deferred-probe works in 3.5. 

commit 04bf30115f4ba2beda1efb6cfbae49cdc757f3a9
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date:   Sun Mar 11 13:07:56 2012 +

regulator: Support driver probe deferral
 
makes it work for regulators.

commit d1c3414c2a9d10ef7f0f7665f5d2947cd088c093
Author: Grant Likely grant.lik...@secretlab.ca
Date:   Mon Mar 5 08:47:41 2012 -0700

drivercore: Add driver probe deferral mechanism

added the basic mechanism.

GPIOs are also supported in 3.6-rc thanks to

commit e93545763021988def06fbda28fe5da133589a96
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date:   Mon Jul 9 12:22:56 2012 +0100

gpiolib: Defer failed gpio requests by default

so the omap_hsmmc_late_init() stuff can probably be removed, though I haven't
tried and there might be some subtlety in there that isn't covered by
EPROBE_DEFER

NeilBrown


 
 
  Thanks,
  NeilBrown
 
 
  Signed-off-by: NeilBrownne...@suse.de
 
  diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
  index 389a3ee..f052c29 100644
  --- a/drivers/mmc/host/omap_hsmmc.c
  +++ b/drivers/mmc/host/omap_hsmmc.c
  @@ -299,12 +299,12 @@ static int omap_hsmmc_reg_get(struct 
  omap_hsmmc_host *host)
struct regulator *reg;
int ocr_value = 0;
 
  - mmc_slot(host).set_power = omap_hsmmc_set_power;
  -
reg = regulator_get(host-dev, vmmc);
if (IS_ERR(reg)) {
dev_dbg(host-dev, vmmc regulator missing\n);
  + return PTR_ERR(reg);
} else {
  + mmc_slot(host).set_power = omap_hsmmc_set_power;
host-vcc = reg;
ocr_value = mmc_regulator_get_ocrmask(reg);
if (!mmc_slot(host).ocr_mask) {
 



signature.asc
Description: PGP signature

Re: [PATCH v3 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk

[Paul Walmsley]

Hi Rajendra

On Mon, 2 Jul 2012, Rajendra Nayak wrote:

 While we move to Common Clk Framework (CCF), direct deferencing of struct
 clk wouldn't be possible anymore. Hence get rid of all such instances
 in the current clock code and use macros/helpers similar to the ones that
 are provided by CCF.
 
 While here also concatenate some strings split across multiple lines
 which seem to be needed anyway.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com

This one has some checkpatch warnings:

WARNING: quoted string split across lines
#482: FILE: arch/arm/mach-omap2/clock.c:109:
pr_debug(clock: could not associate clk %s to 
+clkdm %s\n, clk_name, clk-clkdm_name);

ERROR: Macros with complex values should be enclosed in parenthesis
#709: FILE: arch/arm/plat-omap/include/plat/clock.h:22:
+#define __clk_get_name(clk) clk-name

ERROR: Macros with complex values should be enclosed in parenthesis
#710: FILE: arch/arm/plat-omap/include/plat/clock.h:23:
+#define __clk_get_parent(clk) clk-parent

... etc. 

These have been fixed in the version below, and a few other minor changes 
made.  The patch below has been queued for 3.7.  Please don't forget to 
make sure a patch doesn't cause checkpatch.pl warnings before posting.


- Paul

From: Rajendra Nayak rna...@ti.com
Date: Wed, 27 Jun 2012 14:18:35 +0530
Subject: [PATCH] ARM: OMAP2+: clk: Remove all direct dereferencing of struct
 clk

While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.

Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: simplified some compound expressions; resolved checkpatch
 warnings; reformatted some messages]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@linaro.org
---
 arch/arm/mach-omap2/clkt2xxx_apll.c  |2 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |   10 ++-
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c   |   18 +++---
 arch/arm/mach-omap2/clkt_clksel.c|   90 --
 arch/arm/mach-omap2/clkt_dpll.c  |   24 ---
 arch/arm/mach-omap2/clock.c  |   11 ++--
 arch/arm/mach-omap2/dpll3xxx.c   |   48 --
 arch/arm/mach-omap2/omap_hwmod.c |6 +-
 arch/arm/mach-omap2/pm.c |2 +-
 arch/arm/plat-omap/include/plat/clock.h  |5 ++
 10 files changed, 133 insertions(+), 83 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c 
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index b19a1f7..c2d15212 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -59,7 +59,7 @@ static int omap2_clk_apll_enable(struct clk *clk, u32 
status_mask)
omap2_cm_write_mod_reg(cval, PLL_MOD, CM_CLKEN);
 
omap2_cm_wait_idlest(cm_idlest_pll, status_mask,
-OMAP24XX_CM_IDLEST_VAL, clk-name);
+OMAP24XX_CM_IDLEST_VAL, __clk_get_name(clk));
 
/*
 * REVISIT: Should we return an error code if omap2_wait_clock_ready()
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c 
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3d9d746..da03fa4 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -68,14 +68,15 @@ unsigned long omap2_table_mpu_recalc(struct clk *clk)
 long omap2_round_to_table_rate(struct clk *clk, unsigned long rate)
 {
const struct prcm_config *ptr;
-   long highest_rate;
+   long highest_rate, sys_clk_rate;
 
highest_rate = -EINVAL;
+   sys_clk_rate = __clk_get_rate(sclk);
 
for (ptr = rate_table; ptr-mpu_speed; ptr++) {
if (!(ptr-flags  cpu_mask))
continue;
-   if (ptr-xtal_speed != sclk-rate)
+   if (ptr-xtal_speed != sys_clk_rate)
continue;
 
highest_rate = ptr-mpu_speed;
@@ -94,12 +95,15 @@ int omap2_select_table_rate(struct clk *clk, unsigned long 
rate)
const struct prcm_config *prcm;
unsigned long found_speed = 0;
unsigned long flags;
+   long sys_clk_rate;
+
+   sys_clk_rate = __clk_get_rate(sclk);
 
for (prcm = rate_table; prcm-mpu_speed; prcm++) {
if (!(prcm-flags  cpu_mask))
continue;
 
-   if (prcm-xtal_speed != sclk-rate)
+   if (prcm-xtal_speed != sys_clk_rate)
continue;
 
if (prcm-mpu_speed = rate) {
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..51601db 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -56,6 +56,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long 

Passing device tree via intitrd

[Thomas Renninger]

Hello,

I recently posted a patch to be able to pass data to
the kernel and make use of it really early.
Use-cases are currently:
Pass modified ACPI tables and make use of these instead of BIOS provided 
ones
and (nothing has been done there yet):
Pass CPU microcode updates and flash it really early

This is done by an uncompressed cpio (initrd can consist of one
or more glued cpio archives, compressed or uncompressed).

I've been told that on ARM this feature might get convenient
to pass a flattened device tree via initrd.

These are my posts on lkml:

https://lkml.org/lkml/2012/7/18/165

Early initrd file overwrite and ACPI table override making use of it
  [PATCH 1/2] init: Introduce early initrd files through uncompressed cpio 
passing
  [PATCH 2/2] ACPI: Override arbitrary ACPI tables via initrd for 
debugging

The interesting part for ARM is the first patch.
Enabling this feature on ARM could then be (with the first patch slightly
modified using HAVE_EARLY_INITRD) as easy as below.

The code setup_arch() in arch/arm/kernel/setup.c would at least need some
shifting. But I guess it should be possible to get an arch independent
unified format (via uncompressed, glued cpio) how to pass early data via 
initrd to the kernel?

Unfortunately X86 might need the cpio scanning even earlier (before 
initrd_start is valid). The same seem to be the case for ARM?
I put the scanning, right after initrd_start got valid, for my purposes
that's early enough. Looks like in the end architectures may need
special handling early, but it's certainly a good idea to provide a kernel
wide mechanism to pass data to the kernel early (via uncompressed cpio).

Thanks for comments,

   Thomas

ARM: Enable early initrd file access feature

This would allow passing an uncompressed cpio initrd glued to
the initrd and accessing it early.
The files can be accessed as soon as arm_memblock_init()
(which sets up initrd_start) got called.

This patch is only to show how arch independent the early
initrd feature is and to ask whether this would be useful
for ARM (or other archs):

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..db48897 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -45,6 +45,7 @@ config ARM
select GENERIC_SMP_IDLE_THREAD
select KTIME_SCALAR
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
+   select HAVE_EARLY_INITRD
help
  The ARM series is a line of low-power-consumption RISC chip designs
  licensed by ARM Ltd and targeted at embedded applications and
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..5abc675 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -363,6 +363,8 @@ void __init arm_memblock_init(struct meminfo *mi, 
struct machine_desc *mdesc)
/* Now convert initrd to virtual addresses */
initrd_start = __phys_to_virt(phys_initrd_start);
initrd_end = initrd_start + phys_initrd_size;
+   early_initrd_find_cpio_data((void *)initrd_start,
+   initrd_end - initrd_start);
}
 #endif
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk

[Rajendra Nayak]

Hi Paul,

On Monday 30 July 2012 12:42 PM, Paul Walmsley wrote:

Hi Rajendra

On Mon, 2 Jul 2012, Rajendra Nayak wrote:


While we move to Common Clk Framework (CCF), direct deferencing of
struct clk wouldn't be possible anymore. Hence get rid of all such
instances in the current clock code and use macros/helpers similar
to the ones that are provided by CCF.

While here also concatenate some strings split across multiple
lines which seem to be needed anyway.

Signed-off-by: Rajendra Nayakrna...@ti.com


This one has some checkpatch warnings:

WARNING: quoted string split across lines #482: FILE:
arch/arm/mach-omap2/clock.c:109: pr_debug(clock: could not associate
clk %s to  +   clkdm %s\n, clk_name, clk-clkdm_name);


Are you sure you are using the v3 of this patch? You already mentioned
about these in the v2 [1] and I fixed all these in v3. I went back and
looked at the v3 of this patch, and it does not complain me about any
of these warnings or errors.

regards,
Rajendra

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/107103.html




ERROR: Macros with complex values should be enclosed in parenthesis
#709: FILE: arch/arm/plat-omap/include/plat/clock.h:22: +#define
__clk_get_name(clk) clk-name

ERROR: Macros with complex values should be enclosed in parenthesis
#710: FILE: arch/arm/plat-omap/include/plat/clock.h:23: +#define
__clk_get_parent(clk) clk-parent

... etc.

These have been fixed in the version below, and a few other minor
changes made.  The patch below has been queued for 3.7.  Please don't
forget to make sure a patch doesn't cause checkpatch.pl warnings
before posting.


- Paul

From: Rajendra Nayakrna...@ti.com Date: Wed, 27 Jun 2012 14:18:35
+0530 Subject: [PATCH] ARM: OMAP2+: clk: Remove all direct
dereferencing of struct clk

While we move to Common Clk Framework (CCF), direct deferencing of
struct clk wouldn't be possible anymore. Hence get rid of all such
instances in the current clock code and use macros/helpers similar to
the ones that are provided by CCF.

Signed-off-by: Rajendra Nayakrna...@ti.com [p...@pwsan.com:
simplified some compound expressions; resolved checkpatch warnings;
reformatted some messages] Signed-off-by: Paul
Walmsleyp...@pwsan.com Cc: Mike Turquettemturque...@linaro.org
--- arch/arm/mach-omap2/clkt2xxx_apll.c  |2 +-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |   10 ++-
arch/arm/mach-omap2/clkt34xx_dpll3m2.c   |   18 +++---
arch/arm/mach-omap2/clkt_clksel.c|   90
-- arch/arm/mach-omap2/clkt_dpll.c
|   24 --- arch/arm/mach-omap2/clock.c  |   11
++-- arch/arm/mach-omap2/dpll3xxx.c   |   48
-- arch/arm/mach-omap2/omap_hwmod.c |6
+- arch/arm/mach-omap2/pm.c |2 +-
arch/arm/plat-omap/include/plat/clock.h  |5 ++ 10 files
changed, 133 insertions(+), 83 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c
b/arch/arm/mach-omap2/clkt2xxx_apll.c index b19a1f7..c2d15212 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c +++
b/arch/arm/mach-omap2/clkt2xxx_apll.c @@ -59,7 +59,7 @@ static int
omap2_clk_apll_enable(struct clk *clk, u32 status_mask)
omap2_cm_write_mod_reg(cval, PLL_MOD, CM_CLKEN);

omap2_cm_wait_idlest(cm_idlest_pll, status_mask, -
OMAP24XX_CM_IDLEST_VAL, clk-name); + 
OMAP24XX_CM_IDLEST_VAL,
__clk_get_name(clk));

/* * REVISIT: Should we return an error code if
omap2_wait_clock_ready() diff --git
a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c index 3d9d746..da03fa4
100644 --- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c +++
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c @@ -68,14 +68,15 @@
unsigned long omap2_table_mpu_recalc(struct clk *clk) long
omap2_round_to_table_rate(struct clk *clk, unsigned long rate) {
const struct prcm_config *ptr; -long highest_rate; +long
highest_rate, sys_clk_rate;

highest_rate = -EINVAL; +   sys_clk_rate = __clk_get_rate(sclk);

for (ptr = rate_table; ptr-mpu_speed; ptr++) { if (!(ptr-flags
cpu_mask)) continue; -  if (ptr-xtal_speed != sclk-rate) +
  if
(ptr-xtal_speed != sys_clk_rate) continue;

highest_rate = ptr-mpu_speed; @@ -94,12 +95,15 @@ int
omap2_select_table_rate(struct clk *clk, unsigned long rate) const
struct prcm_config *prcm; unsigned long found_speed = 0; unsigned
long flags; +   long sys_clk_rate; + +  sys_clk_rate =
__clk_get_rate(sclk);

for (prcm = rate_table; prcm-mpu_speed; prcm++) { if (!(prcm-flags
cpu_mask)) continue;

-   if (prcm-xtal_speed != sclk-rate) + if 
(prcm-xtal_speed !=
sys_clk_rate) continue;

if (prcm-mpu_speed= rate) { diff --git
a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c index d6e34dd..51601db
100644 --- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c +++
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c @@ -56,6 +56,7 @@ int

RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

Hi Tony,

On Thu, Jun 28, 2012 at 18:14:30, Mohammed, Afzal wrote:
 On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote:
  * Mohammed, Afzal af...@ti.com [120628 02:36]:

   diff --git a/arch/arm/mach-omap2/gpmc-onenand.c 
   b/arch/arm/mach-omap2/gpmc-onenand.c
   index c8a9487..bbae674 100644
   --- a/arch/arm/mach-omap2/gpmc-onenand.c
   +++ b/arch/arm/mach-omap2/gpmc-onenand.c
   @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem 
   *onenand_base)
   struct gpmc_timings t;
   int ret;
   
   +   omap2_onenand_set_async_mode(onenand_base);
   +
   t = omap2_onenand_calc_async_timings();
   
   ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t);
  
  Yes that seems to do the trick, thanks! I can fold that into the
  breaking patch when applying.
 
 
 Also following needs to be removed from commit message,
 
 Ensuring sync read/write are disabled in onenand cannot
 be expected to work properly unless GPMC is setup, this
 has been removed.
 
 With the above diff we are in effect disabling sync mode in
 onenand before GPMC has been setup in the Kernel
 
 If you want, I can sent a new series too.

Can you please take this series along with the above changes
folded in $subject patch. I  Jon concurred on this as a
solution in this same thread (along with preventing
hwmod reset, which is taken care in hwmod patch).

Please let me know whether you prefer to have a separate series
posted inclusive of the above changes.

Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe 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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Shilimkar, Santosh]

On Mon, Jul 30, 2012 at 7:51 AM, S, Venkatraman svenk...@ti.com wrote:
 On Sat, Jul 28, 2012 at 1:40 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
 On Fri, Jul 27, 2012 at 6:50 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
 On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
  Just a quick reminder that I'm still on holiday, and at this point there
  are over 2500 messages from the mailing lists which are sitting unread
  since I left the UK.  As I mentioned before I left the UK, it is my
  intention *not* to go back and read all those outstanding messages -
  there's too many of them to do that.
 
  So, if you want me to react to any email message you've sent, you'd
  *better* send it again next week unless I've already responded.
 
  Meanwhile, I see v3.5 has been released; I have a couple of things I
  need to do with my tree before I can push the changes, and I'll
  probably see about sorting those out over the weekend.  I also see
  that 14 new patches have landed in the patch system.
 
  However, the timing of my holiday vs the merge window means that I
  can't take anything new, unless they're fixes, so don't be surprised
  if some stuff gets missed this merge window.
 
  Right.  I'm not fully recovered from the jet lag (I'm still rather tired
  - I hate travelling back from the North American continent because it
  takes days to recover.)
 
  I have now archived off *all* email sent to me during July - which means
  that I will *NOT* be responding to anything sent during the last 17 days.
  If anyone has sent me anything important, it *MUST* be resent now.
 
  I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
  exactly what is required there, so I've dropped them from my planned pull
  request in the interests of getting everything else I have to Linus.  I
  may plan to send a pull request this evening.
 
 Well the only pending discussion was enabling the CONFIG option for
 DMA at driver level SOC config level. Not sure if there was anything else
 on this really.

 Why?  The DMA driver itself is optional.
 That was Tony's point too. Unfortunately MMC and SPI driver don't work
 today without DMA. Some works needs to be done to support polling
 mode and am bit skeptical if it is really worth it. Same case be with other
 SDMA supported drivers mostly.

 Russell, Tony,
   Can I request to include the DMA  MMC changes into this merge window ?
 We have many cleanups and new patches waiting to be queued up for next (3.7)
 merge window, and it'd be easier if they are implemented on top of the
 DMA changes,
 so that it gets tested together, and don't create merge conflicts.
   I am looking into implementing polling mode, which might take some time.

Thanks Venkat. For the SPI driver as well I heard from Shubro (in cc) that
he is looking into polling mode.

IMHO, we should merge the OMAP DMA engine support which is now sufficiently
tested and has been in linux-next for some time. Polling mode and ASOC
related issues can be then debugged directly on mainline.
For the time being, the SOC patch which Tony merged in linux-omap
master can be included along with rest of the OMAP DMA engine patches
to have working kernel.

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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Shubhrajyoti Datta]

On Mon, Jul 30, 2012 at 1:10 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
[...]

 Why?  The DMA driver itself is optional.
 That was Tony's point too. Unfortunately MMC and SPI driver don't work
 today without DMA. Some works needs to be done to support polling
 mode and am bit skeptical if it is really worth it. Same case be with other
 SDMA supported drivers mostly.

 Russell, Tony,
   Can I request to include the DMA  MMC changes into this merge window ?
 We have many cleanups and new patches waiting to be queued up for next (3.7)
 merge window, and it'd be easier if they are implemented on top of the
 DMA changes,
 so that it gets tested together, and don't create merge conflicts.
   I am looking into implementing polling mode, which might take some time.

 Thanks Venkat. For the SPI driver as well I heard from Shubro (in cc) that
 he is looking into polling mode.

I had a patch in case of errors falling back to poll mode

http://www.spinics.net/lists/linux-omap/msg74417.html


 IMHO, we should merge the OMAP DMA engine support which is now sufficiently
 tested and has been in linux-next for some time. Polling mode and ASOC
 related issues can be then debugged directly on mainline.
 For the time being, the SOC patch which Tony merged in linux-omap
 master can be included along with rest of the OMAP DMA engine patches
 to have working kernel.

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

Re: [PATCHv4 6/8] ARM: OMAP: pm-debug: enhanced usecount debug support

[Tero Kristo]

On Fri, 2012-07-27 at 12:55 -0700, Kevin Hilman wrote:
 Tero Kristo t-kri...@ti.com writes:
 
  Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
  their own file, 'usecount'. This file shows the usecounts for every
  active domain and their children recursively. 'count' file now only
  shows power state counts for powerdomains.
 
  This patch also provices a way to do printk dumps from kernel code,
  by calling the pm_dbg_dump_X functions. The plan is to call these
  functions once an error condition is detected, e.g. failed suspend.
 
  Signed-off-by: Tero Kristo t-kri...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@ti.com
 
 I think we should separate out the debug stuff as a separate patch set.
 
 Where I want to go with PM debug is away from in-kernel debug prints and
 towards using tracepoints.  We have tracepoints in the clock code that
 correspond to usecounts, but we need them in the clkdm, pwrdm and voltdm
 code as well.  With that, you can use userspace tools (perf, ftrace) to
 trace a problem (e.g. failed suspend) and see voltdm/pwrdm/clkdm/clks
 are on when they shouldn't be.

Yes, I can split out the debug stuff from this set for next rev. I'll
also take a look at the tracepoints if they can be used reasonably for
this purpose. We can add tracepoints for failed suspend for each
powerdomain, but are tracepoints a good way to do this kind of recursive
dumps (well, we could maybe register a trace event recursively from
clkdm + clk code if a powerdomain fails to transition.)

-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: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting

[Tero Kristo]

On Fri, 2012-07-27 at 12:36 -0700, Kevin Hilman wrote:
 Tero Kristo t-kri...@ti.com writes:
 
  mpu / core powerdomain usecounts are now statically increased
  by 1 during MPU activity. This allows the domains to reflect
  actual usage, and will allow the usecount to reach 0 just before
  all CPUs are ready to idle. Proper powerdomain usecounts are
  propageted to voltagedomain level also, and will allow vc
  callbacks to be triggered at right point of time.
 
  Signed-off-by: Tero Kristo t-kri...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Kevin Hilman khil...@ti.com
 
 IMO, the idea is fine, but I'm not crazy about the implementation in
 powerdomain.c, which is meant for pwrdm generic code.   In particular,
 I'm not crazy about the pwrdm lookups in powerdomain.c.
 
 Since pmsoc.c already has references to mpu_pwrdm and core_pwrdm, why
 not just add the pwrdm_clkdm_enable/disable calls directly in pmsoc.c

I think this was how the patch was in some earlier rev but I thought I'd
try to be more clever with this. :) I can revert the implementation back
to this.

 Also, the changelog should be a bit more specific about why CORE
 powerdomain is also handled here when most of the code only talks about
 the CPU.

Yea, I'll add some beef to this also.

-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

[GPIO] Crashed when not using

[Poddar, Sourav]

Hi All,

I tried using gpio as an interrupt line for my driver
(drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
The interrupt line number was directly passed to the driver using
device tree. But what I observed
is the following crash..


[1.599273] mousedev: PS/2 mouse device common for all mice
[1.607513] i2c /dev entries driver
[1.613739] Driver for 1-wire Dallas network protocol.
[1.622650] usbcore: registered new interface driver usbhid
[1.628540] usbhid: USB HID core driver
[1.633728] Unhandled fault: imprecise external abort (0x1406) at 0x
[1.641113] Internal error: : 1406 [#1] SMP ARM
[1.645874] Modules linked in:
[1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty #415)
[1.655761] PC is at _set_gpio_triggering+0x44/0x264
[1.660980] LR is at gpio_irq_type+0xb8/0x160
[1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
[1.665527] sp : dc851df0  ip : c07a8f00  fp : 
[1.677581] r10: 0081  r9 :   r8 : dc8ffc10
[1.683074] r7 : 2093  r6 :   r5 : 0001  r4 : fa05b000
[1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 : 0140
[1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment kernel
[1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
[1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
[1.716857] Stack: (0xdc851df0 to 0xdc852000)
[1.721405] 1de0: 0002
c0731280 dc8ffc6c 2093
[1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
0141 0002 c00a37b8
[1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
c07312b4 4013 c00a3d7c
[1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
c00a2d5c c0412258 0141
[1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
2002 c071bed8 c247f000
[1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
c04ea344 c06728c0 c247f000
[1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
c04ea194 0091 c071bed8
[1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
dc9df054 c07bf60c c03272ac
[1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
c03274c0 c07bf60c dc851f08
[1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
c07bf60c c07bcea8 c243d6c0
[1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
c07bf60c c03e12a0 
[1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
0007 c07c8c40 
[1.824401] 1f60: 0091 c03e1738  dc85 0007
c0008648  c112c9f0
[1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
 0006 0006
[1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
0091 c071bed8 c0700a28
[1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
  c06d028c
[1.858703] 1fe0: c001548c 0013   
c001548c 3f3f3f3f 3f3f3f3f
[1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
[c02dc224] (gpio_irq_type+0x0/0x160)
[1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] (0x2002)
[1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
[1.890960] [ cut here ]
[1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
l3_interrupt_handler+0x184/0x1bc()
[1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
[1.910430] Modules linked in:
[1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
[c00414c4] (warn_slowpath_common+0x4c/0x64)
[1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
[c0041570] (warn_slowpath_fmt+0x30/0x40)
[1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
[c0035de4] (l3_interrupt_handler+0x184/0x1bc)
[1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
[c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
[1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
[c00a2adc] (handle_irq_event+0x3c/0x5c)
[1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
[c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
[1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
[c00a235c] (generic_handle_irq+0x34/0x44)
[1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
[c00153a0] (handle_IRQ+0x4c/0xac)
[1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
(gic_handle_irq+0x2c/0x60)
[2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
[c04f26e4] (__irq_svc+0x44/0x60)
[2.011718] Exception stack(0xdc851c48 to 0xdc851c90)
[2.017028] 1c40:   c07a87a0  dc851c80
 c0743f80 dc851da8
[2.025604] 1c60: 0001 0001 dc851cd7  c02dbb6a
c02dbb6c  dc851c90
[2.034179] 1c80: c04f2440 c04f2444 6113 
[2.039489] [c04f26e4] (__irq_svc+0x44/0x60) from [c04f2444]
(_raw_spin_unlock_irq+0x28/0x2c)
[2.048797] [c04f2444] 

[PATCH v6 06/11] arm/dts: Add twl6030-usb data

[Kishon Vijay Abraham I]

Add twl6030-usb data node in twl6030 device tree file

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4-panda.dts |4 
 arch/arm/boot/dts/omap4-sdp.dts   |4 
 arch/arm/boot/dts/twl6030.dtsi|5 +
 3 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
 };
+
+twlusb {
+   usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
 };
+
+twlusb {
+   usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..8e3aac9 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,9 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+   twlusb: twl6030-usb {
+   compatible = ti,twl6030-usb;
+   interrupts =  4 10 ;
+   };
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module

[Kishon Vijay Abraham I]

The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.

Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 249ff76..775e185 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5934,6 +5934,11 @@ static struct omap_hwmod_addr_space 
omap44xx_wd_timer2_addrs[] = {
.pa_end = 0x4a31407f,
.flags  = ADDR_TYPE_RT
},
+   {
+   .pa_start   = 0x4a00233c,
+   .pa_end = 0x4a00233f,
+   .flags  = ADDR_TYPE_RT
+   },
{ }
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c

[Kishon Vijay Abraham I]

All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.

Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/omap_phy_internal.c |  138 ---
 arch/arm/mach-omap2/twl-common.c|5 --
 arch/arm/mach-omap2/usb-musb.c  |3 -
 3 files changed, 146 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
 #include plat/usb.h
 #include control.h
 
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF   0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL   0x33c
-#defineAVALID  BIT(0)
-#defineBVALID  BIT(1)
-#defineVBUSVALID   BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG   BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
-   ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
-   if (!ctrl_base) {
-   pr_err(control module ioremap failed\n);
-   return -ENOMEM;
-   }
-   /* Power down the phy */
-   __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
-   if (!dev) {
-   iounmap(ctrl_base);
-   return 0;
-   }
-
-   phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
-   if (IS_ERR(phyclk)) {
-   dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
-   iounmap(ctrl_base);
-   return PTR_ERR(phyclk);
-   }
-
-   clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
-   if (IS_ERR(clk48m)) {
-   dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
-   clk_put(phyclk);
-   iounmap(ctrl_base);
-   return PTR_ERR(clk48m);
-   }
-
-   clk32k = clk_get(dev, usb_phy_cm_clk32k);
-   if (IS_ERR(clk32k)) {
-   dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
-   clk_put(phyclk);
-   clk_put(clk48m);
-   iounmap(ctrl_base);
-   return PTR_ERR(clk32k);
-   }
-   return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
-   static int state;
-
-   if (on  !state) {
-   /* Enable the phy clocks */
-   clk_enable(phyclk);
-   clk_enable(clk48m);
-   clk_enable(clk32k);
-   state = 1;
-   } else if (state) {
-   /* Disable the phy clocks */
-   clk_disable(phyclk);
-   clk_disable(clk48m);
-   clk_disable(clk32k);
-   state = 0;
-   }
-   return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
-   if (on) {
-   if (ID)
-   /* enable VBUS valid, IDDIG groung */
-   __raw_writel(AVALID | VBUSVALID, ctrl_base +
-   USBOTGHS_CONTROL);
-   else
-   /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
-   __raw_writel(IDDIG | AVALID | VBUSVALID,
-   ctrl_base + USBOTGHS_CONTROL);
-   } else {
-   /* Enable session END and IDIG to high impedance. */
-   __raw_writel(SESSEND | IDDIG, ctrl_base +
-   USBOTGHS_CONTROL);
-   }
-   return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
-   if (suspend) {
-   /* Disable the clocks */
-   omap4430_phy_set_clk(dev, 0);
-   /* Power down the phy */
-   __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
-   /* save the context */
-   usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
-   } else {
-   /* Enable the internel phy clcoks */
-   omap4430_phy_set_clk(dev, 1);
-   /* power on the phy */
-   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF)  PHY_PD) {
-   __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-   mdelay(200);
-   }
-
-   /* restore the context */
-   __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
-   }
-
-   return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
-   if (ctrl_base)
-   

[PATCH v6 00/11] omap: musb: Add device tree support

[Kishon Vijay Abraham I]

This patch series adds device tree support for MUSB and device
tree support for all the related modules to get MUSB working in
OMAP platform.

A new omap-usb2 phy driver has been added (with only dt suppport)
to perform phy configurations. Previously this configuration was
performed by twl6030, using pdata function pointers.

With the addition of omap-usb2 to perform phy configurations,
twl6030 is made as a comparator driver to detect VBUS and ID events
and notify it to the glue layer.

musb core is _NOT_ yet converted to support device tree support as it
would need lot of driver re-design because of its enormous use of
function pointers. That will be in _TO DO_ list.

Changes from v5:
minor cleanups like checking for return value in get_sync and few changes
in the documentation has been done.

Changes from v4:
duplicate getting of 'mode' property is removed in omap-musb glue.

Changes from v3:
remove the address in the node name of usb_otg_hs since the usb_otg_hs
node doesn't have a reg property. Thanks Ajay Gupta for finding this.

Changes from v2:
Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080

Changes from v1:
* Fixed Rajendra Nayak comments (regulator naming, compatible naming of
musb and other minor cleanups.)
* It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of
ocp2scp, the documentation is updated accordingly.

Changes from RFC:
Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module.
Writing to control module register is now handled in otg driver itself.
Once the system control module driver get upstreamed, I'll send a patch
to make use of API's in control module driver to write to control
module register.

This series was developed on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv

This patch series depends on
[PATCH 0/2] omap: add ocp2scp as a bus driver

Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP
and OMAP3 beagle.

Kishon Vijay Abraham I (11):
  drivers: usb: otg: add a new driver for omap usb2 phy
  arm/dts: omap: Add omap-usb2 dt data
  drivers: usb: otg: make twl6030_usb as a comparator driver to
omap_usb2
  arm: omap: hwmod: add a new addr space in otg for writing to control
module
  drivers: usb: twl6030: Add dt support for twl6030 usb
  arm/dts: Add twl6030-usb data
  drivers: usb: twl4030: Add device tree support for twl4030 usb
  arm/dts: Add twl4030-usb data
  drivers: usb: musb: Add device tree support for omap musb glue
  arm/dts: omap: Add usb_otg and glue data
  arm: omap: phy: remove unused functions from omap-phy-internal.c

 .../devicetree/bindings/bus/omap-ocp2scp.txt   |3 +
 Documentation/devicetree/bindings/usb/omap-usb.txt |   49 
 .../devicetree/bindings/usb/twl-usb.txt|   40 +++
 arch/arm/boot/dts/omap3-beagle.dts |6 +
 arch/arm/boot/dts/omap3-evm.dts|6 +
 arch/arm/boot/dts/omap3.dtsi   |8 +
 arch/arm/boot/dts/omap4-panda.dts  |   10 +
 arch/arm/boot/dts/omap4-sdp.dts|   10 +
 arch/arm/boot/dts/omap4.dtsi   |   13 +
 arch/arm/boot/dts/twl4030.dtsi |   21 ++
 arch/arm/boot/dts/twl6030.dtsi |5 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
 arch/arm/mach-omap2/omap_phy_internal.c|  138 --
 arch/arm/mach-omap2/twl-common.c   |5 -
 arch/arm/mach-omap2/usb-musb.c |3 -
 drivers/usb/musb/omap2430.c|  106 +++-
 drivers/usb/musb/omap2430.h|9 +
 drivers/usb/otg/Kconfig|   10 +
 drivers/usb/otg/Makefile   |1 +
 drivers/usb/otg/omap-usb2.c|  280 
 drivers/usb/otg/twl4030-usb.c  |   26 +-
 drivers/usb/otg/twl6030-usb.c  |  153 +++
 include/linux/usb/omap_usb.h   |   45 
 include/linux/usb/phy_companion.h  |   34 +++
 24 files changed, 713 insertions(+), 273 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
 create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
 create mode 100644 drivers/usb/otg/omap-usb2.c
 create mode 100644 include/linux/usb/omap_usb.h
 create mode 100644 include/linux/usb/phy_companion.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 02/11] arm/dts: omap: Add omap-usb2 dt data

[Kishon Vijay Abraham I]

Add omap-usb2 data node in omap4 device tree file.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+   usb2phy@4a0ad080 {
+   compatible = ti,omap-usb2;
+   reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+   };
};
};
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 09/11] drivers: usb: musb: Add device tree support for omap musb glue

[Kishon Vijay Abraham I]

Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |   34 +++-
 drivers/usb/musb/omap2430.c|   54 
 2 files changed, 87 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 52f503b..49a90fb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
 
 OMAP USB2 PHY
 
@@ -15,3 +15,35 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x1;
 };
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+   interface between the controller and the phy. It should be 0 or 1
+   specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+   represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+   100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+   compatible = ti,musb-omap2430;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..5db228f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
 #include linux/init.h
 #include linux/list.h
 #include linux/io.h
+#include linux/of.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
 #include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
 static int __devinit omap2430_probe(struct platform_device *pdev)
 {
struct musb_hdrc_platform_data  *pdata = pdev-dev.platform_data;
+   struct omap_musb_board_data *data;
struct platform_device  *musb;
struct omap2430_glue*glue;
+   struct device_node  *np = pdev-dev.of_node;
+   struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
 
@@ -500,6 +504,42 @@ static int __devinit omap2430_probe(struct platform_device 
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
 
+   if (np) {
+   pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(pdev-dev,
+   failed to allocate musb platfrom data\n);
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+   if (!data) {
+   dev_err(pdev-dev,
+   failed to allocate musb board data\n);
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+   if (!data) {
+   dev_err(pdev-dev,
+   failed to allocate musb hdrc config\n);
+   goto err1;
+   }
+
+   of_property_read_u32(np, mode, (u32 *)pdata-mode);
+   of_property_read_u32(np, interface_type,
+   (u32 *)data-interface_type);
+   of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+   of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+   of_property_read_u32(np, power, (u32 *)pdata-power);
+   config-multipoint = of_property_read_bool(np, multipoint);
+
+   pdata-board_data   = data;
+   pdata-config   = config;
+   }
+
pdata-platform_ops = omap2430_ops;
 
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
 #define DEV_PM_OPS NULL
 #endif
 
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+   {
+   .compatible = ti,omap4-musb
+   },
+   {
+   

[PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[Kishon Vijay Abraham I]

All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.

This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 .../devicetree/bindings/bus/omap-ocp2scp.txt   |3 +
 Documentation/devicetree/bindings/usb/omap-usb.txt |   17 ++
 drivers/usb/otg/Kconfig|   10 +
 drivers/usb/otg/Makefile   |1 +
 drivers/usb/otg/omap-usb2.c|  280 
 include/linux/usb/omap_usb.h   |   45 
 include/linux/usb/phy_companion.h  |   34 +++
 7 files changed, 390 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
 create mode 100644 drivers/usb/otg/omap-usb2.c
 create mode 100644 include/linux/usb/omap_usb.h
 create mode 100644 include/linux/usb/phy_companion.h

diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt 
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
 
 Sub-nodes:
 All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+   The binding details of usb2phy can be found in:
+   Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..52f503b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,17 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@4a0ad080 {
+   compatible = ti,omap-usb2;
+   reg = 0x4a0ad080 0x58,
+   0x4a002300 0x1;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
  are hooked to this driver through platform_data structure.
  The definition of internal PHY APIs are in the mach-omap2 layer.
 
+config OMAP_USB2
+   tristate OMAP USB2 PHY Driver
+   depends on OMAP_OCP2SCP
+   select USB_OTG_UTILS
+   help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
 config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS)   += gpio_vbus.o
 obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
 obj-$(CONFIG_TWL4030_USB)  += twl4030-usb.o
 obj-$(CONFIG_TWL6030_USB)  += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
 obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
 obj-$(CONFIG_USB_ULPI) += ulpi.o
 obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..026cb3c
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,280 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h

[PATCH v6 10/11] arm/dts: omap: Add usb_otg and glue data

[Kishon Vijay Abraham I]

Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |6 ++
 arch/arm/boot/dts/omap3-evm.dts|6 ++
 arch/arm/boot/dts/omap3.dtsi   |8 
 arch/arm/boot/dts/omap4-panda.dts  |6 ++
 arch/arm/boot/dts/omap4-sdp.dts|6 ++
 arch/arm/boot/dts/omap4.dtsi   |8 
 6 files changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
 mmc3 {
status = disable;
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
 };
+
+usb_otg_hs {
+   interface_type = 0;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..4b8c142 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+   usb_otg_hs: usb_otg_hs {
+   compatible = ti,omap3-musb;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   };
};
 };
diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
 twlusb {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
 twlusb {
usb-supply = vusb;
 };
+
+usb_otg_hs {
+   interface_type = 1;
+   mode = 3;
+   power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..7886518 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
  0x4a002300 0x1;
};
};
+
+   usb_otg_hs: usb_otg_hs {
+   compatible = ti,omap4-musb;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   };
};
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb

[Kishon Vijay Abraham I]

Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 .../devicetree/bindings/usb/twl-usb.txt|   19 ++
 drivers/usb/otg/twl4030-usb.c  |   26 +++-
 2 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index 930f9ff..36b9aed 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -19,3 +19,22 @@ Board specific device node entry
 twl6030-usb {
usb-supply = vusb;
 };
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts
+   and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+   supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+   specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+   compatible = ti,twl4030-usb;
+   interrupts =  10 4 ;
+   usb1v5-supply = vusb1v5;
+   usb1v8-supply = vusb1v8;
+   usb3v1-supply = vusb3v1;
+   usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct 
platform_device *pdev)
struct twl4030_usb  *twl;
int status, err;
struct usb_otg  *otg;
-
-   if (!pdata) {
-   dev_dbg(pdev-dev, platform_data not available\n);
-   return -EINVAL;
-   }
+   struct device_node  *np = pdev-dev.of_node;
 
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
 
+   if (np)
+   of_property_read_u32(np, usb_mode,
+   (enum twl4030_usb_mode *)twl-usb_mode);
+   else if (pdata)
+   twl-usb_mode = pdata-usb_mode;
+   else {
+   dev_err(pdev-dev, twl4030 initialized without pdata\n);
+   return -EINVAL;
+   }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
 
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
-   twl-usb_mode   = pdata-usb_mode;
twl-vbus_supplied  = false;
twl-asleep = 1;
twl-linkstat   = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+   { .compatible = ti,twl4030-usb },
+   {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
 static struct platform_driver twl4030_usb_driver = {
.probe  = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name   = twl4030_usb,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 08/11] arm/dts: Add twl4030-usb data

[Kishon Vijay Abraham I]

Add twl4030-usb data node in twl4030 device tree file.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 arch/arm/boot/dts/twl4030.dtsi |   21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
 
+   vusb1v5: regulator-vusb1v5 {
+   compatible = ti,twl4030-vusb1v5;
+   };
+
+   vusb1v8: regulator-vusb1v8 {
+   compatible = ti,twl4030-vusb1v8;
+   };
+
+   vusb3v1: regulator-vusb3v1 {
+   compatible = ti,twl4030-vusb3v1;
+   };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+   twl4030-usb {
+   compatible = ti,twl4030-usb;
+   interrupts =  10 4 ;
+   usb1v5-supply = vusb1v5;
+   usb1v8-supply = vusb1v8;
+   usb3v1-supply = vusb3v1;
+   usb_mode = 1;
+   };
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe 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 v6 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2

[Kishon Vijay Abraham I]

All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.

Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c   |   52 ---
 drivers/usb/musb/omap2430.h   |9 
 drivers/usb/otg/twl6030-usb.c |  114 +
 3 files changed, 67 insertions(+), 108 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device  *musb;
enum omap_musb_vbus_id_status status;
struct work_struct  omap_musb_mailbox_work;
+   u32 __iomem *control_otghs;
 };
 #define glue_to_musb(g)platform_get_drvdata(g-musb)
 
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
 
 static struct timer_list musb_idle_timer;
 
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+   if (glue-control_otghs)
+   writel(val, glue-control_otghs);
+}
+
 static void musb_do_idle(unsigned long _musb)
 {
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
+   u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
-   usb_phy_init(musb-xceiv);
+   val = AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
-   usb_phy_init(musb-xceiv);
+   val = IDDIG | AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
break;
 
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
-   usb_phy_shutdown(musb-xceiv);
+   val = SESSEND | IDDIG;
+   omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
 static void omap2430_musb_enable(struct musb *musb)
 {
u8  devctl;
+   u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
 
case OMAP_MUSB_ID_GROUND:
-   usb_phy_init(musb-xceiv);
+   val = AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
 
case OMAP_MUSB_VBUS_VALID:
-   usb_phy_init(musb-xceiv);
+   val = IDDIG | AVALID | VBUSVALID;
+   omap4_usb_phy_mailbox(glue, val);
break;
 
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
 
 static void omap2430_musb_disable(struct musb *musb)
 {
+   u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue = 

[PATCH v6 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb

[Kishon Vijay Abraham I]

Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 .../devicetree/bindings/usb/twl-usb.txt|   21 +++
 drivers/usb/otg/twl6030-usb.c  |   39 +---
 2 files changed, 47 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt 
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..930f9ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,21 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+   interrupt number is the otg interrupt number that raises ID interrupts when
+   the controller has to act as host and the second interrupt number is the
+   usb interrupt number that raises VBUS interrupts when the controller has to
+   act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+   if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+   compatible = ti,twl6030-usb;
+   interrupts =  4 10 ;
+};
+
+Board specific device node entry
+twl6030-usb {
+   usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..f29c9ef 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8  asleep;
boolirq_enabled;
boolvbus_enable;
-   unsigned long   features;
+   const char  *regulator;
 };
 
 #definecomparator_to_twl(x) container_of((x), struct twl6030_usb, 
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion 
*comparator)
 
 static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
 {
-   char *regulator_name;
-
-   if (twl-features  TWL6025_SUBCLASS)
-   regulator_name = ldousb;
-   else
-   regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
 
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
 
-   twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+   twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
 
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
 {
struct twl6030_usb  *twl;
int status, err;
-   struct twl4030_usb_data *pdata;
-   struct device *dev = pdev-dev;
-   pdata = dev-platform_data;
+   struct device_node  *np = pdev-dev.of_node;
+   struct device   *dev = pdev-dev;
+   struct twl4030_usb_data *pdata = dev-platform_data;
 
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,24 @@ static int __devinit twl6030_usb_probe(struct 
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1   = platform_get_irq(pdev, 0);
twl-irq2   = platform_get_irq(pdev, 1);
-   twl-features   = pdata-features;
twl-linkstat   = OMAP_MUSB_UNKNOWN;
 
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp   = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
 
+   if (np) {
+   twl-regulator = usb;
+   } else if (pdata) {
+   if (pdata-features  TWL6025_SUBCLASS)
+   twl-regulator = ldousb;
+   else
+   twl-regulator = vusb;
+   } else {
+   dev_err(pdev-dev, twl6030 initialized without pdata\n);
+   return -EINVAL;
+   }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
 
@@ -403,12 +407,21 @@ static int __exit twl6030_usb_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+   { .compatible = ti,twl6030-usb },
+   {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
 static struct platform_driver twl6030_usb_driver = {
.probe  = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name   = twl6030_usb,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(twl6030_usb_id_table),

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sun, Jul 29, 2012 at 11:31 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
 On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon will.dea...@arm.com wrote:
  Acked-by: Will Deacon will.dea...@arm.com
 
  The next question is: who's putting this into the patch system?
 
  Will

 Hi,

 I just put the patch with Will's Acked-by on the patch system. It  was
 accepted as patch 7480/1 [1].

 The patch is on top of today's linux-next (next-20120727).

 Thanks a lot and best regards,
 Javier

 [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

 Isn't this a candidate for stable kernels?

Yes, I forgot it, sorry for that.

Please let me know if I need to resubmit the patch cc'ing stable.

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

Re: [GPIO] Crashed when not using

[DebBarma, Tarun Kanti]

Sourav,

On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
 Hi All,

 I tried using gpio as an interrupt line for my driver
 (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
 The interrupt line number was directly passed to the driver using
 device tree. But what I observed
 is the following crash..


 [1.599273] mousedev: PS/2 mouse device common for all mice
 [1.607513] i2c /dev entries driver
 [1.613739] Driver for 1-wire Dallas network protocol.
 [1.622650] usbcore: registered new interface driver usbhid
 [1.628540] usbhid: USB HID core driver
 [1.633728] Unhandled fault: imprecise external abort (0x1406) at 
 0x
 [1.641113] Internal error: : 1406 [#1] SMP ARM
 [1.645874] Modules linked in:
 [1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty #415)
 [1.655761] PC is at _set_gpio_triggering+0x44/0x264
 [1.660980] LR is at gpio_irq_type+0xb8/0x160
 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
 [1.665527] sp : dc851df0  ip : c07a8f00  fp : 
 [1.677581] r10: 0081  r9 :   r8 : dc8ffc10
 [1.683074] r7 : 2093  r6 :   r5 : 0001  r4 : fa05b000
 [1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 : 0140
 [1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
 Segment kernel
 [1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
 [1.716857] Stack: (0xdc851df0 to 0xdc852000)
 [1.721405] 1de0: 0002
 c0731280 dc8ffc6c 2093
 [1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
 0141 0002 c00a37b8
 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
 c07312b4 4013 c00a3d7c
 [1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
 c00a2d5c c0412258 0141
 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
 2002 c071bed8 c247f000
 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
 c04ea344 c06728c0 c247f000
 [1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
 c04ea194 0091 c071bed8
 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
 dc9df054 c07bf60c c03272ac
 [1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
 c03274c0 c07bf60c dc851f08
 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
 c07bf60c c07bcea8 c243d6c0
 [1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
 c07bf60c c03e12a0 
 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
 0007 c07c8c40 
 [1.824401] 1f60: 0091 c03e1738  dc85 0007
 c0008648  c112c9f0
 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
  0006 0006
 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
 0091 c071bed8 c0700a28
 [1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
   c06d028c
 [1.858703] 1fe0: c001548c 0013   
 c001548c 3f3f3f3f 3f3f3f3f
 [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
 [c02dc224] (gpio_irq_type+0x0/0x160)
 [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] 
 (0x2002)
 [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
 [1.890960] [ cut here ]
 [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
 l3_interrupt_handler+0x184/0x1bc()
 [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [1.910430] Modules linked in:
 [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
 [c00414c4] (warn_slowpath_common+0x4c/0x64)
 [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
 [c0041570] (warn_slowpath_fmt+0x30/0x40)
 [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
 [c0035de4] (l3_interrupt_handler+0x184/0x1bc)
 [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
 [c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
 [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
 [c00a2adc] (handle_irq_event+0x3c/0x5c)
 [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
 [c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
 [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
 [c00a235c] (generic_handle_irq+0x34/0x44)
 [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
 [c00153a0] (handle_IRQ+0x4c/0xac)
 [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
 (gic_handle_irq+0x2c/0x60)
 [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
 [c04f26e4] (__irq_svc+0x44/0x60)
 [2.011718] Exception stack(0xdc851c48 to 0xdc851c90)
 [2.017028] 1c40:   c07a87a0  dc851c80
  c0743f80 dc851da8
 [2.025604] 1c60: 0001 0001 dc851cd7  c02dbb6a
 c02dbb6c  dc851c90
 [2.034179] 1c80: 

Re: [PATCH v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[Shubhrajyoti]

On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote:
 + writel(~PHY_PD, phy-control_dev);
 + /* XXX: add proper documentation for this delay */
 + mdelay(200);
Do you need this to be busy?
--
To unsubscribe from this list: send the line unsubscribe 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[ABRAHAM, KISHON VIJAY]

Hi,

On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
 On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote:
 + writel(~PHY_PD, phy-control_dev);
 + /* XXX: add proper documentation for this delay */
 + mdelay(200);
 Do you need this to be busy?
This might be called from interrupt context. This delay was initially
added in omap_phy_internal.c and I just inherited it.

Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe 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 v6 01/11] drivers: usb: otg: add a new driver for omap usb2 phy

[Shubhrajyoti]

On Monday 30 July 2012 03:16 PM, ABRAHAM, KISHON VIJAY wrote:
 Hi,

 On Mon, Jul 30, 2012 at 3:07 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
 On Monday 30 July 2012 02:39 PM, Kishon Vijay Abraham I wrote:
 + writel(~PHY_PD, phy-control_dev);
 + /* XXX: add proper documentation for this delay */
 + mdelay(200);
 Do you need this to be busy?
 This might be called from interrupt context. This delay was initially
 added in omap_phy_internal.c and I just inherited it.
Thanks for the explanation.

 Thanks
 Kishon

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

Re: [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection

[Tomi Valkeinen]

On Fri, 2012-07-27 at 19:21 -0500, Ricardo Neri wrote:
 Hello,
 
 DSS code wrongly assumes that VENC is always available as source for the 
 external
 sync signal for the display controller DIGIT channel. One cannot blindly
 rely only on the value of DSS_CONTROL register as certain processors may not
 have VENC (e.g., OMAP5).
 
 These patches add logic to correctly set/get the sync signal based on the
 available displays in the DIGIT channel.
 
 For the HDMI driver, handle the error in the selection of the source.

Is there an actual problem seen that this resolves? If so, It'd be nice
to have a brief description of the problem.

Does the bit 15 in DSS_CONTROL still exist on OMAP5? What does it return
on OMAP5?

I think it's clear that dss_get_hdmi_venc_clk_source() needs to return a
correct value so that DSS operates correctly. But I'm not sure we need
the extra code in dss_select_hdmi_venc_clk_source().

dss_select_hdmi_venc_clk_source() should be called by venc or hdmi, and
there should be any possibility of using it in the wrong way. For extra
sanity checking there could be a BUG_ON() check in the
dss_select_hdmi_venc_clk_source() to point out if there's a bad bug in
venc or hdmi.

I'd like to keep the lowest level dss-internal functions as simple as
possible, and written in the manner that they presume they are called
correctly. Otherwise we'll end up with lots of new code, checking for
errors that can never happen in practice.

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [GPIO] Crashed when not using

[Poddar, Sourav]

On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
tarun.ka...@ti.com wrote:
 Sourav,

 On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
 Hi All,

 I tried using gpio as an interrupt line for my driver
 (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
 The interrupt line number was directly passed to the driver using
 device tree. But what I observed
 is the following crash..


 [1.599273] mousedev: PS/2 mouse device common for all mice
 [1.607513] i2c /dev entries driver
 [1.613739] Driver for 1-wire Dallas network protocol.
 [1.622650] usbcore: registered new interface driver usbhid
 [1.628540] usbhid: USB HID core driver
 [1.633728] Unhandled fault: imprecise external abort (0x1406) at 
 0x
 [1.641113] Internal error: : 1406 [#1] SMP ARM
 [1.645874] Modules linked in:
 [1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty #415)
 [1.655761] PC is at _set_gpio_triggering+0x44/0x264
 [1.660980] LR is at gpio_irq_type+0xb8/0x160
 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
 [1.665527] sp : dc851df0  ip : c07a8f00  fp : 
 [1.677581] r10: 0081  r9 :   r8 : dc8ffc10
 [1.683074] r7 : 2093  r6 :   r5 : 0001  r4 : fa05b000
 [1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 : 0140
 [1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
 Segment kernel
 [1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
 [1.716857] Stack: (0xdc851df0 to 0xdc852000)
 [1.721405] 1de0: 0002
 c0731280 dc8ffc6c 2093
 [1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
 0141 0002 c00a37b8
 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
 c07312b4 4013 c00a3d7c
 [1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
 c00a2d5c c0412258 0141
 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
 2002 c071bed8 c247f000
 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
 c04ea344 c06728c0 c247f000
 [1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
 c04ea194 0091 c071bed8
 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
 dc9df054 c07bf60c c03272ac
 [1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
 c03274c0 c07bf60c dc851f08
 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
 c07bf60c c07bcea8 c243d6c0
 [1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
 c07bf60c c03e12a0 
 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
 0007 c07c8c40 
 [1.824401] 1f60: 0091 c03e1738  dc85 0007
 c0008648  c112c9f0
 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
  0006 0006
 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
 0091 c071bed8 c0700a28
 [1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
   c06d028c
 [1.858703] 1fe0: c001548c 0013   
 c001548c 3f3f3f3f 3f3f3f3f
 [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
 [c02dc224] (gpio_irq_type+0x0/0x160)
 [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] 
 (0x2002)
 [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
 [1.890960] [ cut here ]
 [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
 l3_interrupt_handler+0x184/0x1bc()
 [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [1.910430] Modules linked in:
 [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
 [c00414c4] (warn_slowpath_common+0x4c/0x64)
 [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
 [c0041570] (warn_slowpath_fmt+0x30/0x40)
 [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
 [c0035de4] (l3_interrupt_handler+0x184/0x1bc)
 [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
 [c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
 [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
 [c00a2adc] (handle_irq_event+0x3c/0x5c)
 [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
 [c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
 [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
 [c00a235c] (generic_handle_irq+0x34/0x44)
 [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
 [c00153a0] (handle_IRQ+0x4c/0xac)
 [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
 (gic_handle_irq+0x2c/0x60)
 [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
 [c04f26e4] (__irq_svc+0x44/0x60)
 [2.011718] Exception stack(0xdc851c48 to 0xdc851c90)
 [2.017028] 1c40:   c07a87a0  dc851c80
  c0743f80 dc851da8
 [2.025604] 1c60: 0001 

Re: [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection

[Archit Taneja]

On Monday 30 July 2012 04:41 PM, Tomi Valkeinen wrote:

On Fri, 2012-07-27 at 19:21 -0500, Ricardo Neri wrote:

Hello,

DSS code wrongly assumes that VENC is always available as source for the 
external
sync signal for the display controller DIGIT channel. One cannot blindly
rely only on the value of DSS_CONTROL register as certain processors may not
have VENC (e.g., OMAP5).

These patches add logic to correctly set/get the sync signal based on the
available displays in the DIGIT channel.

For the HDMI driver, handle the error in the selection of the source.


Is there an actual problem seen that this resolves? If so, It'd be nice
to have a brief description of the problem.


The issue is seen on OMAP5 with a 3.5 kernel. In 3.5 kernel, we had a 
hack where we used to divide the TV manager's height by 2 if the 
connected interface was VENC. On OMAP5, the bit 15 returns VENC (a zero) 
irrespective of what we write.


This won't happen in 3.6 as we have included interlace as a part of the 
omap_video_timings struct, and we don't try to check the bit to see 
whether we are VENC or HDMI.


I guess we should still put a check to not set the bit on OMAP5 as it 
may cause unknown HW behavior, i.e, make the select function like:


void dss_select_hdmi_venc_clk_source()
{
...

displays =
dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);

if ((displays  OMAP_DISPLAY_TYPE_VENC) == 0)
return;

REG_FLD_MOD(DSS_CONTROL, src, 15, 15);  /* VENC_HDMI_SWITCH */
}

Archit



Does the bit 15 in DSS_CONTROL still exist on OMAP5? What does it return
on OMAP5?

I think it's clear that dss_get_hdmi_venc_clk_source() needs to return a
correct value so that DSS operates correctly. But I'm not sure we need
the extra code in dss_select_hdmi_venc_clk_source().

dss_select_hdmi_venc_clk_source() should be called by venc or hdmi, and
there should be any possibility of using it in the wrong way. For extra
sanity checking there could be a BUG_ON() check in the
dss_select_hdmi_venc_clk_source() to point out if there's a bad bug in
venc or hdmi.

I'd like to keep the lowest level dss-internal functions as simple as
possible, and written in the manner that they presume they are called
correctly. Otherwise we'll end up with lots of new code, checking for
errors that can never happen in practice.

  Tomi



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

[PATCH 0/2] OMAP DT fixes

[Rajendra Nayak]

Hi Tony,

These are couple of DT fixes for OMAP, first fixes a lockup
/boot failure on OMAP4 boards (SDP and panda) on mainline,
second is a long pending cleanup.

regards,
Rajendra

Rajendra Nayak (2):
  arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on
  arm/dts: Cleanup regulator naming and remove @0,1..

 arch/arm/boot/dts/omap3-beagle.dts |2 +-
 arch/arm/boot/dts/omap4-sdp.dts|4 ++--
 arch/arm/boot/dts/twl4030.dtsi |6 +++---
 arch/arm/boot/dts/twl6030.dtsi |   29 -
 4 files changed, 22 insertions(+), 19 deletions(-)

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

[PATCH 2/2] arm/dts: Cleanup regulator naming and remove @0,1..

[Rajendra Nayak]

regulators do not have a 'reg' property, hence the regulator@0,
regulator@1 do not make sense. get rid of it.

Reported-by: David Brown dav...@codeaurora.org
Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |2 +-
 arch/arm/boot/dts/omap4-sdp.dts|4 ++--
 arch/arm/boot/dts/twl4030.dtsi |6 +++---
 arch/arm/boot/dts/twl6030.dtsi |   26 +-
 4 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index cdcb98c..e60cba0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,7 +27,7 @@
interrupts = 7; /* SYS_NIRQ cascaded to intc */
interrupt-parent = intc;
 
-   vsim: regulator@10 {
+   vsim: regulator-vsim {
compatible = ti,twl4030-vsim;
regulator-min-microvolt = 180;
regulator-max-microvolt = 300;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 72216e9..dbcdc4a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,7 +18,7 @@
reg = 0x8000 0x4000; /* 1 GB */
};
 
-   vdd_eth: fixedregulator@0 {
+   vdd_eth: fixedregulator-vdd-eth {
compatible = regulator-fixed;
regulator-name = VDD_ETH;
regulator-min-microvolt = 330;
@@ -28,7 +28,7 @@
regulator-boot-on;
};
 
-   vbat: fixedregulator@2 {
+   vbat: fixedregulator-vbat {
compatible = regulator-fixed;
regulator-name = VBAT;
regulator-min-microvolt = 375;
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..ff00017 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -19,19 +19,19 @@
interrupts = 11;
};
 
-   vdac: regulator@0 {
+   vdac: regulator-vdac {
compatible = ti,twl4030-vdac;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
};
 
-   vpll2: regulator@1 {
+   vpll2: regulator-vpll2 {
compatible = ti,twl4030-vpll2;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
};
 
-   vmmc1: regulator@2 {
+   vmmc1: regulator-vmmc1 {
compatible = ti,twl4030-vmmc1;
regulator-min-microvolt = 185;
regulator-max-microvolt = 315;
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index d351b27..123e2c4 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -20,70 +20,70 @@
interrupts = 11;
};
 
-   vaux1: regulator@0 {
+   vaux1: regulator-vaux1 {
compatible = ti,twl6030-vaux1;
regulator-min-microvolt = 100;
regulator-max-microvolt = 300;
};
 
-   vaux2: regulator@1 {
+   vaux2: regulator-vaux2 {
compatible = ti,twl6030-vaux2;
regulator-min-microvolt = 120;
regulator-max-microvolt = 280;
};
 
-   vaux3: regulator@2 {
+   vaux3: regulator-vaux3 {
compatible = ti,twl6030-vaux3;
regulator-min-microvolt = 100;
regulator-max-microvolt = 300;
};
 
-   vmmc: regulator@3 {
+   vmmc: regulator-vmmc {
compatible = ti,twl6030-vmmc;
regulator-min-microvolt = 120;
regulator-max-microvolt = 300;
};
 
-   vpp: regulator@4 {
+   vpp: regulator-vpp {
compatible = ti,twl6030-vpp;
regulator-min-microvolt = 180;
regulator-max-microvolt = 250;
};
 
-   vusim: regulator@5 {
+   vusim: regulator-vusim {
compatible = ti,twl6030-vusim;
regulator-min-microvolt = 120;
regulator-max-microvolt = 290;
};
 
-   vdac: regulator@6 {
+   vdac: regulator-vdac {
compatible = ti,twl6030-vdac;
};
 
-   vana: regulator@7 {
+   vana: regulator-vana {
compatible = ti,twl6030-vana;
};
 
-   vcxio: regulator@8 {
+   vcxio: regulator-vcxio {
compatible = ti,twl6030-vcxio;
regulator-always-on;
};
 
-   vusb: regulator@9 {
+   vusb: regulator-vusb {
compatible = ti,twl6030-vusb;
};
 
-   v1v8: regulator@10 {
+   v1v8: regulator-v1v8 {
compatible = ti,twl6030-v1v8;
regulator-always-on;
};
 
-   v2v1: regulator@11 {
+   v2v1: 

[PATCH 1/2] arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on

[Rajendra Nayak]

vcxio, v2v1 and v1v8 are expected to be always on, update the dtsi
for twl6030 to reflect this.

commit '86f5fc' regulator: core: Mark all DT based boards as having
full constraints) caused these to be disabled at late boot causing
OMAP4 boards (using twl6030) to lockup.

Reported-by: Kishon Vijay Abraham I kis...@ti.com
Reported-by: J Keerthy j-keer...@ti.com
Signed-off-by: Rajendra nayak rna...@ti.com
---
 arch/arm/boot/dts/twl6030.dtsi |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..d351b27 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -66,6 +66,7 @@
 
vcxio: regulator@8 {
compatible = ti,twl6030-vcxio;
+   regulator-always-on;
};
 
vusb: regulator@9 {
@@ -74,10 +75,12 @@
 
v1v8: regulator@10 {
compatible = ti,twl6030-v1v8;
+   regulator-always-on;
};
 
v2v1: regulator@11 {
compatible = ti,twl6030-v2v1;
+   regulator-always-on;
};
 
clk32kg: regulator@12 {
-- 
1.7.1

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

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 09:40:27AM +0200, Shilimkar, Santosh wrote:
 On Mon, Jul 30, 2012 at 7:51 AM, S, Venkatraman svenk...@ti.com wrote:
  On Sat, Jul 28, 2012 at 1:40 PM, Shilimkar, Santosh
  santosh.shilim...@ti.com wrote:
  On Fri, Jul 27, 2012 at 6:50 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
  On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
  On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
   On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux 
   wrote:
   Just a quick reminder that I'm still on holiday, and at this point 
   there
   are over 2500 messages from the mailing lists which are sitting unread
   since I left the UK.  As I mentioned before I left the UK, it is my
   intention *not* to go back and read all those outstanding messages -
   there's too many of them to do that.
  
   So, if you want me to react to any email message you've sent, you'd
   *better* send it again next week unless I've already responded.
  
   Meanwhile, I see v3.5 has been released; I have a couple of things I
   need to do with my tree before I can push the changes, and I'll
   probably see about sorting those out over the weekend.  I also see
   that 14 new patches have landed in the patch system.
  
   However, the timing of my holiday vs the merge window means that I
   can't take anything new, unless they're fixes, so don't be surprised
   if some stuff gets missed this merge window.
  
   Right.  I'm not fully recovered from the jet lag (I'm still rather 
   tired
   - I hate travelling back from the North American continent because it
   takes days to recover.)
  
   I have now archived off *all* email sent to me during July - which 
   means
   that I will *NOT* be responding to anything sent during the last 17 
   days.
   If anyone has sent me anything important, it *MUST* be resent now.
  
   I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
   exactly what is required there, so I've dropped them from my planned 
   pull
   request in the interests of getting everything else I have to Linus.  I
   may plan to send a pull request this evening.
  
  Well the only pending discussion was enabling the CONFIG option for
  DMA at driver level SOC config level. Not sure if there was anything else
  on this really.
 
  Why?  The DMA driver itself is optional.
  That was Tony's point too. Unfortunately MMC and SPI driver don't work
  today without DMA. Some works needs to be done to support polling
  mode and am bit skeptical if it is really worth it. Same case be with other
  SDMA supported drivers mostly.
 
  Russell, Tony,
Can I request to include the DMA  MMC changes into this merge window ?
  We have many cleanups and new patches waiting to be queued up for next (3.7)
  merge window, and it'd be easier if they are implemented on top of the
  DMA changes,
  so that it gets tested together, and don't create merge conflicts.
I am looking into implementing polling mode, which might take some time.
 
 Thanks Venkat. For the SPI driver as well I heard from Shubro (in cc) that
 he is looking into polling mode.
 
 IMHO, we should merge the OMAP DMA engine support which is now sufficiently
 tested and has been in linux-next for some time. Polling mode and ASOC
 related issues can be then debugged directly on mainline.
 For the time being, the SOC patch which Tony merged in linux-omap
 master can be included along with rest of the OMAP DMA engine patches
 to have working kernel.

So I take that as you wanting exactly what is in linux-next merged without
any further changes?
--
To unsubscribe from this list: send the line unsubscribe 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 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
 Yes, I forgot it, sorry for that.
 
 Please let me know if I need to resubmit the patch cc'ing stable.

I can just add it to the commit.
--
To unsubscribe from this list: send the line unsubscribe 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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Shilimkar, Santosh]

On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jul 30, 2012 at 09:40:27AM +0200, Shilimkar, Santosh wrote:
 On Mon, Jul 30, 2012 at 7:51 AM, S, Venkatraman svenk...@ti.com wrote:
  On Sat, Jul 28, 2012 at 1:40 PM, Shilimkar, Santosh
  santosh.shilim...@ti.com wrote:
  On Fri, Jul 27, 2012 at 6:50 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
  On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
  On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
   On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux 
   wrote:
   Just a quick reminder that I'm still on holiday, and at this point 
   there
   are over 2500 messages from the mailing lists which are sitting 
   unread
   since I left the UK.  As I mentioned before I left the UK, it is my
   intention *not* to go back and read all those outstanding messages -
   there's too many of them to do that.
  
   So, if you want me to react to any email message you've sent, you'd
   *better* send it again next week unless I've already responded.
  
   Meanwhile, I see v3.5 has been released; I have a couple of things I
   need to do with my tree before I can push the changes, and I'll
   probably see about sorting those out over the weekend.  I also see
   that 14 new patches have landed in the patch system.
  
   However, the timing of my holiday vs the merge window means that I
   can't take anything new, unless they're fixes, so don't be surprised
   if some stuff gets missed this merge window.
  
   Right.  I'm not fully recovered from the jet lag (I'm still rather 
   tired
   - I hate travelling back from the North American continent because it
   takes days to recover.)
  
   I have now archived off *all* email sent to me during July - which 
   means
   that I will *NOT* be responding to anything sent during the last 17 
   days.
   If anyone has sent me anything important, it *MUST* be resent now.
  
   I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
   exactly what is required there, so I've dropped them from my planned 
   pull
   request in the interests of getting everything else I have to Linus.  
   I
   may plan to send a pull request this evening.
  
  Well the only pending discussion was enabling the CONFIG option for
  DMA at driver level SOC config level. Not sure if there was anything 
  else
  on this really.
 
  Why?  The DMA driver itself is optional.
  That was Tony's point too. Unfortunately MMC and SPI driver don't work
  today without DMA. Some works needs to be done to support polling
  mode and am bit skeptical if it is really worth it. Same case be with 
  other
  SDMA supported drivers mostly.
 
  Russell, Tony,
Can I request to include the DMA  MMC changes into this merge window ?
  We have many cleanups and new patches waiting to be queued up for next 
  (3.7)
  merge window, and it'd be easier if they are implemented on top of the
  DMA changes,
  so that it gets tested together, and don't create merge conflicts.
I am looking into implementing polling mode, which might take some time.

 Thanks Venkat. For the SPI driver as well I heard from Shubro (in cc) that
 he is looking into polling mode.

 IMHO, we should merge the OMAP DMA engine support which is now sufficiently
 tested and has been in linux-next for some time. Polling mode and ASOC
 related issues can be then debugged directly on mainline.
 For the time being, the SOC patch which Tony merged in linux-omap
 master can be included along with rest of the OMAP DMA engine patches
 to have working kernel.

 So I take that as you wanting exactly what is in linux-next merged without
 any further changes?

Just one patch[1] on top of that so that default omap2plus_defconfig
keeps working.

Regards
Santosh

[1] https://patchwork.kernel.org/patch/1220141/
--
To unsubscribe from this list: send the line unsubscribe 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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
 On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  So I take that as you wanting exactly what is in linux-next merged without
  any further changes?
 
 Just one patch[1] on top of that so that default omap2plus_defconfig
 keeps working.

Err, I don't see what that patch does.  Setting ret=-ENXIO at the
start of the function, when it's subsequently overwritten by:

+   int ret = -ENXIO, irq;
...
ret = omap_hsmmc_gpio_init(pdata);
...
... dma stuff ...

seems absurd.
--
To unsubscribe from this list: send the line unsubscribe 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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 09:40:27AM +0200, Shilimkar, Santosh wrote:
 IMHO, we should merge the OMAP DMA engine support which is now sufficiently
 tested and has been in linux-next for some time. Polling mode and ASOC
 related issues can be then debugged directly on mainline.
 For the time being, the SOC patch which Tony merged in linux-omap
 master can be included along with rest of the OMAP DMA engine patches
 to have working kernel.

BTW, I was referring to the copyright issues which you apparantly raised
while I was away.  I assume you've dropped those objections now.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[S, Venkatraman]

On Mon, Jul 30, 2012 at 8:14 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
 On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  So I take that as you wanting exactly what is in linux-next merged without
  any further changes?

 Just one patch[1] on top of that so that default omap2plus_defconfig
 keeps working.

 Err, I don't see what that patch does.  Setting ret=-ENXIO at the
 start of the function, when it's subsequently overwritten by:

 +   int ret = -ENXIO, irq;
 ...
 ret = omap_hsmmc_gpio_init(pdata);
 ...
 ... dma stuff ...

 seems absurd.

I think Santosh meant this patch..
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
--
To unsubscribe from this list: send the line unsubscribe 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 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jul 30, 2012 at 4:35 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
 Yes, I forgot it, sorry for that.

 Please let me know if I need to resubmit the patch cc'ing stable.

 I can just add it to the commit.

Perfect, thanks a lot and sorry for missing that.

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

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Javier Martinez Canillas]

On Mon, Jul 30, 2012 at 4:46 PM, S, Venkatraman svenk...@ti.com wrote:
 On Mon, Jul 30, 2012 at 8:14 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
 On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  So I take that as you wanting exactly what is in linux-next merged without
  any further changes?

 Just one patch[1] on top of that so that default omap2plus_defconfig
 keeps working.

 Err, I don't see what that patch does.  Setting ret=-ENXIO at the
 start of the function, when it's subsequently overwritten by:

 +   int ret = -ENXIO, irq;
 ...
 ret = omap_hsmmc_gpio_init(pdata);
 ...
 ... dma stuff ...

 seems absurd.

 I think Santosh meant this patch..
 http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13

That is the patch that fixes the DMA issue with the OMAP MMC and OMAP
MMC HS drivers when OMAP_DMA option is not set, since they still don't
support poll mode without DMA.

Russell, are you going to take the patch from Tony's linux-omap/master
tree or do I have to add the patch to the patch system also?

Thanks a lot and 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

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 05:19:06PM +0200, Javier Martinez Canillas wrote:
 On Mon, Jul 30, 2012 at 4:46 PM, S, Venkatraman svenk...@ti.com wrote:
  On Mon, Jul 30, 2012 at 8:14 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
  On Mon, Jul 30, 2012 at 04:37:09PM +0200, Shilimkar, Santosh wrote:
  On Mon, Jul 30, 2012 at 4:33 PM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
   So I take that as you wanting exactly what is in linux-next merged 
   without
   any further changes?
 
  Just one patch[1] on top of that so that default omap2plus_defconfig
  keeps working.
 
  Err, I don't see what that patch does.  Setting ret=-ENXIO at the
  start of the function, when it's subsequently overwritten by:
 
  +   int ret = -ENXIO, irq;
  ...
  ret = omap_hsmmc_gpio_init(pdata);
  ...
  ... dma stuff ...
 
  seems absurd.
 
  I think Santosh meant this patch..
  http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
 
 That is the patch that fixes the DMA issue with the OMAP MMC and OMAP
 MMC HS drivers when OMAP_DMA option is not set, since they still don't
 support poll mode without DMA.
 
 Russell, are you going to take the patch from Tony's linux-omap/master
 tree or do I have to add the patch to the patch system also?

It'd be better to have it via the patch system, because pulling it out
of a URL isn't an easy task.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep

[Paul Walmsley]

Hi

On Fri, 27 Jul 2012, Nayak, Rajendra wrote:

 On Fri, Jul 27, 2012 at 2:34 AM, Paul Walmsley p...@pwsan.com wrote:
 
  Commit 4da71ae6 (OMAP: clockdomain: Arch specific funcs for
  clkdm_clk_enable/disable) called the OMAP2xxx-specific functions for
  clockdomain wakeup and sleep.  This would probably have broken
  software-supervised clockdomain wakeup and sleep on OMAP3.
 
 Would something like this be better than duplicating most of
 omap2_clkdm_clk_enable/disable?

Am working towards getting the cpu_is_*() calls out of there in 
preparation for the move to drivers/.  In fact there are some patches here 
that will be posted shortly to get rid of those clkdm_clk_(enable|disable) 
functions completely.


- 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

New build warnings

[Russell King - ARM Linux]

Okay, so last night's build run shows some new warnings...

drivers/regulator/twl-regulator.c: In function 'twlreg_probe':
drivers/regulator/twl-regulator.c:1151: warning: assignment discards qualifiers 
from pointer target type
drivers/regulator/twl-regulator.c:1160: warning: assignment discards qualifiers 
from pointer target type

These two look like missing const - looks like they were introduced by:

commit 98d7bbb9929bcc14e11ac8a55245a4f2dc174e17
Author: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Date:   Thu Jun 7 12:20:14 2012 +0200

of: add const to struct *of_device_id.data

Drivers should never need to modify the data of a device id. So it can
be const which in turn allows more consts in the driver.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de




drivers/regulator/twl-regulator.c: At top level:
drivers/regulator/twl-regulator.c:1051: warning: 'TWLRES_INFO_CLK32KG' defined 
but not used

This one looks like it was caused by:

commit 0e8e5c34cf1a8beaaf0a6a05c053592693bf8cb4
Author: Mark Brown broo...@opensource.wolfsonmicro.com
Date:   Mon Jun 4 17:23:13 2012 +0100

regulator: twl: Remove references to 32kHz clock from DT bindings

Due to the lack of a generic clock API we'd had the 32kHz clock in the
regulator driver but this is definitely a Linux-specific thing and now
we have a clock API hopefully the code can be moved elsewhere. Try to
avoid getting DTs deployed relying on the 32kHz clock by removing it
from the bindings, grep seems to tell me it's not currently used anyway.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com

which removes:

-#define TWLRES_OF_MATCH(comp, label) TWL_OF_MATCH(comp, TWLRES, label)
-   TWLRES_OF_MATCH(ti,twl6030-clk32kg, CLK32KG),

but completely forgets that this:

TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0);

defines a structure that it was using.  (Welcome to why macros are horrid
when they hide the names of stuff they create.)
--
To unsubscribe from this list: send the line unsubscribe 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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [120730 08:31]:
 On Mon, Jul 30, 2012 at 05:19:06PM +0200, Javier Martinez Canillas wrote:
  
   I think Santosh meant this patch..
   http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
  
  That is the patch that fixes the DMA issue with the OMAP MMC and OMAP
  MMC HS drivers when OMAP_DMA option is not set, since they still don't
  support poll mode without DMA.
  
  Russell, are you going to take the patch from Tony's linux-omap/master
  tree or do I have to add the patch to the patch system also?
 
 It'd be better to have it via the patch system, because pulling it out
 of a URL isn't an easy task.

Javier, can you please submit it to Russell's patch tracking system?
Please just replace my Signed-off-by with my Acked-by for that patch.

Regards,

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

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Javier Martinez Canillas]

On Mon, Jul 30, 2012 at 7:02 PM, Tony Lindgren t...@atomide.com wrote:
 * Russell King - ARM Linux li...@arm.linux.org.uk [120730 08:31]:
 On Mon, Jul 30, 2012 at 05:19:06PM +0200, Javier Martinez Canillas wrote:
  
   I think Santosh meant this patch..
   http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=55936cdfaaf11ac352b56bc58e42d6661e65ee13
 
  That is the patch that fixes the DMA issue with the OMAP MMC and OMAP
  MMC HS drivers when OMAP_DMA option is not set, since they still don't
  support poll mode without DMA.
 
  Russell, are you going to take the patch from Tony's linux-omap/master
  tree or do I have to add the patch to the patch system also?

 It'd be better to have it via the patch system, because pulling it out
 of a URL isn't an easy task.

 Javier, can you please submit it to Russell's patch tracking system?
 Please just replace my Signed-off-by with my Acked-by for that patch.

 Regards,

 Tony

Hi Tony,

I just submitted the patch [1] to Russell's patch system before
reading this email so I left your Signed-off-by instead of Acked-by,
hope this won't be an issue.

Best regards,
Javier

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7481/1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New build warnings

[Mark Brown]

On Mon, Jul 30, 2012 at 05:44:44PM +0100, Russell King - ARM Linux wrote:

 -#define TWLRES_OF_MATCH(comp, label) TWL_OF_MATCH(comp, TWLRES, label)
 -   TWLRES_OF_MATCH(ti,twl6030-clk32kg, CLK32KG),

 but completely forgets that this:

 TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0);

 defines a structure that it was using.  (Welcome to why macros are horrid
 when they hide the names of stuff they create.)

I actually have the fix in a separate patch which completely removes
the regulator but wasn't happy about pushing the patch for 3.6 since I
can't test (I don't think anyone's ever actually used those and
obviously they should be using the clk API now).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New build warnings

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 06:40:43PM +0100, Mark Brown wrote:
 On Mon, Jul 30, 2012 at 05:44:44PM +0100, Russell King - ARM Linux wrote:
 
  -#define TWLRES_OF_MATCH(comp, label) TWL_OF_MATCH(comp, TWLRES, label)
  -   TWLRES_OF_MATCH(ti,twl6030-clk32kg, CLK32KG),
 
  but completely forgets that this:
 
  TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0);
 
  defines a structure that it was using.  (Welcome to why macros are horrid
  when they hide the names of stuff they create.)
 
 I actually have the fix in a separate patch which completely removes
 the regulator but wasn't happy about pushing the patch for 3.6 since I
 can't test (I don't think anyone's ever actually used those and
 obviously they should be using the clk API now).

If the structure is unused, the fix is to delete the
TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0); line because nothing is using
that (if it was, we wouldn't end up with the warning).
--
To unsubscribe from this list: send the line unsubscribe 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: New build warnings

[Mark Brown]

On Mon, Jul 30, 2012 at 07:06:23PM +0100, Russell King - ARM Linux wrote:
 On Mon, Jul 30, 2012 at 06:40:43PM +0100, Mark Brown wrote:

  I actually have the fix in a separate patch which completely removes
  the regulator but wasn't happy about pushing the patch for 3.6 since I
  can't test (I don't think anyone's ever actually used those and
  obviously they should be using the clk API now).

 If the structure is unused, the fix is to delete the
 TWL6030_FIXED_RESOURCE(CLK32KG, 0x8C, 0); line because nothing is using
 that (if it was, we wouldn't end up with the warning).

Well, clearly.  I had thought there were implicit references somewhere
but apparently not since it's not in an array or anything.  Oh, well.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] ARM: omap: clk: Remove all direct dereferencing of struct clk

[Paul Walmsley]

On Mon, 30 Jul 2012, Rajendra Nayak wrote:

 Are you sure you are using the v3 of this patch? You already mentioned
 about these in the v2 [1] and I fixed all these in v3. I went back and
 looked at the v3 of this patch, and it does not complain me about any
 of these warnings or errors.

Yep that's probably what happened.  Here's the updated patch, starting
from your v3.


- Paul


From: Rajendra Nayak rna...@ti.com
Date: Mon, 30 Jul 2012 12:52:55 -0600
Subject: [PATCH] ARM: OMAP2+: clock: Remove all direct dereferencing of
 struct clk

While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.

While here also concatenate some strings split across multiple lines
which seem to be needed anyway.

Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: simplified some compound expressions; reformatted some
 messages]
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mike Turquette mturque...@linaro.org
---
 arch/arm/mach-omap2/clkt2xxx_apll.c  |2 +-
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |   10 ++-
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c   |   20 +++---
 arch/arm/mach-omap2/clkt_clksel.c|   91 --
 arch/arm/mach-omap2/clkt_dpll.c  |   26 
 arch/arm/mach-omap2/clock.c  |   11 ++--
 arch/arm/mach-omap2/dpll3xxx.c   |   48 --
 arch/arm/mach-omap2/omap_hwmod.c |6 +-
 arch/arm/mach-omap2/pm.c |2 +-
 arch/arm/plat-omap/include/plat/clock.h  |5 ++
 10 files changed, 135 insertions(+), 86 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt2xxx_apll.c 
b/arch/arm/mach-omap2/clkt2xxx_apll.c
index b19a1f7..c2d15212 100644
--- a/arch/arm/mach-omap2/clkt2xxx_apll.c
+++ b/arch/arm/mach-omap2/clkt2xxx_apll.c
@@ -59,7 +59,7 @@ static int omap2_clk_apll_enable(struct clk *clk, u32 
status_mask)
omap2_cm_write_mod_reg(cval, PLL_MOD, CM_CLKEN);
 
omap2_cm_wait_idlest(cm_idlest_pll, status_mask,
-OMAP24XX_CM_IDLEST_VAL, clk-name);
+OMAP24XX_CM_IDLEST_VAL, __clk_get_name(clk));
 
/*
 * REVISIT: Should we return an error code if omap2_wait_clock_ready()
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c 
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 3d9d746..da03fa4 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -68,14 +68,15 @@ unsigned long omap2_table_mpu_recalc(struct clk *clk)
 long omap2_round_to_table_rate(struct clk *clk, unsigned long rate)
 {
const struct prcm_config *ptr;
-   long highest_rate;
+   long highest_rate, sys_clk_rate;
 
highest_rate = -EINVAL;
+   sys_clk_rate = __clk_get_rate(sclk);
 
for (ptr = rate_table; ptr-mpu_speed; ptr++) {
if (!(ptr-flags  cpu_mask))
continue;
-   if (ptr-xtal_speed != sclk-rate)
+   if (ptr-xtal_speed != sys_clk_rate)
continue;
 
highest_rate = ptr-mpu_speed;
@@ -94,12 +95,15 @@ int omap2_select_table_rate(struct clk *clk, unsigned long 
rate)
const struct prcm_config *prcm;
unsigned long found_speed = 0;
unsigned long flags;
+   long sys_clk_rate;
+
+   sys_clk_rate = __clk_get_rate(sclk);
 
for (prcm = rate_table; prcm-mpu_speed; prcm++) {
if (!(prcm-flags  cpu_mask))
continue;
 
-   if (prcm-xtal_speed != sclk-rate)
+   if (prcm-xtal_speed != sys_clk_rate)
continue;
 
if (prcm-mpu_speed = rate) {
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
index d6e34dd..0fd8b70 100644
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
@@ -56,6 +56,7 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
struct omap_sdrc_params *sdrc_cs0;
struct omap_sdrc_params *sdrc_cs1;
int ret;
+   unsigned long clkrate;
 
if (!clk || !rate)
return -EINVAL;
@@ -64,11 +65,12 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned 
long rate)
if (validrate != rate)
return -EINVAL;
 
-   sdrcrate = sdrc_ick_p-rate;
-   if (rate  clk-rate)
-   sdrcrate = ((rate / clk-rate)  1);
+   sdrcrate = __clk_get_rate(sdrc_ick_p);
+   clkrate = __clk_get_rate(clk);
+   if (rate  clkrate)
+   sdrcrate = ((rate / clkrate)  1);
else
-   sdrcrate = ((clk-rate / rate)  1);
+   sdrcrate = ((clkrate / rate)  1);
 
ret = omap2_sdrc_get_params(sdrcrate, sdrc_cs0, sdrc_cs1);
   

Re: [PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection

[Ricardo Neri]

Hi Tomi, Archit,

Thanks for your feedback.

On 07/30/2012 06:48 AM, Archit Taneja wrote:

On Monday 30 July 2012 04:41 PM, Tomi Valkeinen wrote:

On Fri, 2012-07-27 at 19:21 -0500, Ricardo Neri wrote:

Hello,

DSS code wrongly assumes that VENC is always available as source for
the external
sync signal for the display controller DIGIT channel. One cannot blindly
rely only on the value of DSS_CONTROL register as certain processors
may not
have VENC (e.g., OMAP5).

These patches add logic to correctly set/get the sync signal based on
the
available displays in the DIGIT channel.

For the HDMI driver, handle the error in the selection of the source.


Is there an actual problem seen that this resolves? If so, It'd be nice
to have a brief description of the problem.


The issue is seen on OMAP5 with a 3.5 kernel. In 3.5 kernel, we had a
hack where we used to divide the TV manager's height by 2 if the
connected interface was VENC. On OMAP5, the bit 15 returns VENC (a zero)
irrespective of what we write.

This won't happen in 3.6 as we have included interlace as a part of the
omap_video_timings struct, and we don't try to check the bit to see
whether we are VENC or HDMI.

I guess we should still put a check to not set the bit on OMAP5 as it
may cause unknown HW behavior, i.e, make the select function like:

void dss_select_hdmi_venc_clk_source()
{
 ...

 displays =
 dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);

 if ((displays  OMAP_DISPLAY_TYPE_VENC) == 0)
 return;

 REG_FLD_MOD(DSS_CONTROL, src, 15, 15);/* VENC_HDMI_SWITCH */
}


As Tomi mentions, perhaps this could be complemented with a BUG_ON could 
be used if someone tries to use VENC as source when this is not available.


Archit



Does the bit 15 in DSS_CONTROL still exist on OMAP5? What does it return
on OMAP5?

I think it's clear that dss_get_hdmi_venc_clk_source() needs to return a
correct value so that DSS operates correctly. But I'm not sure we need
the extra code in dss_select_hdmi_venc_clk_source().


Yes, the main purpose of these patch was to avoid blindly reading 
DSS_CONTROL[15]. The additions to selection were just for completeness.


dss_select_hdmi_venc_clk_source() should be called by venc or hdmi, and
there should be any possibility of using it in the wrong way. For extra
sanity checking there could be a BUG_ON() check in the
dss_select_hdmi_venc_clk_source() to point out if there's a bad bug in
venc or hdmi.

I'd like to keep the lowest level dss-internal functions as simple as
possible, and written in the manner that they presume they are called
correctly. Otherwise we'll end up with lots of new code, checking for
errors that can never happen in practice.

Well, this was an error that happened in practice :).

I will resubmit based on these comments.

Thanks,

Ricardo


  Tomi





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

Re: [GPIO] Crashed when not using

[Kevin Hilman]

Poddar, Sourav sourav.pod...@ti.com writes:

 On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
 tarun.ka...@ti.com wrote:
 Sourav,

 On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
 Hi All,

 I tried using gpio as an interrupt line for my driver
 (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
 The interrupt line number was directly passed to the driver using
 device tree. But what I observed
 is the following crash..


 [1.599273] mousedev: PS/2 mouse device common for all mice
 [1.607513] i2c /dev entries driver
 [1.613739] Driver for 1-wire Dallas network protocol.
 [1.622650] usbcore: registered new interface driver usbhid
 [1.628540] usbhid: USB HID core driver
 [1.633728] Unhandled fault: imprecise external abort (0x1406) at 
 0x
 [1.641113] Internal error: : 1406 [#1] SMP ARM
 [1.645874] Modules linked in:
 [1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty #415)
 [1.655761] PC is at _set_gpio_triggering+0x44/0x264
 [1.660980] LR is at gpio_irq_type+0xb8/0x160
 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
 [1.665527] sp : dc851df0  ip : c07a8f00  fp : 
 [1.677581] r10: 0081  r9 :   r8 : dc8ffc10
 [1.683074] r7 : 2093  r6 :   r5 : 0001  r4 : fa05b000
 [1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 : 0140
 [1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
 Segment kernel
 [1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
 [1.716857] Stack: (0xdc851df0 to 0xdc852000)
 [1.721405] 1de0: 0002
 c0731280 dc8ffc6c 2093
 [1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
 0141 0002 c00a37b8
 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
 c07312b4 4013 c00a3d7c
 [1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
 c00a2d5c c0412258 0141
 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
 2002 c071bed8 c247f000
 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
 c04ea344 c06728c0 c247f000
 [1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
 c04ea194 0091 c071bed8
 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
 dc9df054 c07bf60c c03272ac
 [1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
 c03274c0 c07bf60c dc851f08
 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
 c07bf60c c07bcea8 c243d6c0
 [1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
 c07bf60c c03e12a0 
 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
 0007 c07c8c40 
 [1.824401] 1f60: 0091 c03e1738  dc85 0007
 c0008648  c112c9f0
 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
  0006 0006
 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
 0091 c071bed8 c0700a28
 [1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
   c06d028c
 [1.858703] 1fe0: c001548c 0013   
 c001548c 3f3f3f3f 3f3f3f3f
 [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
 [c02dc224] (gpio_irq_type+0x0/0x160)
 [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] 
 (0x2002)
 [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
 [1.890960] [ cut here ]
 [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
 l3_interrupt_handler+0x184/0x1bc()
 [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [1.910430] Modules linked in:
 [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
 [c00414c4] (warn_slowpath_common+0x4c/0x64)
 [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
 [c0041570] (warn_slowpath_fmt+0x30/0x40)
 [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
 [c0035de4] (l3_interrupt_handler+0x184/0x1bc)
 [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
 [c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
 [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
 [c00a2adc] (handle_irq_event+0x3c/0x5c)
 [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
 [c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
 [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
 [c00a235c] (generic_handle_irq+0x34/0x44)
 [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
 [c00153a0] (handle_IRQ+0x4c/0xac)
 [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
 (gic_handle_irq+0x2c/0x60)
 [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
 [c04f26e4] (__irq_svc+0x44/0x60)
 [2.011718] Exception stack(0xdc851c48 to 0xdc851c90)
 [2.017028] 1c40:   c07a87a0  dc851c80
  c0743f80 

Re: [RFC 0/6] ARM: OMAP3+: minor PM core code cleanup

[Kevin Hilman]

Tero, Paul,

Tero Kristo t-kri...@ti.com writes:

 Hi,

 Following set moves some PRM related code away from PM core code to
 PRM / HWMOD. This requires the hwmod cleanup set from Paul that
 implements the setup_preprogram hooks for hwmods. Sending as RFC for
 initial commenting.

What is the status of the setup_preprogram hooks patch(es)?  Looks like
that part was dropped from Paul's original series of fixes.

Just curious,

Kevin

 This set does following:
 - gets rid of the prcm interrupt handler from pm34xx.c
 - removes iva_idle from pm34xx.c
 - removes d2d_idle from pm34xx.c

 There are some side-effects though, it looks like the reset statuses
 for iva / d2d modules are rather flaky, and some failed hardreset
 warnings are generated during boot. PM works fine though and the
 modules are put to idle properly. Could use some ideas how to handle
 this, maybe add a flag for ignoring the hardreset status completely...?

 -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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare

[Paul Walmsley]

Hi

On Mon, 2 Jul 2012, Rajendra Nayak wrote:

 As part of Common Clk Framework (CCF) the clk_enable() operation
 was split into a clk_prepare() which could sleep, and a clk_enable()
 which should never sleep. Similarly the clk_disable() was
 split into clk_disable() and clk_unprepare(). This was
 needed to handle complex cases where in a clk gate/ungate
 would require a slow and a fast part to be implemented.
 None of the clocks below seem to be in the 'complex' clocks
 category and are just simple clocks which are enabled/disabled
 through simple register writes.
 Most of the instances also seem to be called in non-atomic
 context which means its safe to move all of those from
 using a clk_enable() to clk_prepare_enable() and clk_disable() to
 clk_disable_unprepare().
 For a few others where there is a possibility they get called from
 an interrupt or atomic context, there is an additonal clk_prepare()
 done before a clk_enable() and a clk_unprepare()
 after a clk_disable().
 This is in preparation of OMAP moving to CCF.
 
 Based on initial changes from Mike turquette.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com

Looking at this one, it seems basically okay except for this part:

 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index 7731936..f904993 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -608,6 +608,7 @@ static int _init_main_clk(struct omap_hwmod *oh)
  oh-name, oh-main_clk);
   return -EINVAL;
   }
 + clk_prepare(oh-_clk);
  
   if (!oh-_clk-clkdm)
   pr_warning(omap_hwmod: %s: missing clockdomain for %s.\n,
 @@ -645,6 +646,7 @@ static int _init_interface_clks(struct omap_hwmod *oh)
   ret = -EINVAL;
   }
   os-_clk = c;
 + clk_prepare(os-_clk);
   }
  
   return ret;
 @@ -672,6 +674,7 @@ static int _init_opt_clks(struct omap_hwmod *oh)
   ret = -EINVAL;
   }
   oc-_clk = c;
 + clk_prepare(oc-_clk);
   }
  
   return ret;

Seems to me that the strategy here of calling clk_prepare() right after 
the clk_get() is only going to work as long as clk_prepare() is a no-op. 
Right now this code is called early in the boot before many subsystems are 
available.

So if we make a change like this one, it seems like we would basically 
expect it to break once we start doing anything meaningful with 
clk_prepare(), like using clk_prepare() for voltage scaling or something 
that requires I2C?  We'd also probably want to mark this with some kind of 
HACK comment.
 


- 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: [GPIO] Crashed when not using

[Shilimkar, Santosh]

On Mon, Jul 30, 2012 at 10:36 PM, Kevin Hilman khil...@ti.com wrote:

 Poddar, Sourav sourav.pod...@ti.com writes:

  On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
  tarun.ka...@ti.com wrote:
  Sourav,
 
  On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com
  wrote:
  Hi All,
 
  I tried using gpio as an interrupt line for my driver
  (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
  The interrupt line number was directly passed to the driver using
  device tree. But what I observed
  is the following crash..
 
 
  [1.599273] mousedev: PS/2 mouse device common for all mice
  [1.607513] i2c /dev entries driver
  [1.613739] Driver for 1-wire Dallas network protocol.
  [1.622650] usbcore: registered new interface driver usbhid
  [1.628540] usbhid: USB HID core driver
  [1.633728] Unhandled fault: imprecise external abort (0x1406) at
  0x
  [1.641113] Internal error: : 1406 [#1] SMP ARM
  [1.645874] Modules linked in:
  [1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty
  #415)
  [1.655761] PC is at _set_gpio_triggering+0x44/0x264
  [1.660980] LR is at gpio_irq_type+0xb8/0x160
  [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
  [1.665527] sp : dc851df0  ip : c07a8f00  fp : 
  [1.677581] r10: 0081  r9 :   r8 : dc8ffc10
  [1.683074] r7 : 2093  r6 :   r5 : 0001  r4 :
  fa05b000
  [1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 :
  0140
  [1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
  Segment kernel
  [1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
  [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
  [1.716857] Stack: (0xdc851df0 to 0xdc852000)
  [1.721405] 1de0: 0002
  c0731280 dc8ffc6c 2093
  [1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
  0141 0002 c00a37b8
  [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
  c07312b4 4013 c00a3d7c
  [1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
  c00a2d5c c0412258 0141
  [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
  2002 c071bed8 c247f000
  [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
  c04ea344 c06728c0 c247f000
  [1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
  c04ea194 0091 c071bed8
  [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
  dc9df054 c07bf60c c03272ac
  [1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
  c03274c0 c07bf60c dc851f08
  [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
  c07bf60c c07bcea8 c243d6c0
  [1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
  c07bf60c c03e12a0 
  [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
  0007 c07c8c40 
  [1.824401] 1f60: 0091 c03e1738  dc85 0007
  c0008648  c112c9f0
  [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
   0006 0006
  [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
  0091 c071bed8 c0700a28
  [1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
    c06d028c
  [1.858703] 1fe0: c001548c 0013   
  c001548c 3f3f3f3f 3f3f3f3f
  [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
  [c02dc224] (gpio_irq_type+0x0/0x160)
  [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from
  [2002] (0x2002)
  [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
  [1.890960] [ cut here ]
  [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
  l3_interrupt_handler+0x184/0x1bc()
  [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
  [1.910430] Modules linked in:
  [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
  [c00414c4] (warn_slowpath_common+0x4c/0x64)
  [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
  [c0041570] (warn_slowpath_fmt+0x30/0x40)
  [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
  [c0035de4] (l3_interrupt_handler+0x184/0x1bc)
  [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
  [c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
  [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
  [c00a2adc] (handle_irq_event+0x3c/0x5c)
  [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
  [c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
  [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
  [c00a235c] (generic_handle_irq+0x34/0x44)
  [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
  [c00153a0] (handle_IRQ+0x4c/0xac)
  [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
  (gic_handle_irq+0x2c/0x60)
  [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
  

Re: [PATCH v3 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare

[Turquette, Mike]

On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
 So if we make a change like this one, it seems like we would basically
 expect it to break once we start doing anything meaningful with
 clk_prepare(), like using clk_prepare() for voltage scaling or something
 that requires I2C?  We'd also probably want to mark this with some kind of
 HACK comment.

Hi Paul,

Did you have anything in mind to start using clk_prepare?  I still
hope to get rid of it some day and replace that call with a
combination of clk_enable and a check like clk_enable_can_sleep.

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

Re: [PATCH v3 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
 On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
  So if we make a change like this one, it seems like we would basically
  expect it to break once we start doing anything meaningful with
  clk_prepare(), like using clk_prepare() for voltage scaling or something
  that requires I2C?  We'd also probably want to mark this with some kind of
  HACK comment.
 
 Hi Paul,
 
 Did you have anything in mind to start using clk_prepare?  I still
 hope to get rid of it some day and replace that call with a
 combination of clk_enable and a check like clk_enable_can_sleep.

Don't you dare.

We arrived at the clk_prepare()/clk_enable() split after lots of
discussion between different platform maintainers and their
requirements.

Shoving crap like clk_enable_can_sleep() down into drivers is
totally and utterly idiotic.  We've had the situation *already*
where some drivers can be used on some platforms but not on others
because of differences in clk_enable() expectations.

Don't go back there.  clk_prepare() and clk_enable() are separate
calls for a very good reason.  One is sleepable, the other can be
called from any atomic contexts.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

[Jon Hunter]

Hi Paul,

On 07/16/2012 01:38 PM, Paul Walmsley wrote:
 Hi Jon,
 
 On Mon, 16 Jul 2012, Jon Hunter wrote:
 
 Yes I see that makes sense. However, patch #7 has already changed the
 mapping of the flags. I had intended that patch #7 and #8 would be
 applied together. However, I could see that patch #7 can be taken just
 to eliminate using the SW_SLEEP state. So basically, what I am saying is
 does patch #7 have any value without #8?
 
 Certainly not as much value as it had before.  But my understanding, which 
 is possibly incorrect, matches what you wrote in patch #7's description:
 
 For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is 
 equivalent to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP 
 for OMAP4 devices is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt 
 status is set in case of SW_SLEEP transition, and not set in case of 
 HW_AUTO transition.
 
 We don't use that PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt bit.  So if 
 SW_SLEEP and HW_AUTO really have identical meanings otherwise, then I 
 suppose we might as well use the one that does what we need with no 
 extraneous side-effects?  My recollection from a conversation with Benoît 
 a few months ago was that this was his view as well.
 
 That's fine with me. We can always workaround such issues by adding flags.

 I can give this a try this week and let you know how it goes.
 
 Okay, great.  No rush on my account.

I have been testing your patch [1] on OMAP3 and found that the EMU
clock domain was not being disabled for two reasons. 

1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices 
   we simply return without doing anything. Not sure if it is safe to 
   remove this but I can do some more testing on OMAP2/3. 

commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunter jon-hun...@ti.com
Date:   Mon Jul 30 18:04:06 2012 -0500

ARM: OMAP2/3: Allow HWMOD to disable clock domains

Currently when HWMOD attempts to disable a clock domain on OMAP2/3 devices 
we
will return from the function clkdm_hwmod_disable() without actually 
disabling
the clock domain. Per the comment this is deliberate because initially HWMOD
OMAP2/3 devices did not support clock domains. However, clock domains are 
now
supported by HWMOD for these devices and so allow HWMOD to disable the clock
domains.

XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 011186f..8f7a941 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
  */
 int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
 {
-   /* The clkdm attribute does not exist yet prior OMAP4 */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
-   return 0;
-
/*
 * XXX Rewrite this code to maintain a list of enabled
 * downstream hwmods for debugging purposes?


2. I need to make the following changes to your patch. The change to
   omap2_clkdm_clk_disable() was needed to get the EMU to turn off.
   At the same time I thought we should make the same change to
   omap2_clkdm_clk_enable().

diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 09385a9..c94b2fb 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -223,7 +223,8 @@ static int omap2_clkdm_clk_enable(struct clockdomain *clkdm)
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
-   omap2_clkdm_wakeup(clkdm);
+   (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
+   omap3_clkdm_wakeup(clkdm);
}
 
return 0;
@@ -257,7 +258,8 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
*clkdm)
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
-   omap2_clkdm_sleep(clkdm);
+   (cpu_is_omap24xx()) ? omap2_clkdm_sleep(clkdm) :
+   omap3_clkdm_sleep(clkdm);
}


I need to do more testing but wanted to give you this feedback and
get your comments.

Cheers
Jon

[1] http://marc.info/?l=linux-arm-kernelm=134212814812557w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 0/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503

[Juha Kuikka]

Based on Mark A. Greer's findings on the AM3703 and the corresponding patch
ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature.

Similarly to am3703, it seems that omap3503 has an IVA control registers even
though the subsystem is non-functional.

Tested on Gumstix Overo Earth (OMAP3503). Without this patch the IVA domain
fails to enter retention on suspend.


Juha Kuikka (1):
  ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503

 arch/arm/mach-omap2/id.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
1.7.5.4

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

[PATCH v1 1/1] ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503

[Juha Kuikka]

Similarly to am3703, it seems that omap3503 has an IVA control
registers even though the subsystem is non-functional.

This patch sets the OMAP3_HAS_IVA_REGS feature to force
initialization of there registers.

Based in Mark A. Greer's patch
ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature.

Signed-off-by: Juha Kuikka juha.kui...@gmail.com
---
 arch/arm/mach-omap2/id.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 4072fbd..45d3eb4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -244,7 +244,7 @@ void __init omap3xxx_check_features(void)
if (cpu_is_omap3630())
omap_features |= OMAP3_HAS_192MHZ_CLK | OMAP3_HAS_IVA_REGS;
if (cpu_is_omap3430() || cpu_is_omap3630())
-   omap_features |= OMAP3_HAS_IO_WAKEUP;
+   omap_features |= OMAP3_HAS_IO_WAKEUP | OMAP3_HAS_IVA_REGS;
if (cpu_is_omap3630() || omap_rev() == OMAP3430_REV_ES3_1 ||
omap_rev() == OMAP3430_REV_ES3_1_2)
omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
-- 
1.7.5.4

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

[PATCH v2] OMAPDSS: DISPC: Improve DIGIT channel sync signal selection

[Ricardo Neri]

DSS code wrongly assumes that VENC is always available as source for the 
external
sync signal for the display controller DIGIT channel. One cannot blindly
rely only on the value of DSS_CONTROL[15] as on certain processors (e.g., OMAP5)
reading/writing on that bit may not be valid. If the the sync source is not read
correctly, the callers of dss_get_hdmi_venc_clk_source might make wrong 
assumptions
about, for instance, video timings.

This patch adds logic to correctly get the sync signal based on the
available displays in the DIGIT channel. A kernel BUG is thrown if an
invalid source is selected.

Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
v2: use BUG_ON() to simplify handling of invalid cases.
 drivers/video/omap2/dss/dss.c |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 04b4586..2f8e4b6 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -648,9 +648,15 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
 }
 
-void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select hdmi)
+void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select src)
 {
-   REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* VENC_HDMI_SWITCH */
+   enum omap_display_type dp;
+   dp = dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);
+
+   BUG_ON((src == DSS_VENC_TV_CLK)  !(dp  OMAP_DISPLAY_TYPE_VENC));
+   BUG_ON((src == DSS_HDMI_M_PCLK)  !(dp  OMAP_DISPLAY_TYPE_HDMI));
+
+   REG_FLD_MOD(DSS_CONTROL, src, 15, 15);  /* VENC_HDMI_SWITCH */
 }
 
 enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
@@ -661,6 +667,9 @@ enum dss_hdmi_venc_clk_source_select 
dss_get_hdmi_venc_clk_source(void)
if ((displays  OMAP_DISPLAY_TYPE_HDMI) == 0)
return DSS_VENC_TV_CLK;
 
+   if ((displays  OMAP_DISPLAY_TYPE_VENC) == 0)
+   return DSS_HDMI_M_PCLK;
+
return REG_GET(DSS_CONTROL, 15, 15);
 }
 
-- 
1.7.5.4

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

[PATCH] OMAPDSS: HDMI: Disable PLL properly in case of error at power_on

[Ricardo Neri]

Small patch to disable the PLL appropriately before runtime_put in case
an error occurs while enabling the PHY.

Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
 drivers/video/omap2/dss/hdmi.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 060216f..a65dafa 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -501,7 +501,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
r = hdmi.ip_data.ops-phy_enable(hdmi.ip_data);
if (r) {
DSSDBG(Failed to start PHY\n);
-   goto err;
+   goto err_phy_enable;
}
 
hdmi.ip_data.ops-video_configure(hdmi.ip_data);
@@ -537,6 +537,7 @@ err_mgr_enable:
hdmi.ip_data.ops-video_disable(hdmi.ip_data);
 err_vid_enable:
hdmi.ip_data.ops-phy_disable(hdmi.ip_data);
+err_phy_enable:
hdmi.ip_data.ops-pll_disable(hdmi.ip_data);
 err:
hdmi_runtime_put();
-- 
1.7.5.4

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

Re: [RFC 1/6] ARM: OMAP3: PRM: move prcm interrupt handlers to PRM driver code

[Kevin Hilman]

Tero Kristo t-kri...@ti.com writes:

 PM code doesn't really care about the PRCM wakeup + io interrupts on
 OMAP3, as these are used only for acking PRCM internal events, and the
 IO chain handler is taken care of by hwmod code. Thus move the interrupt
 handling logic from pm34xx.c to prm2xxx_3xxx.c file. This patch also
 includes a minor cleanup for removing the priority handling and replacing
 it with a mechanism for acking pending events. This gets rid of the need
 for registering the shared interrupt handlers in specific order.

 Signed-off-by: Tero Kristo t-kri...@ti.com

Like Rajendra, I found this combination a bit difficult to review, so I
decided to apply it and test it first.

Testing with just this patch (on top of Paul's omap4_warnings_fix_3.6
branch, which has the setup_preprogram hooks), and I get a hang on
3530 and 3730 Overo platforms (works fine on 3430/n900 and 3630/xM.)

I'm not sure what is happening yet, but there seems to be a race between
the IO and wkup handlers...

[...]

 +/**
 + * omap3xxx_prm_clear_wakeups - clears wakeup event sources
 + * @events: active PRCM interrupt event mask
 + *
 + * This function will first check if PRCM chain handler detected
 + * a wakeup event or not. If yes, it will continue to clear any
 + * pending wakeup events from PRCM module. Typically the module
 + * will generate an actual interrupt together with the wakeup event,
 + * which will then be handled separately by the driver code.
 + */
 +void omap3xxx_prm_clear_wakeups(unsigned long *events)
 +{
 + int c;
 +
 + /*
 +  * If we didn't come here because of a wakeup event, do nothing
 +  */
 + if (!(events[0]  OMAP3430_WKUP_ST_MASK))
 + return;

... because if I comment out the above two lines, it goes back to
working again.

 + c = _prcm_clear_mod_irqs(WKUP_MOD, 1);
 + c += _prcm_clear_mod_irqs(CORE_MOD, 1);
 + c += _prcm_clear_mod_irqs(OMAP3430_PER_MOD, 1);
 + if (omap_rev()  OMAP3430_REV_ES1_0) {
 + c += _prcm_clear_mod_irqs(CORE_MOD, 3);
 + c += _prcm_clear_mod_irqs(OMAP3430ES2_USBHOST_MOD, 1);
 + }
 +}

At first, I wasn't sure why this was happening on Overo boards and not
on the other boards, but then I notcied there was a *lot* more pm_wkup
interrupts during boot on Overo compared to the other boards.  This is
because of the GPIO IRQ for the network interface as well as the network
stack itself setting timers, resulting in a lot more pm_wkup events
during boot and making the race more likely.

Kevin

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

Re: [PATCH v3 1/3] ARM: omap: clk: add clk_prepare and clk_unprepare

[Turquette, Mike]

On Mon, Jul 30, 2012 at 4:02 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Mon, Jul 30, 2012 at 03:42:13PM -0700, Turquette, Mike wrote:
 On Mon, Jul 30, 2012 at 3:31 PM, Paul Walmsley p...@pwsan.com wrote:
  So if we make a change like this one, it seems like we would basically
  expect it to break once we start doing anything meaningful with
  clk_prepare(), like using clk_prepare() for voltage scaling or something
  that requires I2C?  We'd also probably want to mark this with some kind of
  HACK comment.

 Hi Paul,

 Did you have anything in mind to start using clk_prepare?  I still
 hope to get rid of it some day and replace that call with a
 combination of clk_enable and a check like clk_enable_can_sleep.

 Don't you dare.

 We arrived at the clk_prepare()/clk_enable() split after lots of
 discussion between different platform maintainers and their
 requirements.

 Shoving crap like clk_enable_can_sleep() down into drivers is
 totally and utterly idiotic.  We've had the situation *already*
 where some drivers can be used on some platforms but not on others
 because of differences in clk_enable() expectations.


How does having a dynamic run-time check cause a generic driver to run
on some platforms but not on others?

 Don't go back there.  clk_prepare() and clk_enable() are separate
 calls for a very good reason.  One is sleepable, the other can be
 called from any atomic contexts.

Two calls exist because of context differences.  But in practice they
do the same thing: cause a line to toggle at a rate.  If a run-time
check exists and the framework could handle this gracefully, why would
you still choose the split api?

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

Issue with DSS power domain always in ON state

[Juha Kuikka]

Hello,

I am running the l-o (55936cdfaaf11ac352b56bc58e42d6661e65ee13) with following:
- ARM: OMAP3: Add OMAP3_HAS_IVA_REGS feature
- ARM: OMAP3: Use OMAP3_HAS_IVA_REGS with OMAP3503
- OMAPDSS: PM runtime fixes for 3.5-rc

Using omap2plus_defconfig.
- Minus EHCI
- Minus ADS7846
- Minus SMP
- Plus initramfs

Running on Gumstix Overo Earth (OMP3503).

My problem is that while suspend (with the above patches) seems to
function the debug counters for DSS do not indicate retention or off
mode.

What happens:

/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm 
(ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:464,INA:0,ON:465,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:464,INA:0,ON:465,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm 
(RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm-usbhost_pwrdm (1)
sgx_clkdm-sgx_pwrdm (0)
per_clkdm-per_pwrdm (18)
cam_clkdm-cam_pwrdm (0)
dss_clkdm-dss_pwrdm (1)
d2d_clkdm-core_pwrdm (0)
iva2_clkdm-iva2_pwrdm (0)
mpu_clkdm-mpu_pwrdm (0)
core_l4_clkdm-core_pwrdm (24)
core_l3_clkdm-core_pwrdm (4)
neon_clkdm-neon_pwrdm (0)
/ # echo mem  /sys/power/state
[   41.891540] PM: Syncing filesystems ... done.
[   41.910003] Freezing user space processes ... (elapsed 0.01 seconds) done.
[   41.935607] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[   41.966796] Suspending console(s) (use no_console_suspend to debug)
[   42.098388] PM: suspend of devices complete after 119.872 msecs
[   42.102722] PM: late suspend of devices complete after 4.272 msecs
[   42.109222] PM: noirq suspend of devices complete after 6.469 msecs
[   44.625213] Successfully put all powerdomains to target state
[   44.628753] PM: noirq resume of devices complete after 3.295 msecs
[   44.632995] PM: early resume of devices complete after 2.685 msecs
[   45.050598] PM: resume of devices complete after 417.449 msecs
[   45.100341] Restarting tasks ... done.
/ # cat /debug/pm_debug/count
usbhost_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm 
(ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
per_pwrdm (ON),OFF:0,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:616,INA:0,ON:617,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:616,INA:0,ON:617,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm 
(RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0
usbhost_clkdm-usbhost_pwrdm (1)
sgx_clkdm-sgx_pwrdm (0)
per_clkdm-per_pwrdm (18)
cam_clkdm-cam_pwrdm (0)
dss_clkdm-dss_pwrdm (1)
d2d_clkdm-core_pwrdm (0)
iva2_clkdm-iva2_pwrdm (0)
mpu_clkdm-mpu_pwrdm (0)
core_l4_clkdm-core_pwrdm (24)
core_l3_clkdm-core_pwrdm (4)
neon_clkdm-neon_pwrdm (0)

In the defconfig DSS is built as a module. After building it (and
PANEL_GENERIC) into kernel the situation does not change.

Strangely the core domain is able to go to retention (or off if
enabled) even though DSS isn't.

Suspend _seems_ to work but I only see a meager 10mA reduction (from
80mA to 70mA) in the current to the gumstix so I'm suspicious.

Can anyone shed any light on this?

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

[Jon Hunter]

Hi Paul,

On 07/30/2012 06:26 PM, Jon Hunter wrote:

[...]

 1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices 
we simply return without doing anything. Not sure if it is safe to 
remove this but I can do some more testing on OMAP2/3. 
 
 commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
 Author: Jon Hunter jon-hun...@ti.com
 Date:   Mon Jul 30 18:04:06 2012 -0500
 
 ARM: OMAP2/3: Allow HWMOD to disable clock domains
 
 Currently when HWMOD attempts to disable a clock domain on OMAP2/3 
 devices we
 will return from the function clkdm_hwmod_disable() without actually 
 disabling
 the clock domain. Per the comment this is deliberate because initially 
 HWMOD
 OMAP2/3 devices did not support clock domains. However, clock domains are 
 now
 supported by HWMOD for these devices and so allow HWMOD to disable the 
 clock
 domains.
 
 XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3
 
 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 011186f..8f7a941 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, 
 struct omap_hwmod *oh)
   */
  int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
  {
 -   /* The clkdm attribute does not exist yet prior OMAP4 */
 -   if (cpu_is_omap24xx() || cpu_is_omap34xx())
 -   return 0;
 -
 /*
  * XXX Rewrite this code to maintain a list of enabled
  * downstream hwmods for debugging purposes?
 
 
 2. I need to make the following changes to your patch. The change to
omap2_clkdm_clk_disable() was needed to get the EMU to turn off.
At the same time I thought we should make the same change to
omap2_clkdm_clk_enable().
 
 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index 09385a9..c94b2fb 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -223,7 +223,8 @@ static int omap2_clkdm_clk_enable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 -   omap2_clkdm_wakeup(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
 +   omap3_clkdm_wakeup(clkdm);
 }
  
 return 0;
 @@ -257,7 +258,8 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 -   omap2_clkdm_sleep(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_sleep(clkdm) :
 +   omap3_clkdm_sleep(clkdm);
 }

I just remembered you sending out a patch [1] to address #2 above. Let
me know your thoughts about change #1.

Cheers
Jon

[1] http://marc.info/?l=linux-omapm=134333691309305w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep

[Jon Hunter]

Hi Paul, Rajendra,

On 07/27/2012 12:43 AM, Rajendra Nayak wrote:
 On Friday 27 July 2012 02:34 AM, Paul Walmsley wrote:

 Commit 4da71ae6 (OMAP: clockdomain: Arch specific funcs for
 clkdm_clk_enable/disable) called the OMAP2xxx-specific functions for
 clockdomain wakeup and sleep.  This would probably have broken
 software-supervised clockdomain wakeup and sleep on OMAP3.
 
 Its strange this went unnoticed for so long. Thanks for this fix and
 sorry about introducing the bug in the first place.

Any chance that's because of the following code? I needed to
remove this to get the EMU clock domain to turn off on OMAP3
whilst testing PMU.

Cheers
Jon

commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunter jon-hun...@ti.com
Date:   Mon Jul 30 18:04:06 2012 -0500

ARM: OMAP2/3: Allow HWMOD to disable clock domains

Currently when HWMOD attempts to disable a clock domain on OMAP2/3 devices 
we
will return from the function clkdm_hwmod_disable() without actually 
disabling
the clock domain. Per the comment this is deliberate because initially HWMOD
OMAP2/3 devices did not support clock domains. However, clock domains are 
now
supported by HWMOD for these devices and so allow HWMOD to disable the clock
domains.

XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 011186f..8f7a941 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
  */
 int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
 {
-   /* The clkdm attribute does not exist yet prior OMAP4 */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
-   return 0;
-
/*
 * XXX Rewrite this code to maintain a list of enabled
 * downstream hwmods for debugging purposes?

--
To unsubscribe from this list: send the line unsubscribe 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: [GPIO] Crashed when not using

[Poddar, Sourav]

Hi Kevin,

On Tue, Jul 31, 2012 at 2:06 AM, Kevin Hilman khil...@ti.com wrote:
 Poddar, Sourav sourav.pod...@ti.com writes:

 On Mon, Jul 30, 2012 at 3:04 PM, DebBarma, Tarun Kanti
 tarun.ka...@ti.com wrote:
 Sourav,

 On Mon, Jul 30, 2012 at 2:13 PM, Poddar, Sourav sourav.pod...@ti.com 
 wrote:
 Hi All,

 I tried using gpio as an interrupt line for my driver
 (drivers/staging/iio/light/tsl2x7x_core.c) for omap5.
 The interrupt line number was directly passed to the driver using
 device tree. But what I observed
 is the following crash..


 [1.599273] mousedev: PS/2 mouse device common for all mice
 [1.607513] i2c /dev entries driver
 [1.613739] Driver for 1-wire Dallas network protocol.
 [1.622650] usbcore: registered new interface driver usbhid
 [1.628540] usbhid: USB HID core driver
 [1.633728] Unhandled fault: imprecise external abort (0x1406) at 
 0x
 [1.641113] Internal error: : 1406 [#1] SMP ARM
 [1.645874] Modules linked in:
 [1.649078] CPU: 0Not tainted  (3.5.0-02045-g0b474d6-dirty #415)
 [1.655761] PC is at _set_gpio_triggering+0x44/0x264
 [1.660980] LR is at gpio_irq_type+0xb8/0x160
 [1.665527] pc : [c02dbb68]lr : [c02dc2dc]psr: 6093
 [1.665527] sp : dc851df0  ip : c07a8f00  fp : 
 [1.677581] r10: 0081  r9 :   r8 : dc8ffc10
 [1.683074] r7 : 2093  r6 :   r5 : 0001  r4 : fa05b000
 [1.689910] r3 : dc8ffc10  r2 : 0002  r1 : 0002  r0 : 0140
 [1.696746] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
 Segment kernel
 [1.704528] Control: 10c53c7d  Table: 8000406a  DAC: 0017
 [1.710540] Process swapper/0 (pid: 1, stack limit = 0xdc8502f8)
 [1.716857] Stack: (0xdc851df0 to 0xdc852000)
 [1.721405] 1de0: 0002
 c0731280 dc8ffc6c 2093
 [1.730010] 1e00: c02dc224 c0731280 dc8d4980  c07a8e50
 0141 0002 c00a37b8
 [1.738586] 1e20: 2002 c0731280 dc8d4980 0141 c07312d4
 c07312b4 4013 c00a3d7c
 [1.747161] 1e40: 0141 c06728c0  c0090578 c247f000
 c00a2d5c c0412258 0141
 [1.755737] 1e60: c0731280 c0537818 dc8d4980 c00a3fe4 c07bf6a0
 2002 c071bed8 c247f000
 [1.764312] 1e80: dc9df000 0004 c07bf6a0 dc9df020 c247f3c0
 c04ea344 c06728c0 c247f000
 [1.772888] 1ea0:  09090578 c07bf6a0 dc9df004 dc9df000
 c04ea194 0091 c071bed8
 [1.781494] 1ec0: c06f89f4 c03e13c0 c03e1314 dc9df020 c0d1afd8
 dc9df054 c07bf60c c03272ac
 [1.790069] 1ee0: dc9df020 c07bf60c dc9df054  0091
 c03274c0 c07bf60c dc851f08
 [1.798645] 1f00: c032742c c0325b10 dc8f26a8 dc9ef790 
 c07bf60c c07bcea8 c243d6c0
 [1.807220] 1f20:  c0326240 c0672958 c02bce08 c07bf5e4
 c07bf60c c03e12a0 
 [1.815795] 1f40: 0091 c071bed8 c06f89f4 c0327ab0 c07bf5e4
 0007 c07c8c40 
 [1.824401] 1f60: 0091 c03e1738  dc85 0007
 c0008648  c112c9f0
 [1.832977] 1f80: c06a6d58 c06f89f4 0001 6013 c06694c8
  0006 0006
 [1.841552] 1fa0: 6013 c0700a20 0007 c07c8c40 c06d020c
 0091 c071bed8 c0700a28
 [1.850128] 1fc0:  c06d0380 0006 0006 c06d020c
   c06d028c
 [1.858703] 1fe0: c001548c 0013   
 c001548c 3f3f3f3f 3f3f3f3f
 [1.867309] [c02dbb68] (_set_gpio_triggering+0x44/0x264) from
 [c02dc224] (gpio_irq_type+0x0/0x160)
 [1.877075] [c02dc224] (gpio_irq_type+0x0/0x160) from [2002] 
 (0x2002)
 [1.884552] Code: e3120008 11816006 01c66001 e7846000 (e593c0fc)
 [1.890960] [ cut here ]
 [1.895812] WARNING: at arch/arm/mach-omap2/omap_l3_noc.c:113
 l3_interrupt_handler+0x184/0x1bc()
 [1.905029] L3 custom error: MASTER:MPU TARGET:L4 PER2
 [1.910430] Modules linked in:
 [1.913635] [c001bd5c] (unwind_backtrace+0x0/0xf4) from
 [c00414c4] (warn_slowpath_common+0x4c/0x64)
 [1.923492] [c00414c4] (warn_slowpath_common+0x4c/0x64) from
 [c0041570] (warn_slowpath_fmt+0x30/0x40)
 [1.933563] [c0041570] (warn_slowpath_fmt+0x30/0x40) from
 [c0035de4] (l3_interrupt_handler+0x184/0x1bc)
 [1.943786] [c0035de4] (l3_interrupt_handler+0x184/0x1bc) from
 [c00a28b8] (handle_irq_event_percpu+0x64/0x24c)
 [1.954650] [c00a28b8] (handle_irq_event_percpu+0x64/0x24c) from
 [c00a2adc] (handle_irq_event+0x3c/0x5c)
 [1.964965] [c00a2adc] (handle_irq_event+0x3c/0x5c) from
 [c00a56a8] (handle_fasteoi_irq+0x98/0x13c)
 [1.974822] [c00a56a8] (handle_fasteoi_irq+0x98/0x13c) from
 [c00a235c] (generic_handle_irq+0x34/0x44)
 [1.984863] [c00a235c] (generic_handle_irq+0x34/0x44) from
 [c00153a0] (handle_IRQ+0x4c/0xac)
 [1.994110] [c00153a0] (handle_IRQ+0x4c/0xac) from [c0008480]
 (gic_handle_irq+0x2c/0x60)
 [2.002960] [c0008480] (gic_handle_irq+0x2c/0x60) from
 [c04f26e4] (__irq_svc+0x44/0x60)
 [2.011718] Exception stack(0xdc851c48 to 0xdc851c90)
 [   

Re: [PATCH] ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep

[Rajendra Nayak]

Hi Jon,

On Tuesday 31 July 2012 10:11 AM, Jon Hunter wrote:

Hi Paul, Rajendra,

On 07/27/2012 12:43 AM, Rajendra Nayak wrote:

On Friday 27 July 2012 02:34 AM, Paul Walmsley wrote:


Commit 4da71ae6 (OMAP: clockdomain: Arch specific funcs for
clkdm_clk_enable/disable) called the OMAP2xxx-specific functions for
clockdomain wakeup and sleep.  This would probably have broken
software-supervised clockdomain wakeup and sleep on OMAP3.


Its strange this went unnoticed for so long. Thanks for this fix and
sorry about introducing the bug in the first place.


Any chance that's because of the following code? I needed to
remove this to get the EMU clock domain to turn off on OMAP3
whilst testing PMU.


No, this doesn't seem right. We still have clockdomains for omap2/3
controlled using clkdm_clk_enable/disable functions called from
within clk framework, and not clkdm_hwmod_enable/disable from
within hwmod framework.
Besides you removing these checks only in clkdm_hwmod_disable (and
keeping them in clkdm_hwmod_enable) tells me its just hiding some
usecounting issues you were having with clkdm_clk_enable/disable.

Btw, on OMAP2/3 as long as a domain has interface clocks which are
explicitly enabled and autoidled, the clkdm usecount never ends up
going to 0, which is probably what you are hit with too.

regards,
Rajendra



Cheers
Jon

commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunterjon-hun...@ti.com
Date:   Mon Jul 30 18:04:06 2012 -0500

 ARM: OMAP2/3: Allow HWMOD to disable clock domains

 Currently when HWMOD attempts to disable a clock domain on OMAP2/3 devices 
we
 will return from the function clkdm_hwmod_disable() without actually 
disabling
 the clock domain. Per the comment this is deliberate because initially 
HWMOD
 OMAP2/3 devices did not support clock domains. However, clock domains are 
now
 supported by HWMOD for these devices and so allow HWMOD to disable the 
clock
 domains.

 XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 011186f..8f7a941 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
   */
  int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
  {
-   /* The clkdm attribute does not exist yet prior OMAP4 */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
-   return 0;
-
 /*
  * XXX Rewrite this code to maintain a list of enabled
  * downstream hwmods for debugging purposes?



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

Re: [PATCH v2] OMAPDSS: DISPC: Improve DIGIT channel sync signal selection

[Tomi Valkeinen]

On Mon, 2012-07-30 at 19:11 -0500, Ricardo Neri wrote:
 DSS code wrongly assumes that VENC is always available as source for the 
 external
 sync signal for the display controller DIGIT channel. One cannot blindly
 rely only on the value of DSS_CONTROL[15] as on certain processors (e.g., 
 OMAP5)
 reading/writing on that bit may not be valid. If the the sync source is not 
 read
 correctly, the callers of dss_get_hdmi_venc_clk_source might make wrong 
 assumptions
 about, for instance, video timings.
 
 This patch adds logic to correctly get the sync signal based on the
 available displays in the DIGIT channel. A kernel BUG is thrown if an
 invalid source is selected.
 
 Signed-off-by: Ricardo Neri ricardo.n...@ti.com
 ---
 v2: use BUG_ON() to simplify handling of invalid cases.
  drivers/video/omap2/dss/dss.c |   13 +++--
  1 files changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
 index 04b4586..2f8e4b6 100644
 --- a/drivers/video/omap2/dss/dss.c
 +++ b/drivers/video/omap2/dss/dss.c
 @@ -648,9 +648,15 @@ void dss_set_dac_pwrdn_bgz(bool enable)
   REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
  }
  
 -void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select 
 hdmi)
 +void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select 
 src)
  {
 - REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* VENC_HDMI_SWITCH */
 + enum omap_display_type dp;
 + dp = dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);
 +
 + BUG_ON((src == DSS_VENC_TV_CLK)  !(dp  OMAP_DISPLAY_TYPE_VENC));
 + BUG_ON((src == DSS_HDMI_M_PCLK)  !(dp  OMAP_DISPLAY_TYPE_HDMI));
 +
 + REG_FLD_MOD(DSS_CONTROL, src, 15, 15);  /* VENC_HDMI_SWITCH */
  }

This one will still write to the reserved bit 15 on OMAP5.

Perhaps we could check if both VENC and HDMI are supported, and if not,
return.

 Tomi



signature.asc
Description: This is a digitally signed message part