[PATCH] Fixed gpio polarity of gpio USB-phy reset.

2011-04-14 Thread Juergen Kilb 
With commit 19403165 a main part of ehci-omap.c moved to
drivers/mfd/omap-usb-host.c created by commit 17cdd29d.
Due to this reorganisation the polarity used to reset the
external USB phy changed and USB host doesn't recognize
any devices.

Signed-off-by: Juergen Kilb j.k...@phytec.de
---
 drivers/mfd/omap-usb-host.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 53450f4..491cac5 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -719,14 +719,14 @@ static int usbhs_enable(struct device *dev)
gpio_request(pdata-ehci_data-reset_gpio_port[0],
USB1 PHY reset);
gpio_direction_output
-   (pdata-ehci_data-reset_gpio_port[0], 1);
+   (pdata-ehci_data-reset_gpio_port[0], 0);
}
 
if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1])) {
gpio_request(pdata-ehci_data-reset_gpio_port[1],
USB2 PHY reset);
gpio_direction_output
-   (pdata-ehci_data-reset_gpio_port[1], 1);
+   (pdata-ehci_data-reset_gpio_port[1], 0);
}
 
/* Hold the PHY in RESET for enough time till DIR is high */
@@ -906,11 +906,11 @@ static int usbhs_enable(struct device *dev)
 
if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
gpio_set_value
-   (pdata-ehci_data-reset_gpio_port[0], 0);
+   (pdata-ehci_data-reset_gpio_port[0], 1);
 
if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
gpio_set_value
-   (pdata-ehci_data-reset_gpio_port[1], 0);
+   (pdata-ehci_data-reset_gpio_port[1], 1);
}
 
 end_count:
-- 
1.7.0.4

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

Re: [PATCH] Fixed gpio polarity of gpio USB-phy reset.

2011-04-14 Thread Samuel Ortiz 
Hi Juergen,

On Thu, Apr 14, 2011 at 09:31:43AM +0200, Juergen Kilb wrote:
 With commit 19403165 a main part of ehci-omap.c moved to
 drivers/mfd/omap-usb-host.c created by commit 17cdd29d.
 Due to this reorganisation the polarity used to reset the
 external USB phy changed and USB host doesn't recognize
 any devices.
If that fix is correct, it looks like it should make its way to 2.6.39.
Felipe, are you ok with this fix ?

Cheers,
Samuel.

 Signed-off-by: Juergen Kilb j.k...@phytec.de
 ---
  drivers/mfd/omap-usb-host.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 53450f4..491cac5 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -719,14 +719,14 @@ static int usbhs_enable(struct device *dev)
   gpio_request(pdata-ehci_data-reset_gpio_port[0],
   USB1 PHY reset);
   gpio_direction_output
 - (pdata-ehci_data-reset_gpio_port[0], 1);
 + (pdata-ehci_data-reset_gpio_port[0], 0);
   }
  
   if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1])) {
   gpio_request(pdata-ehci_data-reset_gpio_port[1],
   USB2 PHY reset);
   gpio_direction_output
 - (pdata-ehci_data-reset_gpio_port[1], 1);
 + (pdata-ehci_data-reset_gpio_port[1], 0);
   }
  
   /* Hold the PHY in RESET for enough time till DIR is high */
 @@ -906,11 +906,11 @@ static int usbhs_enable(struct device *dev)
  
   if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
   gpio_set_value
 - (pdata-ehci_data-reset_gpio_port[0], 0);
 + (pdata-ehci_data-reset_gpio_port[0], 1);
  
   if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
   gpio_set_value
 - (pdata-ehci_data-reset_gpio_port[1], 0);
 + (pdata-ehci_data-reset_gpio_port[1], 1);
   }
  
  end_count:
 -- 
 1.7.0.4
 

-- 
Intel Open Source Technology Centre
http://oss.intel.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

[PATCH] ARM: omap2: mtd split nand_scan in ident and tail

2011-04-14 Thread Jan Weitzel 
nand_scan calls nand_scan_ident and nand_scan_tail, setting values like oobvail
according to ecc.layout. If we change the layout afterwards values are wrong.

Signed-off-by: Jan Weitzel j.weit...@phytec.de
---
 drivers/mtd/nand/omap2.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..288423f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1073,9 +1073,9 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
/* DIP switches on some boards change between 8 and 16 bit
 * bus widths for flash.  Try the other width if the first try fails.
 */
