date:20121023

Hi Tero,

On Mon, 22 Oct 2012, Tero Kristo wrote:

 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.
 
 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com

What do you think about these modifications?  The code is quite similar to 
what was in the _ocp_softreset() function, so just moved it into a 
function.  Also moved the callsite from the end of _enable_sysc() to the 
beginning, which makes more sense to me, but would like to get your 
opinion.

- Paul

From: Tero Kristo t-kri...@ti.com
Date: Mon, 22 Oct 2012 19:15:32 +0300
Subject: [PATCH] [RFC] ARM: OMAP: hwmod: wait for sysreset complete after
 enabling hwmod

When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.

This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
to SYSCONFIG register), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Venkatraman S svenk...@ti.com
[p...@pwsan.com: moved softreset wait code into separate function; call
 from top of _enable_sysc() rather than the bottom]

---
 arch/arm/mach-omap2/omap_hwmod.c |   56 --
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 504e0e0..0356a09 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -423,6 +423,38 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
 }
 
 /**
+ * _wait_softreset_complete - wait for an OCP softreset to complete
+ * @oh: struct omap_hwmod * to wait on
+ *
+ * Wait until the IP block represented by @oh reports that its OCP
+ * softreset is complete.  This can be triggered by software (see
+ * _ocp_softreset()) or by hardware upon returning from off-mode (one
+ * example is HSMMC).  Waits for up to MAX_MODULE_SOFTRESET_WAIT
+ * microseconds.  Returns the number of microseconds waited.
+ */
+static int _wait_softreset_complete(struct omap_hwmod *oh)
+{
+   struct omap_hwmod_class_sysconfig *sysc;
+   u32 softrst_mask;
+   int c = 0;
+
+   sysc = oh-class-sysc;
+
+   if (sysc-sysc_flags  SYSS_HAS_RESET_STATUS)
+   omap_test_timeout((omap_hwmod_read(oh, sysc-syss_offs)
+   SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+   else if (sysc-sysc_flags  SYSC_HAS_RESET_STATUS) {
+   softrst_mask = (0x1  sysc-sysc_fields-srst_shift);
+   omap_test_timeout(!(omap_hwmod_read(oh, sysc-sysc_offs)
+softrst_mask),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+   }
+
+   return c;
+}
+
+/**
  * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
  * @oh: struct omap_hwmod *
  *
@@ -1283,6 +1315,14 @@ static void _enable_sysc(struct omap_hwmod *oh)
if (!oh-class-sysc)
return;
 
+   /*
+* Wait until reset has completed, this is needed as the IP
+* block is reset automatically by hardware in some cases
+* (off-mode for example), and the drivers require the
+* IP to be ready when they access it
+*/
+   _wait_softreset_complete(oh);
+
v = oh-_sysc_cache;
sf = oh-class-sysc-sysc_flags;
 
@@ -1805,7 +1845,7 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
  */
 static int _ocp_softreset(struct omap_hwmod *oh)
 {
-   u32 v, softrst_mask;
+   u32 v;
int c = 0;
int ret = 0;
 
@@ -1835,19 +1875,7 @@ static int _ocp_softreset(struct omap_hwmod *oh)
if (oh-class-sysc-srst_udelay)
udelay(oh-class-sysc-srst_udelay);
 
-   if (oh-class-sysc-sysc_flags  SYSS_HAS_RESET_STATUS)
-   omap_test_timeout((omap_hwmod_read(oh,
-   oh-class-sysc-syss_offs)
-   SYSS_RESETDONE_MASK),
- MAX_MODULE_SOFTRESET_WAIT, c);
-   else if (oh-class-sysc-sysc_flags  SYSC_HAS_RESET_STATUS) {
-

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

2012-10-23 Thread Ohad Ben-Cohen

On Tue, Oct 23, 2012 at 9:37 AM, Igor Grinberg grinb...@compulab.co.il wrote:
 + ret = wl12xx_set_platform_data(wlan_data);
 + /* bail out silently in case wl12xx isn't configured */
 + if (ret == -ENOSYS)
 + return ret;

 Since we have the function ifdef'ed, I don't think we need
 the ENOSYS check, do we?

If we want to be strict, we better not remove it.

It's an interface that hides the internal implementation, and it's
just better not to assume anything beyond the return values and their
meanings. This way if WLAN folks change something in the future, we
don't need to update all the boards code again.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe 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 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer

2012-10-23 Thread Wim Van Sebroeck

Hi Paul,

 The OMAP watchdog timer driver directly calls a function exported by
 code in arch/arm/mach-omap2.  This is not good; it tightly couples
 this driver to the mach-omap2 integration code.  Instead, add a
 temporary platform_data function pointer to abstract this function
 call.  A subsequent patch will convert the watchdog driver to use this
 function pointer.
 
 This patch also moves the device creation code out of
 arch/arm/mach-omap2/devices.c and into arch/arm/mach-omap2/wd_timer.c.
 This is another step towards the removal of
 arch/arm/mach-omap2/devices.c.
 
 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Wim Van Sebroeck w...@iguana.be

Signed-off-by: Wim Van Sebroeck w...@iguana.be

Kind regards,
Wim.

--
To unsubscribe from this list: send the line unsubscribe 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 6/7] watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr

2012-10-23 Thread Wim Van Sebroeck

Hi Paul,

 Previously the OMAP watchdog driver used a non-standard way to report
 the chip reset source via the GETBOOTSTATUS ioctl.  This patch
 converts the driver to use the standard WDIOF_* flags for this
 purpose.
 
 This patch may break existing userspace code that uses the existing
 non-standard data format returned by the OMAP watchdog driver's
 GETBOOTSTATUS ioctl.  To fetch detailed reset source information,
 userspace code will need to retrieve it directly from the CGRM or PRM
 drivers when those are completed.
 
 Previously, to fetch the reset source, the driver either read a
 register outside the watchdog IP block (OMAP1), or called a function
 exported directly from arch/arm/mach-omap2.  Both approaches are
 broken.  This patch also converts the driver to use a platform_data
 function pointer.  This approach is temporary, and is due to the lack
 of drivers for the OMAP16xx+ Clock Generation and Reset Management IP
 block and the OMAP2+ Power and Reset Management IP block.  Once
 drivers are available for those IP blocks, the watchdog driver can be
 converted to call exported drivers from those functions directly.
 At that point, the platform_data function pointer can be removed.
 
 In the short term, this patch is needed to allow the PRM code to be
 removed from arch/arm/mach-omap2 (it is being moved to a driver).
 
 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Wim Van Sebroeck w...@iguana.be

Signed-off-by: Wim Van Sebroeck w...@iguana.be

Kind regards,
Wim.

--
To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

2012-10-23 Thread Tero Kristo

Hi Paul,

On Tue, 2012-10-23 at 07:47 +, Paul Walmsley wrote:
 Hi Tero,
 
 On Mon, 22 Oct 2012, Tero Kristo wrote:
 
  When waking up from off-mode, some IP blocks are reset automatically by
  hardware. For this reason, software must wait until the reset has
  completed before attempting to access the IP block.
  
  This patch fixes for example the bug introduced by commit
  6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
  to SYSCONFIG register), in which the MMC IP block is reset during
  off-mode entry, but the code expects the module to be already available
  during the execution of context restore.
  
  Signed-off-by: Tero Kristo t-kri...@ti.com
  Cc: Paul Walmsley p...@pwsan.com
  Cc: Benoit Cousson b-cous...@ti.com
  Cc: Venkatraman S svenk...@ti.com
 
 What do you think about these modifications?  The code is quite similar to 
 what was in the _ocp_softreset() function, so just moved it into a 
 function.  Also moved the callsite from the end of _enable_sysc() to the 
 beginning, which makes more sense to me, but would like to get your 
 opinion.

Looks good to me. Only reason I pushed the reset wait to the end of the
function was a minimal potential timing optimization. As the beginning
of the function will write a register, it will consume a bit of time
(especially if in 32k domain), so it can maybe save a single register
read in the delay loop if ordered that way.

Your way is probably safer, it might cause problems in some cases if the
config is written before reset has completed (can it?)

-Tero

 
 - Paul
 
 From: Tero Kristo t-kri...@ti.com
 Date: Mon, 22 Oct 2012 19:15:32 +0300
 Subject: [PATCH] [RFC] ARM: OMAP: hwmod: wait for sysreset complete after
  enabling hwmod
 
 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.
 
 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com
 [p...@pwsan.com: moved softreset wait code into separate function; call
  from top of _enable_sysc() rather than the bottom]
 
 ---
  arch/arm/mach-omap2/omap_hwmod.c |   56 
 --
  1 file changed, 42 insertions(+), 14 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index 504e0e0..0356a09 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -423,6 +423,38 @@ static int _set_softreset(struct omap_hwmod *oh, u32 *v)
  }
  
  /**
 + * _wait_softreset_complete - wait for an OCP softreset to complete
 + * @oh: struct omap_hwmod * to wait on
 + *
 + * Wait until the IP block represented by @oh reports that its OCP
 + * softreset is complete.  This can be triggered by software (see
 + * _ocp_softreset()) or by hardware upon returning from off-mode (one
 + * example is HSMMC).  Waits for up to MAX_MODULE_SOFTRESET_WAIT
 + * microseconds.  Returns the number of microseconds waited.
 + */
 +static int _wait_softreset_complete(struct omap_hwmod *oh)
 +{
 + struct omap_hwmod_class_sysconfig *sysc;
 + u32 softrst_mask;
 + int c = 0;
 +
 + sysc = oh-class-sysc;
 +
 + if (sysc-sysc_flags  SYSS_HAS_RESET_STATUS)
 + omap_test_timeout((omap_hwmod_read(oh, sysc-syss_offs)
 + SYSS_RESETDONE_MASK),
 +   MAX_MODULE_SOFTRESET_WAIT, c);
 + else if (sysc-sysc_flags  SYSC_HAS_RESET_STATUS) {
 + softrst_mask = (0x1  sysc-sysc_fields-srst_shift);
 + omap_test_timeout(!(omap_hwmod_read(oh, sysc-sysc_offs)
 +  softrst_mask),
 +   MAX_MODULE_SOFTRESET_WAIT, c);
 + }
 +
 + return c;
 +}
 +
 +/**
   * _set_dmadisable: set OCP_SYSCONFIG.DMADISABLE bit in @v
   * @oh: struct omap_hwmod *
   *
 @@ -1283,6 +1315,14 @@ static void _enable_sysc(struct omap_hwmod *oh)
   if (!oh-class-sysc)
   return;
  
 + /*
 +  * Wait until reset has completed, this is needed as the IP
 +  * block is reset automatically by hardware in some cases
 +  * (off-mode for example), and the drivers require the
 +  * IP to be ready when they access it
 +  */
 + _wait_softreset_complete(oh);
 +
   v = oh-_sysc_cache;
   sf = oh-class-sysc-sysc_flags;
  
 @@ -1805,7 +1845,7 @@ static int _am33xx_disable_module(struct omap_hwmod *oh)
   */
  static int _ocp_softreset(struct omap_hwmod *oh)
  {
 - u32 v, softrst_mask;
 + u32 v;
   int c = 0;

Re: [PATCH 5/7] ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer (fwd)

2012-10-23 Thread Wim Van Sebroeck

Hi Paul,

 When you have the opportunity, could you take a look at this patch, and 
 the subsequent patch 6/7, and ack them if you're okay with them?

Signed them off, Acked-by would probably have been better :-).

 We'd like to merge thse as part of a larger cleanup series through the 
 arm-soc tree.  They like cleanup patches to arrive at the beginning of the 
 -rc series, which means that we need to have the pull request sent pretty 
 soon.

Please go ahead. The sooner those ifdefs are gone the better.

Kind regards,
Wim.
--
To unsubscribe from this list: send the line unsubscribe 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 0/4] ARM: dts: Update OMAP5 with address space and interrupts

Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the 
address space
and interrupt line description inside dtsi file for OMAP5. This serie is 
updating the
current OMAP5 IP with missing entry.

It has been tested on OMAP5 with 3.7-audio-display feature tree.
- MMC is probing and functional
- TWL6041 probing (GPIO/I2C)
- booting (UART)

Update since v1:
- Add Ack and review
- Fix up commit messages.

Sebastien Guiriec (4):
  ARM: dts: omap5: Update GPIO with address space and interrupts
  ARM: dts: omap5: Update I2C with address space and interrupts
  ARM: dts: omap5: Update UART with address space and interrupts
  ARM: dts: omap5: Update MMC with address space and interrupts

 arch/arm/boot/dts/omap5.dtsi |   56 +++---
 1 file changed, 52 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 2/4] ARM: dts: omap5: Update I2C with address space and interrupts

Add base address and interrupt line inside Device Tree data for
OMAP5

Signed-off-by: Sebastien Guiriec s-guir...@ti.com
Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9e39f9f..6c22e1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -192,6 +192,8 @@
 
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
+   reg = 0x4807 0x100;
+   interrupts = 0 56 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c1;
@@ -199,6 +201,8 @@
 
i2c2: i2c@48072000 {
compatible = ti,omap4-i2c;
+   reg = 0x48072000 0x100;
+   interrupts = 0 57 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c2;
@@ -206,20 +210,26 @@
 
i2c3: i2c@4806 {
compatible = ti,omap4-i2c;
+   reg = 0x4806 0x100;
+   interrupts = 0 61 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c3;
};
 
-   i2c4: i2c@4807A000 {
+   i2c4: i2c@4807a000 {
compatible = ti,omap4-i2c;
+   reg = 0x4807a000 0x100;
+   interrupts = 0 62 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c4;
};
 
-   i2c5: i2c@4807C000 {
+   i2c5: i2c@4807c000 {
compatible = ti,omap4-i2c;
+   reg = 0x4807c000 0x100;
+   interrupts = 0 60 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c5;
-- 
1.7.10.4

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

[PATCH v2 4/4] ARM: dts: omap5: Update MMC with address space and interrupts

Add base address and interrupt line inside Device Tree data for
OMAP5.

Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 413df94..b643cd3 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -285,6 +285,8 @@
 
mmc1: mmc@4809c000 {
compatible = ti,omap4-hsmmc;
+   reg = 0x4809c000 0x400;
+   interrupts = 0 83 0x4;
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
@@ -292,24 +294,32 @@
 
mmc2: mmc@480b4000 {
compatible = ti,omap4-hsmmc;
+   reg = 0x480b4000 0x400;
+   interrupts = 0 86 0x4;
ti,hwmods = mmc2;
ti,needs-special-reset;
};
 
mmc3: mmc@480ad000 {
compatible = ti,omap4-hsmmc;
+   reg = 0x480ad000 0x400;
+   interrupts = 0 94 0x4;
ti,hwmods = mmc3;
ti,needs-special-reset;
};
 
mmc4: mmc@480d1000 {
compatible = ti,omap4-hsmmc;
+   reg = 0x480d1000 0x400;
+   interrupts = 0 96 0x4;
ti,hwmods = mmc4;
ti,needs-special-reset;
};
 
mmc5: mmc@480d5000 {
compatible = ti,omap4-hsmmc;
+   reg = 0x480d5000 0x400;
+   interrupts = 0 59 0x4;
ti,hwmods = mmc5;
ti,needs-special-reset;
};
-- 
1.7.10.4

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

[PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

Add base address and interrupt line inside Device Tree data for
OMAP5

Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@
 
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
+   reg = 0x4ae1 0x200;
+   interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -113,6 +115,8 @@
 
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
+   reg = 0x48055000 0x200;
+   interrupts = 0 30 0x4;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -122,6 +126,8 @@
 
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
+   reg = 0x48057000 0x200;
+   interrupts = 0 31 0x4;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -131,6 +137,8 @@
 
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
+   reg = 0x48059000 0x200;
+   interrupts = 0 32 0x4;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -140,6 +148,8 @@
 
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
+   reg = 0x4805b000 0x200;
+   interrupts = 0 33 0x4;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -149,6 +159,8 @@
 
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
+   reg = 0x4805d000 0x200;
+   interrupts = 0 34 0x4;
ti,hwmods = gpio6;
gpio-controller;
#gpio-cells = 2;
@@ -158,6 +170,8 @@
 
gpio7: gpio@48051000 {
compatible = ti,omap4-gpio;
+   reg = 0x48051000 0x200;
+   interrupts = 0 35 0x4;
ti,hwmods = gpio7;
gpio-controller;
#gpio-cells = 2;
@@ -167,6 +181,8 @@
 
gpio8: gpio@48053000 {
compatible = ti,omap4-gpio;
+   reg = 0x48053000 0x200;
+   interrupts = 0 121 0x4;
ti,hwmods = gpio8;
gpio-controller;
#gpio-cells = 2;
-- 
1.7.10.4

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

[PATCH v2 3/4] ARM: dts: omap5: Update UART with address space and interrupts

Add base address and interrupt line inside Device Tree data for
OMAP5.

Signed-off-by: Sebastien Guiriec s-guir...@ti.com
Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi |   16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413df94 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -237,36 +237,48 @@
 
uart1: serial@4806a000 {
compatible = ti,omap4-uart;
+   reg = 0x4806a000 0x100;
+   interrupts = 0 72 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
};
 
uart2: serial@4806c000 {
compatible = ti,omap4-uart;
+   reg = 0x4806c000 0x100;
+   interrupts = 0 73 0x4;
ti,hwmods = uart2;
clock-frequency = 4800;
};
 
uart3: serial@4802 {
compatible = ti,omap4-uart;
+   reg = 0x4802 0x100;
+   interrupts = 0 74 0x4;
ti,hwmods = uart3;
clock-frequency = 4800;
};
 
uart4: serial@4806e000 {
compatible = ti,omap4-uart;
+   reg = 0x4806e000 0x100;
+   interrupts = 0 70 0x4;
ti,hwmods = uart4;
clock-frequency = 4800;
};
 
uart5: serial@48066000 {
-   compatible = ti,omap5-uart;
+   compatible = ti,omap4-uart;
+   reg = 0x48066000 0x100;
+   interrupts = 0 105 0x4;
ti,hwmods = uart5;
clock-frequency = 4800;
};
 
uart6: serial@48068000 {
-   compatible = ti,omap6-uart;
+   compatible = ti,omap4-uart;
+   reg = 0x48068000 0x100;
+   interrupts = 0 106 0x4;
ti,hwmods = uart6;
clock-frequency = 4800;
};
-- 
1.7.10.4

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 Hi Sourav,

 On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
 Adapt keypad to use pinctrl framework.

 Tested on omap4430 sdp with 3.7-rc1 kernel.

 I do not see anything in the driver that would directly use pinctrl. Is
 there a better place to select default pin configuration; maybe when
 instantiating platform device?

The option is to use pinctrl hogs. Then the pins will be taken,
muxed and configured by the pin controller itself.

Another option (not implemented) is to use bus notifiers.

(I wrote about this in some other thread but can't find it now.)

Each approach above come with its own set of problems.

If the driver need to handle multiple states like default/idle/sleep
it is IMO better to put the handling into the driver, so if that
is what is going to happen also to this driver it could be a good
idea to actually implement that code upfront and include in
this submission so as to show that this driver is really going
to exercise its pins.

But it's also a question of conformity: if other drivers in the
system is using different states and this is the only one
using a single default state, then it doesn't make sense
to have just one driver get its pins using hogs, it's just
inconsistent.

So Sourav, please tell us a bit about your plans for this
and other drivers!

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi Dimitry,

On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
 Hi Sourav,
 
 On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
 Adapt keypad to use pinctrl framework.

 Tested on omap4430 sdp with 3.7-rc1 kernel.
 
 I do not see anything in the driver that would directly use pinctrl. Is
 there a better place to select default pin configuration; maybe when
 instantiating platform device?

Why?
The devm_pinctrl_get_select_default is using the pinctrl.
That's why it is named get_select_default and not get only.
This API ensure that the pin will be set to the default state, and this
is all we need to do during the probe.

There is no point to change the mux if the driver is not probed, because
potentially the pin can be use be another driver.
So probe is the right place to do that for my point of view. Moreover
with DT we don't have that board static config like we had before to do
that kind of pin mux init.

But, maybe I'm missing your point.

Regards,
Benoit


 
 Thanks.
 

 Cc: Felipe Balbi ba...@ti.com
 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 v1-v2
 - Added PROBE_DEFER check 
  drivers/input/keyboard/omap4-keypad.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

 diff --git a/drivers/input/keyboard/omap4-keypad.c 
 b/drivers/input/keyboard/omap4-keypad.c
 index c05f98c..502b832 100644
 --- a/drivers/input/keyboard/omap4-keypad.c
 +++ b/drivers/input/keyboard/omap4-keypad.c
 @@ -31,6 +31,7 @@
  #include linux/input.h
  #include linux/slab.h
  #include linux/pm_runtime.h
 +#include linux/pinctrl/consumer.h
  
  #include linux/platform_data/omap4-keypad.h
  
 @@ -76,6 +77,7 @@ enum {
  
  struct omap4_keypad {
  struct input_dev *input;
 +struct pinctrl  *pins;
  
  void __iomem *base;
  unsigned int irq;
 @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct 
 platform_device *pdev)
  goto err_release_mem;
  }
  
 +keypad_data-pins = devm_pinctrl_get_select_default(pdev-dev);
 +if (IS_ERR(keypad_data-pins)) {
 +if (PTR_ERR(keypad_data-pins) == -EPROBE_DEFER)
 +return -EPROBE_DEFER;
 +
 +dev_warn(pdev-dev, did not get pins for keypad error: %li\n,
 +PTR_ERR(keypad_data-pins));
 +keypad_data-pins = NULL;
 +}
  
  /*
   * Enable clocks for the keypad module so that we can read
 -- 
 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: RT throttling and suspend/resume (was Re: [PATCH] i2c: omap: revert i2c: omap: switch to threaded IRQ support)

2012-10-23 Thread Russell King - ARM Linux

On Mon, Oct 22, 2012 at 09:47:06AM -0700, Kevin Hilman wrote:
 Peter Zijlstra pet...@infradead.org writes:
 
  On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
 
  So I did the same thing for my ARM SoC, and it definitley stops the RT
  throttling.  
  
  However, it has the undesriable (IMO) side effect of making timed printk
  output rather unhelpful for debugging suspend/resume since printk time
  stays constant throughout suspend/resume no matter how long you
  sleep. :(
  
  So does that mean we have to choose between useful printk times during
  suspend/resume or functioning IRQ threads during suspend/resume ?
 
  Urgh.. this was not something I considered. This being primarily the
  sched_clock infrastructure and such.
 
  So what exactly is the problem with the suspend resume thing (its not
  something I've ever debugged), is all you need a clean break between pre
  and post suspend, or do you need the actual time the machine was gone?
 
 I think it's more a question of what people are used to.  I think folks
 used to debugging suspend/resume (at least on ARM) are used to having
 the printk timestamps reflect the amount of time the machine was gone.
 
 With a sched_clock() that counts during suspend, that feature doesn't
 work anymore.  I'm not sure that this feature is a deal breaker, but it
 has been convenient.

IMHO, this isn't a deal breaker, it's nothing more than cosmetic issue.
The big hint about the sched_clock() behaviour is partly in the name,
and the behaviour you get from the scheduler if you don't give it what
it wants.  The scheduler sets the requirements for sched_clock(), not
printk, so if we have to fix sched_clock() to get correct behaviour
from the scheduler, that's what we have to do irrespective of cosmetic
printk issues.

And there are many other ways to measure time off in suspend... we have
at least three other functions which return time, and which will return
updated time after a resume event.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi Linus,

On 10/23/2012 11:13 AM, Linus Walleij wrote:
 On Mon, Oct 22, 2012 at 5:50 PM, Dmitry Torokhov
 dmitry.torok...@gmail.com wrote:
 Hi Sourav,

 On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
 Adapt keypad to use pinctrl framework.

 Tested on omap4430 sdp with 3.7-rc1 kernel.

 I do not see anything in the driver that would directly use pinctrl. Is
 there a better place to select default pin configuration; maybe when
 instantiating platform device?
 
 The option is to use pinctrl hogs. Then the pins will be taken,
 muxed and configured by the pin controller itself.
 
 Another option (not implemented) is to use bus notifiers.
 
 (I wrote about this in some other thread but can't find it now.)
 
 Each approach above come with its own set of problems.
 
 If the driver need to handle multiple states like default/idle/sleep
 it is IMO better to put the handling into the driver, so if that
 is what is going to happen also to this driver it could be a good
 idea to actually implement that code upfront and include in
 this submission so as to show that this driver is really going
 to exercise its pins.
 
 But it's also a question of conformity: if other drivers in the
 system is using different states and this is the only one
 using a single default state, then it doesn't make sense
 to have just one driver get its pins using hogs, it's just
 inconsistent.
 
 So Sourav, please tell us a bit about your plans for this
 and other drivers!

Yeah, this idea is to handle pinctrl from all the drivers, and
potentially change the mode during suspend when it is relevant.

Regards,
Benoit

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

Re: [PATCH 6/6] OMAPDSS: HDMI: Create platform device to support audio

2012-10-23 Thread Tomi Valkeinen

On 2012-10-23 03:48, Ricardo Neri wrote:

 +#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
 +#define HDMI_AUDIO_MEM_RESOURCE 0
 +#define HDMI_AUDIO_DMA_RESOURCE 1

 I don't see much point with these definitions. They are hdmi.c internal,
 so the audio driver can't use them, and so they aren't really fixed.
 
 I just thought it could make the code more readable; but if the
 resources array is going to be local, then they are not helpful.

My point was that if the defines as hdmi.c internal, you need to add the
same defines into the audio code also in order to use them. And then
we'd have the same defines in two places.

Or, if audio code doesn't need them to parse the resources, then they
aren't really relevant here either, as you are just adding two resources
to the array, and their order is not important.

 So, how will this work? All the audio related functions will be removed
 from the (video) hdmi driver, and the audio driver will access the
 registers independently? The audio driver will still need to access the
 video parts, right?
 That could be a new approach, but the idea here is to continue having an
 omapdss audio interface for audio drivers to use.

Ok. Do you have a git tree with the audio code working with this
approach? Or can you just copy paste a few lines showing how the audio
driver uses this. It'd be easier to understand by seeing that side of
the code also.

The audio uses sDMA for the transfer?

 The root problem that I am trying to address is that the omapdss audio
 interface does not have functionality for DMA transfer of audio samples
 to the HDMI IP. Also, I am not sure how that could be done without
 duplicating the functionality that ASoC already provides.

Ok. But the audio driver still needs access to the HDMI registers? I'm
not worried about passing the DMA resource. Video side doesn't use that.
But video side uses the registers, and both having the same ioremapped
area could possibly lead both writing to the same register. Or perhaps
not the same register, but still doing conflicting things at the hw
level at the same time.

 I feel a bit uneasy about giving the same ioremapped register space to
 two independent drivers... If we could split the registers to video and
 audio parts, each driver only ioremapping their respective registers,
 it'd be much better.
 
 Fwiw, the audio drivers (at least my audio drivers) will not ioremap.
 They will just take the DMA request number and port. Maybe spliting the
 register space into audio and video is not practical as we would endup
 having many tiny address spaces.

Yes, if there's no clear HDMI block division for video and audio, then
it doesn't sound good to split them up if we'd have lots of small
address spaces.

What registers does the audio side need to access? Why are part of the
registers accessed via the hdmi driver API, and some directly? I imagine
it'd be better to do either one of those, but not both.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

2012-10-23 Thread Igor Grinberg



On 10/23/12 09:51, Ohad Ben-Cohen wrote:
 On Tue, Oct 23, 2012 at 9:37 AM, Igor Grinberg grinb...@compulab.co.il 
 wrote:
 + ret = wl12xx_set_platform_data(wlan_data);
 + /* bail out silently in case wl12xx isn't configured */
 + if (ret == -ENOSYS)
 + return ret;

 Since we have the function ifdef'ed, I don't think we need
 the ENOSYS check, do we?
 
 If we want to be strict, we better not remove it.
 
 It's an interface that hides the internal implementation, and it's
 just better not to assume anything beyond the return values and their
 meanings. This way if WLAN folks change something in the future, we
 don't need to update all the boards code again.

Well, with this argument, we can add this (and many other checks) to
many more places in the code...
I just wanted to point out that most probably ret == -ENOSYS will
never happen since the #ifdef is added, but no problem from my side,
it does not hurt to have 4 more lines just in case, right?

Thanks for the patch and the explanation!

You have my ack already...

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson b-cous...@ti.com wrote:
 On 10/23/2012 11:13 AM, Linus Walleij wrote:

 So Sourav, please tell us a bit about your plans for this
 and other drivers!

 Yeah, this idea is to handle pinctrl from all the drivers, and
 potentially change the mode during suspend when it is relevant.

I'm leaning toward the same approach for ux500.

But it appears that shmobile prefer to get all resources using
bus notifiers.

So we need to form some kind of consensus ... or live with
the fact that different systems do it different ways. Which will
explode the day we need to use a driver on two systems,
each using the other approach :-)

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi,

On Tue, Oct 23, 2012 at 12:04:01PM +0200, Linus Walleij wrote:
 On Tue, Oct 23, 2012 at 11:35 AM, Benoit Cousson b-cous...@ti.com wrote:
  On 10/23/2012 11:13 AM, Linus Walleij wrote:
 
  So Sourav, please tell us a bit about your plans for this
  and other drivers!
 
  Yeah, this idea is to handle pinctrl from all the drivers, and
  potentially change the mode during suspend when it is relevant.
 
 I'm leaning toward the same approach for ux500.
 
 But it appears that shmobile prefer to get all resources using
 bus notifiers.
 
 So we need to form some kind of consensus ... or live with
 the fact that different systems do it different ways. Which will
 explode the day we need to use a driver on two systems,
 each using the other approach :-)

I much prefer having drivers explicitly manage all their resources,
which would mean that pinctrl calls need to be done on probe() and, if
necessary, during suspend()/resume().

Using bus notifiers for that is quite a hack IMHO.

-- 
balbi


signature.asc
Description: Digital signature

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

2012-10-23 Thread Russell King - ARM Linux

On Fri, Oct 12, 2012 at 04:54:34PM +0100, Russell King - ARM Linux wrote:
 For those who don't bother looking at my kautobuild boot tests on the OMAP
 boards I have, here's the errors which get spat out at boot time.  Note
 that some of these I've reported in the past, and one of them is missing
 a newline character at the end of its string.
 
 twd: can't register interrupt 45 (-22)
 twd_local_timer_register failed -22
 omap_hwmod: mcpdm: cannot be enabled for reset (3)
 omap-gpmc omap-gpmc: error: clk_get
 omap-gpmc: probe of omap-gpmc failed with error -2
 Error setting wl12xx data: -38
 omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
 omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
 omap_hsmmc omap_hsmmc.4: Failed to get debounce clk
 twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file
 omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
 omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels 
 (0).Power Management for TI OMAP4.
 mmc1: host does not support reading read-only switch. assuming write-enable.

Here's the latest set of error like messages, thanks to the kautobuild
system:

omap_hwmod: mcpdm: cannot be enabled for reset (3)
Error setting wl12xx data: -38
omap_hsmmc omap_hsmmc.1: Failed to get debounce clk
omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
omap_hsmmc omap_hsmmc.4: Failed to get debounce clk
omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0).
omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels 
(0).Power Management for TI OMAP4.
mmc1: host does not support reading read-only switch. assuming write-enable.

This looks much better compared to the previous set, but we could still
do with getting a \n on at least one of those messages...
--
To unsubscribe from this list: send the line unsubscribe 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: sched: stop sched_clock() during suspend

On Mon, Oct 22, 2012 at 1:54 PM, Felipe Balbi ba...@ti.com wrote:

 The scheduler imposes a requirement to sched_clock()
 which is to stop the clock during suspend, if we don't
 do that IRQ threads will be rescheduled in the future
 which might cause transfers to timeout depending on
 how driver is written.

 This became an issue on OMAP when we converted omap-i2c.c
 to use threaded IRQs, it turned out that depending on how
 much time we spent on suspend, the I2C IRQ thread would
 end up being rescheduled so far in the future that I2C
 transfers would timeout and, because omap_hsmmc depends
 on an I2C-connected device to detect if an MMC card is
 inserted in the slot, our rootfs would just vanish.

 arch/arm/kernel/sched_clock.c already had an optional
 implementation (sched_clock_needs_suspend()) which would
 handle scheduler's requirement properly, what this patch
 does is simply to make that implementation non-optional.

 This has been tested with beagleboard XM (OMAP3630) and
 pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
 after this patch.

 Signed-off-by: Felipe Balbi ba...@ti.com

After Russell explains so I get it:
Acked-by: Linus Walleij linus.wall...@linaro.org

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe 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: Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio

2012-10-23 Thread Hiremath, Vaibhav

On Fri, Oct 19, 2012 at 11:46:30, Richard Cochran wrote:
 On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
  
  Another important point is, this driver is also required and used for
  Davinci family of devices (arch/mach/mach-davinci/).
 
 That is really beside the point. If the code isn't ready yet, then
 don't merge it.
 

With respect to AM33xx the driver may not be ready, but that doesn't mean 
driver itself is not ready. As I mentioned before, driver is used on davinci 
platform and it could be functional there. 

In case of AM33xx, where DT only boot mode is supported, you are forced to 
migrate driver to DT, which is addition to the driver.

Note that, all the patches you have posted recently are AM33xx SoC 
integration specific patches.

 When I asked about the beaglebone, I was given the impression that it
 will be ready for v3.7-rc1.  But, as I know realize, at the current
 rate, it might not even be ready for v3.8.
 

I understand, and as you mentioned we are not fully there at v3.7-rc1 with 
all the drivers/module support, due to all known reasons. Its good that with 
v3.7-rc2, Beaglebone boots up out of box from mainline. 


Thanks,
Vaibhav
 I don't mind waiting, but please make sure that whatever lands into a
 release is really, truly working.
 
 Thanks,
 Richard
 
 
 

--
To unsubscribe from this list: send the line unsubscribe 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/4] mtd: nand: omap2: Update nerrors using ecc.strength

2012-10-23 Thread Philip, Avinash

On Tue, Oct 16, 2012 at 00:26:40, Peter Korsgaard wrote:
  Philip, Avinash avinashphi...@ti.com writes:
 
   Update number of errors using nand ecc strength.
   Also add macro definitions BCH8_ERROR_MAX  BCH4_ERROR_MAX
 
   Signed-off-by: Philip, Avinash avinashphi...@ti.com
   ---
   :100644 100644 5b31386... af511a9... M drivers/mtd/nand/omap2.c
drivers/mtd/nand/omap2.c |   12 
1 files changed, 8 insertions(+), 4 deletions(-)
 
   diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
   index 5b31386..af511a9 100644
   --- a/drivers/mtd/nand/omap2.c
   +++ b/drivers/mtd/nand/omap2.c
   @@ -111,6 +111,9 @@
#define   ECCCLEAR0x100
#define   ECC10x1
  
   +#define BCH8_MAX_ERROR8   /* upto 8 bit coorectable */
   +#define BCH4_MAX_ERROR4   /* upto 4 bit correctable */
 
 First 'correctable' misspelled.

I will correct it

 
 I don't personally think these defines improve readability very much
 compared to to just using 4/8, though.

Thought of removing magic numbers  provide information also.

Thanks
Avinash

 
 -- 
 Bye, Peter Korsgaard
 

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

RE: [PATCH 2/4] mtd: devices: elm: Add support for ELM error correction

2012-10-23 Thread Philip, Avinash

On Tue, Oct 16, 2012 at 01:10:47, Peter Korsgaard wrote:
  Philip, Avinash avinashphi...@ti.com writes:
 
   Platforms containing the ELM module can be used to correct errors
   reported by BCH 4, 8  16 bit ECC scheme. For now only 4  8 bit
   support is added.
 
 This sounds odd to me. What about something like:
 
 The ELM hardware module can be used to speedup BCH 4/8/16 ECC scheme
 error correction.
 
 For now only 4  8 bit support is added.

Ok I will correct it.

 
 
   +++ b/drivers/mtd/devices/Makefile
   @@ -17,8 +17,10 @@ obj-$(CONFIG_MTD_LART)  += lart.o
obj-$(CONFIG_MTD_BLOCK2MTD)   += block2mtd.o
obj-$(CONFIG_MTD_DATAFLASH)   += mtd_dataflash.o
obj-$(CONFIG_MTD_M25P80)  += m25p80.o
   +obj-$(CONFIG_MTD_NAND_OMAP2)  += elm.o
 
 You seem to only use it in 4/4 if CONFIG_MTD_NAND_OMAP_BCH is set, so it
 probably makes more sense to use that symbol to not needlessly include
 it if it won't be used.

Ok. This been good.

 
 
   +static void elm_write_reg(void *offset, u32 val)
   +{
   +  writel(val, offset);
   +}
   +
   +static u32 elm_read_reg(void *offset)
   +{
   +  return readl(offset);
   +}
 
 As written these read/write wrappers don't add anything. How about
 passing struct elm_info and offset as an integer so you can drop
 elm_base from all call sites, E.G.:
 
 static void elm_write_reg(struct elm_info *info, int offset, u32 val)
 {
 writel(val, info-elm_base + offset);
 }


Ok, this helps to reduce some indentation levels also.
 
 
   +void elm_decode_bch_error_page(struct device *dev, u8 *ecc_calc,
   +  struct elm_errorvec *err_vec)
   +{
   +  int i;
   +  u8 syndrome[BCH_MAX_ECC_BYTES_PER_SECTOR] = {0}, *syn_p;
 
 
 Why do you need to keep the entire syndrome around? You seem to only use
 it between elm_reverse_eccdata() and elm_load_syndrome(), so it could as
 well be BCH8_ECC_OOB_BYTES long (or rather a multiple of sizeof(u32).
 
 It would also be good to do the shuffeling directly in elm_load_syndrome
 so you don't need the extra copy.

I will check.

 
 
   + */
   +
   +#ifndef __ELM_H
   +#define __ELM_H
   +
   +enum bch_ecc {
   +  BCH4_ECC = 0,
   +  BCH8_ECC,
   +  BCH16_ECC,
 
 It probably makes more sense to not provide the enum value for BCH16 as
 you don't support it.
 

Ok I will remove.

 
   +};
   +

Thanks
Avinash


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

RE: [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme

2012-10-23 Thread Philip, Avinash

On Tue, Oct 16, 2012 at 00:18:30, Peter Korsgaard wrote:
  Philip, Avinash avinashphi...@ti.com writes:
 
   Add support for BCH ECC scheme to gpmc driver and also enabling multi
   sector read/write. This helps in doing single shot NAND page read and
   write.
 
   ECC engine configurations
   BCH 4 bit support
   1. write = ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
   2. read  = ECC engine configured in wrap mode 1 and with ecc_size0 as
   13 and ecc_size1 as 1.
 
   BCH 8 bit support
   1. write = ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
   2. read  = ECC engine configured in wrap mode 1 and with ecc_size0 as
   26 and ecc_size1 as 2.
 
   Note: For BCH8 ECC bytes set to 14 to make compatible with RBL.
 
 On what device? In the am335x TRM (spruh73f.pdf) figure 26-15 (pg 4273)
 the rom code is documented to not use any padding on the ECC bytes
 (E.G. oob 2..53):
 
 http://www.ti.com/litv/pdf/spruh73f
 
 I see the driver in the u-boot-am33x tree (ti81xx_nand.c) seems to use
 4x14 bytes as well though, so perhaps that's a bug in the documentation
 instead?

Yes, RBL uses 4x14 bytes.

Thanks
Avinash

 
 -- 
 Bye, Peter Korsgaard
 

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Thomas Petazzoni


On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:

  But it appears that shmobile prefer to get all resources using
  bus notifiers.
  
  So we need to form some kind of consensus ... or live with
  the fact that different systems do it different ways. Which will
  explode the day we need to use a driver on two systems,
  each using the other approach :-)
 
 I much prefer having drivers explicitly manage all their resources,
 which would mean that pinctrl calls need to be done on probe() and, if
 necessary, during suspend()/resume().
 
 Using bus notifiers for that is quite a hack IMHO.

Agreed. Just like drivers do their ioremap, request_irq and others,
they should also request their pin resources using the pinctrl API.
Hiding this behind a bus notifier is not nice.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:

 On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:

  But it appears that shmobile prefer to get all resources using
  bus notifiers.
 
  So we need to form some kind of consensus ... or live with
  the fact that different systems do it different ways. Which will
  explode the day we need to use a driver on two systems,
  each using the other approach :-)

 I much prefer having drivers explicitly manage all their resources,
 which would mean that pinctrl calls need to be done on probe() and, if
 necessary, during suspend()/resume().

 Using bus notifiers for that is quite a hack IMHO.

 Agreed. Just like drivers do their ioremap, request_irq and others,
 they should also request their pin resources using the pinctrl API.
 Hiding this behind a bus notifier is not nice.

So the biggest implementation of the notifier approach to resource
handling is the SH clock thing:
drivers/base/power/clock_ops.c

It's made to be generic but AFAICT only SH is using this.

So according to that paradigm most device resources should
be handled that way if I understand correctly the basic idea.

So let's get Rafael, Paul and Magnus in here to beat us up
a bit :-)

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi,

On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
 On Tue, Oct 23, 2012 at 12:23 PM, Thomas Petazzoni
 thomas.petazz...@free-electrons.com wrote:
 
  On Tue, 23 Oct 2012 13:03:33 +0300, Felipe Balbi wrote:
 
   But it appears that shmobile prefer to get all resources using
   bus notifiers.
  
   So we need to form some kind of consensus ... or live with
   the fact that different systems do it different ways. Which will
   explode the day we need to use a driver on two systems,
   each using the other approach :-)
 
  I much prefer having drivers explicitly manage all their resources,
  which would mean that pinctrl calls need to be done on probe() and, if
  necessary, during suspend()/resume().
 
  Using bus notifiers for that is quite a hack IMHO.
 
  Agreed. Just like drivers do their ioremap, request_irq and others,
  they should also request their pin resources using the pinctrl API.
  Hiding this behind a bus notifier is not nice.
 
 So the biggest implementation of the notifier approach to resource
 handling is the SH clock thing:
 drivers/base/power/clock_ops.c

that's different right ? It's just creating the list of clocks, device
drivers still have to call pm_clk_add().

That's ok, I guess, otherwise all struct device would allocate memory
which hardly ever used (so far).

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi ba...@ti.com wrote:
 On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:

 So the biggest implementation of the notifier approach to resource
 handling is the SH clock thing:
 drivers/base/power/clock_ops.c

 that's different right ? It's just creating the list of clocks, device
 drivers still have to call pm_clk_add().

 That's ok, I guess, otherwise all struct device would allocate memory
 which hardly ever used (so far).

Hm so I have had this idea of runtime PM core helping out
with pins, so I could add something like

pm_pins_fetch()
pm_pins_default()
pm_pins_idle()
pm_pins_sleep()

So if one is using the pin states defined in linux/pinctrl/pinctrl-state.h
then the PM core can help out in keeping track of the pins
and states, and the driver will just tell the PM core what
to do and when.

Would this fit the bill for everyone's code consolidation needs?
It would sure work for us...

It however require that no custom states are used and that we
keep to the state semantics I just happen to think is most
common.

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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi,

On Tue, Oct 23, 2012 at 12:45:33PM +0200, Linus Walleij wrote:
 On Tue, Oct 23, 2012 at 12:29 PM, Felipe Balbi ba...@ti.com wrote:
  On Tue, Oct 23, 2012 at 12:29:28PM +0200, Linus Walleij wrote:
 
  So the biggest implementation of the notifier approach to resource
  handling is the SH clock thing:
  drivers/base/power/clock_ops.c
 
  that's different right ? It's just creating the list of clocks, device
  drivers still have to call pm_clk_add().
 
  That's ok, I guess, otherwise all struct device would allocate memory
  which hardly ever used (so far).
 
 Hm so I have had this idea of runtime PM core helping out
 with pins, so I could add something like
 
 pm_pins_fetch()
 pm_pins_default()
 pm_pins_idle()
 pm_pins_sleep()
 
 So if one is using the pin states defined in linux/pinctrl/pinctrl-state.h
 then the PM core can help out in keeping track of the pins
 and states, and the driver will just tell the PM core what
 to do and when.
 
 Would this fit the bill for everyone's code consolidation needs?
 It would sure work for us...
 
 It however require that no custom states are used and that we
 keep to the state semantics I just happen to think is most
 common.

From a quick read, it looks ok. I guess problems will only how up when
we actually end up with a silicon errata or something similar which
mandates that we change pin's state at a particular location. Not sure
if we have those yet.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Thomas Petazzoni


On Tue, 23 Oct 2012 12:45:33 +0200, Linus Walleij wrote:

 Hm so I have had this idea of runtime PM core helping out
 with pins, so I could add something like
 
 pm_pins_fetch()
 pm_pins_default()
 pm_pins_idle()
 pm_pins_sleep()
 
 So if one is using the pin states defined in
 linux/pinctrl/pinctrl-state.h then the PM core can help out in
 keeping track of the pins and states, and the driver will just tell
 the PM core what to do and when.
 
 Would this fit the bill for everyone's code consolidation needs?
 It would sure work for us...

That surely would work but is kind of non-obvious when reading a
driver's code: that's the problem with bus notifier, they do things a
bit behind your back without you noticing. Having the driver request
its own pinctrl state, and switch between states upon suspend/resume is
a lot more explicit, IMO.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.7-rc2

2012-10-23 Thread Matt Porter

On Tue, Oct 23, 2012 at 03:15:44AM +, Paul Walmsley wrote:
 On Mon, 22 Oct 2012, Matt Porter wrote:
 
  I've mentioned this a few times in various threads...no need to use
  appended DTB on a current U-Boot. Some of us are indeed booting this way
  with the DTB properly passed separately from the bootloader and chosen
  filled out by the bootloader. And yes, am335x_evm_config applies to all
  AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
  that is used to determine what board is present so a single
  MLO/u-boot.img can be used.
 
 As Kevin mentioned earlier, this is unfortunately not true for those of us 
 with earlier BeagleBoards:
 
http://marc.info/?l=linux-omapm=135094296931913w=2

Yes, we spoke about this a bit.
 
 Do you know what the minimum board revision is that you all are 
 supporting in U-boot?

It's not so much a revision as it is getting the right contents in the
EEPROM. As it's a community board, it's generally only supported over at
beaglebo...@googlegroups.com. Jason Kridner recommends posting support
questions there (like why isn't my A2 supported in U-Boot?). If there
isn't some solution suggested there for updating the A2 I would contact
him directly. I have an A1 Bone here that also doesn't work with
mainline U-Boot even after configuring the EEPROM. You can try this
procedure if you want to write the proper contents in, an A2 may work
but for some reason there's no available history on Bone revisions prior
to A3. I vaguely recall a lot of chatter around the phy and so forth in
the A1 to A2 timeframe so it's entirely possible that your A2 will work
with just the eeprom contents programmed. Without it, it's guaranteed to
fail as the pin muxing is tied to detecting the board this way. Also,
you may need to change offset.1 in the below example to offset.2 for
your eeprom i/o to work as A2 may require an address length of 2.

-Matt

U-Boot 2012.10-00286-gfe27b3b (Oct 22 2012 - 16:40:21)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   PHY reset timed out
cpsw
Hit any key to stop autoboot:  0
U-Boot# i2c dev 0
Setting bus to 0
U-Boot# i2c md 50 0.1
: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

U-Boot# mm.b 8400
8400: 55 ? aa
8401: 51 ? 55
8402: 16 ? 33
8403: 00 ? ee
8404: 40 ? 41
8405: 94 ? 33
8406: 28 ? 33
8407: 41 ? 35
8408: 11 ? 42
8409: 55 ? 4f
840a: 80 ? 4e
840b: 8e ? 45
840c: 03 ? 30
840d: 5d ? 30
840e: 44 ? 41
840f: a0 ? 32
8410: 46 ? .
U-Boot# i2c write 8400 50 0.1 10
U-Boot# i2c md 50 0.1 10
: aa 55 33 ee 41 33 33 35 42 4f 4e 45 30 30 41 32
.U3.A335BONE00A2
U-Boot#

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

Re: OMAP baseline test results for v3.7-rc2

2012-10-23 Thread Matt Porter

On Tue, Oct 23, 2012 at 08:24:36AM -0400, Matt Porter wrote:
 On Tue, Oct 23, 2012 at 03:15:44AM +, Paul Walmsley wrote:
  On Mon, 22 Oct 2012, Matt Porter wrote:
  
   I've mentioned this a few times in various threads...no need to use
   appended DTB on a current U-Boot. Some of us are indeed booting this way
   with the DTB properly passed separately from the bootloader and chosen
   filled out by the bootloader. And yes, am335x_evm_config applies to all
   AM33xx TI EVMs and the BeagleBone board. There's an EEPROM onboard all
   that is used to determine what board is present so a single
   MLO/u-boot.img can be used.
  
  As Kevin mentioned earlier, this is unfortunately not true for those of us 
  with earlier BeagleBoards:
  
 http://marc.info/?l=linux-omapm=135094296931913w=2
 
 Yes, we spoke about this a bit.
  
  Do you know what the minimum board revision is that you all are 
  supporting in U-boot?
 
 It's not so much a revision as it is getting the right contents in the
 EEPROM. As it's a community board, it's generally only supported over at
 beaglebo...@googlegroups.com. Jason Kridner recommends posting support
 questions there (like why isn't my A2 supported in U-Boot?). If there
 isn't some solution suggested there for updating the A2 I would contact
 him directly. I have an A1 Bone here that also doesn't work with
 mainline U-Boot even after configuring the EEPROM. You can try this
 procedure if you want to write the proper contents in, an A2 may work
 but for some reason there's no available history on Bone revisions prior
 to A3. I vaguely recall a lot of chatter around the phy and so forth in
 the A1 to A2 timeframe so it's entirely possible that your A2 will work
 with just the eeprom contents programmed. Without it, it's guaranteed to
 fail as the pin muxing is tied to detecting the board this way. Also,
 you may need to change offset.1 in the below example to offset.2 for
 your eeprom i/o to work as A2 may require an address length of 2.

Ok, very quick update...no need to mess around with the eeprom. I just
received the official word on what will be supported. Since A2 is
pre-release, simply go to http://beagleboard.org/support/rma and fill
out the form to have it replaced with the current revision (A6).

This applies to *anyone* that received a pre-release A2 board.

-Matt
--
To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

Paul Walmsley p...@pwsan.com writes:

 Hi Tero,

 On Mon, 22 Oct 2012, Tero Kristo wrote:

 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.
 
 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com

 What do you think about these modifications?  The code is quite similar to 
 what was in the _ocp_softreset() function, so just moved it into a 
 function.  Also moved the callsite from the end of _enable_sysc() to the 
 beginning, which makes more sense to me, but would like to get your 
 opinion.

FYI, after some more testing with this patch, I noticed that this patch
(and the original from Tero) cause some sluggishness on UART1 console my
37xx/EVM platform as soon as off-mode is enabled (even without the UART
autosuspend timeouts enabled.)  I don't see this on any other OMAP3
platform but all the others I have have UART3 console (in PER), the EVM
is the only one with UART1 console (in CORE.)

I haven't debugged this any furhter, but thought it should be reported
before this gets merged.

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

Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

2012-10-23 Thread Santosh Shilimkar


On Tuesday 23 October 2012 07:58 PM, Kevin Hilman wrote:

Paul Walmsley p...@pwsan.com writes:


Hi Tero,

On Mon, 22 Oct 2012, Tero Kristo wrote:


When waking up from off-mode, some IP blocks are reset automatically by
hardware. For this reason, software must wait until the reset has
completed before attempting to access the IP block.

This patch fixes for example the bug introduced by commit
6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
to SYSCONFIG register), in which the MMC IP block is reset during
off-mode entry, but the code expects the module to be already available
during the execution of context restore.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Venkatraman S svenk...@ti.com


What do you think about these modifications?  The code is quite similar to
what was in the _ocp_softreset() function, so just moved it into a
function.  Also moved the callsite from the end of _enable_sysc() to the
beginning, which makes more sense to me, but would like to get your
opinion.


FYI, after some more testing with this patch, I noticed that this patch
(and the original from Tero) cause some sluggishness on UART1 console my
37xx/EVM platform as soon as off-mode is enabled (even without the UART
autosuspend timeouts enabled.)  I don't see this on any other OMAP3
platform but all the others I have have UART3 console (in PER), the EVM
is the only one with UART1 console (in CORE.)

I haven't debugged this any furhter, but thought it should be reported
before this gets merged.


Trying to shoot in the dark but the UART sluggishness I observed in the
past on OMAP4 was due to improper setting of sysconfig which is
what $subject + Tero's patch is dealing with. Good to check the
value of UART sysconfig before and after the offmode entry to
see if the smart-idle/smart-idle wakeup setting getting disturbed
for some reason.

Below is the OMAP4 commit am referring to.

commit 5ae256dcd91bf308826a4ac19598b27ebb86a536
Author: Santosh Shilimkar santosh.shilim...@ti.com
Date:   Fri Apr 13 23:25:04 2012 +0530

ARM: OMAP: serial: Fix the ocp smart idlemode handling bug

Regards,
Santosh



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

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

Hi Seb,

On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
 Add base address and interrupt line inside Device Tree data for
 OMAP5
 
 Signed-off-by: Sebastien Guiriec s-guir...@ti.com
 ---
  arch/arm/boot/dts/omap5.dtsi |   16 
  1 file changed, 16 insertions(+)
 
 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index 42c78be..9e39f9f 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -104,6 +104,8 @@
  
   gpio1: gpio@4ae1 {
   compatible = ti,omap4-gpio;
 + reg = 0x4ae1 0x200;
 + interrupts = 0 29 0x4;
   ti,hwmods = gpio1;
   gpio-controller;
   #gpio-cells = 2;

I am wondering if we should add the interrupt-parent property to add
nodes in the device-tree source. I know that today the interrupt-parent
is being defined globally, but when device-tree maps an interrupt for a
device it searches for the interrupt-parent starting the current device
node.

So in other words, for gpio1 it will search the gpio1 binding for
interrupt-parent and if not found move up a level and search again. It
will keep doing this until it finds the interrupt-parent.

Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.

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

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

On 10/23/2012 04:49 PM, Jon Hunter wrote:
 Hi Seb,
 
 On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
 Add base address and interrupt line inside Device Tree data for
 OMAP5

 Signed-off-by: Sebastien Guiriec s-guir...@ti.com
 ---
  arch/arm/boot/dts/omap5.dtsi |   16 
  1 file changed, 16 insertions(+)

 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index 42c78be..9e39f9f 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -104,6 +104,8 @@
  
  gpio1: gpio@4ae1 {
  compatible = ti,omap4-gpio;
 +reg = 0x4ae1 0x200;
 +interrupts = 0 29 0x4;
  ti,hwmods = gpio1;
  gpio-controller;
  #gpio-cells = 2;
 
 I am wondering if we should add the interrupt-parent property to add
 nodes in the device-tree source. I know that today the interrupt-parent
 is being defined globally, but when device-tree maps an interrupt for a
 device it searches for the interrupt-parent starting the current device
 node.
 
 So in other words, for gpio1 it will search the gpio1 binding for
 interrupt-parent and if not found move up a level and search again. It
 will keep doing this until it finds the interrupt-parent.
 
 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.

Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.

That being said, it might be interesting to benchmark that to see what
is the real impact.

Regards,
Benoit

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

[PATCH] i2c: omap: re-factor omap_i2c_init function

2012-10-23 Thread Shubhrajyoti D

re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.

Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html

Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3636 beagle both idle and suspend.

Functional testing on omap4sdp.

 drivers/i2c/busses/i2c-omap.c |   68 +
 1 files changed, 28 insertions(+), 40 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5e5cefb..338cee7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
-   u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev 
*i2c_dev, int reg)
}
 }
 
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+   omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+   /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+   omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+
+   /* SCL low and high time values */
+   omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+   omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+   if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
+   omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+   /* Take the I2C module out of reset: */
+   omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+   omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
 static int omap_i2c_init(struct omap_i2c_dev *dev)
 {
-   u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+   u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 * REVISIT: Some wkup sources might not be needed.
 */
dev-westate = OMAP_I2C_WE_ALL;
-   omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
-   dev-westate);
}
}
-   omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
 
if (dev-flags  OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
}
 
-   /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
-   omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
-   /* SCL low and high time values */
-   omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
-   omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
-   /* Take the I2C module out of reset: */
-   omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL)  |
((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
-   omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
-   if (dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
-   dev-pscstate = psc;
-   dev-scllstate = scll;
-   dev-sclhstate = sclh;
-   dev-bufstate = buf;
-   }
+
+   dev-pscstate = psc;
+   dev-scllstate = scll;
+   dev-sclhstate = sclh;
+
+   __omap_i2c_init(dev);
+
return 0;
 }
 
@@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(r))
goto err_free_mem;
 
-   dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)  0xff;
+   dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)   0xff;
 