-   if (nand_scan(info-mtd, 1)) {
+   if (nand_scan_ident(info-mtd, 1, NULL)) {
info-nand.options ^= NAND_BUSWIDTH_16;
-   if (nand_scan(info-mtd, 1)) {
+   if (nand_scan_ident(info-mtd, 1, NULL)) {
err = -ENXIO;
goto out_release_mem_region;
}
@@ -1101,6 +1101,12 @@ static int __devinit omap_nand_probe(struct 
platform_device *pdev)
info-nand.ecc.layout = omap_oobinfo;
}
 
+   /* second phase scan */
+   if (nand_scan_tail(info-mtd)) {
+   err = -ENXIO;
+   goto out_release_mem_region;
+   }
+
 #ifdef CONFIG_MTD_PARTITIONS
err = parse_mtd_partitions(info-mtd, part_probes, info-parts, 0);
if (err  0)
-- 
1.7.0.4

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

Re: [PATCH] Fixed gpio polarity of gpio USB-phy reset.

2011-04-14 Thread Felipe Balbi 
On Thu, Apr 14, 2011 at 09:31:43AM +0200, Juergen Kilb wrote:
 With commit 19403165 a main part of ehci-omap.c moved to
 drivers/mfd/omap-usb-host.c created by commit 17cdd29d.
 Due to this reorganisation the polarity used to reset the
 external USB phy changed and USB host doesn't recognize
 any devices.
 
 Signed-off-by: Juergen Kilb j.k...@phytec.de

Judging by how ehci-omap.c was before moving the code:

Acked-by: Felipe Balbi ba...@ti.com

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

Re: [PATCH] usb: musb: omap2430: fix build failure

2011-04-14 Thread Felipe Balbi 
On Wed, Apr 13, 2011 at 03:27:44PM -0700, Greg KH wrote:
 On Wed, Apr 13, 2011 at 08:22:51PM +0300, Felipe Balbi wrote:
  Hi,
  
  On Wed, Apr 13, 2011 at 07:01:39PM +0200, Johan Hovold wrote:
   On Tue, Apr 05, 2011 at 07:50:34PM +0200, Johan Hovold wrote:
Fix build failure introduced by commit
7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 (usb: musb: Idle path retention
and offmode support for OMAP3) when building without gadget
support.

  CC  drivers/usb/musb/omap2430.o
drivers/usb/musb/omap2430.c: In function ‘musb_otg_notifications’:
drivers/usb/musb/omap2430.c:262: error: ‘struct musb’ has no member 
named ‘gadget_driver’
   
   I noted that this one wasn't included in your pull-request today. Just
   thought I'd send a reminder as I haven't received any feedback.
  
  Sorry about that, I missed it from my queue. I'll add and send on a
  separate pull request. Thanks for the note.
 
 I can pick it up right now.

Thanks Greg, here's my SOB line:

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

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

Re: [PATCH] Fixed gpio polarity of gpio USB-phy reset.

2011-04-14 Thread Sergei Shtylyov 

Hello.

On 14-04-2011 11:31, Juergen Kilb wrote:


With commit 19403165 a main part of ehci-omap.c moved to
drivers/mfd/omap-usb-host.c created by commit 17cdd29d.


   Pelase also specify the summaries of those commits -- for the human readers.


Due to this reorganisation the polarity used to reset the
external USB phy changed and USB host doesn't recognize
any devices.



Signed-off-by: Juergen Kilb j.k...@phytec.de


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

Re: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS support

2011-04-14 Thread Jarkko Nikula 
On Wed, 13 Apr 2011 10:57:54 -0700
Vishwanath Sripathy vishwanath...@ti.com wrote:

  -Original Message-
  From: Jarkko Nikula [mailto:jhnik...@gmail.com]
  Sent: Wednesday, April 13, 2011 7:13 AM
  To: Vishwanath BS
  Cc: linux-omap@vger.kernel.org; patc...@linaro.org; Santosh
  Shilimkar
  Subject: Re: [PATCH 08/13] OMAP3: cpufreq driver changes for DVFS
  support
 
  Hi
 
  A few comments below in case this is still under development as I
  was
  playing a bit with this version on omap3.
 There is an updated version of omap cpufreq patches where this issue is
 fixed.
 https://patchwork.kernel.org/patch/632781/
 
Thanks, I didn't notice that patch fixes the issues I noticed. Now
also the clk_round_rate works fine since the dpll1_ck does have the
round_clock defined and the former arm_fck is anyway derived from it.

-- 
Jarkko
--
To unsubscribe from this list: send the line unsubscribe 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 v9 1/9] OMAP3: PM: Fix for the TWL4030 sleep/wakeup sequence

2011-04-14 Thread Lesly A M 
Only configure sleep script when the flag is TWL4030_SLEEP_SCRIPT.

Adding the missing brackets for fixing the issue.

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/twl4030-power.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 16422de..2c0d4d1 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -447,12 +447,13 @@ static int __init load_twl4030_script(struct 
twl4030_script *tscript,
if (err)
goto out;
}
-   if (tscript-flags  TWL4030_SLEEP_SCRIPT)
+   if (tscript-flags  TWL4030_SLEEP_SCRIPT) {
if (order)
pr_warning(TWL4030: Bad order of scripts (sleep \
script before wakeup) Leads to boot\
failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
+   }
 out:
return err;
 }
-- 
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

[PATCH v9 2/9] OMAP3: PM: Correct the warning print during script loading

2011-04-14 Thread Lesly A M 
Correcting the if condition check for printing the warning,
if wakeup script is not updated before updating the sleep script.

Since the flag 'order' is set to '1' while updating the wakeup script for P1P2,
the condition checking for printing the warning should be if(!order)
(ie: print the warning if wakeup script is not updated before updating the 
sleep script)

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/twl4030-power.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 2c0d4d1..8373d79 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -448,7 +448,7 @@ static int __init load_twl4030_script(struct twl4030_script 
*tscript,
goto out;
}
if (tscript-flags  TWL4030_SLEEP_SCRIPT) {
-   if (order)
+   if (!order)
pr_warning(TWL4030: Bad order of scripts (sleep \
script before wakeup) Leads to boot\
failure on some boards\n);
-- 
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

[PATCH v9 0/9] OMAP3: PM: TWL4030 power scripts and workaround for TWL erratum 27

2011-04-14 Thread Lesly A M 
Patch series for TWL4030 power scripts and workaround for TWL erratum 27.

Changes for implementing TWL4030 power scripts recommended by hardware team.
Introduced a new TWL4030 power script file, which can be used by different
OMAP3 board with the power companion chip TWL4030.

Updated the changes for TWL4030 errata 27  28, and modified
the TWL4030 power script.
Workaround for TWL4030 erratum 27 is required for Si version less than or
equal to TWL5030 ES1.1.

TWL4030 script changes re-based on Kevin's PM tree in pm branch.

Changes in v7:
changes to fix Nishanth Menon's comments
i) Added the workaround for TWL4030 Erratum 27
  
split the first patch in v6
i)  fix for twl4030 script load
ii) correct the warning print during script loading

Added new patch files
i) changing sys_off signal polarity

Changes in v8:
updated the change logs
moving the TWL IDCODE checking to twl-core.c

Changes in V9:
changes to fix David Derrick's comments
i) turn OFF the NRES_PWRON resource in warm reset sequence
ii) optimize the i2c writes during resource configuration

Since the voltage layer is evolving to a new design, the voltage dependant
changes required for the TWL4030 script are not incorporated in the patch 
series.
So this TWL4030 script patch series can be tested with a separate patch for
voltage layer changes.

link: http://pastebin.mozilla.org/1204011

This changes are tested on OMAP3430  OMAP3630 SDP with off mode enabled in 
suspend path.
Tested with suspend/resume script, which will test system suspend in a 
loop.
Tested for more than 1000 iterations.
Also tested the reboot with WRM_RST button  reboot command.

Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
Lesly A M (9):
  OMAP3: PM: Fix for the TWL4030 sleep/wakeup sequence
  OMAP3: PM: Correct the warning print during script loading
  OMAP3: PM: Modifying the macro name Main_Ref to all caps
  OMAP3: PM: TWL4030 power scripts for OMAP3 boards
  OMAP3: PM: TWL5030 version checking
  MFD: TWL4030: workaround changes for TWL4030 Erratum 27
  OMAP3430: Updating the board file to use TWL4030 scripts
  OMAP3630: Updating the board file to use TWL4030 scripts
  OMAP3: PM: TWL4030 optimizing resource configuration

 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-3430sdp.c  |2 +
 arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 +
 arch/arm/mach-omap2/twl4030-script.c |  481 ++
 arch/arm/mach-omap2/twl4030-script.h |   23 ++
 drivers/mfd/twl-core.c   |   62 
 drivers/mfd/twl4030-power.c  |  211 ---
 include/linux/i2c/twl.h  |   53 +++-
 9 files changed, 774 insertions(+), 63 deletions(-)
 create mode 100644 arch/arm/mach-omap2/twl4030-script.c
 create mode 100644 arch/arm/mach-omap2/twl4030-script.h

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