dev-errata = 0;
 
@@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
 {
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
 
-   if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
-   omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
-   omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
-   omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
-   omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
-   omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
-   omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
-   omap_i2c_write_reg(_dev,

Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Tero Kristo t-kri...@ti.com writes:

 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.

 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com

 I can confirm that this patch the regression in my OMAP3 PM tests where
 suspend test (to retention or off) failed if ran after the off-idle
 test.

 Tested-by: Kevin Hilman khil...@ti.com

 on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM

on 3630/Beagle works.
However on 3430 on idle path didnot work.
let me know if i am missing some thing.


 Thanks Tero for the fix,

 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
--
To unsubscribe from this list: send the line unsubscribe 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 6/6] OMAPDSS: HDMI: Create platform device to support audio

2012-10-23 Thread Ricardo Neri

On 10/23/2012 04:37 AM, Tomi Valkeinen wrote:

On 2012-10-23 03:48, Ricardo Neri wrote:

+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#define HDMI_AUDIO_MEM_RESOURCE 0
+#define HDMI_AUDIO_DMA_RESOURCE 1

I don't see much point with these definitions. They are hdmi.c internal,
so the audio driver can't use them, and so they aren't really fixed.

I just thought it could make the code more readable; but if the
resources array is going to be local, then they are not helpful.

My point was that if the defines as hdmi.c internal, you need to add the
same defines into the audio code also in order to use them. And then
we'd have the same defines in two places.

Or, if audio code doesn't need them to parse the resources, then they
aren't really relevant here either, as you are just adding two resources
to the array, and their order is not important.

Oh OK. So they are not needed at all.

So, how will this work? All the audio related functions will be removed
from the (video) hdmi driver, and the audio driver will access the
registers independently? The audio driver will still need to access the
video parts, right?

That could be a new approach, but the idea here is to continue having an
omapdss audio interface for audio drivers to use.

Ok. Do you have a git tree with the audio code working with this
approach? Or can you just copy paste a few lines showing how the audio
driver uses this. It'd be easier to understand by seeing that side of
the code also.

Here is the code:

static __devinit int omap_hdmi_probe(struct platform_device *pdev)
{
...

hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!hdmi_rsrc) {
dev_err(pdev-dev, Cannot obtain IORESOURCE_MEM);
return -ENODEV;
}

hdmi_data-dma_params.port_addr = hdmi_rsrc-start
+ OMAP_HDMI_AUDIO_DMA_PORT;

hdmi_rsrc = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!hdmi_rsrc) {
dev_err(pdev-dev, Cannot obtain IORESOURCE_DMA);
return -ENODEV;
}

hdmi_data-dma_params.dma_req = hdmi_rsrc-start;
hdmi_data-dma_params.name = HDMI playback;

...
}

You can also take a look here:
git://gitorious.org/omap-audio/linux-audio.git
ricardon/topic/for-3.8-hdmi_rename_devs

at sound/soc/omap/omap-hdmi.c

or directly here:

http://gitorious.org/omap-audio/linux-audio/blobs/ricardon/topic/for-3.8-hdmi_rename_devs/sound/soc/omap/omap-hdmi.c

The audio uses sDMA for the transfer?

Yes, it does.

The root problem that I am trying to address is that the omapdss audio
interface does not have functionality for DMA transfer of audio samples
to the HDMI IP. Also, I am not sure how that could be done without
duplicating the functionality that ASoC already provides.

Ok. But the audio driver still needs access to the HDMI registers? I'm
not worried about passing the DMA resource. Video side doesn't use that.

Audio driver does not access the HDMI registers nor ioremaps them. The
audio driver relies solely on the OMAPDSS audio interface for audio
configuration, start and stop.

But video side uses the registers, and both having the same ioremapped
area could possibly lead both writing to the same register. Or perhaps
not the same register, but still doing conflicting things at the hw
level at the same time.
Also, for things like display enable/disable, the audio driver relies
the the display driver. If the display is disable or the current timing
does not support audio, audio will just not play.

I feel a bit uneasy about giving the same ioremapped register space to
two independent drivers... If we could split the registers to video and
audio parts, each driver only ioremapping their respective registers,
it'd be much better.

Fwiw, the audio drivers (at least my audio drivers) will not ioremap.
They will just take the DMA request number and port. Maybe spliting the
register space into audio and video is not practical as we would endup
having many tiny address spaces.

Yes, if there's no clear HDMI block division for video and audio, then
it doesn't sound good to split them up if we'd have lots of small
address spaces.

What registers does the audio side need to access?

It only needs access to the DMA audio data port. All other operations
that the audio driver needs are done through the omapdss audio interface.

Why are part of the
registers accessed via the hdmi driver API, and some directly? I imagine
it'd be better to do either one of those, but not both.

This is because in the current omapdss audio interface we have no
functionality to handle the DMA transfers for audio. Do you think it
would be good to explore implementing support for that? At this point it
is not clear for me how to do it without duplicating the functionality
that ASoC provides for that.

BR,

Ricardo

Tomi

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts


On 10/23/2012 10:09 AM, Benoit Cousson wrote:
 On 10/23/2012 04:49 PM, Jon Hunter wrote:
 Hi Seb,

 On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
 Add base address and interrupt line inside Device Tree data for
 OMAP5

 Signed-off-by: Sebastien Guiriec s-guir...@ti.com
 ---
  arch/arm/boot/dts/omap5.dtsi |   16 
  1 file changed, 16 insertions(+)

 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index 42c78be..9e39f9f 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -104,6 +104,8 @@
  
 gpio1: gpio@4ae1 {
 compatible = ti,omap4-gpio;
 +   reg = 0x4ae1 0x200;
 +   interrupts = 0 29 0x4;
 ti,hwmods = gpio1;
 gpio-controller;
 #gpio-cells = 2;

 I am wondering if we should add the interrupt-parent property to add
 nodes in the device-tree source. I know that today the interrupt-parent
 is being defined globally, but when device-tree maps an interrupt for a
 device it searches for the interrupt-parent starting the current device
 node.

 So in other words, for gpio1 it will search the gpio1 binding for
 interrupt-parent and if not found move up a level and search again. It
 will keep doing this until it finds the interrupt-parent.

 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.
 
 Mmm, I'm not that sure. it will increase the size of the blob, so
 increase the time to load it and then to parse it. Where in the current
 case, it is just going up to the parent node using the already
 un-flatten tree in memory and thus that should not take that much time.

Yes it will definitely increase the size, so that could slow things down.

 That being said, it might be interesting to benchmark that to see what
 is the real impact.

Right, I wonder what the key functions are we need to benchmark to get
an overall feel for what is best? Right now I am seeing some people add
the interrupt-parent for device nodes and others not. Ideally we should
be consistent, but at the same time it is probably something that we can
easily sort out later. So not a big deal either way.

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

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

On 10/23/2012 05:59 PM, Jon Hunter wrote:
 
 On 10/23/2012 10:09 AM, Benoit Cousson wrote:
 On 10/23/2012 04:49 PM, Jon Hunter wrote:
 Hi Seb,

 On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:
 Add base address and interrupt line inside Device Tree data for
 OMAP5

 Signed-off-by: Sebastien Guiriec s-guir...@ti.com
 ---
  arch/arm/boot/dts/omap5.dtsi |   16 
  1 file changed, 16 insertions(+)

 diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
 index 42c78be..9e39f9f 100644
 --- a/arch/arm/boot/dts/omap5.dtsi
 +++ b/arch/arm/boot/dts/omap5.dtsi
 @@ -104,6 +104,8 @@
  
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
 +  reg = 0x4ae1 0x200;
 +  interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;

 I am wondering if we should add the interrupt-parent property to add
 nodes in the device-tree source. I know that today the interrupt-parent
 is being defined globally, but when device-tree maps an interrupt for a
 device it searches for the interrupt-parent starting the current device
 node.

 So in other words, for gpio1 it will search the gpio1 binding for
 interrupt-parent and if not found move up a level and search again. It
 will keep doing this until it finds the interrupt-parent.

 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.

 Mmm, I'm not that sure. it will increase the size of the blob, so
 increase the time to load it and then to parse it. Where in the current
 case, it is just going up to the parent node using the already
 un-flatten tree in memory and thus that should not take that much time.
 
 Yes it will definitely increase the size, so that could slow things down.
 
 That being said, it might be interesting to benchmark that to see what
 is the real impact.
 
 Right, I wonder what the key functions are we need to benchmark to get
 an overall feel for what is best? Right now I am seeing some people add
 the interrupt-parent for device nodes and others not. Ideally we should
 be consistent, but at the same time it is probably something that we can
 easily sort out later. So not a big deal either way.

For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)

Regards,
Benoit


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

Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

Shubhrajyoti Datta omaplinuxker...@gmail.com writes:

 On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 Tero Kristo t-kri...@ti.com writes:

 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.

 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com

 I can confirm that this patch the regression in my OMAP3 PM tests where
 suspend test (to retention or off) failed if ran after the off-idle
 test.

 Tested-by: Kevin Hilman khil...@ti.com

 on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM

 on 3630/Beagle works.
 However on 3430 on idle path didnot work.
 let me know if i am missing some thing.

Could you please explain what worked and didn't work on each platforms?

Also, which 3430 did you test on?  If it's SDP, then it has a UART1
console, correct?

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

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts


Hi Benoit and John,

On 10/23/2012 06:07 PM, Benoit Cousson wrote:

On 10/23/2012 05:59 PM, Jon Hunter wrote:


On 10/23/2012 10:09 AM, Benoit Cousson wrote:

On 10/23/2012 04:49 PM, Jon Hunter wrote:

Hi Seb,

On 10/23/2012 03:37 AM, Sebastien Guiriec wrote:

Add base address and interrupt line inside Device Tree data for
OMAP5

Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
  arch/arm/boot/dts/omap5.dtsi |   16 
  1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -104,6 +104,8 @@

gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
+   reg = 0x4ae1 0x200;
+   interrupts = 0 29 0x4;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;


I am wondering if we should add the interrupt-parent property to add
nodes in the device-tree source. I know that today the interrupt-parent
is being defined globally, but when device-tree maps an interrupt for a
device it searches for the interrupt-parent starting the current device
node.

So in other words, for gpio1 it will search the gpio1 binding for
interrupt-parent and if not found move up a level and search again. It
will keep doing this until it finds the interrupt-parent.

Therefore, I believe it will improve search time and hence, boot time if
we have interrupt-parent defined in each node.


Mmm, I'm not that sure. it will increase the size of the blob, so
increase the time to load it and then to parse it. Where in the current
case, it is just going up to the parent node using the already
un-flatten tree in memory and thus that should not take that much time.


Yes it will definitely increase the size, so that could slow things down.


That being said, it might be interesting to benchmark that to see what
is the real impact.


Right, I wonder what the key functions are we need to benchmark to get
an overall feel for what is best? Right now I am seeing some people add
the interrupt-parent for device nodes and others not. Ideally we should
be consistent, but at the same time it is probably something that we can
easily sort out later. So not a big deal either way.


For consistency, I'd rather not add it at all for the moment.
Later, when we will only support DT boot, people will start complaining
about the boot time increase and then we will start optimizing a little
bit :-)


I just do it like that to be consistent with what is inside OMAP4 dtsi 
for those IPs (GPIO/UART/MMC/I2C). Now after checking Peter already add 
the interrupt-parent for all audio IPs (OMAP3/4/5). But here we need 
also interrupts name. So here we should try to be consistent.


So I can send back the series for OMAP5 and update the OMAP4 with
  interrupts-parent = gic

As of today we are not consistent.



Regards,
Benoit




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

Re: [PATCH 6/6] OMAPDSS: HDMI: Create platform device to support audio

2012-10-23 Thread Tomi Valkeinen

On 2012-10-23 18:42, Ricardo Neri wrote:

 What registers does the audio side need to access?
 
 It only needs access to the DMA audio data port. All other operations
 that the audio driver needs are done through the omapdss audio interface.

Hmm, so the audio side only needs the address of one register, for the
audio data, and this address is given to sDMA? You have
OMAP_HDMI_AUDIO_DMA_PORT in the audio code, is it the HDMI_WP_AUDIO_DATA
register?

If so, you could pass only that one address, instead of the whole HDMI
register space?

My point here is that we should make it very clear what the audio side
can access. If we pass the whole HDMI register space, we should, in
theory, be prepared to cope with the audio driver changing any register
there. But if we pass only one register (or certain small ranges), we
know the rest of the registers are safe.

 Why are part of the
 registers accessed via the hdmi driver API, and some directly? I imagine
 it'd be better to do either one of those, but not both.
 
 This is because in the current omapdss audio interface we have no
 functionality to handle the DMA transfers for audio. Do you think it
 would be good to explore implementing support for that? At this point it
 is not clear for me how to do it without duplicating the functionality
 that ASoC provides for that.

No, if the common ASoC code provides functionality for this, we should
at least try to use it.

I was looking at the ti_hdmi_4xxx_ip.h, searching for audio related
registers by searching AUD string. I don't know if it makes any sense
(you're better to have a say on that), but I think we could pass some of
the audio registers ranges to the audio driver for use.

For example, the HDMI_WP_AUDIO_* registers are together, we could give
those to the audio driver if it makes sense. HDMI_CORE_AV_AUD* registers
are a bit scattered, but... I guess it wouldn't be difficult to pass
those also, there's still only a couple separate ranges.

But I also have no problem with having the hdmi audio API in the hdmi
video driver, as we do now. And I think we in any case need a few
functions, even if we would give the audio driver access to the AUD
registers.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

On 10/23/2012 4:49 AM, Jon Hunter wrote:

 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.

I strongly suspect (based on many years of performance tuning, with
special focus on boot time) that the time difference will be completely
insignificant.  The total extra time for walking up the interrupt tree
for every interrupt in a large system is comparable to the time it takes
to send a few characters out a UART.  So you can get more improvement
from eliminating a single printk() than from globally adding per-node
interrupt-parent.

Furthermore, the cost of processing all of the interrupt-parent
properties is probably similar to the cost of the avoided tree walks.

CPU cycles are very fast compared to I/O register accesses, say a factor
of 100.  Now consider that many modern devices contain embedded
microcontrollers (SD cards, network interface modules, USB hubs and
devices, ...), and those devices usually require various delays measured
in milliseconds, to ensure that the microcontroller is ready for the
next initialization step.  Those delays are extremely long compared to
CPU cycles.  Obviously, some of that can be overlapped by careful
multithreading, but that isn't free either.

The bottom line is that I'm pretty sure that adding per-node
interrupt-parent would not be worthwhile from the standpoint of speeding
up boot time.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

On 10/23/2012 12:03 AM, Felipe Balbi wrote:
 Hi,
 
 I much prefer having drivers explicitly manage all their resources,
 which would mean that pinctrl calls need to be done on probe() and, if
 necessary, during suspend()/resume().


Per-driver resource management is certainly convenient when you are
dealing with a single system, but it becomes difficult to maintain for
drivers that are shared among many platforms.

The industry trend for many years has been consolidation around a single
programming model per class of device.  For example, SDHCI, EHCI, ATA.
This trend will only accelerate, as the cost of developing controller IP
and associated drivers increases.  Such drivers need to be as
platform-agnostic as possible.

--
To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

Kevin Hilman khil...@deeprootsystems.com writes:

 Paul Walmsley p...@pwsan.com writes:

 Hi Tero,

 On Mon, 22 Oct 2012, Tero Kristo wrote:

 When waking up from off-mode, some IP blocks are reset automatically by
 hardware. For this reason, software must wait until the reset has
 completed before attempting to access the IP block.
 
 This patch fixes for example the bug introduced by commit
 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access
 to SYSCONFIG register), in which the MMC IP block is reset during
 off-mode entry, but the code expects the module to be already available
 during the execution of context restore.
 
 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Venkatraman S svenk...@ti.com

 What do you think about these modifications?  The code is quite similar to 
 what was in the _ocp_softreset() function, so just moved it into a 
 function.  Also moved the callsite from the end of _enable_sysc() to the 
 beginning, which makes more sense to me, but would like to get your 
 opinion.

 FYI, after some more testing with this patch, I noticed that this patch
 (and the original from Tero) cause some sluggishness on UART1 console my
 37xx/EVM platform as soon as off-mode is enabled (even without the UART
 autosuspend timeouts enabled.)  I don't see this on any other OMAP3
 platform but all the others I have have UART3 console (in PER), the EVM
 is the only one with UART1 console (in CORE.)

OK, found it.

The reason for the sluggishness is that the GPIO blocks are timing
out in the omap_test_timout() calls added in this patch, suggesting that
they never detect reset done.

Looking at the other user of _wait_softreset_complete made me remember
that there modules that need their optional clocks enabled in order for
softreset to work.  It appears that the optional clocks are needed not
only to initiate a softrest, but also to check SYSS.RESETDONE.

The patch below on top of Paul's version makes the sluggishness disappear.

Kevin




diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index f9d8b2a..70267d2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1320,7 +1320,11 @@ static void _enable_sysc(struct omap_hwmod *oh)
 * (off-mode for example), and the drivers require the
 * IP to be ready when they access it
 */
+   if (oh-flags  HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _enable_optional_clocks(oh);
_wait_softreset_complete(oh);
+   if (oh-flags  HWMOD_CONTROL_OPT_CLKS_IN_RESET)
+   _disable_optional_clocks(oh);
 
v = oh-_sysc_cache;
sf = oh-class-sysc-sysc_flags;
--
To unsubscribe from this list: send the line unsubscribe 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 6/6] OMAPDSS: HDMI: Create platform device to support audio

2012-10-23 Thread Ricardo Neri




On 10/23/2012 11:17 AM, Tomi Valkeinen wrote:

On 2012-10-23 18:42, Ricardo Neri wrote:


What registers does the audio side need to access?


It only needs access to the DMA audio data port. All other operations
that the audio driver needs are done through the omapdss audio interface.


Hmm, so the audio side only needs the address of one register, for the
audio data, and this address is given to sDMA? You have
OMAP_HDMI_AUDIO_DMA_PORT in the audio code, is it the HDMI_WP_AUDIO_DATA
register?

Yes, that is the register it needs.


If so, you could pass only that one address, instead of the whole HDMI
register space?
Yes, that could work. I thought about that but the common HDMI driver 
would have to know the the IP-specific register, which it should not. 
Perhaps the IP-specific register address can be passed by a IP-specific 
function such as hdmi_get_audio_dma_port for the common HDMI driver to 
populate the resource.


Btw, could this be another reason to convert the IP-specific libraries 
to drivers?


My point here is that we should make it very clear what the audio side
can access. If we pass the whole HDMI register space, we should, in
theory, be prepared to cope with the audio driver changing any register
there. But if we pass only one register (or certain small ranges), we
know the rest of the registers are safe.


True.



Why are part of the
registers accessed via the hdmi driver API, and some directly? I imagine
it'd be better to do either one of those, but not both.


This is because in the current omapdss audio interface we have no
functionality to handle the DMA transfers for audio. Do you think it
would be good to explore implementing support for that? At this point it
is not clear for me how to do it without duplicating the functionality
that ASoC provides for that.


No, if the common ASoC code provides functionality for this, we should
at least try to use it.

I was looking at the ti_hdmi_4xxx_ip.h, searching for audio related
registers by searching AUD string. I don't know if it makes any sense
(you're better to have a say on that), but I think we could pass some of
the audio registers ranges to the audio driver for use.

For example, the HDMI_WP_AUDIO_* registers are together, we could give
those to the audio driver if it makes sense. HDMI_CORE_AV_AUD* registers
are a bit scattered, but... I guess it wouldn't be difficult to pass
those also, there's still only a couple separate ranges.


Even though this would allow our HDMI drivers to be more inline with 
what other HDMI drivers do, things like power management and interrupts 
are still handled by DSS, unlike x86, for instance [1][2]. So the audio 
drivers will still depend on DSS. Also, the register layout is different 
for OMAP5 and audio registers are even more scattered. Furthermore, the 
common HDMI driver would have to know the IP-specific layout to know 
what register spaces expose to the audio driver (another reason to have 
IP-specific drivers?). So I would vote for continuing using the omapdss 
audio interface.




But I also have no problem with having the hdmi audio API in the hdmi
video driver, as we do now. And I think we in any case need a few
functions, even if we would give the audio driver access to the AUD
registers.

Yes, interrupt handling, for instance.

BR,

Ricardo


[1].http://www.spinics.net/lists/linux-omap/msg75969.html
[2]. http://www.spinics.net/lists/linux-omap/msg75968.html



  Tomi



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

Re: [PATCH] i2c: omap: re-factor omap_i2c_init function

Hi,

On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
 re-factor omap_i2c_init() so that we can re-use it for resume.
 While at it also remove the bufstate variable as we write it
 in omap_i2c_resize_fifo for every transfer.
 
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
 Applies on Felipe's series
 http://www.spinics.net/lists/linux-omap/msg79995.html
 
 Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
 on omap3636 beagle both idle and suspend.
 
 Functional testing on omap4sdp.
 
  drivers/i2c/busses/i2c-omap.c |   68 
 +
  1 files changed, 28 insertions(+), 40 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index 5e5cefb..338cee7 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -209,7 +209,6 @@ struct omap_i2c_dev {
   u16 pscstate;
   u16 scllstate;
   u16 sclhstate;
 - u16 bufstate;
   u16 syscstate;
   u16 westate;
   u16 errata;
 @@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev 
 *i2c_dev, int reg)
   }
  }
  
 +static void __omap_i2c_init(struct omap_i2c_dev *dev)
 +{
 +
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
 + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
 +
 + /* SCL low and high time values */
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
 + if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
 + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
 + /* Take the I2C module out of reset: */
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 +
 +}
  static int omap_i2c_init(struct omap_i2c_dev *dev)
  {
 - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
 + u16 psc = 0, scll = 0, sclh = 0;
   u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
   unsigned long fclk_rate = 1200;
   unsigned long timeout;
 @@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
   dev-westate = OMAP_I2C_WE_ALL;
 - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
 - dev-westate);
   }
   }
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
  
   if (dev-flags  OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
   /*
 @@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
   sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
   }
  
 - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
 -
 - /* SCL low and high time values */
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
 -
 - /* Take the I2C module out of reset: */
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 -
   /* Enable interrupts */
   dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
   OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL)  |
   ((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
   OMAP_I2C_IE_XDR) : 0);
 - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 - if (dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - dev-pscstate = psc;
 - dev-scllstate = scll;
 - dev-sclhstate = sclh;
 - dev-bufstate = buf;
 - }
 +
 + dev-pscstate = psc;
 + dev-scllstate = scll;
 + dev-sclhstate = sclh;
 +
 + __omap_i2c_init(dev);
 +
   return 0;
  }
  
 @@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
   if (IS_ERR_VALUE(r))
   goto err_free_mem;
  
 - dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)  0xff;
 + dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)   0xff;

trailing change. not part of $SUBJECT

   dev-errata = 0;
  
 @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
  {
   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
  
 - if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
 - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
 -

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

HI,

On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
 On 10/23/2012 12:03 AM, Felipe Balbi wrote:
  Hi,
  
  I much prefer having drivers explicitly manage all their resources,
  which would mean that pinctrl calls need to be done on probe() and, if
  necessary, during suspend()/resume().
 
 
 Per-driver resource management is certainly convenient when you are
 dealing with a single system, but it becomes difficult to maintain for
 drivers that are shared among many platforms.

why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe
and a couple of different FPGA implementations inside TI. Not to mention
what other licensees of that IP core might have internally.

So far no problesm with resources at all.

We have frameworks exactly to hide the differences.

 The industry trend for many years has been consolidation around a single
 programming model per class of device.  For example, SDHCI, EHCI, ATA.
 This trend will only accelerate, as the cost of developing controller IP
 and associated drivers increases.  Such drivers need to be as
 platform-agnostic as possible.

that's why we have pinctrl framework to abstract the details about pin
muxing.

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod

On Tue, Oct 23, 2012 at 9:39 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
 Shubhrajyoti Datta omaplinuxker...@gmail.com writes:
[...]

 Could you please explain what worked and didn't work on each platforms?

 Also, which 3430 did you test on?  If it's SDP, then it has a UART1
 console, correct?
idle mode

set autosuspend for uart
sleep

off count didnt increment on 3430sdp.

hope not hitting any setup at my end.


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

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Perhaps I misunderstood what you were suggesting.  I thought that, when
you said explicitly manage all their resources, you meant that the
driver should know the platform-specific details about clocks and power
domains.  That is one possible interpretation of the word explicit.

Now I see that you meant that the driver should explicitly call
abstracted functions.


On 10/23/2012 7:20 AM, Felipe Balbi wrote:
 HI,
 
 On Tue, Oct 23, 2012 at 07:02:09AM -1000, Mitch Bradley wrote:
 On 10/23/2012 12:03 AM, Felipe Balbi wrote:
 Hi,

 I much prefer having drivers explicitly manage all their resources,
 which would mean that pinctrl calls need to be done on probe() and, if
 necessary, during suspend()/resume().


 Per-driver resource management is certainly convenient when you are
 dealing with a single system, but it becomes difficult to maintain for
 drivers that are shared among many platforms.
 
 why ? look at drivers/usb/dwc3/, we're using that on OMAP, exynos, PCIe
 and a couple of different FPGA implementations inside TI. Not to mention
 what other licensees of that IP core might have internally.
 
 So far no problesm with resources at all.
 
 We have frameworks exactly to hide the differences.
 
 The industry trend for many years has been consolidation around a single
 programming model per class of device.  For example, SDHCI, EHCI, ATA.
 This trend will only accelerate, as the cost of developing controller IP
 and associated drivers increases.  Such drivers need to be as
 platform-agnostic as possible.
 
 that's why we have pinctrl framework to abstract the details about pin
 muxing.
 
--
To unsubscribe from this list: send the line unsubscribe 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] i2c: omap: re-factor omap_i2c_init function