[PATCH v9 7/9] OMAP3430: Updating the board file to use TWL4030 scripts

2011-04-14 Thread Lesly A M 
Using TWL4030 power scripts to control the LDOs and DCDC regulators
while going to low power mode.

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 arch/arm/mach-omap2/Makefile|1 +
 arch/arm/mach-omap2/board-3430sdp.c |2 ++
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 82b2a67..51d17da 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_ARCH_OMAP4)  += pm44xx.o pm_bus.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
 obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3)  += smartreflex-class3.o
+obj-$(CONFIG_TWL4030_POWER)+= twl4030-script.o
 
 AFLAGS_sleep24xx.o :=-Wa,-march=armv6
 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index b391804..fafbfb5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,6 +46,7 @@
 #include mux.h
 #include sdram-qimonda-hyb18m512160af-6.h
 #include hsmmc.h
+#include twl4030-script.h
 #include pm.h
 #include control.h
 
@@ -569,6 +570,7 @@ static struct twl4030_platform_data sdp3430_twldata = {
.madc   = sdp3430_madc_data,
.keypad = sdp3430_kp_data,
.usb= sdp3430_usb_data,
+   .power  = twl4030_generic_script,
.codec  = sdp3430_codec,
 
.vaux1  = sdp3430_vaux1,
-- 
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

[PATCH v9 8/9] OMAP3630: Updating the board file to use TWL4030 scripts

2011-04-14 Thread Lesly A M 
Using TWL4030 power scripts to control the LDOs and DCDC regulators
while going to low power mode.

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c 
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 448ab60..aa8f50d 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -31,6 +31,7 @@
 
 #include mux.h
 #include hsmmc.h
+#include twl4030-script.h
 
 #define OMAP_ZOOM_WLAN_PMENA_GPIO  (101)
 #define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
@@ -339,6 +340,7 @@ static struct twl4030_platform_data zoom_twldata = {
.usb= zoom_usb_data,
.gpio   = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
+   .power  = twl4030_generic_script,
.codec  = zoom_codec_data,
.vmmc1  = zoom_vmmc1,
.vmmc2  = zoom_vmmc2,
-- 
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

[PATCH v9 5/9] OMAP3: PM: TWL5030 version checking

2011-04-14 Thread Lesly A M 
Added API to get the TWL5030 Si version from the IDCODE register.
It is used for enabling the workaround for TWL erratum 27.

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/twl-core.c  |   62 +++
 include/linux/i2c/twl.h |   17 -
 2 files changed, 78 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index a35fa7d..c68e0cf 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -229,6 +229,9 @@
 /* is driver active, bound to a chip? */
 static bool inuse;
 
+/* TWL IDCODE Register value */
+static u32 twl_idcode;
+
 static unsigned int twl_id;
 unsigned int twl_rev(void)
 {
@@ -487,6 +490,58 @@ EXPORT_SYMBOL(twl_i2c_read_u8);
 
 /*--*/
 
+/**
+ * twl_read_idcode_register - API to read the IDCODE register.
+ *
+ * Unlocks the IDCODE register and read the 32 bit value.
+ */
+static int twl_read_idcode_register(void)
+{
+   int err;
+
+   err = twl_i2c_write_u8(TWL4030_MODULE_INTBR, TWL_EEPROM_R_UNLOCK,
+   REG_UNLOCK_TEST_REG);
+   if (err) {
+   pr_err(TWL4030 Unable to unlock IDCODE registers -%d\n, err);
+   goto fail;
+   }
+
+   err = twl_i2c_read(TWL4030_MODULE_INTBR, (u8 *)(twl_idcode),
+   REG_IDCODE_7_0, 4);
+   if (err) {
+   pr_err(TWL4030: unable to read IDCODE -%d\n, err);
+   goto fail;
+   }
+
+   err = twl_i2c_write_u8(TWL4030_MODULE_INTBR, 0x0, REG_UNLOCK_TEST_REG);
+   if (err)
+   pr_err(TWL4030 Unable to relock IDCODE registers -%d\n, err);
+fail:
+   return err;
+}
+
+/**
+ * twl_get_type - API to get TWL Si type.
+ *
+ * Api to get the TWL Si type from IDCODE value.
+ */
+int twl_get_type(void)
+{
+   return TWL_SIL_TYPE(twl_idcode);
+}
+EXPORT_SYMBOL_GPL(twl_get_type);
+
+/**
+ * twl_get_version - API to get TWL Si version.
+ *
+ * Api to get the TWL Si version from IDCODE value.
+ */
+int twl_get_version(void)
+{
+   return TWL_SIL_REV(twl_idcode);
+}
+EXPORT_SYMBOL_GPL(twl_get_version);
+
 static struct device *
 add_numbered_child(unsigned chip, const char *name, int num,
void *pdata, unsigned pdata_len,
@@ -1010,6 +1065,7 @@ twl_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
unsignedi;
struct twl4030_platform_data*pdata = client-dev.platform_data;
u8 temp;
+   int ret = 0;
 
if (!pdata) {
dev_dbg(client-dev, no platform data?\n);
@@ -1056,6 +1112,12 @@ twl_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
/* setup clock framework */
clocks_init(client-dev, pdata-clock);
 
+   /* read TWL IDCODE Register */
+   if (twl_id == TWL4030_CLASS_ID) {
+   ret = twl_read_idcode_register();
+   WARN(ret  0, Error: reading twl_idcode register value\n);
+   }
+
/* load power event scripts */
if (twl_has_power()  pdata-power)
twl4030_power_init(pdata-power);
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index bb28d33..e1ff2c4 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -150,7 +150,12 @@
 #define MMC_PU (0x1  3)
 #define MMC_PD (0x1  2)
 
-
+#define TWL_SIL_TYPE(rev)  ((rev)  0x00FF)
+#define TWL_SIL_REV(rev)   ((rev)  24)
+#define TWL_SIL_5030   0x09002F
+#define TWL5030_REV_1_00x00
+#define TWL5030_REV_1_10x10
+#define TWL5030_REV_1_20x30
 
 #define TWL4030_CLASS_ID   0x4030
 #define TWL6030_CLASS_ID   0x6030
@@ -180,6 +185,9 @@ int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 reg);
 int twl_i2c_write(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
 int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned num_bytes);
 
+int twl_get_type(void);
+int twl_get_version(void);
+
 int twl6030_interrupt_unmask(u8 bit_mask, u8 offset);
 int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
 
@@ -279,7 +287,12 @@ static inline int twl6030_mmc_card_detect(struct device 
*dev, int slot)
  *(Use TWL_4030_MODULE_INTBR)
  */
 
+#define REG_IDCODE_7_0 0x00
+#define REG_IDCODE_15_80x01
+#define REG_IDCODE_16_23   0x02
+#define REG_IDCODE_31_24   0x03
 #define REG_GPPUPDCTR1 0x0F
+#define REG_UNLOCK_TEST_REG0x12
 
 /*I2C1 and I2C4(SR) SDA/SCL pull-up control bits */
 
@@ -288,6 +301,8 @@ static inline int twl6030_mmc_card_detect(struct device 
*dev, int slot)
 #define SR_I2C_SCL_CTRL_PU BIT(4)

[PATCH v9 9/9] OMAP3: PM: TWL4030 optimizing resource configuration

2011-04-14 Thread Lesly A M 
Skip the i2c register writes in twl4030_configure_resource() if the new value
is same as the old value, for devgrp/type/remap regs.

Suggested by David Derrick dderr...@ti.com

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 drivers/mfd/twl4030-power.c |  126 --
 1 files changed, 72 insertions(+), 54 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 8d1db78..95ef257 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -335,9 +335,9 @@ static int __init twl4030_configure_resource(struct 
twl4030_resconfig *rconfig)
 {
int rconfig_addr;
int err;
-   u8 type;
-   u8 grp;
-   u8 remap;
+   u8 type, type_value;
+   u8 grp, grp_value;
+   u8 remap, remap_value;
 
if (rconfig-resource  TOTAL_RESOURCES) {
pr_err(TWL4030 Resource %d does not exist\n,
@@ -348,76 +348,94 @@ static int __init twl4030_configure_resource(struct 
twl4030_resconfig *rconfig)
rconfig_addr = res_config_addrs[rconfig-resource];
 
/* Set resource group */
-   err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, grp,
+   if (rconfig-devgroup != TWL4030_RESCONFIG_UNDEF) {
+   err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, grp,
  rconfig_addr + DEV_GRP_OFFSET);
-   if (err) {
-   pr_err(TWL4030 Resource %d group could not be read\n,
-   rconfig-resource);
-   return err;
-   }
+   if (err) {
+   pr_err(TWL4030 Resource %d group could not be read\n,
+   rconfig-resource);
+   return err;
+   }
 
-   if (rconfig-devgroup != TWL4030_RESCONFIG_UNDEF) {
-   grp = ~DEV_GRP_MASK;
-   grp |= rconfig-devgroup  DEV_GRP_SHIFT;
-   err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+   grp_value = (grp  DEV_GRP_MASK)  DEV_GRP_SHIFT;
+
+   if (rconfig-devgroup != grp_value) {
+   grp = ~DEV_GRP_MASK;
+   grp |= rconfig-devgroup  DEV_GRP_SHIFT;
+   err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
   grp, rconfig_addr + DEV_GRP_OFFSET);
-   if (err  0) {
-   pr_err(TWL4030 failed to program devgroup\n);
-   return err;
+   if (err  0) {
+   pr_err(TWL4030 failed to program devgroup\n);
+   return err;
+   }
}
}
 
/* Set resource types */
-   err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+   if ((rconfig-type != TWL4030_RESCONFIG_UNDEF) ||
+   (rconfig-type2 != TWL4030_RESCONFIG_UNDEF)) {
+
+   err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
rconfig_addr + TYPE_OFFSET);
-   if (err  0) {
-   pr_err(TWL4030 Resource %d type could not be read\n,
-   rconfig-resource);
-   return err;
-   }
+   if (err  0) {
+   pr_err(TWL4030 Resource %d type could not be read\n,
+   rconfig-resource);
+   return err;
+   }
 
-   if (rconfig-type != TWL4030_RESCONFIG_UNDEF) {
-   type = ~TYPE_MASK;
-   type |= rconfig-type  TYPE_SHIFT;
-   }
+   type_value = type;
 
-   if (rconfig-type2 != TWL4030_RESCONFIG_UNDEF) {
-   type = ~TYPE2_MASK;
-   type |= rconfig-type2  TYPE2_SHIFT;
-   }
+   if (rconfig-type != TWL4030_RESCONFIG_UNDEF) {
+   type = ~TYPE_MASK;
+   type |= rconfig-type  TYPE_SHIFT;
+   }
 
-   err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+   if (rconfig-type2 != TWL4030_RESCONFIG_UNDEF) {
+   type = ~TYPE2_MASK;
+   type |= rconfig-type2  TYPE2_SHIFT;
+   }
+
+   if (type != type_value) {
+   err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
-   if (err  0) {
-   pr_err(TWL4030 failed to program resource type\n);
-   return err;
+   if (err  0) {
+   pr_err(TWL4030 failed to program resource 
type\n);
+   return err;
+   }
+   }
}
 
/* Set remap states */
-   err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+   if ((rconfig-remap_off != TWL4030_RESCONFIG_UNDEF) ||
+

[PATCH v9 6/9] MFD: TWL4030: workaround changes for TWL4030 Erratum 27

2011-04-14 Thread Lesly A M 
Workaround for TWL5030 Silicon Errata 27  28:
27 - VDD1, VDD2, may have glitches when their output value is updated.
28 - VDD1 and / or VDD2 DCDC clock may stop working when internal clock
is switched from internal to external.

Erratum 27:
If the DCDC regulators is running on their internal oscillator,
negative glitches may occur on VDD1, VDD2 output when voltage is 
changed.
The OMAP device may reboot if the VDD1 or VDD2 go below the
core minimum operating voltage.

WORKAROUND
Set up the TWL5030 DC-DC power supplies to use the HFCLKIN instead of
the internal oscillator.

Erratum 28:
VDD1/VDD2 clock system may hang during switching the clock source from
internal oscillator to external. VDD1/VDD2 output voltages may collapse
if clock stops.

WORKAROUND
If HFCLK is disabled in OFFMODE, modify the sleep/wakeup sequence and
setuptimes to make sure the switching will happen only when HFCLKIN is 
stable.
Also use the TWL5030 watchdog to safeguard the first switching from
internal oscillator to HFCLKIN during the TWL5030 init.

IMPACT
power sequence is changed.
sleep/wakeup time values will be changed.

The workaround changes are called from twl4030_power_init(), since we have to
make some i2c_read calls to check the TWL4030 version  the i2c will not be
initialized in the early stage.

This workaround is required for TWL5030 Silicon version less than ES1.2
The power script  setup time changes are recommended by TI HW team.

http://omapedia.org/wiki/TWL4030_power_scripts

Changes taken from TWL4030 Erratum 27 workaround patch by Nishanth Menon.

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 arch/arm/mach-omap2/twl4030-script.c |  150 ++
 drivers/mfd/twl4030-power.c  |   78 ++
 include/linux/i2c/twl.h  |1 +
 3 files changed, 229 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/twl4030-script.c 
b/arch/arm/mach-omap2/twl4030-script.c
index aa5afbd..97cdaa3 100644
--- a/arch/arm/mach-omap2/twl4030-script.c
+++ b/arch/arm/mach-omap2/twl4030-script.c
@@ -324,8 +324,158 @@ static struct twl4030_resconfig twl4030_rconfig[] = {
{ 0, 0},
 };
 
+/*
+ * Sleep and active sequences with changes for TWL5030 Erratum 27 workaround
+ *
+ * Sysoff (using sys_off signal):
+ * When SYS_CLKREQ goes low during retention no resources will be affected
+ * since no resources are assigned to P3 only.
+ *
+ * Since all resources are assigned to P1 and P3 then all resources
+ * will be affected on the falling edge of P3 (SYS_CLKREQ).
+ * When OMAP lower the SYS_CLKREQ signal PMIC will execute the
+ * A2S sequence in which HFCLKOUT is dissabled first and
+ * after 488.32 usec(PRM_VOLTOFFSET) resources assigned to P1 and P3
+ * and of TYPE2=1 are put to sleep
+ * (VDD1, VDD2, VPLL1, REGEN, NRESPWRON  SYSEN).
+ * Again after a 61.04 usec resources assigned to P1 and P3
+ * and of TYPE2=2 are put to sleep
+ * (VINTANA1, VINTANA2, VINTDIG, VIO  CLKEN).
+ *
+ * On wakeup event OMAP goes active and pulls the SYS_CLKREQ high,
+ * and will execute the S2A sequence which is same for P1_P2  P3.
+ * This will turn on all resources of TYPE2=2 to go to the active state.
+ * Three dummy broadcast messages are added to get a delay of ~10 ms
+ * before enabling the HFCLKOUT resource. And after a 30.52 usec
+ * all resources of TYPE2=1 are put to the active state.
+ *
+ * This 10ms delay can be reduced if the oscillator is having less
+ * stabilization time. A should be taken care if it needs more time
+ * for stabilization.
+ *
+ */
+
+/**
+ * DOC: Sleep to Active sequence for P1/P2/P3
+ *
+ * The wakeup sequence is adjusted to do the VDD1/VDD2 voltage ramp-up
+ * only after HFCLKIN is stabilized and the HFCLKOUT is enabled.
+ */
+static struct twl4030_ins wakeup_seq_erratum27[] __initdata = {
+   /*
+* Broadcast message to put res(TYPE2 = 2) to active.
+* Wait for ~10 mS (ramp-up time for OSC on the board)
+* after HFCLKIN is enabled
+*/
+   {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+   RES_STATE_ACTIVE), 55},
+   {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+   RES_STATE_ACTIVE), 55},
+   {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+   RES_STATE_ACTIVE), 54},
+   {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+   RES_STATE_ACTIVE), 1},
+   /*

[PATCH v9 4/9] OMAP3: PM: TWL4030 power scripts for OMAP3 boards

2011-04-14 Thread Lesly A M 
Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.

TWL4030 power scripts which can be used by different OMAP3 boards
with the power companion chip (TWL4030 series).

The twl4030 generic script can be used by any board file to update
the power data in twl4030_platform_data.

http://omapedia.org/wiki/TWL4030_power_scripts

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 arch/arm/mach-omap2/twl4030-script.c |  331 ++
 arch/arm/mach-omap2/twl4030-script.h |   23 +++
 include/linux/i2c/twl.h  |   33 +++-
 3 files changed, 384 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-omap2/twl4030-script.c
 create mode 100644 arch/arm/mach-omap2/twl4030-script.h

diff --git a/arch/arm/mach-omap2/twl4030-script.c 
b/arch/arm/mach-omap2/twl4030-script.c
new file mode 100644
index 000..aa5afbd
--- /dev/null
+++ b/arch/arm/mach-omap2/twl4030-script.c
@@ -0,0 +1,331 @@
+/*
+ * OMAP power script for PMIC TWL4030
+ *
+ * Author: Lesly A M lesl...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Lesly A M lesl...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/i2c/twl.h
+
+#include twl4030-script.h
+
+/*
+ * power management signal connections for OMAP3430 with TWL5030
+ *
+ *  TWL5030 OMAP3430
+ * __ _
+ *|  |   | 
|
+ *|  (P1) NSLEEP1|--|SYS_OFFMODE  
|
+ *|  NRESWARM|--|NWARMRESET   
|
+ *|  (P2) NSLEEP2|---|   | 
|
+ *|  |  ===  | 
|
+ *|  |   -   | 
|
+ *|  |   | 
|
+ *| VDD1 |--| VDD1
|
+ *| VDD2 |--| VDD2
|
+ *|  VIO |--| VDDS
|
+ *    |VAUX1 |   | 
|
+ * || | ...  |   | 
|
+ * |  ENABLE||CLKEN   CLKREQ|--|SYS_CLKREQ   
|
+ * |  CLKOUT||HFCLKIN  (P3) HFCLKOUT|--|XTALIN   
|
+ * || |__|   
|_|
+ *
+ *
+ * Signal descriptions:
+ *
+ * SYS_OFFMODE - OMAP drives this signal low only when the OMAP is in the
+ * OFF idle mode. It is driven high when a wake up event is detected.
+ * This signal should control the P1 device group in the PMIC.
+ *
+ * SYS_CLKREQ - OMAP should drive this signal low when the OMAP goes into
+ * any idle mode. This signal should control the P3 device group
+ * in the PMIC. It is used to notify PMIC when XTALIN is no longer needed.
+ *
+ * NSLEEP1(P1) - When this signal goes low the P1 sleep sequence is executed
+ * in the PMIC turning off certain resources. When this signal goes high
+ * the P1 active sequence is executed turning back on certain resources.
+ *
+ * NSLEEP2(P2) - This signal controls the P2 device group of the PMIC.
+ * It is not used in this setup and should be tied to ground.
+ * This can be used for connecting a different processor or MODEM chip.
+ *
+ * CLKREQ(P3) - When this signal goes low the P3 sleep sequence is executed
+ * in the PMIC turning off HFCLKOUT. When this signal goes high
+ * the P3 active sequence is executed turning back on HFCLKOUT and other
+ * resources.
+ *
+ * CLKEN - Enable signal for oscillator. Should only go low when OMAP is
+ * in the OFF idle mode due to long oscillator startup times.
+ *
+ * HFCLKIN - Oscillator output clock into PMIC.
+ *
+ * HFCLKOUT - System clock output from PMIC to OMAP.
+ *
+ * XTALIN - OMAP system clock input(HFCLKOUT).
+ */
+
+/*
+ * Recommended sleep and active sequences for TWL5030 when connected to OMAP3
+ *
+ * WARNING: If the board is using NSLEEP2(P2), should modify this script and
+ * setuptime values accordingly.
+ *
+ * Chip Retention/Off (using i2c for scaling voltage):
+ * When OMAP de-assert the SYS_CLKREQ signal, only HFCLKOUT is affected
+ * since it is the only resource assigned to P3 only.
+ *
+ * Sysoff (using sys_off signal):
+ * When OMAP de-assert the SYS_OFFMODE signal A2S(active to sleep sequence)
+ * on the PMIC is executed. This

[PATCH v9 3/9] OMAP3: PM: Modifying the macro name Main_Ref to all caps

2011-04-14 Thread Lesly A M 
Modifying the macro name Main_Ref to all caps(MAIN_REF).

Suggested by Nishanth Menon n...@ti.com

Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
 drivers/mfd/twl4030-power.c  |2 +-
 include/linux/i2c/twl.h  |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 5f1900c..e42b391 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -730,7 +730,7 @@ static struct twl4030_resconfig twl4030_rconfig[] 
__initdata = {
{ .resource = RES_RESET, .devgroup = -1,
  .type = 1, .type2 = -1, .remap_off = -1, .remap_sleep = -1
},
-   { .resource = RES_Main_Ref, .devgroup = -1,
+   { .resource = RES_MAIN_REF, .devgroup = -1,
  .type = 1, .type2 = -1, .remap_off = -1, .remap_sleep = -1
},
{ 0, 0},
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 8373d79..8162e43 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -120,7 +120,7 @@ static u8 res_config_addrs[] = {
[RES_HFCLKOUT]  = 0x8b,
[RES_32KCLKOUT] = 0x8e,
[RES_RESET] = 0x91,
-   [RES_Main_Ref]  = 0x94,
+   [RES_MAIN_REF]  = 0x94,
 };
 
 static int __init twl4030_write_script_byte(u8 address, u8 byte)
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 9d88b71..dcc2998 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -501,7 +501,7 @@ static inline int twl6030_mmc_card_detect(struct device 
*dev, int slot)
 #define RES_32KCLKOUT   26
 #define RES_RESET   27
 /* Power Reference */
-#define RES_Main_Ref28
+#define RES_MAIN_REF28
 
 #define TOTAL_RESOURCES28
 /*
-- 
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

[PATCH linux-omap-pm/pm-wip/cpufreq] OMAP2PLUS: cpufreq: Fix typo when attempting to set mpu_clk for OMAP4

2011-04-14 Thread Jarkko Nikula 
Fix this typo as there is no dpll_mpu_ck for OMAP3 and code flow is clearly
trying to set mpu_clk for OMAP4 for which this dpll_mpu_ck is available.

Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
 arch/arm/mach-omap2/omap2plus-cpufreq.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c 
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 8d472f6..d53ce23 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -161,7 +161,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy 
*policy)
mpu_clk = clk_get(NULL, virt_prcm_set);
else if (cpu_is_omap34xx())
mpu_clk = clk_get(NULL, dpll1_ck);
-   else if (cpu_is_omap34xx())
+   else if (cpu_is_omap44xx())
mpu_clk = clk_get(NULL, dpll_mpu_ck);
 
if (IS_ERR(mpu_clk))
-- 
1.7.4.1

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

RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

2011-04-14 Thread Premi, Sanjeev 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Valentin, Eduardo
 Sent: Wednesday, April 13, 2011 8:51 PM
 To: Paul Walmsley; Kevin Hilman
 Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo
 Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to 
 restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
 
 As per OMAP3 erratum (i671), ROM code adds extra latencies while
 restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.
 
 This patch stores 0's in scratchpad content area corresponding to
 AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
 it won't respect proper programing scheme.
 
 This register is then stored in prcm context. The saving and restore
 is now done by kernel side.
 
 Here follow the erratum description
 
 DESCRIPTION
 
 After OFF mode transition, among many restorations, the ROM 
 Code restores the
 CM_AUTOIDLE_PLL register, and after that, it tries to relock 
 the PER DPLL.
 
 In case the restoration data stored in scratchpad memory 
 contains a field
 CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM 
 Code restores and
 locks the PER DPLL does not respect the PER DPLL programming scheme.
 
 In that case, the DPLL might not lock. Meanwhile, when trying 
 to lock the PER
 DPLL, the ROM Code does not hang. Only extra latencies are 
 introduced at
 wake-up.
 

[sp] You seem to have missed this patch:
http://marc.info/?l=linux-arm-kernelm=129735383925285w=2

~sanjeev


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

Re: [PATCH linux-omap-pm/pm-wip/cpufreq] OMAP2PLUS: cpufreq: Fix typo when attempting to set mpu_clk for OMAP4

2011-04-14 Thread Santosh Shilimkar 

On 4/14/2011 6:51 PM, Jarkko Nikula wrote:

Fix this typo as there is no dpll_mpu_ck for OMAP3 and code flow is clearly
trying to set mpu_clk for OMAP4 for which this dpll_mpu_ck is available.

Signed-off-by: Jarkko Nikulajhnik...@gmail.com
---
  arch/arm/mach-omap2/omap2plus-cpufreq.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap2plus-cpufreq.c 
b/arch/arm/mach-omap2/omap2plus-cpufreq.c
index 8d472f6..d53ce23 100644
--- a/arch/arm/mach-omap2/omap2plus-cpufreq.c
+++ b/arch/arm/mach-omap2/omap2plus-cpufreq.c
@@ -161,7 +161,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy 
*policy)
mpu_clk = clk_get(NULL, virt_prcm_set);
else if (cpu_is_omap34xx())
mpu_clk = clk_get(NULL, dpll1_ck);
-   else if (cpu_is_omap34xx())
+   else if (cpu_is_omap44xx())

My Bad :(
Thanks Jarkko for finding this.

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com


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

Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

2011-04-14 Thread Eduardo Valentin 
Hello Sanjeev,


On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote:
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
  Valentin, Eduardo
  Sent: Wednesday, April 13, 2011 8:51 PM
  To: Paul Walmsley; Kevin Hilman
  Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo
  Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to 
  restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  
  As per OMAP3 erratum (i671), ROM code adds extra latencies while
  restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL is equal to 1.
  
  This patch stores 0's in scratchpad content area corresponding to
  AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per DPLL, since
  it won't respect proper programing scheme.
  
  This register is then stored in prcm context. The saving and restore
  is now done by kernel side.
  
  Here follow the erratum description
  
  DESCRIPTION
  
  After OFF mode transition, among many restorations, the ROM 
  Code restores the
  CM_AUTOIDLE_PLL register, and after that, it tries to relock 
  the PER DPLL.
  
  In case the restoration data stored in scratchpad memory 
  contains a field
  CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM 
  Code restores and
  locks the PER DPLL does not respect the PER DPLL programming scheme.
  
  In that case, the DPLL might not lock. Meanwhile, when trying 
  to lock the PER
  DPLL, the ROM Code does not hang. Only extra latencies are 
  introduced at
  wake-up.
  
 
 [sp] You seem to have missed this patch:
 http://marc.info/?l=linux-arm-kernelm=129735383925285w=2

Right,

But that one doesn't clear the AUTO_PERIPH_DPLL bits in the scratchpad area
to avoid rom code extra overhead (check my patch description).

Besides, why do we want to add more code inside omap_sram_idle,
if we have better places to this SR?


 
 ~sanjeev
 
 

All best,

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

RE: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

2011-04-14 Thread Premi, Sanjeev 
 -Original Message-
 From: Valentin, Eduardo 
 Sent: Thursday, April 14, 2011 11:04 PM
 To: Premi, Sanjeev
 Cc: Valentin, Eduardo; Paul Walmsley; Kevin Hilman; 
 Linux-OMAP; Linux-ARM
 Subject: Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code 
 to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
 
 Hello Sanjeev,
 
 
 On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote:
   -Original Message-
   From: linux-omap-ow...@vger.kernel.org 
   [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
   Valentin, Eduardo
   Sent: Wednesday, April 13, 2011 8:51 PM
   To: Paul Walmsley; Kevin Hilman
   Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo
   Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to 
   restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
   
   As per OMAP3 erratum (i671), ROM code adds extra latencies while
   restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL 
 is equal to 1.
   
   This patch stores 0's in scratchpad content area corresponding to
   AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per 
 DPLL, since
   it won't respect proper programing scheme.
   
   This register is then stored in prcm context. The saving 
 and restore
   is now done by kernel side.
   
   Here follow the erratum description
   
   DESCRIPTION
   
   After OFF mode transition, among many restorations, the ROM 
   Code restores the
   CM_AUTOIDLE_PLL register, and after that, it tries to relock 
   the PER DPLL.
   
   In case the restoration data stored in scratchpad memory 
   contains a field
   CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM 
   Code restores and
   locks the PER DPLL does not respect the PER DPLL 
 programming scheme.
   
   In that case, the DPLL might not lock. Meanwhile, when trying 
   to lock the PER
   DPLL, the ROM Code does not hang. Only extra latencies are 
   introduced at
   wake-up.
   
  
  [sp] You seem to have missed this patch:
  http://marc.info/?l=linux-arm-kernelm=129735383925285w=2
 
 Right,
 
 But that one doesn't clear the AUTO_PERIPH_DPLL bits in the 
 scratchpad area
 to avoid rom code extra overhead (check my patch description).
 
 Besides, why do we want to add more code inside omap_sram_idle,
 if we have better places to this SR?

Didn't see that as a comment earlier?

~sanjeev

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

Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

2011-04-14 Thread Eduardo Valentin 
Hello Sanjeev,

On Thu, Apr 14, 2011 at 12:36:17PM -0500, Premi, Sanjeev wrote:
  -Original Message-
  From: Valentin, Eduardo 
  Sent: Thursday, April 14, 2011 11:04 PM
  To: Premi, Sanjeev
  Cc: Valentin, Eduardo; Paul Walmsley; Kevin Hilman; 
  Linux-OMAP; Linux-ARM
  Subject: Re: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code 
  to restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL
  
  Hello Sanjeev,
  
  
  On Thu, Apr 14, 2011 at 09:13:14AM -0500, Premi, Sanjeev wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
Valentin, Eduardo
Sent: Wednesday, April 13, 2011 8:51 PM
To: Paul Walmsley; Kevin Hilman
Cc: Linux-OMAP; Linux-ARM; Valentin, Eduardo
Subject: [PATCH 2/2] OMAP3: PM: Do not rely on ROM code to 
restore CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL

As per OMAP3 erratum (i671), ROM code adds extra latencies while
restoring CM_AUTOIDLE_PLL register, if AUTO_PERIPH_DPLL 
  is equal to 1.

This patch stores 0's in scratchpad content area corresponding to
AUTO_PERIPH_DPLL, to prevent ROM code to try to lock per 
  DPLL, since
it won't respect proper programing scheme.

This register is then stored in prcm context. The saving 
  and restore
is now done by kernel side.

Here follow the erratum description

DESCRIPTION

After OFF mode transition, among many restorations, the ROM 
Code restores the
CM_AUTOIDLE_PLL register, and after that, it tries to relock 
the PER DPLL.

In case the restoration data stored in scratchpad memory 
contains a field
CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL = 1, then the way the ROM 
Code restores and
locks the PER DPLL does not respect the PER DPLL 
  programming scheme.

In that case, the DPLL might not lock. Meanwhile, when trying 
to lock the PER
DPLL, the ROM Code does not hang. Only extra latencies are 
introduced at
wake-up.

   
   [sp] You seem to have missed this patch:
   http://marc.info/?l=linux-arm-kernelm=129735383925285w=2
  
  Right,
  
  But that one doesn't clear the AUTO_PERIPH_DPLL bits in the 
  scratchpad area
  to avoid rom code extra overhead (check my patch description).
  
  Besides, why do we want to add more code inside omap_sram_idle,
  if we have better places to this SR?
 
 Didn't see that as a comment earlier?

Better later than never :-) ?

 
 ~sanjeev
 
  
  
   
   ~sanjeev
   
   
  
  All best,
  
  --
  Eduardo Valentin
  


Cheers,

-- 
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-14 Thread Fernando Guzman Lugo 
From: Ramesh Gupta grgu...@ti.com

This patch is to flush the iommu page table entries from L1 and L2
caches using dma_map_single. This also simplifies the implementation
by removing the functions  flush_iopgd_range/flush_iopte_range.

Change-Id: I19c0bf437d75c79084b2fa28c7da50a4c84b91a0
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Fernando Guzman Lugo fernando.l...@ti.com
---
 arch/arm/plat-omap/iommu.c |   41 ++---
 1 files changed, 10 insertions(+), 31 deletions(-)

diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index 8a51fd5..1fb5e41 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -18,6 +18,7 @@
 #include linux/ioport.h
 #include linux/clk.h
 #include linux/platform_device.h
+#include linux/dma-mapping.h
 
 #include asm/cacheflush.h
 
@@ -466,29 +467,6 @@ EXPORT_SYMBOL_GPL(foreach_iommu_device);
 
 #endif /* CONFIG_OMAP_IOMMU_DEBUG_MODULE */
 
-/*
- * H/W pagetable operations
- */
-static void flush_iopgd_range(u32 *first, u32 *last)
-{
-   /* FIXME: L2 cache should be taken care of if it exists */
-   do {
-   asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
-   : : r (first));
-   first += L1_CACHE_BYTES / sizeof(*first);
-   } while (first = last);
-}
-
-static void flush_iopte_range(u32 *first, u32 *last)
-{
-   /* FIXME: L2 cache should be taken care of if it exists */
-   do {
-   asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
-   : : r (first));
-   first += L1_CACHE_BYTES / sizeof(*first);
-   } while (first = last);
-}
-
 static void iopte_free(u32 *iopte)
 {
/* Note: freed iopte's must be clean ready for re-use */
@@ -515,7 +493,7 @@ static u32 *iopte_alloc(struct iommu *obj, u32 *iopgd, u32 
da)
return ERR_PTR(-ENOMEM);
 
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
-   flush_iopgd_range(iopgd, iopgd);
+   dma_map_single(obj-dev, iopgd, 1, DMA_TO_DEVICE);
 
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -544,7 +522,7 @@ static int iopgd_alloc_section(struct iommu *obj, u32 da, 
u32 pa, u32 prot)
}
 
*iopgd = (pa  IOSECTION_MASK) | prot | IOPGD_SECTION;
-   flush_iopgd_range(iopgd, iopgd);
+   dma_map_single(obj-dev, iopgd, 1, DMA_TO_DEVICE);
return 0;
 }
 
@@ -561,7 +539,7 @@ static int iopgd_alloc_super(struct iommu *obj, u32 da, u32 
pa, u32 prot)
 
for (i = 0; i  16; i++)
*(iopgd + i) = (pa  IOSUPER_MASK) | prot | IOPGD_SUPER;
-   flush_iopgd_range(iopgd, iopgd + 15);
+   dma_map_single(obj-dev, iopgd, 16, DMA_TO_DEVICE);
return 0;
 }
 
@@ -574,7 +552,7 @@ static int iopte_alloc_page(struct iommu *obj, u32 da, u32 
pa, u32 prot)
return PTR_ERR(iopte);
 
*iopte = (pa  IOPAGE_MASK) | prot | IOPTE_SMALL;
-   flush_iopte_range(iopte, iopte);
+   dma_map_single(obj-dev, iopte, 1, DMA_TO_DEVICE);
 
dev_vdbg(obj-dev, %s: da:%08x pa:%08x pte:%p *pte:%08x\n,
 __func__, da, pa, iopte, *iopte);
@@ -599,7 +577,7 @@ static int iopte_alloc_large(struct iommu *obj, u32 da, u32 
pa, u32 prot)
 
for (i = 0; i  16; i++)
*(iopte + i) = (pa  IOLARGE_MASK) | prot | IOPTE_LARGE;
-   flush_iopte_range(iopte, iopte + 15);
+   dma_map_single(obj-dev, iopte, 15, DMA_TO_DEVICE);
return 0;
 }
 