On Tue, Oct 23, 2012 at 10:48 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
 re-factor omap_i2c_init() so that we can re-use it for resume.
 While at it also remove the bufstate variable as we write it
 in omap_i2c_resize_fifo for every transfer.

 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
 Applies on Felipe's series
 http://www.spinics.net/lists/linux-omap/msg79995.html

 Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
 on omap3636 beagle both idle and suspend.

 Functional testing on omap4sdp.

  drivers/i2c/busses/i2c-omap.c |   68 
 +
  1 files changed, 28 insertions(+), 40 deletions(-)

 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index 5e5cefb..338cee7 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -209,7 +209,6 @@ struct omap_i2c_dev {
   u16 pscstate;
   u16 scllstate;
   u16 sclhstate;
 - u16 bufstate;
   u16 syscstate;
   u16 westate;
   u16 errata;
 @@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev 
 *i2c_dev, int reg)
   }
  }

 +static void __omap_i2c_init(struct omap_i2c_dev *dev)
 +{
 +
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
 + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
 +
 + /* SCL low and high time values */
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
 + if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
 + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
 + /* Take the I2C module out of reset: */
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 +
 +}
  static int omap_i2c_init(struct omap_i2c_dev *dev)
  {
 - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
 + u16 psc = 0, scll = 0, sclh = 0;
   u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
   unsigned long fclk_rate = 1200;
   unsigned long timeout;
 @@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
   dev-westate = OMAP_I2C_WE_ALL;
 - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
 - dev-westate);
   }
   }
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);

   if (dev-flags  OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
   /*
 @@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
   sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
   }

 - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
 -
 - /* SCL low and high time values */
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
 -
 - /* Take the I2C module out of reset: */
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 -
   /* Enable interrupts */
   dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
   OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL)  |
   ((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
   OMAP_I2C_IE_XDR) : 0);
 - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 - if (dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - dev-pscstate = psc;
 - dev-scllstate = scll;
 - dev-sclhstate = sclh;
 - dev-bufstate = buf;
 - }
 +
 + dev-pscstate = psc;
 + dev-scllstate = scll;
 + dev-sclhstate = sclh;
 +
 + __omap_i2c_init(dev);
 +
   return 0;
  }

 @@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
   if (IS_ERR_VALUE(r))
   goto err_free_mem;

 - dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)  0xff;
 + dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)   0xff;

 trailing change. not part of $SUBJECT

my mistake will remove.


   dev-errata = 0;

 @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
  {
   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);

 - if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
 - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
 -

Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Hi,

(please don't top-post)

On Tue, Oct 23, 2012 at 07:51:22AM -1000, Mitch Bradley wrote:
 Perhaps I misunderstood what you were suggesting.  I thought that, when
 you said explicitly manage all their resources, you meant that the
 driver should know the platform-specific details about clocks and power
 domains.  That is one possible interpretation of the word explicit.

we had two suggestions in the thread:

1) handle it in driver source code (explict)
2) handle at bus notifiers level (hidden)

archives would've helped you clear up that confusion ;-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] i2c: omap: re-factor omap_i2c_init function

Hi,

On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
  @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device 
  *dev)
   {
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
 
  - if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
  - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
  - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev-syscstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
  - }
  -
  - /*
  -  * Don't write to this register if the IE state is 0 as it can
  -  * cause deadlock.
  -  */
  - if (_dev-iestate)
  - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
 
  this part is not on __omap_i2c_init() so you're potentially causing a
  regression here.
 
 iestate is set at init so cannot be zero. so the check was removed.

so you never read it back ? Then you need to add a note for that in
changelog, since this is a behavior change ;-)


-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] i2c: omap: re-factor omap_i2c_init function

On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
  @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device 
  *dev)
   {
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
 
  - if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
  - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
  - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, 
  _dev-scllstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, 
  _dev-sclhstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, 
  _dev-syscstate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
  - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
  - }
  -
  - /*
  -  * Don't write to this register if the IE state is 0 as it can
  -  * cause deadlock.
  -  */
  - if (_dev-iestate)
  - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
 
  this part is not on __omap_i2c_init() so you're potentially causing a
  regression here.

 iestate is set at init so cannot be zero. so the check was removed.

 so you never read it back ? Then you need to add a note for that in
 changelog, since this is a behavior change ;-)

Indeed will do.


 --
 balbi
--
To unsubscribe from this list: send the line unsubscribe 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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable

From: Kevin Hilman khil...@ti.com

When debounce clocks are disabled, ensure that the banks
dbck_enable_mask is cleared also.  Otherwise, context restore on
subsequent off-mode transition will restore previous value from the
shadow copies (bank-context.debounce*) leading to mismatch state
between driver state and hardware state.

This was discovered when board code was doing

  gpio_request_one()
  gpio_set_debounce()
  gpio_free()

which was leaving the GPIO debounce settings in a confused state.
Then, enabling off mode causing bogus state to be restored, leaving
GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.

Reported-by: Paul Walmsley p...@pwsan.com
Cc: Igor Grinberg grinb...@compulab.co.il
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies on v3.7-rc2, targetted for v3.7.

 drivers/gpio/gpio-omap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..dee2856 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank 
*bank)
 * to detect events and generate interrupts at least on OMAP3.
 */
__raw_writel(0, bank-base + bank-regs-debounce_en);
+   bank-dbck_enable_mask = 0;
 
clk_disable(bank-dbck);
bank-dbck_enabled = false;
-- 
1.8.0

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

Re: OMAP baseline test results for v3.7-rc2

Kevin Hilman khil...@deeprootsystems.com writes:

 +Igor

 Paul Walmsley p...@pwsan.com writes:

 Here are some basic OMAP test results for Linux v3.7-rc2.
 Logs and other details at:

 http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/

 [...]

 * 37xx EVM: CORE not entering dynamic off-idle
   - Cause unknown; dynamic retention-idle seems to work; system suspend to 
 off works

 I got a start on this one, and discovered (using CM_IDLEST1_CORE) that
 SPI1 was not idle when going off.  A quick hack disabling the
 touchscreen showed that after that, core was hitting idle just fine.

 I ran out of time today debugging this, but it's definitely realted to
 the GPIO debounce setting for the touchscreen.  Changing it to zero[1]
 makes CORE hit retention again in idle.

OK, found the root cause of this in the GPIO driver.  Patch submitted:

http://marc.info/?l=linux-omapm=135101577925972w=2

however...

 Igor, I'm hoping you might know what's going on here since we already
 had some problems with this ads7846 init stuff and you're more familiar
 with this debounce init.

... board files that are setting debounce values for ads7846 will no
longer work.  

Currently, omap_ads7846_init() in common-board-devices.c does this:

   gpio_request_one()
   gpio_set_debounce()
   gpio_free()

because of a bug in the GPIO driver, the debounce settings were sticky
and lingered even after the gpio_free().  That bug has been fixed by the
above patch, which means the above gpio_set_debounce() is completely
pointless because it's followed immediately by a gpio_free().

IMO, the whole GPIO init for the ads7846 needs a rethink as it's
currently partially done by common-board-devices.c and done (again) in
the ads7846 driver.  If the gpio_free() isn't done in
common-board-devices, then the ads7846 driver will currently fail to
probe/load becasue it can't request a GPIO line.

Having found and fixed the PM regression, I'll leave the ads7846 cleanup to
somone else.

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] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable

Hi,

On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
 From: Kevin Hilman khil...@ti.com
 
 When debounce clocks are disabled, ensure that the banks
 dbck_enable_mask is cleared also.  Otherwise, context restore on
 subsequent off-mode transition will restore previous value from the
 shadow copies (bank-context.debounce*) leading to mismatch state
 between driver state and hardware state.
 
 This was discovered when board code was doing
 
   gpio_request_one()
   gpio_set_debounce()
   gpio_free()
 
 which was leaving the GPIO debounce settings in a confused state.
 Then, enabling off mode causing bogus state to be restored, leaving
 GPIO debounce enabled which then prevented the CORE powerdomain from
 transitioning.
 
 Reported-by: Paul Walmsley p...@pwsan.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com

looks like this deserves a Cc: sta...@vger.kernel.org tag.

 ---
 Applies on v3.7-rc2, targetted for v3.7.
 
  drivers/gpio/gpio-omap.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 94cbc84..dee2856 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank 
 *bank)
* to detect events and generate interrupts at least on OMAP3.
*/
   __raw_writel(0, bank-base + bank-regs-debounce_en);
 + bank-dbck_enable_mask = 0;

shouldn't omap_gpio_restore_context() check for dbck_enabled instead of
the mask ? I mean:

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..b3a39a7 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1371,7 +1371,7 @@ static void omap_gpio_restore_context(struct gpio_bank 
*bank)
bank-base + bank-regs-dataout);
__raw_writel(bank-context.oe, bank-base + bank-regs-direction);
 
-   if (bank-dbck_enable_mask) {
+   if (bank-dbck_enabled) {
__raw_writel(bank-context.debounce, bank-base +
bank-regs-debounce);
__raw_writel(bank-context.debounce_en,

the outcome would be the same, so it doesn't really matter. Just that,
at least to me, it would look better.

No strong feelings though.

-- 
balbi


signature.asc
Description: Digital signature

Re: OMAP baseline test results for v3.7-rc1

Jean Pihet jean.pi...@newoldbits.com writes:

 Hi,

 On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi Jean

 On Fri, 19 Oct 2012, Paul Walmsley wrote:

 On Thu, 18 Oct 2012, Paul Walmsley wrote:

  Here are some basic OMAP test results for Linux v3.7-rc1.
  Logs and other details at 
  http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/

 ...

  Failing tests: needing investigation
  
 
  Boot tests:

 * 3530ES3 Beagle: I2C timeouts during userspace init
   - May be related to the threaded IRQ conversion of the I2C driver
   - Unknown cause

 This one turned out to be caused by:

 commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc
 Author: Jean Pihet jean.pi...@newoldbits.com
 Date:   Thu Sep 20 18:08:03 2012 +0200

 ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints


 Reverting this commit causes the problem to go away, but since the OMAP PM
 constraint code was removed as well, it's unlikely that a simple revert is
 the right thing to do.

 Jean could you please investigate and fix this?
 I tried the latest l-o with omap2plus defconfig on my Beagleboard B5
 (ES2.1) and could not reproduce the problem.
 I do not have the I2C error messages at boot, nor at user space start
 up. I tried to read/write the TWL RTC, successfully.

 Another difference is the bootloader images. I have the following:
 - Texas Instruments X-Loader 1.4.2 (Feb  3 2009 - 15:34:17)
 - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
 Could you send your bootloader images?

 I noticed you have I2C error messages in U-Boot, could that be the
 cause of the I2C lock-up?

FWIW, I have a relatively recent mainline u-boot+SPL:

U-Boot SPL 2012.04.01 (Jul 03 2012 - 07:07:04)
U-Boot 2012.04.01 (Jul 03 2012 - 07:07:04)

And I see I2C error messages from u-boot too:

timed out in wait_for_pin: I2C_STAT=0
I2C read: I/O error

I think these are normal/expected since u-boot may be looking for
expansion cards.

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] i2c: omap: re-factor omap_i2c_init function

Hi,

On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
 re-factor omap_i2c_init() so that we can re-use it for resume.
 While at it also remove the bufstate variable as we write it
 in omap_i2c_resize_fifo for every transfer.
 
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
 Applies on Felipe's series
 http://www.spinics.net/lists/linux-omap/msg79995.html
 
 Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
 on omap3636 beagle both idle and suspend.
 
 Functional testing on omap4sdp.
 
  drivers/i2c/busses/i2c-omap.c |   68 
 +
  1 files changed, 28 insertions(+), 40 deletions(-)
 
 diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
 index 5e5cefb..338cee7 100644
 --- a/drivers/i2c/busses/i2c-omap.c
 +++ b/drivers/i2c/busses/i2c-omap.c
 @@ -209,7 +209,6 @@ struct omap_i2c_dev {
   u16 pscstate;
   u16 scllstate;
   u16 sclhstate;
 - u16 bufstate;
   u16 syscstate;
   u16 westate;
   u16 errata;
 @@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev 
 *i2c_dev, int reg)
   }
  }
  
 +static void __omap_i2c_init(struct omap_i2c_dev *dev)
 +{
 +
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
 + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
 +
 + /* SCL low and high time values */
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
 + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
 + if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
 + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
 + /* Take the I2C module out of reset: */
 + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 +
 +}
  static int omap_i2c_init(struct omap_i2c_dev *dev)
  {
 - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
 + u16 psc = 0, scll = 0, sclh = 0;
   u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
   unsigned long fclk_rate = 1200;
   unsigned long timeout;
 @@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
   dev-westate = OMAP_I2C_WE_ALL;
 - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
 - dev-westate);
   }
   }
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
  
   if (dev-flags  OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
   /*
 @@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
   sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
   }
  
 - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
 - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
 -
 - /* SCL low and high time values */
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
 - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
 -
 - /* Take the I2C module out of reset: */
 - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
 -
   /* Enable interrupts */
   dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
   OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL)  |
   ((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
   OMAP_I2C_IE_XDR) : 0);
 - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
 - if (dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - dev-pscstate = psc;
 - dev-scllstate = scll;
 - dev-sclhstate = sclh;
 - dev-bufstate = buf;
 - }
 +
 + dev-pscstate = psc;
 + dev-scllstate = scll;
 + dev-sclhstate = sclh;
 +
 + __omap_i2c_init(dev);
 +
   return 0;
  }
  
 @@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
   if (IS_ERR_VALUE(r))
   goto err_free_mem;
  
 - dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)  0xff;
 + dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG)   0xff;
  
   dev-errata = 0;
  
 @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
  {
   struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
  
 - if (_dev-flags  OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
 - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
 - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
 - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG,

Re: OMAP baseline test results for v3.7-rc1

Hi

On Mon, 22 Oct 2012, Jean Pihet wrote:

 I tried the latest l-o with omap2plus defconfig on my Beagleboard B5
 (ES2.1) and could not reproduce the problem.
 I do not have the I2C error messages at boot, nor at user space start
 up. I tried to read/write the TWL RTC, successfully.
 
 Another difference is the bootloader images. I have the following:
 - Texas Instruments X-Loader 1.4.2 (Feb  3 2009 - 15:34:17)
 - U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)
 Could you send your bootloader images?

Just sent you a link via private E-mail.

 On the PM QoS side the commit 3db11fef moves the I2C code from the
 OMAP PM no-op layer to the PM QoS for CPU and DMA latency, which
 influences the cpuidle states. However CPU_IDLE is not set in
 omap2plus_defconfig so there should not be any effect.
 Do you have CPU_IDLE enabled?

No, it's omap2plus_defconfig.


- 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: OMAP baseline test results for v3.7-rc1

On Mon, 22 Oct 2012, Jean Pihet wrote:

 On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com wrote:

  Do you have CPU_IDLE enabled?
 FYI the issue is not present with CPU_IDLE enabled.

Hmm, how can you tell?  I thought you weren't able to reproduce it with 
CPU_IDLE disabled either?


- 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: OMAP baseline test results for v3.7-rc1

2012-10-23 Thread Jean Pihet

On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley p...@pwsan.com wrote:
 On Mon, 22 Oct 2012, Jean Pihet wrote:

 On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet jean.pi...@newoldbits.com 
 wrote:

  Do you have CPU_IDLE enabled?
 FYI the issue is not present with CPU_IDLE enabled.

 Hmm, how can you tell?  I thought you weren't able to reproduce it with
 CPU_IDLE disabled either?
I could not reproduce the issue, with and without CPU_IDLE enabled.
What puzzles me is that the PM QoS code only has influence on the
states chosen by cpuidle, so the change should not have any impact
with CPU_IDLE enabled. I reallt need to reproduce the issue.
Let me try with the same setup as yours (bootloader images,
omap2pus_defconfig, angstrom roots).

Regards,
Jean



 - 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: OMAP baseline test results for v3.7-rc2

On Mon, 22 Oct 2012, Tony Lindgren wrote:

 * Jon Hunter jon-hun...@ti.com [121022 09:30]:
  On 10/20/2012 04:26 PM, Paul Walmsley wrote:
   
   * 2430sdp: vfp_reload_hw oops during MMC initialization
 - Kernel attempts to save FP registers that don't exist; fix posted:
   - http://www.spinics.net/lists/arm-kernel/msg200646.html
 
 Has that one been posted to RMK's patch system?

Just did that, let's see what happens.

   * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
 - due to a GPMC bug
 - Apparently fixed by 
   http://www.spinics.net/lists/arm-kernel/msg200787.html
  
  This is now addressed and I have verified it is booting on v3.7-rc2. The
  following patch address this boot problem ...
  
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8119024ef7363591fd958ec89ebfaee7c18209e3
 
 That's in v3.7-rc2 already, is there some other problem too?

Will try a re-test.

- 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support

2012-10-23 Thread Dmitry Torokhov

On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote:
 Hi Dimitry,
 
 On 10/22/2012 05:50 PM, Dmitry Torokhov wrote:
  Hi Sourav,
  
  On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
  Adapt keypad to use pinctrl framework.
 
  Tested on omap4430 sdp with 3.7-rc1 kernel.
  
  I do not see anything in the driver that would directly use pinctrl. Is
  there a better place to select default pin configuration; maybe when
  instantiating platform device?
 
 Why?
 The devm_pinctrl_get_select_default is using the pinctrl.

No, I guess we ihave different understanding of what directly use means.
This particular driver does directly use interrupts: it requests it and
performs some actions when interrupt arrives. Same goes for IO memory -
it gets requested, then we access it. With pinctrl we do not do anything
- we just ask another layer to configure it and that is it.

I have seen just in a few days 3 or 4 drivers having exactly the same
change - call to devm_pinctrl_get_select_default(), and I guess I will
receive the same patches for the rest of input drivers shortly.
This suggests that the operation is done at the wrong level. Do the
pin configuration as you parse DT data, the same way you set up i2c
devices registers in of_i2c.c, and leave the individual drivers that do
not care about specifics alone.

 That's why it is named get_select_default and not get only.
 This API ensure that the pin will be set to the default state, and this
 is all we need to do during the probe.

Why during the probe and not by default? Realistically, the driver will
be loaded as long as there is a matching device and pins will need to be
configured.

 
 There is no point to change the mux if the driver is not probed, because
 potentially the pin can be use be another driver.

What other driver would use it? Who would chose what driver to load?

Thanks.

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

[PATCH] ARM: PMU: fix runtime PM enable

Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
use runtime PM which was prototyped and validated on the OMAP devices. In this
commit, there is no call pm_runtime_enable() and for OMAP devices
pm_runtime_enable() is currently being called from the OMAP PMU code when the
PMU device is created. However, there are two problems with this:

1. For any other ARM device wishing to use runtime PM for PMU they will need
   to call pm_runtime_enable() for runtime PM to work.
2. When booting with device-tree and using device-tree to create the PMU
   device, pm_runtime_enable() needs to be called from within the ARM PERF
   driver as we are no longer calling any device specific code to create the
   device. Hence, PMU does not work on OMAP devices that use the runtime PM
   callbacks when using device-tree to create the PMU device.

Therefore, add a new platform data variable to indicate whether runtime PM is
used and if so call pm_runtime_enable() when the PMU device is registered. Note
that devices using runtime PM may not use the runtime_resume/suspend callbacks
and so we cannot use the presence of these handlers in the platform data to
determine whether we should call pm_runtime_enable().

Tested with PERF on OMAP2420, OMAP3430 and OMAP4460.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/include/asm/pmu.h   |1 +
 arch/arm/kernel/perf_event.c |6 ++
 arch/arm/mach-omap2/pmu.c|9 +
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index a26170d..50a6c3b 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -36,6 +36,7 @@
 struct arm_pmu_platdata {
irqreturn_t (*handle_irq)(int irq, void *dev,
  irq_handler_t pmu_handler);
+   bool use_runtime_pm;
int (*runtime_resume)(struct device *dev);
int (*runtime_suspend)(struct device *dev);
 };
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 93971b1..a8c5ddf 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -515,7 +515,13 @@ static void __init armpmu_init(struct arm_pmu *armpmu)
 
 int armpmu_register(struct arm_pmu *armpmu, char *name, int type)
 {
+   struct platform_device *plat_device = armpmu-plat_device;
+   struct arm_pmu_platdata *plat = dev_get_platdata(plat_device-dev);
+
armpmu_init(armpmu);
+   if (plat  plat-use_runtime_pm)
+   pm_runtime_enable(armpmu-plat_device-dev);
+
pr_info(enabled with %s PMU driver, %d counters available\n,
armpmu-name, armpmu-num_events);
return perf_pmu_register(armpmu-pmu, name, type);
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 2a79176..1a3d4d7 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -22,6 +22,7 @@ static char *omap2_pmu_oh_names[] = {mpu};
 static char *omap3_pmu_oh_names[] = {mpu, debugss};
 static char *omap4430_pmu_oh_names[] = {l3_main_3, l3_instr, debugss};
 static struct platform_device *omap_pmu_dev;
+static struct arm_pmu_platdata omap_pmu_data;
 
 /**
  * omap2_init_pmu - creates and registers PMU platform device
@@ -49,16 +50,14 @@ static int __init omap2_init_pmu(unsigned oh_num, char 
*oh_names[])
}
}
 
-   omap_pmu_dev = omap_device_build_ss(dev_name, -1, oh, oh_num, NULL, 0,
-   NULL, 0, 0);
+   omap_pmu_dev = omap_device_build_ss(dev_name, -1, oh, oh_num,
+   omap_pmu_data, sizeof(omap_pmu_data), NULL, 0, 0);
WARN(IS_ERR(omap_pmu_dev), Can't build omap_device for %s.\n,
 dev_name);
 
if (IS_ERR(omap_pmu_dev))
return PTR_ERR(omap_pmu_dev);
 
-   pm_runtime_enable(omap_pmu_dev-dev);
-
return 0;
 }
 
@@ -85,9 +84,11 @@ static int __init omap_init_pmu(void)
} else if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
oh_num = ARRAY_SIZE(omap3_pmu_oh_names);
oh_names = omap3_pmu_oh_names;
+   omap_pmu_data.use_runtime_pm = true;
} else {
oh_num = ARRAY_SIZE(omap2_pmu_oh_names);
oh_names = omap2_pmu_oh_names;
+   omap_pmu_data.use_runtime_pm = false;
}
 
return omap2_init_pmu(oh_num, oh_names);
-- 
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

OMAP NAND driver issue with subpage reads

2012-10-23 Thread Juha Kuikka

Hi,

There seems to be an issue in the omap nand driver
(drivers/mtd/nand/omap2.c) concerning sub-page reads (visible when
using 16bit LP NAND,  SOFT_ECC and UBI).

Problem is caused by the omap_read_buf_pref() function using 32bit
reads from the pre-fetch engine. It takes care of the mis-aligned
length but not a mis-aligned buffer pointer. Combined with how the
nand_read_subpage() function aligns the pointer and length to NAND
width (8 or 16 bits) this can lead to situation where the handling of
the mis-aligned length in omap_read_buf_pref() causes the pointer to
not be aligned to 32bits and the data gets corrupted in the read. This
of course leds to ECC issues.

The way I see is there are several ways to fix this:

1. Change nand_read_subpage() to be more strict about alignment
2. Change omap_read_buf_pref() to handle any reads (len % 4) || (buf %
4) with omap_read_bufX() completely
3. Change omap_read_buf_pref() to use ioread16_rep() since buffer and
length are already aligned for us.

I'm leaning towards #2 because, assuming that the nand driver cannot
make assumptions of alignment, we need to be able to handle them all
anyway. The common case of reading big chunks of page data would still
be fast (since reads are always sub-page aligned) but the special case
of reading small OOB chunks would be handled gracefully.

Something like this:

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5c8978e..8a929cf 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -334,13 +334,12 @@ static void omap_read_buf_pref(struct mtd_info
*mtd, u_char *buf, int len)
u32 *p = (u32 *)buf;

/* take care of subpage reads */
-   if (len % 4) {
+   if (len % 4 || (unsigned long) buf % 4) {
if (info-nand.options  NAND_BUSWIDTH_16)
omap_read_buf16(mtd, buf, len % 4);
else
omap_read_buf8(mtd, buf, len % 4);
-   p = (u32 *) (buf + len % 4);
-   len -= len % 4;
+   return;
}

/* configure and start prefetch transfer */

Comments?

 - 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: OMAP baseline test results for v3.7-rc2

Matt Porter mpor...@ti.com writes:

[...]

 Ok, very quick update...no need to mess around with the eeprom. I just
 received the official word on what will be supported. Since A2 is
 pre-release, simply go to http://beagleboard.org/support/rma and fill
 out the form to have it replaced with the current revision (A6).

 This applies to *anyone* that received a pre-release A2 board.

Hmm, doesn't seem the RMA people are aware of this.  They just rejected
my request since it's not a hardware related issue:

   Kevin,

   We only work with hardware related issue here. BeagleBone revision A2
   was not officially released. We recommend you to work with the
   community for support in Uboot. You can post your questions at the
   BeagleBoard Google Groups:
   https://groups.google.com/forum/?fromgroups=#!forum/beagleboard

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

Re: OMAP baseline test results for v3.7-rc2

2012-10-23 Thread Matt Porter

On Tue, Oct 23, 2012 at 02:03:43PM -0700, Kevin Hilman wrote:
 Matt Porter mpor...@ti.com writes:
 
 [...]
 
  Ok, very quick update...no need to mess around with the eeprom. I just
  received the official word on what will be supported. Since A2 is
  pre-release, simply go to http://beagleboard.org/support/rma and fill
  out the form to have it replaced with the current revision (A6).
 
  This applies to *anyone* that received a pre-release A2 board.
 
 Hmm, doesn't seem the RMA people are aware of this.  They just rejected
 my request since it's not a hardware related issue:
 
Kevin,
 
We only work with hardware related issue here. BeagleBone revision A2
was not officially released. We recommend you to work with the
community for support in Uboot. You can post your questions at the
BeagleBoard Google Groups:
https://groups.google.com/forum/?fromgroups=#!forum/beagleboard
 
Regards,
RMA Team

That's sad considering the beagleboard.org/BeagleBone hardware designer
specifically said they would be replaced via this route. *sigh*. Ok, I'll
go back and share this with him.

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

[RFC PATCH 3/6] ARM: OMAP: voltage: move voltdm_reset to platform_data header

Move voltdm_reset to include/linux/platform_data/voltage-omap.h
This is an intermediate step to allow usage of the header by smartreflex
driver for usage of the same.

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/voltage.h  |1 -
 include/linux/platform_data/voltage-omap.h |1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index af9d469..0665f21 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -149,5 +149,4 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, 
void *user),
 int voltdm_for_each_pwrdm(struct voltagedomain *voltdm,
  int (*fn)(struct voltagedomain *voltdm,
struct powerdomain *pwrdm));
-void voltdm_reset(struct voltagedomain *voltdm);
 #endif
diff --git a/include/linux/platform_data/voltage-omap.h 
b/include/linux/platform_data/voltage-omap.h
index 5be4d5d..4eb3d43 100644
--- a/include/linux/platform_data/voltage-omap.h
+++ b/include/linux/platform_data/voltage-omap.h
@@ -36,4 +36,5 @@ int voltdm_scale(struct voltagedomain *voltdm, unsigned long 
target_volt);
 unsigned long voltdm_get_voltage(struct voltagedomain *voltdm);
 struct omap_volt_data *omap_voltage_get_voltdata(struct voltagedomain *voltdm,
unsigned long volt);
+void voltdm_reset(struct voltagedomain *voltdm);
 #endif
-- 
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

[RFC PATCH 0/6] ARM: OMAP3+: move smartreflex-class3.c to drivers/power/avs

smartreflex.c now resides in drivers/power/avs directory, but class driver
is in mach-omap2. High time we move it off to drivers/power/avs.

This series *does not* try to fix VP/VC to be voltage regulator OR introduce
a new OMAP voltage regulator series. instead, it purely tries to do the minimal
changes needed to move code to drivers/power/avs as a start.

Baseline: k.org v3.7-rc2 
Testing: Platform: beagle XM C1 (3730)
while [ 1 ]
do
echo -n 0 /sys/kernel/debug/smartreflex/smartreflex_core/autocomp
date
echo -n 1 /sys/kernel/debug/smartreflex/smartreflex_core/autocomp
done
Screen capture after the series: on inductor L5 (VDD2 - core):
https://plus.google.com/photos/112464029509057661457/albums/5715034179943520193/5802619719180530114

RFC for a view if this is ok as an intermediate step.

Nishanth Menon (6):
  PM / AVS / OMAP: move Kconfig definition of smartreflex to avs
directory
  ARM: OMAP: voltage: remove duplicate header definitions
  ARM: OMAP: voltage: move voltdm_reset to platform_data header
  ARM: OMAP: SmartReflex: provide SoC integration API for VP
  ARM: OMAP: SmartReflex: use pr_warn instead of pr_warning
  PM / AVS / OMAP: move Smartreflex-class3 driver to power/avs

 arch/arm/mach-omap2/Makefile   |1 -
 arch/arm/mach-omap2/sr_device.c|5 
 arch/arm/mach-omap2/voltage.h  |4 ---
 arch/arm/plat-omap/Kconfig |   31 
 drivers/power/avs/Kconfig  |   31 
 drivers/power/avs/Makefile |1 +
 .../power/avs}/smartreflex-class3.c|   20 +
 drivers/power/avs/smartreflex.c|2 ++
 include/linux/platform_data/voltage-omap.h |1 +
 include/linux/power/smartreflex.h  |   18 
 10 files changed, 73 insertions(+), 41 deletions(-)
 rename {arch/arm/mach-omap2 = drivers/power/avs}/smartreflex-class3.c (75%)

Regards,
Nishanth Menon
-- 
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

[RFC PATCH 1/6] PM / AVS / OMAP: move Kconfig definition of smartreflex to avs directory

Don't see why the source should be in drivers/power/avs, but not
config option

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/plat-omap/Kconfig |   22 --
 drivers/power/avs/Kconfig  |   22 ++
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7cd56ed..e5e7520 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -46,28 +46,6 @@ config OMAP_DEBUG_LEDS
depends on OMAP_DEBUG_DEVICES
select LEDS_CLASS
 
-config POWER_AVS_OMAP
-   bool AVS(Adaptive Voltage Scaling) support for OMAP IP versions 12
-   depends on POWER_AVS  (ARCH_OMAP3 || ARCH_OMAP4)  PM
-   select POWER_SUPPLY
-   help
- Say Y to enable AVS(Adaptive Voltage Scaling)
- support on OMAP containing the version 1 or
- version 2 of the SmartReflex IP.
- V1 is the 65nm version used in OMAP3430.
- V2 is the update for the 45nm version of the IP used in OMAP3630
- and OMAP4430
-
- Please note, that by default SmartReflex is only
- initialized and not enabled. To enable the automatic voltage
- compensation for vdd mpu and vdd core from user space,
- user must write 1 to
-   /debug/smartreflex/sr_X/autocomp,
- where X is mpu_iva or core for OMAP3.
- Optionally autocompensation can be enabled in the kernel
- by default during system init via the enable_on_init flag
- which an be passed as platform data to the smartreflex driver.
-
 config POWER_AVS_OMAP_CLASS3
bool Class 3 mode of Smartreflex Implementation
depends on POWER_AVS_OMAP  TWL4030_CORE
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
index 2a1008b..466a391 100644
--- a/drivers/power/avs/Kconfig
+++ b/drivers/power/avs/Kconfig
@@ -10,3 +10,25 @@ menuconfig POWER_AVS
  AVS is also called SmartReflex on OMAP devices.
 
  Say Y here to enable Adaptive Voltage Scaling class support.
+
+config POWER_AVS_OMAP
+   bool AVS(Adaptive Voltage Scaling) support for OMAP IP versions 12
+   depends on POWER_AVS  (ARCH_OMAP3 || ARCH_OMAP4)  PM
+   select POWER_SUPPLY
+   help
+ Say Y to enable AVS(Adaptive Voltage Scaling)
+ support on OMAP containing the version 1 or
+ version 2 of the SmartReflex IP.
+ V1 is the 65nm version used in OMAP3430.
+ V2 is the update for the 45nm version of the IP used in OMAP3630
+ and OMAP4430
+
+ Please note, that by default SmartReflex is only
+ initialized and not enabled. To enable the automatic voltage
+ compensation for vdd mpu and vdd core from user space,
+ user must write 1 to
+   /debug/smartreflex/sr_X/autocomp,
+ where X is mpu_iva or core for OMAP3.
+ Optionally autocompensation can be enabled in the kernel
+ by default during system init via the enable_on_init flag
+ which an be passed as platform data to the smartreflex driver.
-- 
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

[RFC PATCH 2/6] ARM: OMAP: voltage: remove duplicate header definitions

Remove duplicate definitions which are already present
in linux/platform_data/voltage-omap.h

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/voltage.h |3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 7283b7e..af9d469 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -142,7 +142,6 @@ extern void omap3xxx_voltagedomains_init(void);
 extern void am33xx_voltagedomains_init(void);
 extern void omap44xx_voltagedomains_init(void);
 
-struct voltagedomain *voltdm_lookup(const char *name);
 void voltdm_init(struct voltagedomain **voltdm_list);
 int voltdm_add_pwrdm(struct voltagedomain *voltdm, struct powerdomain *pwrdm);
 int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, void *user),
@@ -150,7 +149,5 @@ int voltdm_for_each(int (*fn)(struct voltagedomain *voltdm, 
void *user),
 int voltdm_for_each_pwrdm(struct voltagedomain *voltdm,
  int (*fn)(struct voltagedomain *voltdm,
struct powerdomain *pwrdm));
-int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt);
 void voltdm_reset(struct voltagedomain *voltdm);
-unsigned long voltdm_get_voltage(struct voltagedomain *voltdm);
 #endif
-- 
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

[RFC PATCH 5/6] ARM: OMAP: SmartReflex: use pr_warn instead of pr_warning

Minor cleanup to use the preferred pr_warn

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/smartreflex-class3.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
b/arch/arm/mach-omap2/smartreflex-class3.c
index 201e219..75a505a 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -18,8 +18,8 @@ static int sr_class3_enable(struct omap_sr *sr)
unsigned long volt = voltdm_get_voltage(sr-voltdm);
 
if (!volt) {
-   pr_warning(%s: Curr voltage unknown. Cannot enable %s\n,
-   __func__, sr-name);
+   pr_warn(%s: Curr voltage unknown. Cannot enable %s\n,
+   __func__, sr-name);
return -ENODATA;
}
if (!sr-soc_ops.vp_enable) {
-- 
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

[RFC PATCH 6/6] PM / AVS / OMAP: move Smartreflex-class3 driver to power/avs

Move the SmartReflex AVS class3 driver to AVS directory along with the
config definition

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/Makefile   |1 -
 arch/arm/plat-omap/Kconfig |9 -
 drivers/power/avs/Kconfig  |9 +
 drivers/power/avs/Makefile |1 +
 .../power/avs}/smartreflex-class3.c|0
 5 files changed, 10 insertions(+), 10 deletions(-)
 rename {arch/arm/mach-omap2 = drivers/power/avs}/smartreflex-class3.c (100%)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..1eae31d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -71,7 +71,6 @@ obj-$(CONFIG_SOC_OMAP5)   += 
omap-mpuss-lowpower.o sleep44xx.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 
 obj-$(CONFIG_POWER_AVS_OMAP)   += sr_device.o
-obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
 
 AFLAGS_sleep24xx.o :=-Wa,-march=armv6
 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index e5e7520..dba674b 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -46,15 +46,6 @@ config OMAP_DEBUG_LEDS
depends on OMAP_DEBUG_DEVICES
select LEDS_CLASS
 
-config POWER_AVS_OMAP_CLASS3
-   bool Class 3 mode of Smartreflex Implementation
-   depends on POWER_AVS_OMAP  TWL4030_CORE
-   help
- Say Y to enable Class 3 implementation of Smartreflex
-
- Class 3 implementation of Smartreflex employs continuous hardware
- voltage calibration.
-
 config OMAP_RESET_CLOCKS
bool Reset unused clocks during boot
depends on ARCH_OMAP
diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
index 466a391..4f1c1b4 100644
--- a/drivers/power/avs/Kconfig
+++ b/drivers/power/avs/Kconfig
@@ -32,3 +32,12 @@ config POWER_AVS_OMAP
  Optionally autocompensation can be enabled in the kernel
  by default during system init via the enable_on_init flag
  which an be passed as platform data to the smartreflex driver.
+
+config POWER_AVS_OMAP_CLASS3
+   bool Class 3 mode of Smartreflex Implementation
+   depends on POWER_AVS_OMAP  TWL4030_CORE
+   help
+ Say Y to enable Class 3 implementation of Smartreflex
+
+ Class 3 implementation of Smartreflex employs continuous hardware
+ voltage calibration.
diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index 0843386..ac72ec5 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_POWER_AVS_OMAP)   += smartreflex.o
+obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
b/drivers/power/avs/smartreflex-class3.c
similarity index 100%
rename from arch/arm/mach-omap2/smartreflex-class3.c
rename to drivers/power/avs/smartreflex-class3.c
-- 
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

[RFC PATCH 4/6] ARM: OMAP: SmartReflex: provide SoC integration API for VP

SoC integration of SmartReflex AVS block is varied. Some use
Voltage Processor for a hardware loop in certain OMAP SoC (called
hardware loop), while others have just the AVS block without
hardware loop automatic calibration mechanism for AVS block
to talk through. So provide the Voltage Processor API
to allow for SmartReflex class drivers to use the same.

NOTE: SmartReflex class 3 mode of operation mandates VP APIs
so, refuse to enable AVS driver if corresponding APIs are
not available.

As part of this change, remove the inclusion of voltage.h
which is no longer needed as smartreflex.h includes
linux/platform_data/voltage-omap.h which contain relevant
definitions used here.

Signed-off-by: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/smartreflex-class3.c |   16 +---
 arch/arm/mach-omap2/sr_device.c  |5 +
 drivers/power/avs/smartreflex.c  |2 ++
 include/linux/power/smartreflex.h|   18 ++
 4 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/smartreflex-class3.c 
b/arch/arm/mach-omap2/smartreflex-class3.c
index 1da8f03..201e219 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -12,7 +12,6 @@
  */
 
 #include linux/power/smartreflex.h
-#include voltage.h
 
 static int sr_class3_enable(struct omap_sr *sr)
 {
@@ -23,15 +22,26 @@ static int sr_class3_enable(struct omap_sr *sr)
__func__, sr-name);
return -ENODATA;
}
+   if (!sr-soc_ops.vp_enable) {
+   pr_warn(%s: no VP enable available.Cannot enable %s!!\n,
+   __func__, sr-name);
+   return -EINVAL;
+   }
 
-   omap_vp_enable(sr-voltdm);
+   sr-soc_ops.vp_enable(sr-voltdm);
return sr_enable(sr-voltdm, volt);
 }
 
 static int sr_class3_disable(struct omap_sr *sr, int is_volt_reset)
 {
+   if (!sr-soc_ops.vp_enable) {
+   pr_warn(%s: no VP disable available.Cannot disable %s!!\n,
+   __func__, sr-name);
+   return -EINVAL;
+   }
sr_disable_errgen(sr-voltdm);
-   omap_vp_disable(sr-voltdm);
+
+   sr-soc_ops.vp_disable(sr-voltdm);
sr_disable(sr-voltdm);
if (is_volt_reset)
voltdm_reset(sr-voltdm);
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index f8217a5..6aac2c7 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -139,6 +139,11 @@ static int __init sr_dev_init(struct omap_hwmod *oh, void 
*user)
 
sr_data-enable_on_init = sr_enable_on_init;
 
+   if (sr_data-voltdm-vp) {
+   sr_data-soc_ops.vp_enable = omap_vp_enable;
+   sr_data-soc_ops.vp_disable = omap_vp_disable;
+   }
+
pdev = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
 NULL, 0, 0);
if (IS_ERR(pdev))
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index 24768a2..32a9e3e 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -920,6 +920,8 @@ static int __init omap_sr_probe(struct platform_device 
*pdev)
sr_info-pdev = pdev;
sr_info-srid = pdev-id;
sr_info-voltdm = pdata-voltdm;
+   sr_info-soc_ops.vp_enable =  pdata-soc_ops.vp_enable;
+   sr_info-soc_ops.vp_disable =  pdata-soc_ops.vp_disable;
sr_info-nvalue_table = pdata-nvalue_table;
sr_info-nvalue_count = pdata-nvalue_count;
sr_info-senn_mod = pdata-senn_mod;
diff --git a/include/linux/power/smartreflex.h 
b/include/linux/power/smartreflex.h
index 4a496eb..203fc64 100644
--- a/include/linux/power/smartreflex.h
+++ b/include/linux/power/smartreflex.h
@@ -143,6 +143,21 @@
 #define OMAP3430_SR_ERRWEIGHT  0x04
 #define OMAP3430_SR_ERRMAXLIMIT0x02
 