@@ -703,7 +681,8 @@ static size_t iopgtable_clear_entry_core(struct iommu *obj, 
u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
-   flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+   dma_map_single(obj-dev, iopte, nent * sizeof(*iopte),
+DMA_TO_DEVICE);
 
/*
 * do table walk to check if this table is necessary or not
@@ -725,7 +704,7 @@ static size_t iopgtable_clear_entry_core(struct iommu *obj, 
u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
-   flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+   dma_map_single(obj-dev, iopgd, nent * sizeof(*iopgd), DMA_TO_DEVICE);
 out:
return bytes;
 }
@@ -770,7 +749,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
iopte_free(iopte_offset(iopgd, 0));
 
*iopgd = 0;
-   flush_iopgd_range(iopgd, iopgd);
+   dma_map_single(obj-dev, iopgd, 1, DMA_TO_DEVICE);
}
 
flush_iotlb_all(obj);
-- 
1.7.0.4

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

Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-14 Thread Russell King - ARM Linux 
On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote:
 From: Ramesh Gupta grgu...@ti.com
 
 This patch is to flush the iommu page table entries from L1 and L2
 caches using dma_map_single. This also simplifies the implementation
 by removing the functions  flush_iopgd_range/flush_iopte_range.

No.  This usage is just wrong.  If you're going to use the DMA API then
unmap it, otherwise the DMA API debugging will go awol.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] OMAP: iommu flush page table entries from L1 and L2 cache

2011-04-14 Thread KyongHo Cho 
Hi, Russell.

I think we need cache maintenance operations that effect on inner and
outer caches at the same time.

Even though the DMA APIs are not for cache maintenance but for IO mapping,
they are useful for cache maint'
because they operate on inner and outer caches.

As you know, inner cache of Cortex-A is logical cache and outer cache
is physical cache in the programmer's point of view.
We need logical address and physical address at the same time to clean
or invalidate inner and outer cache.
That means we need to translate logical to physical address and it is
sometimes not trivial.

Finally, the kernel will contain many similar routines that do same thing.

On Fri, Apr 15, 2011 at 7:30 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Apr 14, 2011 at 04:52:48PM -0500, Fernando Guzman Lugo wrote:
 From: Ramesh Gupta grgu...@ti.com

 This patch is to flush the iommu page table entries from L1 and L2
 caches using dma_map_single. This also simplifies the implementation
 by removing the functions  flush_iopgd_range/flush_iopte_range.

 No.  This usage is just wrong.  If you're going to use the DMA API then
 unmap it, otherwise the DMA API debugging will go awol.
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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