+/**
+ * struct omap_sr_soc_ops - SoC specific APIs
+ * @vp_enable: Voltage Processor enable
+ * @vp_disable:Voltage Processor disable
+ *
+ * SmartReflex AVS module integration tends to be SoC
+ * variant. some are integrated with modules like
+ * Voltage Processor (VP), while, some SoC integration
+ * donot use VP. Provide that variance here.
+ */
+struct omap_sr_soc_ops {
+   void (*vp_enable)(struct voltagedomain *voltdm);
+   void (*vp_disable)(struct voltagedomain *voltdm);
+};
+
 struct omap_sr {
char*name;
struct list_headnode;
@@ -165,6 +180,7 @@ struct omap_sr {
u32 senp_mod;
u32 senn_mod;
void __iomem*base;
+   struct omap_sr_soc_ops  soc_ops;
 };
 
 /**
@@ -268,6 +284,7 @@ struct omap_sr_nvalue_table {
  * @nvalue_table:  table containing the  efuse offsets and nvalues
  * corresponding to them.
  * @voltdm:

Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable

Felipe Balbi ba...@ti.com writes:

 Hi,

 On Tue, Oct 23, 2012 at 11:09:31AM -0700, Kevin Hilman wrote:
 From: Kevin Hilman khil...@ti.com
 
 When debounce clocks are disabled, ensure that the banks
 dbck_enable_mask is cleared also.  Otherwise, context restore on
 subsequent off-mode transition will restore previous value from the
 shadow copies (bank-context.debounce*) leading to mismatch state
 between driver state and hardware state.
 
 This was discovered when board code was doing
 
   gpio_request_one()
   gpio_set_debounce()
   gpio_free()
 
 which was leaving the GPIO debounce settings in a confused state.
 Then, enabling off mode causing bogus state to be restored, leaving
 GPIO debounce enabled which then prevented the CORE powerdomain from
 transitioning.
 
 Reported-by: Paul Walmsley p...@pwsan.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com

 looks like this deserves a Cc: sta...@vger.kernel.org tag.


Agreed.  I think this goes all the way back to v3.5, but would've only
been seen on boards using a request/gpio_set_debounce/free sequence
combined with off-mode.

Linus, feel free to add the Cc: stable when commiting.  Thanks.

 ---
 Applies on v3.7-rc2, targetted for v3.7.
 
  drivers/gpio/gpio-omap.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 94cbc84..dee2856 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank 
 *bank)
   * to detect events and generate interrupts at least on OMAP3.
   */
  __raw_writel(0, bank-base + bank-regs-debounce_en);
 +bank-dbck_enable_mask = 0;

 shouldn't omap_gpio_restore_context() check for dbck_enabled instead of
 the mask ? I mean:

 diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
 index 94cbc84..b3a39a7 100644
 --- a/drivers/gpio/gpio-omap.c
 +++ b/drivers/gpio/gpio-omap.c
 @@ -1371,7 +1371,7 @@ static void omap_gpio_restore_context(struct gpio_bank 
 *bank)
   bank-base + bank-regs-dataout);
   __raw_writel(bank-context.oe, bank-base + bank-regs-direction);
  
 - if (bank-dbck_enable_mask) {
 + if (bank-dbck_enabled) {
   __raw_writel(bank-context.debounce, bank-base +
   bank-regs-debounce);
   __raw_writel(bank-context.debounce_en,

 the outcome would be the same, so it doesn't really matter. Just that,
 at least to me, it would look better.

I tried your version, and unfortunately, the outcome is not the same,
but don't plan to look into why.  $SUBJECT version is targetted and
tested.  If you want to cleanup the cosmetics here, please do in a
subsequent patch.  This driver could certainly benefit from more
readability cleanups.

 No strong feelings though.

Good.   I'll take that as an Ack.  :)

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 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod

On Mon, Oct 22, 2012 at 07:49:47PM +, Paul Walmsley wrote:
On Mon, 22 Oct 2012, Mark A. Greer wrote:

On Sat, Oct 20, 2012 at 07:40:19PM +, Paul Walmsley wrote:

static void omap_init_sham(void)
{
- if (cpu_is_omap24xx()) {
- sham_device.resource = omap2_sham_resources;
- sham_device.num_resources = omap2_sham_resources_sz;
+ if (cpu_is_omap24xx()
+ (omap2_cm_read_mod_reg(CORE_MOD, OMAP24XX_CM_IDLEST4)
+OMAP24XX_ST_SHA_MASK))
{

Hmm. Not sure I understand the purpose of this CM read. Don't we want
to
initialize this device unconditionally?

No, the device doesn't exist on all parts.

It should exist on all OMAP2xxx, AFAIK. (Whether some bootloader
firewalled it off is another matter, of course.)

This is the only way to tell if its there (AFAIK).

Hmm. I don't think the CM_IDLEST bits work that way, in the general case.
They just indicate whether the PRCM considers that IP block to be
currently accessible. So for example if the clocks are disabled to an IP
block, the CM_IDLEST bit would indicate that it's not accessible. The
software could then enable the clocks, and the CM_IDLEST bit would
indicate that it is accessible. We use this in the clock framework and
hwmod code after enabling clocks to wait until the system considers the IP
block accessible. See for example

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/clock.c;h=961ac8f7e13d8c84a1cbb4587255ea685520bd18;hb=HEAD#l80

...

Now it's possible that on some TI chips, the CM_IDLEST bit is tied to the
SIdleAck signal originating from the IP block. (I've been told that on
other OMAPs, CM_IDLEST is actually tied to the SIdleReq signal originating
from the PRCM, which is not terribly useful...) So if it's tied to the
SIdleAck signal, and the PRCM clocks are enabled, then it might provide an
indication of whether the IP block exists on that chip. But ultimately
the IP block might still be firewalled off even if it appears to exist to
the PRCM. So for 3xxx, I'd suggest just adding it to the appropriate
GP-specific hwmod init lists, such as omap3xxx_gp_hwmod_ocp_ifs.

Paul, thank you for the clear explanation.

I've talked to some hardware guys and I have come to the following
conclusions:

a) What you say above about CM_IDLEST is correct.
b) There seems to be no good way, in general, to tell if the SHA
(or AES or RNG or ...) module exists.
c) The best thing to do is what you suggest and add the SHA hwmod
data for all omap2's and omap3 GP's.

I will respin my patches with everyone's comments addressed later today.

Thanks everyone.

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

[GIT PULL] ARM: OMAP: PM fixes for v3.7-rc3

Tony,

Here are a few more fixes PM-related fixes for v3.7-rc

Kevin


The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:

  Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
tags/for_3.7-rc3-fixes-pm

for you to fetch changes up to 65bf7ca0005d7d827596d5df28583c83c9158da6:

  ARM: OMAP3: Beagle: fix OPP customization and initcall ordering (2012-10-22 
16:01:42 -0700)


Misc. OMAP PM-related fixes for v3.7-rc


Kevin Hilman (2):
  ARM: OMAP2: UART: fix console UART mismatched runtime PM status
  ARM: OMAP3: Beagle: fix OPP customization and initcall ordering

Paul Walmsley (1):
  ARM: OMAP3: PM: apply part of the erratum i582 workaround

 arch/arm/mach-omap2/board-omap3beagle.c | 22 +-
 arch/arm/mach-omap2/pm.h|  1 +
 arch/arm/mach-omap2/pm34xx.c| 30 --
 arch/arm/mach-omap2/serial.c|  5 +
 4 files changed, 47 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] genirq: provide means to retrigger parent

Russell King - ARM Linux li...@arm.linux.org.uk writes:

 On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
 From: Thomas Gleixner t...@linutronix.de
 
 Attempts to retrigger nested threaded IRQs currently fail because they
 have no primary handler.  In order to support retrigger of nested
 IRQs, the parent IRQ needs to be retriggered.
 
 To fix, when an IRQ needs to be resent, if the interrupt has a parent
 IRQ and runs in the context of the parent IRQ, then resend the parent.
 
 Also, handle_nested_irq() needs to clear the replay flag like the
 other handlers, otherwise check_irq_resend() will set it and it will
 never be cleared.  Without clearing, it results in the first resend
 working fine, but check_irq_resend() returning early on subsequent
 resends because the replay flag is still set.
 
 Problem discovered on ARM/OMAP platforms where a nested IRQ that's
 also a wakeup IRQ happens late in suspend and needed to be retriggered
 during the resume process.
 
 Reported-by: Kevin Hilman khil...@ti.com
 Tested-by: Kevin Hilman khil...@ti.com
 [khil...@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
 Signed-off-by: Thomas Gleixner t...@linutronix.de

 Umm, we also have the converse situation.  We have platforms where the
 resend has to be done from the child IRQ, and the parent must not be
 touched.  I hope that doesn't break those.

I'm assuming the child IRQs you're concerned with are not threaded,
right?  This patch only addresses nested, threaded IRQs, and these don't
have a primary handler to run at all, so cannot do any triggering.

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] genirq: provide means to retrigger parent

2012-10-23 Thread Thomas Gleixner

On Tue, 23 Oct 2012, Kevin Hilman wrote:

 Russell King - ARM Linux li...@arm.linux.org.uk writes:
 
  On Tue, Oct 16, 2012 at 03:07:49PM -0700, Kevin Hilman wrote:
  From: Thomas Gleixner t...@linutronix.de
  
  Attempts to retrigger nested threaded IRQs currently fail because they
  have no primary handler.  In order to support retrigger of nested
  IRQs, the parent IRQ needs to be retriggered.
  
  To fix, when an IRQ needs to be resent, if the interrupt has a parent
  IRQ and runs in the context of the parent IRQ, then resend the parent.
  
  Also, handle_nested_irq() needs to clear the replay flag like the
  other handlers, otherwise check_irq_resend() will set it and it will
  never be cleared.  Without clearing, it results in the first resend
  working fine, but check_irq_resend() returning early on subsequent
  resends because the replay flag is still set.
  
  Problem discovered on ARM/OMAP platforms where a nested IRQ that's
  also a wakeup IRQ happens late in suspend and needed to be retriggered
  during the resume process.
  
  Reported-by: Kevin Hilman khil...@ti.com
  Tested-by: Kevin Hilman khil...@ti.com
  [khil...@ti.com: changelog edits, clear IRQS_REPLAY in handle_nested_irq()]
  Signed-off-by: Thomas Gleixner t...@linutronix.de
 
  Umm, we also have the converse situation.  We have platforms where the
  resend has to be done from the child IRQ, and the parent must not be
  touched.  I hope that doesn't break those.
 
 I'm assuming the child IRQs you're concerned with are not threaded,
 right?  This patch only addresses nested, threaded IRQs, and these don't
 have a primary handler to run at all, so cannot do any triggering.

And it involves that you activly set the parent irq via the new
interface: irq_set_parent()

You don't have that yet or you don't use that in your future changes,
then you're good. :)

Thanks,

tglx


--
To unsubscribe from this list: send the line unsubscribe 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 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

Hi Mitch,

On 10/23/2012 11:55 AM, Mitch Bradley wrote:
 On 10/23/2012 4:49 AM, Jon Hunter wrote:
 
 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.
 
 I strongly suspect (based on many years of performance tuning, with
 special focus on boot time) that the time difference will be completely
 insignificant.  The total extra time for walking up the interrupt tree
 for every interrupt in a large system is comparable to the time it takes
 to send a few characters out a UART.  So you can get more improvement
 from eliminating a single printk() than from globally adding per-node
 interrupt-parent.
 
 Furthermore, the cost of processing all of the interrupt-parent
 properties is probably similar to the cost of the avoided tree walks.
 
 CPU cycles are very fast compared to I/O register accesses, say a factor
 of 100.  Now consider that many modern devices contain embedded
 microcontrollers (SD cards, network interface modules, USB hubs and
 devices, ...), and those devices usually require various delays measured
 in milliseconds, to ensure that the microcontroller is ready for the
 next initialization step.  Those delays are extremely long compared to
 CPU cycles.  Obviously, some of that can be overlapped by careful
 multithreading, but that isn't free either.
 
 The bottom line is that I'm pretty sure that adding per-node
 interrupt-parent would not be worthwhile from the standpoint of speeding
 up boot time.

Absolutely, I don't expect this to miraculously improve the boot time or
suggest that this is a major contributor to boot time, but what is the
best approach in general in terms of efficiency (memory and time). In
other words, is there a best practice? And from your feedback, I
understand that adding a global interrupt-parent is a good practice.

For a bit of fun, I took an omap4430 board and benchmarked the time
taken by the of_irq_find_parent() when interrupt-parent was defined for
each node using interrupts and without.

There were a total of 47 device nodes using interrupts. Adding the
interrupt-parent to all 47 nodes increased the dtb from 13211 bytes to
13963 bytes.

On boot-up I saw 117 calls to of_irq_find_parent() for this platform
(there appears to be multiple calls for a given device). Without
interrupt-parent defined for each node total time spent in
of_irq_find_parent() was 1.028 ms where as with interrupt-parent defined
for each node the total time was 0.4032 ms. This was done using a
38.4MHz timer and the overhead of reading the timer 117 times was about
36 us.

I understand that this does not provide the full picture, but I wanted
to get a better handle on the times here. So yes the overall overhead
here is not significant for us to worry about.

Cheers
Jon


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

Re: [PATCH v2 1/4] ARM: dts: omap5: Update GPIO with address space and interrupts

On 10/23/2012 1:15 PM, Jon Hunter wrote:
 Hi Mitch,
 
 On 10/23/2012 11:55 AM, Mitch Bradley wrote:
 On 10/23/2012 4:49 AM, Jon Hunter wrote:

 Therefore, I believe it will improve search time and hence, boot time if
 we have interrupt-parent defined in each node.

 I strongly suspect (based on many years of performance tuning, with
 special focus on boot time) that the time difference will be completely
 insignificant.  The total extra time for walking up the interrupt tree
 for every interrupt in a large system is comparable to the time it takes
 to send a few characters out a UART.  So you can get more improvement
 from eliminating a single printk() than from globally adding per-node
 interrupt-parent.

 Furthermore, the cost of processing all of the interrupt-parent
 properties is probably similar to the cost of the avoided tree walks.

 CPU cycles are very fast compared to I/O register accesses, say a factor
 of 100.  Now consider that many modern devices contain embedded
 microcontrollers (SD cards, network interface modules, USB hubs and
 devices, ...), and those devices usually require various delays measured
 in milliseconds, to ensure that the microcontroller is ready for the
 next initialization step.  Those delays are extremely long compared to
 CPU cycles.  Obviously, some of that can be overlapped by careful
 multithreading, but that isn't free either.

 The bottom line is that I'm pretty sure that adding per-node
 interrupt-parent would not be worthwhile from the standpoint of speeding
 up boot time.
 
 Absolutely, I don't expect this to miraculously improve the boot time or
 suggest that this is a major contributor to boot time, but what is the
 best approach in general in terms of efficiency (memory and time). In
 other words, is there a best practice? And from your feedback, I
 understand that adding a global interrupt-parent is a good practice.

From a maintenance standpoint, saying it once is best practice.  Time
that you don't spend doing unnecessary maintenance can be spent looking
for other, higher value, improvements.  And when you do need to optimize
something, it's much easier if the function is centralized.

Pushing the interrupt parent up the tree to the appropriate point can
make the next platform easier, opening the possibility of changing just
one thing instead of several dozen.

There have been several cases when I have violated good factoring in
order to save a little time, only to have to undo it later when the next
system was enough different that the de-factored version didn't work.

So, while there are certainly cases where you are forced to do
otherwise, I generally like the don't repeat yourself mantra.

 
 For a bit of fun, I took an omap4430 board and benchmarked the time
 taken by the of_irq_find_parent() when interrupt-parent was defined for
 each node using interrupts and without.
 
 There were a total of 47 device nodes using interrupts. Adding the
 interrupt-parent to all 47 nodes increased the dtb from 13211 bytes to
 13963 bytes.
 
 On boot-up I saw 117 calls to of_irq_find_parent() for this platform
 (there appears to be multiple calls for a given device). Without
 interrupt-parent defined for each node total time spent in
 of_irq_find_parent() was 1.028 ms where as with interrupt-parent defined
 for each node the total time was 0.4032 ms. This was done using a
 38.4MHz timer and the overhead of reading the timer 117 times was about
 36 us.

That sounds about right.  The savings of 600 us is 6 characters at
115200 baud.

 
 I understand that this does not provide the full picture, but I wanted
 to get a better handle on the times here. So yes the overall overhead
 here is not significant for us to worry about.

Big ticket items for boot time improvement are time spent waiting for
peripheral devices to become ready and time spent spewing diagnostic
messages.  But in the final analysis, you just have to measure what is
happening and see what you can do to improve it.  In my experience, CPU
cycles are rarely problematic, unless they are artificially slowed down
due to caches being off or due to direct execution from slow memory like
ROMs.

I once shaved an hour off the startup time for a PowerPC system by
moving some critical code into cache.  This was on a prototype chip
that was being emulated by arrays of FPGAs.

On the first generation OLPC XO-1 machine we were really interested in
super-fast wakeup from suspend.  I tuned that firmware code path to the
nth degree, finally getting stuck at 2 ms because you had to wait that
long before accessing the PCI bus interface, otherwise the SD controller
chip would lock up.  Then I transferred control to the kernel, which had
to wait something like 40 ms (two display frame times) to re-sync the
video subsystem, then it had to re-enable the USB subsystem, which ended
up taking a good fraction of a second.

Things haven't gotten much better (in fact they are probably worse),
because, even the the CPUs have gotten

Re: [GIT PULL] ARM: OMAP: PM fixes for v3.7-rc3

2012-10-23 Thread Tony Lindgren

* Kevin Hilman khil...@deeprootsystems.com [121023 15:15]:
 Tony,
 
 Here are a few more fixes PM-related fixes for v3.7-rc
 
 Kevin
 
 
 The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
 
   Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
 tags/for_3.7-rc3-fixes-pm
 
 for you to fetch changes up to 65bf7ca0005d7d827596d5df28583c83c9158da6:
 
   ARM: OMAP3: Beagle: fix OPP customization and initcall ordering (2012-10-22 
 16:01:42 -0700)
 
 
 Misc. OMAP PM-related fixes for v3.7-rc

Thanks pulling into omap-for-v3.7-rc1/fixes.

Regards,

Tony
 
 
 Kevin Hilman (2):
   ARM: OMAP2: UART: fix console UART mismatched runtime PM status
   ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
 
 Paul Walmsley (1):
   ARM: OMAP3: PM: apply part of the erratum i582 workaround
 
  arch/arm/mach-omap2/board-omap3beagle.c | 22 +-
  arch/arm/mach-omap2/pm.h|  1 +
  arch/arm/mach-omap2/pm34xx.c| 30 --
  arch/arm/mach-omap2/serial.c|  5 +
  4 files changed, 47 insertions(+), 11 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)

2012-10-23 Thread Tony Lindgren

* Ohad Ben-Cohen o...@wizery.com [121021 07:56]:
 On Fri, Oct 19, 2012 at 7:07 PM, Tony Lindgren t...@atomide.com wrote:
 --- a/arch/arm/mach-davinci/board-da850-evm.c
 +++ b/arch/arm/mach-davinci/board-da850-evm.c
 @@ -1401,13 +1401,9 @@ static __init int da850_wl12xx_init(void)
   goto free_wlan_en;
   }
 
 - da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
 -
 - ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data);
 - if (ret) {
 - pr_err(Could not set wl12xx data: %d\n, ret);
 + ret = wl12xx_board_init(da850_wl12xx_wlan_data, DA850_WLAN_IRQ);
 + if (ret)
   goto free_wlan_irq;
 - }
 
   return 0;

I don't think mach-davinci has wl12xx_board_init() available?
Maybe leave this out or define also also somewhere for mach-davinci?

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: [PATCH] ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driver

2012-10-23 Thread Tony Lindgren

* Jon Hunter jon-hun...@ti.com [121017 11:57]:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 Add dmtimer clock aliases for AM33XX devices so that the parent clock for
 the dmtimer can be set correctly by the dmtimer driver. Without these clock
 aliases the dmtimer driver will fail to find the parent clocks for the 
 dmtimer.
 
 Verified that DMTIMERs can be successfully requested on AM335x beagle bone.
 
 Original patch was provided by Vaibhav Hiremath [1]. Changelog and
 additional verification performed by Jon Hunter.
 
 [1] http://marc.info/?l=linux-omapm=134693631608018w=2
 
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 Tested-by: Jon Hunter jon-hun...@ti.com

Thanks applying into omap-for-v3.7-rc2/fixes.

Regards,

Tony

 ---
  arch/arm/mach-omap2/clock33xx_data.c |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/clock33xx_data.c 
 b/arch/arm/mach-omap2/clock33xx_data.c
 index 114ab4b..1a45d6b 100644
 --- a/arch/arm/mach-omap2/clock33xx_data.c
 +++ b/arch/arm/mach-omap2/clock33xx_data.c
 @@ -1073,6 +1073,8 @@ static struct omap_clk am33xx_clks[] = {
   CLK(NULL,   gfx_fck_div_ck,   gfx_fck_div_ck,
 CK_AM33XX),
   CLK(NULL,   sysclkout_pre_ck, sysclkout_pre_ck,  
 CK_AM33XX),
   CLK(NULL,   clkout2_ck,   clkout2_ck,CK_AM33XX),
 + CLK(NULL,   timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
 + CLK(NULL,   timer_sys_ck, sys_clkin_ck,  CK_AM33XX),
  };
  
  int __init am33xx_clk_init(void)
 -- 
 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
--
To unsubscribe from this list: send the line unsubscribe 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 0/7] crypto: omap-sham updates

From: Mark A. Greer mgr...@animalcreek.com

Changes since v1:
- Removed the check of CM_IDLEST to see if the module exists
  and instead add the hwmod data for all omap2's and omap3 GP's.
- Placed new sha_ick clk entries after the 'omap-sham' entry
  in the clockxxx_data.c files
- Removed cpu_is_xxx() checks in
  arch/arm/mach-omap2/devices.c:omap_init_sham()
- Rebased on the latest k.o. kernel


This series updates the crypto omap-sham driver and supporting
infrastructure.

Notes:

a) Based on current k.o. 2d1f4c8 (Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux)

b) Since these patches will likely go though the OMAP tree (and not
   through the crypto tree), it would be nice if the crypto guy(s)
   would ACK or NACK patches 5-7 which modify the
   drivers/crypto/omap-sham.c driver.

c) These have only been tested on an omap2420 h4 and an am37x evm.  If you
   have different hardware available and a few minutes, please test them.
   A quick and easy test is to enable tcrypt as a module
   (CONFIG_CRYPTO_TEST=m), boot, then run 'modprobe tcrypt sec=2 mode=403'.
   'CONFIG_CRYPTO_SHA1' and 'CONFIG_CRYPTO_DEV_OMAP_SHAM' also have to be
   enabled.  A quick 'grep omap-sham /proc/interrupts' will tell you if
   the omap-sham driver was really used.

d) To test these patches, you will likely need...
   i) The patch included here:
   http://marc.info/?l=kernel-janitorsm=134910841909057w=2
   ii) This patch from linux-omap/master:
   27615a9 (ARM: OMAP: Trivial driver changes to remove include
   plat/cpu.h)
   iii) This patch from Paul Walmsley:
   http://www.spinics.net/lists/linux-omap/msg79436.html

e) If you prefer, a version you can test is available at
   g...@github.com:mgreeraz/linux-mag.git mag/wip/crypto/test

f) There is a reduction in DMA performance after switching to dmaengine
   (see http://www.spinics.net/lists/linux-omap/msg79855.html)

g) Many thanks to Jon Hunter for testing on his omap2420 h4.

Mark A. Greer (7):
  ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
  ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module
  ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
  ARM: OMAP2+: Remove unnecessary message when no SHA IP is present
  crypto: omap-sham: Convert to use pm_runtime API
  crypto: omap-sham: Add code to use dmaengine API
  crypto: omap_sham: Remove usage of private DMA API

 arch/arm/mach-omap2/clock2420_data.c   |   1 +
 arch/arm/mach-omap2/clock2430_data.c   |   1 +
 arch/arm/mach-omap2/clock3xxx_data.c   |   1 +
 arch/arm/mach-omap2/devices.c  |  81 +++--
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   1 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   1 +
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |  18 ++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |  43 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  60 +++
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |   2 +
 drivers/crypto/omap-sham.c | 192 +++--
 11 files changed, 250 insertions(+), 151 deletions(-)

-- 
1.7.12


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

[PATCH v2 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod

From: Mark A. Greer mgr...@animalcreek.com

Convert the device data for the OMAP2 SHAM crypto IP from
explicit platform_data to hwmod.

CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 arch/arm/mach-omap2/clock2430_data.c   |  1 +
 arch/arm/mach-omap2/devices.c  | 34 
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |  1 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |  1 +
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 +++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 37 ++
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |  2 ++
 7 files changed, 73 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/clock2430_data.c 
b/arch/arm/mach-omap2/clock2430_data.c
index 22404fe..4d52ec6 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL,   sdrc_ick, sdrc_ick,  CK_243X),
CLK(NULL,   des_ick,  des_ick,   CK_243X),
CLK(omap-sham,ick,  sha_ick,   CK_243X),
+   CLK(NULL,   sha_ick,  sha_ick,   CK_242X),
CLK(omap_rng, ick,  rng_ick,   CK_243X),
CLK(NULL,   rng_ick,  rng_ick,   CK_243X),
CLK(omap-aes, ick,  aes_ick,   CK_243X),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..f18fa50 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -34,6 +34,8 @@
 #include mux.h
 #include control.h
 #include devices.h
+#include cm2xxx_3xxx.h
+#include cm-regbits-24xx.h
 
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
@@ -453,24 +455,6 @@ static void omap_init_rng(void)
 
 #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || 
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
 
-#ifdef CONFIG_ARCH_OMAP2
-static struct resource omap2_sham_resources[] = {
-   {
-   .start  = OMAP24XX_SEC_SHA1MD5_BASE,
-   .end= OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = 51 + OMAP_INTC_START,
-   .flags  = IORESOURCE_IRQ,
-   }
-};
-static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
-#else
-#define omap2_sham_resources   NULL
-#define omap2_sham_resources_sz0
-#endif
-
 #ifdef CONFIG_ARCH_OMAP3
 static struct resource omap3_sham_resources[] = {
{
@@ -501,16 +485,24 @@ static struct platform_device sham_device = {
 static void omap_init_sham(void)
 {
if (cpu_is_omap24xx()) {
-   sham_device.resource = omap2_sham_resources;
-   sham_device.num_resources = omap2_sham_resources_sz;
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
+
+   oh = omap_hwmod_lookup(sham);
+   if (!oh)
+   return;
+
+   pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
+0, 0);
+   WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
} else if (cpu_is_omap34xx()) {
sham_device.resource = omap3_sham_resources;
sham_device.num_resources = omap3_sham_resources_sz;
+   platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
return;
}
-   platform_device_register(sham_device);
 }
 #else
 static inline void omap_init_sham(void) { }
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b5db600..b102a53 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -603,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] 
__initdata = {
omap2420_l4_core__mcbsp2,
omap2420_l4_core__msdi1,
omap2xxx_l4_core__rng,
+   omap2xxx_l4_core__sham,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
omap2420_l3__gpmc,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b1ce7b0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -963,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] 
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2xxx_l4_core__rng,
+   omap2xxx_l4_core__sham,
omap2430_l4_wkup__counter_32k,
omap2430_l3__gpmc,
NULL,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index 1a1287d..bb314c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++

[PATCH v2 2/7] ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module

From: Mark A. Greer mgr...@animalcreek.com

The current OMAP2 SHAM support doesn't enable DMA
so add that support so it can use DMA just like OMAP3.

CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 2 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
index bb314c5..4b4fd5f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
@@ -405,5 +405,5 @@ struct omap_hwmod_ocp_if omap2xxx_l4_core__sham = {
.slave  = omap2xxx_sham_hwmod,
.clk= sha_ick,
.addr   = omap2xxx_sham_addrs,
-   .user   = OCP_USER_MPU,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index a041670..703b269 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -873,9 +873,15 @@ struct omap_hwmod_irq_info omap2_sham_mpu_irqs[] = {
{ .irq = -1 }
 };
 
+struct omap_hwmod_dma_info omap2_sham_sdma_chs[] = {
+   { .name = rx, .dma_req = OMAP24XX_DMA_SHA1MD5_RX },
+   { .dma_req = -1 }
+};
+
 struct omap_hwmod omap2xxx_sham_hwmod = {
.name   = sham,
.mpu_irqs   = omap2_sham_mpu_irqs,
+   .sdma_reqs  = omap2_sham_sdma_chs,
.main_clk   = l4_ck,
.prcm   = {
.omap2 = {
-- 
1.7.12

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

[PATCH v2 4/7] ARM: OMAP2+: Remove unnecessary message when no SHA IP is present

From: Mark A. Greer mgr...@animalcreek.com

Remove the error message that prints when there is no SHA IP
present to make it consistent with all the other IPs.

CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 arch/arm/mach-omap2/devices.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index f38ac9d..f41c793 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -456,20 +456,15 @@ static void omap_init_rng(void)
 
 static void __init omap_init_sham(void)
 {
-   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
-   struct omap_hwmod *oh;
-   struct platform_device *pdev;
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
 
-   oh = omap_hwmod_lookup(sham);
-   if (!oh)
-   return;
+   oh = omap_hwmod_lookup(sham);
+   if (!oh)
+   return;
 
-   pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
-0, 0);
-   WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
-   } else {
-   pr_err(%s: platform not supported\n, __func__);
-   }
+   pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL, 0, 0);
+   WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
 }
 
 #if defined(CONFIG_CRYPTO_DEV_OMAP_AES) || 
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
-- 
1.7.12

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

[PATCH v2 3/7] ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod

From: Mark A. Greer mgr...@animalcreek.com

Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
from explicit platform_data to hwmod.

CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 arch/arm/mach-omap2/clock3xxx_data.c   |  1 +
 arch/arm/mach-omap2/devices.c  | 42 ++---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 60 ++
 3 files changed, 64 insertions(+), 39 deletions(-)

diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 1f42c9d..6f14d9b 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3342,6 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   icr_ick,  icr_ick,   CK_34XX | CK_36XX),
CLK(omap-aes, ick,  aes2_ick,  CK_34XX | CK_36XX),
CLK(omap-sham,ick,  sha12_ick, CK_34XX | CK_36XX),
+   CLK(NULL,   sha12_ick,sha12_ick, CK_34XX | CK_36XX),
CLK(NULL,   des2_ick, des2_ick,  CK_34XX | CK_36XX),
CLK(omap_hsmmc.1, ick,  mmchs2_ick,CK_3XXX),
CLK(omap_hsmmc.0, ick,  mmchs1_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index f18fa50..f38ac9d 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -36,6 +36,7 @@
 #include devices.h
 #include cm2xxx_3xxx.h
 #include cm-regbits-24xx.h
+#include cm-regbits-34xx.h
 
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
@@ -453,38 +454,9 @@ static void omap_init_rng(void)
WARN(IS_ERR(pdev), Can't build omap_device for omap_rng\n);
 }
 
-#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || 
defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct resource omap3_sham_resources[] = {
-   {
-   .start  = OMAP34XX_SEC_SHA1MD5_BASE,
-   .end= OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = 49 + OMAP_INTC_START,
-   .flags  = IORESOURCE_IRQ,
-   },
-   {
-   .start  = OMAP34XX_DMA_SHA1MD5_RX,
-   .flags  = IORESOURCE_DMA,
-   }
-};
-static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
-#else
-#define omap3_sham_resources   NULL
-#define omap3_sham_resources_sz0
-#endif
-
-static struct platform_device sham_device = {
-   .name   = omap-sham,
-   .id = -1,
-};
-
-static void omap_init_sham(void)
+static void __init omap_init_sham(void)
 {
-   if (cpu_is_omap24xx()) {
+   if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
struct omap_hwmod *oh;
struct platform_device *pdev;
 
@@ -495,18 +467,10 @@ static void omap_init_sham(void)
pdev = omap_device_build(omap-sham, -1, oh, NULL, 0, NULL,
 0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for omap-sham\n);
-   } else if (cpu_is_omap34xx()) {
-   sham_device.resource = omap3_sham_resources;
-   sham_device.num_resources = omap3_sham_resources_sz;
-   platform_device_register(sham_device);
} else {
pr_err(%s: platform not supported\n, __func__);
-   return;
}
 }
-#else
-static inline void omap_init_sham(void) { }
-#endif
 
 #if defined(CONFIG_CRYPTO_DEV_OMAP_AES) || 
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..785a0c5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3543,6 +3543,65 @@ static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_core - SHAM2 (SHA1/MD5) (similar to omap24xx) */
+static struct omap_hwmod_class_sysconfig omap3_sham_sysc = {
+   .rev_offs   = 0x5c,
+   .sysc_offs  = 0x60,
+   .syss_offs  = 0x64,
+   .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
+  SYSS_HAS_RESET_STATUS),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_sham_class = {
+   .name   = sham,
+   .sysc   = omap3_sham_sysc,
+};
+
+struct omap_hwmod_irq_info omap3_sham_mpu_irqs[] = {
+   { .irq = 49 + OMAP_INTC_START, },
+   { .irq = -1 }
+};
+
+struct omap_hwmod_dma_info omap3_sham_sdma_reqs[] = {
+   { .name = rx, .dma_req = OMAP34XX_DMA_SHA1MD5_RX, },
+   { .dma_req = -1 }
+};
+
+struct omap_hwmod omap3xxx_sham_hwmod = {
+   .name   = sham,
+   .mpu_irqs   = omap3_sham_mpu_irqs,
+   .sdma_reqs  = omap3_sham_sdma_reqs,
+   .main_clk   = sha12_ick,
+   .prcm   = {
+

[PATCH v2 5/7] crypto: omap-sham: Convert to use pm_runtime API

From: Mark A. Greer mgr...@animalcreek.com

Convert the omap-sham crypto driver to use the
pm_runtime API instead of the clk API.

CC: Kevin Hilman khil...@deeprootsystems.com
CC: Paul Walmsley p...@pwsan.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 drivers/crypto/omap-sham.c | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index a3fd6fc..acb85df 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -22,12 +22,12 @@
 #include linux/errno.h
 #include linux/interrupt.h
 #include linux/kernel.h
-#include linux/clk.h
 #include linux/irq.h
 #include linux/io.h
 #include linux/platform_device.h
 #include linux/scatterlist.h
 #include linux/dma-mapping.h
+#include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/crypto.h
 #include linux/cryptohash.h
@@ -141,7 +141,6 @@ struct omap_sham_dev {
struct device   *dev;
void __iomem*io_base;
int irq;
-   struct clk  *iclk;
spinlock_t  lock;
int err;
int dma;
@@ -238,8 +237,6 @@ static void omap_sham_copy_ready_hash(struct ahash_request 
*req)
 
 static int omap_sham_hw_init(struct omap_sham_dev *dd)
 {
-   clk_enable(dd-iclk);
-
if (!test_bit(FLAGS_INIT, dd-flags)) {
omap_sham_write_mask(dd, SHA_REG_MASK,
SHA_REG_MASK_SOFTRESET, SHA_REG_MASK_SOFTRESET);
@@ -653,7 +650,6 @@ static void omap_sham_finish_req(struct ahash_request *req, 
int err)
/* atomic operation is not needed here */
dd-flags = ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
-   clk_disable(dd-iclk);
 
if (req-base.complete)
req-base.complete(req-base, err);
@@ -1198,14 +1194,6 @@ static int __devinit omap_sham_probe(struct 
platform_device *pdev)
if (err)
goto dma_err;
 
-   /* Initializing the clock */
-   dd-iclk = clk_get(dev, ick);
-   if (IS_ERR(dd-iclk)) {
-   dev_err(dev, clock intialization failed.\n);
-   err = PTR_ERR(dd-iclk);
-   goto clk_err;
-   }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
@@ -1213,11 +1201,12 @@ static int __devinit omap_sham_probe(struct 
platform_device *pdev)
goto io_err;
}
 
-   clk_enable(dd-iclk);
+   pm_runtime_enable(dev);
+   pm_runtime_get_sync(dev);
+
dev_info(dev, hw accel on OMAP rev %u.%u\n,
(omap_sham_read(dd, SHA_REG_REV)  SHA_REG_REV_MAJOR)  4,
omap_sham_read(dd, SHA_REG_REV)  SHA_REG_REV_MINOR);
-   clk_disable(dd-iclk);
 
spin_lock(sham.lock);
list_add_tail(dd-list, sham.dev_list);
@@ -1235,9 +1224,8 @@ err_algs:
for (j = 0; j  i; j++)
crypto_unregister_ahash(algs[j]);
iounmap(dd-io_base);
+   pm_runtime_disable(dev);
 io_err:
-   clk_put(dd-iclk);
-clk_err:
omap_sham_dma_cleanup(dd);
 dma_err:
if (dd-irq = 0)
@@ -1266,7 +1254,8 @@ static int __devexit omap_sham_remove(struct 
platform_device *pdev)
crypto_unregister_ahash(algs[i]);
tasklet_kill(dd-done_task);
iounmap(dd-io_base);
-   clk_put(dd-iclk);
+   pm_runtime_put_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
omap_sham_dma_cleanup(dd);
if (dd-irq = 0)
free_irq(dd-irq, dd);
-- 
1.7.12

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

[PATCH v2 6/7] crypto: omap-sham: Add code to use dmaengine API

From: Mark A. Greer mgr...@animalcreek.com

Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API.  The API to use is chosen by
defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.

CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
 drivers/crypto/omap-sham.c | 150 +++--
 1 file changed, 145 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index acb85df..c782f60 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -13,6 +13,8 @@
  * Some ideas are from old omap-sha1-md5.c driver.
  */
 
+#define OMAP_SHAM_DMA_PRIVATE
+
 #define pr_fmt(fmt) %s:  fmt, __func__
 
 #include linux/err.h
@@ -27,6 +29,10 @@
 #include linux/platform_device.h
 #include linux/scatterlist.h
 #include linux/dma-mapping.h
+#ifndef OMAP_SHAM_DMA_PRIVATE
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#endif
 #include linux/pm_runtime.h
 #include linux/delay.h
 #include linux/crypto.h
@@ -37,9 +43,11 @@
 #include crypto/hash.h
 #include crypto/internal/hash.h
 
+#ifdef OMAP_SHAM_DMA_PRIVATE
 #include plat/cpu.h
 #include plat/dma.h
 #include mach/irqs.h
+#endif
 
 #define SHA_REG_DIGEST(x)  (0x00 + ((x) * 0x04))
 #define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
@@ -47,6 +55,8 @@
 #define SHA1_MD5_BLOCK_SIZESHA1_BLOCK_SIZE
 #define MD5_DIGEST_SIZE16
 
+#defineDST_MAXBURST16 /* Really element number 
(en) */
+
 #define SHA_REG_DIGCNT 0x14
 
 #define SHA_REG_CTRL   0x18
@@ -110,6 +120,9 @@ struct omap_sham_reqctx {
 
/* walk state */
struct scatterlist  *sg;
+#ifndef OMAP_SHAM_DMA_PRIVATE
+   struct scatterlist  sgl;
+#endif
unsigned intoffset; /* offset in current sg */
unsigned inttotal;  /* total request */
 
@@ -143,8 +156,12 @@ struct omap_sham_dev {
int irq;
spinlock_t  lock;
int err;
+#ifdef OMAP_SHAM_DMA_PRIVATE
int dma;
int dma_lch;
+#else
+   struct dma_chan *dma_lch;
+#endif
struct tasklet_struct   done_task;
 
unsigned long   flags;
@@ -312,15 +329,32 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, 
const u8 *buf,
return -EINPROGRESS;
 }
 
+#ifndef OMAP_SHAM_DMA_PRIVATE
+static void omap_sham_dma_callback(void *param)
+{
+   struct omap_sham_dev *dd = param;
+
+   set_bit(FLAGS_DMA_READY, dd-flags);
+   tasklet_schedule(dd-done_task);
+}
+#endif
+
 static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
- size_t length, int final)
+ size_t length, int final, int is_sg)
 {
struct omap_sham_reqctx *ctx = ahash_request_ctx(dd-req);
+#ifdef OMAP_SHAM_DMA_PRIVATE
int len32;
+#else
+   struct dma_async_tx_descriptor *tx;
+   struct dma_slave_config cfg;
+   int ret;
+#endif
 
dev_dbg(dd-dev, xmit_dma: digcnt: %d, length: %d, final: %d\n,
ctx-digcnt, length, final);
 
+#ifdef OMAP_SHAM_DMA_PRIVATE
len32 = DIV_ROUND_UP(length, sizeof(u32));
 
omap_set_dma_transfer_params(dd-dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
@@ -330,6 +364,48 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, 
dma_addr_t dma_addr,
omap_set_dma_src_params(dd-dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
dma_addr, 0, 0);
 
+#else
+   memset(cfg, 0, sizeof(cfg));
+
+   cfg.dst_addr = dd-phys_base + SHA_REG_DIN(0);
+   cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   cfg.dst_maxburst = DST_MAXBURST;
+
+   ret = dmaengine_slave_config(dd-dma_lch, cfg);
+   if (ret) {
+   pr_err(omap-sham: can't configure dmaengine slave: %d\n, ret);
+   return ret;
+   }
+
+   if (is_sg) {
+   /*
+* The SG entry passed in may not have the 'length' member
+* set correctly so use a local SG entry (sgl) with the
+* proper value for 'length' instead.  If this is not done,
+* the dmaengine may try to DMA the incorrect amount of data.
+*/
+   sg_init_table(ctx-sgl, 1);
+   ctx-sgl.page_link = ctx-sg-page_link;
+   ctx-sgl.offset = ctx-sg-offset;
+   sg_dma_len(ctx-sgl) = length;
+   sg_dma_address(ctx-sgl) = sg_dma_address(ctx-sg);
+
+   tx = dmaengine_prep_slave_sg(dd-dma_lch, ctx-sgl, 1,
+   DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   } else {
+   tx =

[PATCH v2 7/7] crypto: omap_sham: Remove usage of private DMA API