Re: [PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot

[Zumeng Chen]

于 2012年07月05日 13:39, Shubhrajyoti 写道:

Hello,
On Wednesday 04 July 2012 09:27 PM, zumeng.chen wrote:

To: Shubhrajyoti
On 2012年07月04日 23:54, Zumeng Chen wrote:

Does the following fix make sense?

yes , thanks for the patch.
IIRC Rajendra had a similar one.
Some comments below.

WDIOC_GETBOOTSTATUS always return 0 even if the machine
comes from omap-wdt reboot. Because WKUP_MOD is not right
for OMAP3,so give the right addr 0xA00 of PRM_RSTST for
get_reset_sources, which inputs the signal from omap-wdt
reboot, and return 1 when coming from omap-wdt reboot for
WDIOC_GETBOOTSTATUS.

Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
   arch/arm/mach-omap2/prcm.c  |4 +++-
   drivers/watchdog/omap_wdt.c |3 +++
   drivers/watchdog/omap_wdt.h |3 +++
   3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..43f3feb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -49,8 +49,10 @@ void __iomem *prcm_mpu_base;
   u32 omap_prcm_get_reset_sources(void)
   {
   /* XXX This presumably needs modification for 34XX */
-if (cpu_is_omap24xx() || cpu_is_omap34xx())
+if (cpu_is_omap24xx())
   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)
0x7f;
+if (cpu_is_omap34xx())
+return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST)   0x7f;
   if (cpu_is_omap44xx())
   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)
0x7f;

diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..ea57078 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file,
unsigned int cmd,
   if (cpu_is_omap24xx())
   return put_user(omap_prcm_get_reset_sources(),
   (int __user *)arg);
+if (cpu_is_omap34xx())
+return put_user(omap_prcm_get_reset_sources()   0x10
+OMAP3_PRM_RSTST_BIT, (int __user *)arg);

Actually instead of returning yes/no.
The correct  expectation is to return WDIOF_* flags as defined in
include/linux/watchdog.h.

Yes, return WDIOF_CARDRESET is more general, thanks.


(BTW I agree that was something even current code is not
following).Since you are at it may be that’s
something you can consider.
Yes, I just find them, I'll try it to get it more following, like 
get_status.


Regards,
Zumeng



   return put_user(0, (int __user *)arg);
   case WDIOC_KEEPALIVE:
   pm_runtime_get_sync(wdev-dev);
diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
index 09b774c..d8d5daa 100644
--- a/drivers/watchdog/omap_wdt.h
+++ b/drivers/watchdog/omap_wdt.h
@@ -40,6 +40,9 @@
   #define OMAP_WATCHDOG_WPS(0x34)
   #define OMAP_WATCHDOG_SPR(0x48)

+/* PRM_RSTST MPU_WD_RST bit */
+#define OMAP3_PRM_RSTST_BIT4
+
   /* Using the prescaler, the OMAP watchdog could go for many
* months before firing.  These limits work without scaling,
* with the 60 second default assumed by most tools and docs.


--
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: 3.5-rc3: PM/DSS broken (was vdd_mpu_iva warnings)

[Joe Woodward]

 Already debugged and fixed. The exact solution is still under
 discussion, but while waiting for the right fix, you can use this patch
 and you should see CORE hitting retention:
 
http://marc.info/?l=linux-omapm=13453229888w=2
 
 
  Also, why is it now saing sh: write error: Operation not permitted
 after waking, this never happened with 3.4?
 
 I have seen this here and there and have never looked into why that is
 happening.  Clearly the write actually worked because the suspend
 happened, so I'm not sure what's going on there.
 
 Kevin

Thanks!

That does indeed fix it...

Cheers,
Joe


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

Re: [GIT PULL] ARM: OMAP AM33xx: clock data for 3.6

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [120704 02:29]:
 Hi Tony
 
 The following changes since commit 6fd8246b1c1167c983b089f9eaafa13ef9ca7adf:
 
   Merge tag 'omap-devel-a-for-3.6' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into 
 devel-am33xx (2012-06-22 01:50:22 -0700)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-devel-e-for-3.5
 
 for you to fetch changes up to e30384abd63dfa11508a38243e1d78f1d70486b1:
 
   ARM: OMAP3+: clock33xx: Add AM33XX clock tree data (2012-06-29 16:16:40 
 -0600)
 
 
 OMAP AM33xx clock data
 
 

Thanks pulled into devel-am33xx-part2 and fixed up cpu_is_am33xx to
use soc_is_am33xx.

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: [GIT PULL] ARM: OMAP2+: more fixes intended for 3.5-rc

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [120704 07:13]:
 Hi Tony
 
 The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
 
   Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-fixes-b-for-3.5rc
 
 for you to fetch changes up to d7a0b5133f6b1d53d693b9b9873e64e3c8f0db0e:
 
   ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 (2012-07-04 
 06:55:29 -0600)
 
 
 A few more OMAP fixes for 3.5-rc.  These fix some bugs with power
 management and McBSP.
 
 

Thanks pulling into fixes.

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 2/4] arm/dts: Add initial DT support for AM33XX SoC family

[AnilKumar, Chimata]

Hi Tony,

On Fri, Jun 22, 2012 at 15:10:48, AnilKumar, Chimata wrote:
 Add device tree source include file for the AM33XX SoC family.
 An additional .dtsi file is created to describe the generic
 AM33XX CPU module like intc, ocp.
 
 Actual selection of available peripherals is handled in seperate
 .dts files using this am33xx.dtsi generic header file.
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi |  189 
 +
  1 file changed, 189 insertions(+)
  create mode 100644 arch/arm/boot/dts/am33xx.dtsi
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 new file mode 100644
 index 000..f46e353
 --- /dev/null
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -0,0 +1,189 @@
 +/*
 + * Device Tree Source for AM33XX SoC
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/include/ skeleton.dtsi
 +
 +/ {
 + compatible = ti,am33xx;
 +
 + aliases {
 + serial0 = uart1;
 + serial1 = uart2;
 + serial2 = uart3;
 + serial3 = uart4;
 + serial4 = uart5;
 + serial5 = uart6;
 + };
 +
 + cpus {
 + cpu@0 {
 + compatible = arm,cortex-a8;
 + };
 + };
 +
 + /*
 +  * The soc node represents the soc top level view. It is uses for IPs
 +  * that are not memory mapped in the MPU view or for the MPU itself.
 +  */
 + soc {
 + compatible = ti,omap-infra;
 + mpu {
 + compatible = ti,omap3-mpu;
 + ti,hwmods = mpu;
 + };
 + };
 +
 + /*
 +  * XXX: Use a flat representation of the AM33XX interconnect.
 +  * The real AM33XX interconnect network is quite complex.Since
 +  * that will not bring real advantage to represent that in DT
 +  * for the moment, just use a fake OCP bus entry to represent
 +  * the whole bus hierarchy.
 +  */
 + ocp {
 + compatible = simple-bus;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 + ti,hwmods = l3_main;
 +
 + intc: interrupt-controller@4820 {
 + compatible = ti,omap2-intc;
 + interrupt-controller;
 + #interrupt-cells = 1;
 + ti,intc-size = 128;
 + reg = 0x4820 0x1000;
 + };
 +
 + gpio1: gpio@44e07000 {
 + compatible = ti,omap4-gpio;
 + ti,hwmods = gpio1;
 + gpio-controller;
 + #gpio-cells = 2;
 + interrupt-controller;
 + #interrupt-cells = 1;
 + };
 +
 + gpio2: gpio@4804C000 {
 + compatible = ti,omap4-gpio;
 + ti,hwmods = gpio2;
 + gpio-controller;
 + #gpio-cells = 2;
 + interrupt-controller;
 + #interrupt-cells = 1;
 + };
 +
 + gpio3: gpio@481AC000 {
 + compatible = ti,omap4-gpio;
 + ti,hwmods = gpio3;
 + gpio-controller;
 + #gpio-cells = 2;
 + interrupt-controller;
 + #interrupt-cells = 1;
 + };
 +
 + gpio4: gpio@481AE000 {
 + compatible = ti,omap4-gpio;
 + ti,hwmods = gpio4;
 + gpio-controller;
 + #gpio-cells = 2;
 + interrupt-controller;
 + #interrupt-cells = 1;
 + };
 +
 + uart1: serial@44E09000 {
 + compatible = ti,omap3-uart;
 + ti,hwmods = uart1;
 + clock-frequency = 4800;
 + };
 +
 + uart2: serial@48022000 {
 + compatible = ti,omap3-uart;
 + ti,hwmods = uart2;
 + clock-frequency = 4800;
 + };
 +
 + uart3: serial@48024000 {
 + compatible = ti,omap3-uart;
 + ti,hwmods = uart3;
 + clock-frequency = 4800;
 + };
 +
 + uart4: serial@481A6000 {
 + compatible = ti,omap3-uart;
 + ti,hwmods = uart4;
 + clock-frequency = 4800;
 + };
 +
 + uart5: serial@481A8000 {
 + compatible = ti,omap3-uart;
 + ti,hwmods = uart5;
 +  

Re: [GIT PULL] ARM: OMAP2+: more fixes intended for 3.5-rc

[Arnd Bergmann]

On Thursday 05 July 2012, Tony Lindgren wrote:
 * Paul Walmsley p...@pwsan.com [120704 07:13]:
  Hi Tony
  
  The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
  
Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
  
  are available in the git repository at:
  
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
  tags/omap-fixes-b-for-3.5rc
  
  for you to fetch changes up to d7a0b5133f6b1d53d693b9b9873e64e3c8f0db0e:
  
ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 (2012-07-04 
  06:55:29 -0600)
  
 Thanks pulling into fixes.

I'm planning to send a set of fixes upstream to Linus today. Should I
pull your fixes branch before that?

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

Re: [GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [120704 08:48]:
 Hi Tony
 
 The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:
 
   Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-devel-f-for-3.6
 
 for you to fetch changes up to 8cb8de5d87b75f2ecaa1189079764340ea366c0e:
 
   Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 
 'misc_devel_3.6' into omap_devel_f_3.6 (2012-07-04 06:05:51 -0600)
 
 
 
 Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
 for 3.6.  Mostly small infrastructure improvements, and preparation
 for OMAP5 and AM33xx code.
 
 

Thanks applying into cleanup-part2 branch.

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

[PATCH 1/2] OMAP4: otg: phy: fix charger detection

[Ruslan Bilovol]

Charger detection feature is not correctly used
and thus makes some regressions if OTG was used in
the host mode. Charger detection takes 500 ms so
if some device is attached to the host after 500 ms
it will be suddenly resetted.

This feature is enabled by default after reset/cold boot
so always affects PHY usage. So finally this was wrongly
interpreted as phy requires 200ms to start.
After fixing this we can safely remove uggly mdelay after
powering on the PHY.

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/omap_phy_internal.c |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..a13a37c 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -42,12 +42,16 @@
 #defineSESSEND BIT(3)
 #defineIDDIG   BIT(4)
 
+#define CONTROL_USB2PHYCORE0x620
+#define USB2PHY_DISCHGDET  BIT(30)
+
 static struct clk *phyclk, *clk48m, *clk32k;
 static void __iomem *ctrl_base;
 static int usbotghs_control;
 
 int omap4430_phy_init(struct device *dev)
 {
+   u32 usb2phycore;
ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
if (!ctrl_base) {
pr_err(control module ioremap failed\n);
@@ -56,6 +60,11 @@ int omap4430_phy_init(struct device *dev)
/* Power down the phy */
__raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
 
+   /* Disable charger detection by default */
+   usb2phycore = omap4_ctrl_pad_readl(CONTROL_USB2PHYCORE);
+   usb2phycore |= USB2PHY_DISCHGDET;
+   omap4_ctrl_pad_writel(usb2phycore, CONTROL_USB2PHYCORE);
+
if (!dev) {
iounmap(ctrl_base);
return 0;
-- 
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 2/2] OMAP4: otg: phy: remove uggly mdelay(200)

[Ruslan Bilovol]

The original issue with powering on the PHY (and using
200 ms delay after this) is not related to internal
processes in the PHY but is in the incorrect charger
detection feature usage.

Now when it is fixed, we can safely remove this uggly
mdelay that sometimes was called in atomic context and
leads to unacceptable system freezing

Tested with different hubs, devices, and booting scenarios.

Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/omap_phy_internal.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
b/arch/arm/mach-omap2/omap_phy_internal.c
index a13a37c..0a59268 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -152,10 +152,8 @@ int omap4430_phy_suspend(struct device *dev, int suspend)
/* Enable the internel phy clcoks */
omap4430_phy_set_clk(dev, 1);
/* power on the phy */
-   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF)  PHY_PD) {
+   if (__raw_readl(ctrl_base + CONTROL_DEV_CONF)  PHY_PD)
__raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-   mdelay(200);
-   }
 
/* restore the context */
__raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
-- 
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: [GIT PULL] ARM: OMAP2+: more fixes intended for 3.5-rc

[Tony Lindgren]

* Arnd Bergmann a...@arndb.de [120705 01:41]:
 On Thursday 05 July 2012, Tony Lindgren wrote:
  * Paul Walmsley p...@pwsan.com [120704 07:13]:
   Hi Tony
   
   The following changes since commit 
   6887a4131da3adaab011613776d865f4bcfb5678:
   
 Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)
   
   are available in the git repository at:
   
 git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
   tags/omap-fixes-b-for-3.5rc
   
   for you to fetch changes up to d7a0b5133f6b1d53d693b9b9873e64e3c8f0db0e:
   
 ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 
   (2012-07-04 06:55:29 -0600)
   
  Thanks pulling into fixes.
 
 I'm planning to send a set of fixes upstream to Linus today. Should I
 pull your fixes branch before that?

It seems it should be safe to do, I'll take one more look and send
a separate pull request shortly.

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

[PATCH 2/2] arm/dts: Configure pinmuxs for user leds control on Bone

[AnilKumar Ch]

Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/boot/dts/am335x-bone.dts |   24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index a9af4db..c3810b7 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,3 +18,27 @@
reg = 0x8000 0x1000; /* 256 MB */
};
 };
+
+am3358_pinmux {
+
+   pinctrl-names = default;
+   pinctrl-0 = userled_pins;
+
+   userled_pins: pinmux_userled_pins {
+   gpmc_a5.gpio1_21 {
+   pinctrl-simple,cells = 0x54 0x7;  /* 
OMAP_PIN_OUTPUT | OMAP_MUX_MODE7 */
+   };
+
+   gpmc_a6.gpio1_22 {
+   pinctrl-simple,cells = 0x58 0x17; /* 
OMAP_PIN_OUTPUT_PULLUP | OMAP_MUX_MODE7 */
+   };
+
+   gpmc_a7.gpio1_23 {
+   pinctrl-simple,cells = 0x5C 0x7;  /* 
OMAP_PIN_OUTPUT | OMAP_MUX_MODE7 */
+   };
+
+   gpmc_a8.gpio1_24 {
+   pinctrl-simple,cells = 0x60 0x17; /* 
OMAP_PIN_OUTPUT_PULLUP | OMAP_MUX_MODE7 */
+   };
+   };
+};
-- 
1.7.9.5

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

[PATCH 0/2] Add pinctrl support to AM33XX family of devices

[AnilKumar Ch]

Adds pinctrl support to AM33XX family of devices. This patch is
based on the pinctrl-simple driver submitted by Tony L
here: http://lwn.net/Articles/496075/

These patches were tested on AM335x-Bone and AM335x-EVM

AnilKumar Ch (2):
  arm/dts: Add AM33XX basic pinctrl support
  arm/dts: Configure pinmuxs for user leds control on Bone

 arch/arm/boot/dts/am335x-bone.dts |   24 
 arch/arm/boot/dts/am33xx.dtsi |   12 
 2 files changed, 36 insertions(+)

-- 
1.7.9.5

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

[PATCH 1/2] arm/dts: Add AM33XX basic pinctrl support

[AnilKumar Ch]

Adds basic pinctrl support for AM33XX family of devices. This patch
is based on the pinctrl-simple driver submitted by Tony Lindgren's
here: http://lwn.net/Articles/496075/

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..85def31 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,18 @@
};
};
 
+   am3358_pinmux: pinmux@44E10800 {
+   compatible = ti,omap4-padconf;
+   reg = 0x44E10800 0x0338;
+   #address-cells = 1;
+   #size-cells = 0;
+   #pinctrl-cells = 2;
+   pinctrl-simple,register-width = 32;
+   pinctrl-simple,function-mask = 0x7;
+   pinctrl-simple,function-off = 0x;
+   pinctrl-simple,pinconf-mask = 0x78;
+   };
+
/*
 * XXX: Use a flat representation of the AM33XX interconnect.
 * The real AM33XX interconnect network is quite complex.Since
-- 
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

[GIT PULL] omap fixes for v3.5-rc5

[Tony Lindgren]

Hi Arnd  Olof,

Here are few more PM related fixes for the -rc series. If you think
these are too intrusive at this point, let me know.

Regards,

Tony


The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:

  Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-fixes-for-v3.5-rc5

for you to fetch changes up to fa2976a811a764573b2a9c79126d4d66f1f16268:

  Merge tag 'omap-fixes-b-for-3.5rc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes 
(2012-07-05 01:12:08 -0700)



PM related fixes for omaps mostly to get suspend/resume
working again.


Benoit Cousson (1):
  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4

Kevin Hilman (2):
  ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume failure
  ARM: OMAP4: TWL6030: ensure sys_nirq1 is mux'd and wakeup enabled

Paul Walmsley (1):
  ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs 
and aess IP blocks

Tony Lindgren (1):
  Merge tag 'omap-fixes-b-for-3.5rc' of 
git://git.kernel.org/.../pjw/omap-pending into fixes

 arch/arm/mach-omap2/board-overo.c  |  2 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 ++--
 arch/arm/mach-omap2/twl-common.c   |  2 ++
 3 files changed, 17 insertions(+), 15 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: [GIT PULL] ARM: OMAP2+: more fixes intended for 3.5-rc

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [120705 01:57]:
 * Arnd Bergmann a...@arndb.de [120705 01:41]:
  On Thursday 05 July 2012, Tony Lindgren wrote:
   * Paul Walmsley p...@pwsan.com [120704 07:13]:
Hi Tony

The following changes since commit 
6887a4131da3adaab011613776d865f4bcfb5678:

  Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/omap-fixes-b-for-3.5rc

for you to fetch changes up to d7a0b5133f6b1d53d693b9b9873e64e3c8f0db0e:

  ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4 
(2012-07-04 06:55:29 -0600)

   Thanks pulling into fixes.
  
  I'm planning to send a set of fixes upstream to Linus today. Should I
  pull your fixes branch before that?
 
 It seems it should be safe to do, I'll take one more look and send
 a separate pull request shortly.

OK, sent a pull request with Subject: [GIT PULL] omap fixes for v3.5-rc5
 
 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
--
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 0/4] ARM: OMAP2+: dmtimer: cleanup related to devm API and clk usage

[Tony Lindgren]

* DebBarma, Tarun Kanti tarun.ka...@ti.com [120704 21:07]:
 On Thu, Jun 14, 2012 at 4:28 PM, Shilimkar, Santosh 
 santosh.shilim...@ti.com wrote:
 
  Just to let you know that this cleanup is essential for Benoit's OMAP4
  hwmod cleanup
  and OMAP5 minimal support series.

 This is a gentle reminder in case you have missed somehow!!
 Let me know if anything else needs to be done.

Now with the hwmod patch 2/4 pulled into cleanup-part2 from Paul,
I've also applied patch 1/4 there. Patches 3 and 4 have still some pending
comments from Kevin it seems?

Also at least patch 3 won't apply, so please check Kevin's comments
and repost patches 3 and 4 on top of cleanup-part2 at commit 74dd9ec62.

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 RFC] spi: omap2-mcspi: Fix the dma_unmap warning

[Shilimkar, Santosh]

On Thu, Jul 5, 2012 at 2:53 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
 The dma_map and dma_unmap should have same parameter
 passed otherwise we get the below warn.

 ks8851 spi1.0: DMA-API: device driver tries to free DMA memory it has not 
 allocated [device address=0x9f22]

 [2.066925] Modules linked in:
 [2.070312]
 [2.071929] [c001c250] (unwind_backtrace+0x0/0x130) from [c0043d84] 
 (warn_slowpath_common+0x4c/0x64)
 [2.081909] [c0043d84] (warn_slowpath_common+0x4c/0x64) from 
 [c0043e30] (warn_slowpath_fmt+0x30/0x40)
 [2.091949] [c0043e30] (warn_slowpath_fmt+0x30/0x40) from [c0293824] 
 (check_unmap+0x6d0/0x7b0)
 [2.101348] [c0293824] (check_unmap+0x6d0/0x7b0) from [c02939cc] 
 (debug_dma_unmap_page+0x64/0x70)
 [2.111053] [c02939cc] (debug_dma_unmap_page+0x64/0x70) from 
 [c03519a4] (omap2_mcspi_txrx_dma+0x2d8/0x4fc)
 [2.121582] [c03519a4] (omap2_mcspi_txrx_dma+0x2d8/0x4fc) from 
 [c03524d8] (omap2_mcspi_work.clone.4+0xf0/0x290)
 [2.132537] [c03524d8] (omap2_mcspi_work.clone.4+0xf0/0x290) from 
 [c0352900] (omap2_mcspi_transfer_one_message+0x288/0x438)
 [2.144592] [c0352900] (omap2_mcspi_transfer_one_message+0x288/0x438) 
 from [c03503bc] (spi_pump_messages+0x100/0x160)
 [2.156127] [c03503bc] (spi_pump_messages+0x100/0x160) from [c006635c] 
 (kthread_worker_fn+0xac/0x180)
 [2.166168] [c006635c] (kthread_worker_fn+0xac/0x180) from [c0066578] 
 (kthread+0x90/0x9c)
 [2.175140] [c0066578] (kthread+0x90/0x9c) from [c00157fc] 
 (kernel_thread_exit+0x0/0x8)
 [2.183898] ---[ end trace d1830ce6e44292f2 ]---

 Fix the warn by changing the unmap parameter to the one used while doing
 dma_map.

 Reported-by: Russell King li...@arm.linux.org.uk
 Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
 ---
Looks fine to me.
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-V3 1/3] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry

[Tony Lindgren]

* Hiremath, Vaibhav hvaib...@ti.com [120704 02:21]:
 On Wed, Jul 04, 2012 at 12:57:58, Tony Lindgren wrote:
 
  This patch did not apply for some reason, I got:
  
  patching file arch/arm/plat-omap/Makefile
  patch:  malformed patch at line 73: 1.7.0.4
  
  So please tune up your scripts a bit to the patches can be applied
  as they are without manual editing ;)
  
 
 H...
 
 I usually submit the patch against linux-omap/master (to handle cross 
 dependencies), which in some cases fails on other branches you maintain. 
 Probably I will make sure that it allies atleast to relevant branches, for 
 example, in this case it should be applied on linux-omap/cleanup branch as 
 well. 

The malformed patch error usually means that something messed up
the patch, like the mail server.. Maybe tabs got replaced with spaces
or something?

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 v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

Hi Tony,

On Wed, Jul 04, 2012 at 13:21:59, Tony Lindgren wrote:
 * Mohammed, Afzal af...@ti.com [120704 00:05]:
  On Tue, Jul 03, 2012 at 13:47:47, Tony Lindgren wrote:

   Yes how about the gpmc using driver code registers itself with the gpmc 
   code
   and also registers it's retime function with the gpmc? That way the gpmc 
   fck
   stays inside the gpmc code, and the driver specific retime function should
   be able to do the calculation based on driver clocks. The retime function
   needs to have also a pointer to driver private data for it's clocks etc.
  
  Sorry, not sure whether I follow you properly, based on what has been
  understood, will try to rephrase,
  
  All the present gpmc timing calculation done in arch/arm/mach-omap2/gpmc-*
  to be moved to gpmc driver. And all the peripheral drivers using gpmc, i.e
  like smsc911x, tusb6010 needs to register their retime function with gpmc
  driver. And gpmc driver will invoke these registered retime function, when
  clock frequency changes.
  
  But wouldn't it need changes in the existing drivers like smsc911x that are
  used by multiple architectures with gpmc specific registration (put under
  a macro ?). We will be having gpmc driver code that contains knowledge
  about peripheral timing calculation, seems there is no way out of this.
  Peripheral agnostic gpmc code may not happen it seems
 
 It depends. For some drivers scaling both gpmc clock and the device clock
 can happen, like with tusb6010 for example. But the smsc911x does not know
 about the clocks.. So to additional changes to the driver would be required
 to if device clocks need scaling. But for now, we should be able to do it
 at gpmc level with the retime function, or just disable DFS for those clocks
 if not supported.

I have a doubt whether we are talking about the same thing, presently
our main issue is in eliminating the necessity of peripheral specific
functions like gpmc_onenand_init, tusb_setup_interface (which calls
tusb6010_platform_retime), etc., which calculate gpmc timings by
processing peripheral specific timings over gpmc clock period and
these processing were required before gpmc driver probe gets invoked
as gpmc driver needed timings which gpmc can understand to configure
gpmc.

During boot time, gpmc driver needs to know timings in terms of gpmc
parameters to configure gpmc, what I unable to understand from your
proposal is how gpmc driver knows which retime function to invoke (so
that gpmc timings can be calculated based on the type of peripheral)
to calculate gpmc timings. Or do you want a DT field specifying type
of peripheral connected and so that at probe time the relevant retime
can be invoked ?

Initially I thought you were suggesting that all peripheral drivers
connected to gpmc should register their retime function (where
function will be an exported symbol - part of gpmc code) and
invoke the respective retime as part of peripheral driver probe,
hence relieve gpmc driver of doing it, even though retime would be
present as part of gpmc code. But seems that is not what you were
suggesting.

By we should be able to do it at gpmc level, I am unable to
understand what you are suggesting.

  In that case gpmc driver probe would have to be relieved of the task of
  setting up gpmc timings as we have to wait till peripheral drivers
  register their callback, right ?, seems in that case no timing information
  needs (or can be) to be passed from DT
 
 Well we should pass all the gpmc timing information from DT. And then the
 driver also still needs to register it's retime function with gpmc.

So timing information that would be passed from DT should be for
exact gpmc timings like cs_on, cs_off etc., right ?, in that case
should we manually calculate (like as now done by Kernel in
gpmc-onenand.c etc) it by having the knowledge of connected
peripheral  gpmc frequency at boot time and update it in DT ?, as
we can't apply retime on it as we don't know the connected
peripheral in gpmc driver. Or do you want another field through DT
to decide retime that is to be used, then I think passing timing
from DT would not be needed

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

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

[Tony Lindgren]

* Mohammed, Afzal af...@ti.com [120705 03:29]:
 
 I have a doubt whether we are talking about the same thing, presently
 our main issue is in eliminating the necessity of peripheral specific
 functions like gpmc_onenand_init, tusb_setup_interface (which calls
 tusb6010_platform_retime), etc., which calculate gpmc timings by
 processing peripheral specific timings over gpmc clock period and
 these processing were required before gpmc driver probe gets invoked
 as gpmc driver needed timings which gpmc can understand to configure
 gpmc.

Right. The issue is that both the gpmc clock and the peripheral clock
may change, and both cause the need to reprogram the gpmc timings.
 
 During boot time, gpmc driver needs to know timings in terms of gpmc
 parameters to configure gpmc, what I unable to understand from your
 proposal is how gpmc driver knows which retime function to invoke (so
 that gpmc timings can be calculated based on the type of peripheral)
 to calculate gpmc timings. Or do you want a DT field specifying type
 of peripheral connected and so that at probe time the relevant retime
 can be invoked ?

The peripheral init code should register it's timings with gpmc,
and also register a retime function for the gpmc code to use. Then
the timings can eventually come from DT.
 
 Initially I thought you were suggesting that all peripheral drivers
 connected to gpmc should register their retime function (where
 function will be an exported symbol - part of gpmc code) and
 invoke the respective retime as part of peripheral driver probe,
 hence relieve gpmc driver of doing it, even though retime would be
 present as part of gpmc code. But seems that is not what you were
 suggesting.

Yes that's what I was suggesting.
 
 By we should be able to do it at gpmc level, I am unable to
 understand what you are suggesting.

Right, gpmc should be able to handle things alone with the registered
retime function for smsc911x, where the driver does not even know about
the bus. With DT, the platform init code gpmc-smsc911x.c should become
a driver that registers with gpmc and provides the retime function.

For some drivers, like  tusb6010, also the peripheral clock affects the
timings. So both gpmc and the driver may need to be able to call the
retime function.
 
   In that case gpmc driver probe would have to be relieved of the task of
   setting up gpmc timings as we have to wait till peripheral drivers
   register their callback, right ?, seems in that case no timing information
   needs (or can be) to be passed from DT
  
  Well we should pass all the gpmc timing information from DT. And then the
  driver also still needs to register it's retime function with gpmc.
 
 So timing information that would be passed from DT should be for
 exact gpmc timings like cs_on, cs_off etc., right ?, in that case
 should we manually calculate (like as now done by Kernel in
 gpmc-onenand.c etc) it by having the knowledge of connected
 peripheral  gpmc frequency at boot time and update it in DT ?, as
 we can't apply retime on it as we don't know the connected
 peripheral in gpmc driver. Or do you want another field through DT
 to decide retime that is to be used, then I think passing timing
 from DT would not be needed

The timings values should be passed to gpmc from DT. We need to
be able to pass both cycle and time based values. If no cycle based
value is passed, the time based value should be used. This is because
some peripheral timings can be cycle based, while others can be time
based.

The peripheral driver can register it's retime function with gpmc and
get a cookie back that allows getting the DT provided timings from gpmc.
And after that the initial timings can be set.

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] OMAP: USB : Fix the EHCI enumeration and core retention issue

[Samuel Ortiz]

Hi Kevin, Keshava,

On Wed, Jul 04, 2012 at 06:33:35AM -0700, Kevin Hilman wrote:
 Munegowda, Keshava keshava_mgo...@ti.com writes:
 
  On Tue, Jul 3, 2012 at 12:17 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
  On Mon, Jul 2, 2012 at 10:24 PM, Kevin Hilman khil...@ti.com wrote:
  Felipe, Keshava,
 
  Kevin Hilman khil...@ti.com writes:
 
  Felipe Balbi ba...@ti.com writes:
 
  [...]
 
  Keshava is reverting a fix for a HW errata. I can't accept it as it will
  cause regressions. Granted, regression by regression, there's no change,
  but I simply can't knowingly cause a regression to the driver just to
  have PM working. We need a real fix for this issue.
 
  Sure, as long as there is a fix in this -rc cycle.
 
  This driver intoduced changes in v3.5 that break PM for the whole SoC
  (by preventing CORE retention.)  These changes were clearly not tested
  with PM.
 
  If you cannot fix this during the -rc cycle, then you need to revert the
  driver PM changes that broke PM for the *whole* SoC.
 
  What's the status of this regression?
 
  This is still broken in v3.5-rc and is preventing CORE retention for the
  *whole* SoC.
 
  Please fix this, either with a proper fix, or a revert for 3.5-rc.
 
 
  The proper fix for this is implement ion of ehci remote wakeup through
  I/O chain handler; it takes time.
  As Felipe also mentioned,  This patch is OK for now.
 
  Sorry, Felipe still insist not to revert this patch, but to change
  this patch requires quite more changes in the usbhs core
  and we need to see the how the hub control changes need to be brought
  in to usbhs core. so , reverting is the
  best solution to time being.
 
  Its observed that ehci was enabled after linux kernal version 3.3 ;
  before that even though driver was there
  the ehci deriver was disabled by defaults; and it is expected the
  people who want to use NFS then can enable it
  explicitly.
 
  so,  the solution is
 
  1. Use this patch ( reverting the hw errata ) to fix the NFS Boot and
  suspend/resume crash
 
 Or, use the patches from Russ Dill where were more targetted fixes.
 Either way, I'm OK with that.
Keshava, I'll wait for your decision here to know which patch you want me to
take.



  2. Disable the ehci driver to make the pm work in idle case ;
This configuration should exist till the ehci remote
  wakeup implementation completes.
 
 Yes.  Please disabled it by default.
 
 Until PM in this driver can work without breaking PM for the whole SoC,
 it should remain disabled.
So, I should expect another patch here as well.
FYI, I was planning to send a pull request for MFD 3.5 fixes to Linus
tomorrow, but I'll wait for you. Hopefully I should be able to send it on
Monday.

Cheers,
Samuel.

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

Re: [GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6

[Shilimkar, Santosh]

Tony,

On Thu, Jul 5, 2012 at 2:10 PM, Tony Lindgren t...@atomide.com wrote:
 * Paul Walmsley p...@pwsan.com [120704 08:48]:
 Hi Tony

 The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:

   Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-devel-f-for-3.6

 for you to fetch changes up to 8cb8de5d87b75f2ecaa1189079764340ea366c0e:

   Merge branches 'hwmod_am335x_support_3.6', 'clkdm_pwrdm_devel_a_3.6' and 
 'misc_devel_3.6' into omap_devel_f_3.6 (2012-07-04 06:05:51 -0600)

 

 Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
 for 3.6.  Mostly small infrastructure improvements, and preparation
 for OMAP5 and AM33xx code.

 

 Thanks applying into cleanup-part2 branch.

Looks like the merge has not happened correctly.
I see from the commit log that, you had a merge conflict in omap_hwmod.c
and probably while resolving that the below change got missed.

Tarun Kanti DebBarma (1):
  ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API

So I tried pulling Paul's branch again on cleanup-part2 at commit 8cb8de5d87
and it got merged without any conflicts.

Do you want to re-merge Paul's series in cleanup-part2 or re-apply the above
patch ?

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 0/4] ARM: OMAP2+: dmtimer: cleanup related to devm API and clk usage

[DebBarma, Tarun Kanti]

Hi Tony,

On Thu, Jul 5, 2012 at 2:58 PM, Tony Lindgren t...@atomide.com wrote:
 * DebBarma, Tarun Kanti tarun.ka...@ti.com [120704 21:07]:
 On Thu, Jun 14, 2012 at 4:28 PM, Shilimkar, Santosh 
 santosh.shilim...@ti.com wrote:
 
  Just to let you know that this cleanup is essential for Benoit's OMAP4
  hwmod cleanup
  and OMAP5 minimal support series.

 This is a gentle reminder in case you have missed somehow!!
 Let me know if anything else needs to be done.

 Now with the hwmod patch 2/4 pulled into cleanup-part2 from Paul,
 I've also applied patch 1/4 there. Patches 3 and 4 have still some pending
 comments from Kevin it seems?
Yes


 Also at least patch 3 won't apply, so please check Kevin's comments
 and repost patches 3 and 4 on top of cleanup-part2 at commit 74dd9ec62.
Patch 3: Comment was about adding summary in patch 0/x why we have
not removed iclk in OMAP2/3 platform. In other words there was no
specific changes needed on patch 3 as such. BTW, patch 3 is already merged.

Patch 4:
--- [Kevin's comment] ---

 Comment applies to PATCH 4/4 also.
 You mean removing iclk from clkdev table? That is already done in this patch!!
I meant why can't OMAP2/3 data be removed in PATCH 4/4 also, which only
touches OMAP4.
--- [end] ---
In patch 4 the only change done in the clock table was to correct the
name mis-match
of functional clock names for OMAP4 between clock data and hwmod data.
For OMAP2/3 the names are already matching. As the comment was given in patch 3
where iclk entries got removed for OMAP4, he must have expected similar cleanup
is done for fclk in patch 4. But as I said, only the name mis-match is
corrected.
In summary, there is no specific changes needed in the patch.

I will rebase on top of cleanup-part2 are repost patch 4.
--
Tarun

 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 v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

Hi Tony,

On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
 * Mohammed, Afzal af...@ti.com [120705 03:29]:

  Initially I thought you were suggesting that all peripheral drivers
  connected to gpmc should register their retime function (where

 Yes that's what I was suggesting.

To understand you better, peripheral drivers above refers to
driver created out of present gpmc platform init code like
gpmc-smsc911x.c. You were not referring to
drivers/net/ethernet/smsc/smsc911x.c, right ?

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

[PATCH v1 01/14] ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c and call it __weak

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

omap_secure_ram_reserve_memblock is stubbed for OMAP1,2 only builds using a
 ifdef check. But this results in adding CONFIG_ARCH_OMAPxx checks for
future socs that use the real function. So move this to common.c file and
call it __weak.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/plat-omap/common.c   |9 +
 arch/arm/plat-omap/include/plat/omap-secure.h |5 -
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 0a9b9a9..89a3723 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -77,3 +77,12 @@ void __init omap_init_consistent_dma_size(void)
init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE  20);
 #endif
 }
+
+/*
+ * Stub function for OMAP2 so that common files
+ * continue to build when custom builds are used
+ */
+int __weak omap_secure_ram_reserve_memblock(void)
+{
+   return 0;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h 
b/arch/arm/plat-omap/include/plat/omap-secure.h
index 8c7994c..0e4acd2 100644
--- a/arch/arm/plat-omap/include/plat/omap-secure.h
+++ b/arch/arm/plat-omap/include/plat/omap-secure.h
@@ -3,12 +3,7 @@
 
 #include linux/types.h
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
 extern int omap_secure_ram_reserve_memblock(void);
-#else
-static inline void omap_secure_ram_reserve_memblock(void)
-{ }
-#endif
 
 #ifdef CONFIG_OMAP4_ERRATA_I688
 extern int omap_barrier_reserve_memblock(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

[PATCH v1 07/14] ARM: OMAP5: l3: Add l3 error handler support for omap5.

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/Makefile  |1 +
 arch/arm/mach-omap2/devices.c |2 +-
 arch/arm/mach-omap2/omap_l3_noc.h |   22 ++
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index bb6b364..365421d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -191,6 +191,7 @@ obj-$(CONFIG_OMAP3_EMU) += emu.o
 # L3 interconnect
 obj-$(CONFIG_ARCH_OMAP3)   += omap_l3_smx.o
 obj-$(CONFIG_ARCH_OMAP4)   += omap_l3_noc.o
+obj-$(CONFIG_SOC_OMAP5)+= omap_l3_noc.o
 
 obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
 mailbox_mach-objs  := mailbox.o
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b4b932..f443f24 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -84,7 +84,7 @@ static int __init omap4_l3_init(void)
 * To avoid code running on other OMAPs in
 * multi-omap builds
 */
-   if (!(cpu_is_omap44xx()))
+   if (!cpu_is_omap44xx()  !cpu_is_omap54xx())
return -ENODEV;
 
for (i = 0; i  L3_MODULES; i++) {
diff --git a/arch/arm/mach-omap2/omap_l3_noc.h 
b/arch/arm/mach-omap2/omap_l3_noc.h
index 90b5098..a6ce34d 100644
--- a/arch/arm/mach-omap2/omap_l3_noc.h
+++ b/arch/arm/mach-omap2/omap_l3_noc.h
@@ -51,7 +51,9 @@ static u32 l3_targ_inst_clk1[] = {
0x200, /* DMM2 */
0x300, /* ABE */
0x400, /* L4CFG */
-   0x600  /* CLK2 PWR DISC */
+   0x600,  /* CLK2 PWR DISC */
+   0x0,/* Host CLK1 */
+   0x900   /* L4 Wakeup */
 };
 
 static u32 l3_targ_inst_clk2[] = {
@@ -72,11 +74,16 @@ static u32 l3_targ_inst_clk2[] = {
0xE00, /* missing in TRM corresponds to AES2*/
0xC00, /* L4 PER3 */
0xA00, /* L4 PER1*/
-   0xB00 /* L4 PER2*/
+   0xB00, /* L4 PER2*/
+   0x0, /* HOST CLK2 */
+   0x1800, /* CAL */
+   0x1700 /* LLI */
 };
 
 static u32 l3_targ_inst_clk3[] = {
-   0x0100  /* EMUSS */
+   0x0100  /* EMUSS */,
+   0x0300, /* DEBUGSS_CT_TBR */
+   0x0 /* HOST CLK3 */
 };
 
 static struct l3_masters_data {
@@ -110,13 +117,15 @@ static struct l3_masters_data {
{ 0xC8, USBHOSTFS}
 };
 
-static char *l3_targ_inst_name[L3_MODULES][18] = {
+static char *l3_targ_inst_name[L3_MODULES][21] = {
{
DMM1,
DMM2,
ABE,
L4CFG,
CLK2 PWR DISC,
+   HOST CLK1,
+   L4 WAKEUP
},
{
CORTEX M3 ,
@@ -137,9 +146,14 @@ static char *l3_targ_inst_name[L3_MODULES][18] = {
L4 PER3,
L4 PER1,
L4 PER2,
+   HOST CLK2,
+   CAL,
+   LLI
},
{
EMUSS,
+   DEBUG SOURCE,
+   HOST CLK3
},
 };
 
-- 
1.7.9.5

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

[PATCH v1 06/14] ARM: OMAP5: gpmc: Update gpmc_init()

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

GPMC module is the same as in OMAP4.
Just update the base address and irq number.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2286410..fa21b4b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -727,7 +727,8 @@ static int __init gpmc_init(void)
ck = gpmc_fck;
l = OMAP34XX_GPMC_BASE;
gpmc_irq = INT_34XX_GPMC_IRQ;
-   } else if (cpu_is_omap44xx()) {
+   } else if (cpu_is_omap44xx() || cpu_is_omap54xx()) {
+   /* Base address and irq number are same for OMAP4/5 */
ck = gpmc_ck;
l = OMAP44XX_GPMC_BASE;
gpmc_irq = OMAP44XX_IRQ_GPMC;
-- 
1.7.9.5

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

[PATCH v1 10/14] ARM: omap2+: board-generic: clean up the irq data from board file.

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Move the irq_match arrays and the irq init functions of OMAP 2,3
and 4 based boards out of board-generic.c file and also rename the
irq init function to match the interrupt controller present in
the SOCs.

This is a preparatory patch to add the OMAP5 evm board's irq init
support with device tree.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-generic.c |   23 ++-
 arch/arm/mach-omap2/common.h|6 --
 arch/arm/mach-omap2/irq.c   |   13 -
 arch/arm/mach-omap2/omap4-common.c  |   13 +
 4 files changed, 35 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 2f2abfb..716e6b1 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -25,23 +25,12 @@
 #include common-board-devices.h
 
 #if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
-#define omap_intc_of_init  NULL
+#define intc_of_init   NULL
 #endif
 #ifndef CONFIG_ARCH_OMAP4
 #define gic_of_initNULL
 #endif
 
-static struct of_device_id irq_match[] __initdata = {
-   { .compatible = ti,omap2-intc, .data = omap_intc_of_init, },
-   { .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
-   { }
-};
-
-static void __init omap_init_irq(void)
-{
-   of_irq_init(irq_match);
-}
-
 static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -65,7 +54,7 @@ DT_MACHINE_START(OMAP242X_DT, Generic OMAP2420 (Flattened 
Device Tree))
.reserve= omap_reserve,
.map_io = omap242x_map_io,
.init_early = omap2420_init_early,
-   .init_irq   = omap_init_irq,
+   .init_irq   = omap_intc_of_init,
.handle_irq = omap2_intc_handle_irq,
.init_machine   = omap_generic_init,
.timer  = omap2_timer,
@@ -84,7 +73,7 @@ DT_MACHINE_START(OMAP243X_DT, Generic OMAP2430 (Flattened 
Device Tree))
.reserve= omap_reserve,
.map_io = omap243x_map_io,
.init_early = omap2430_init_early,
-   .init_irq   = omap_init_irq,
+   .init_irq   = omap_intc_of_init,
.handle_irq = omap2_intc_handle_irq,
.init_machine   = omap_generic_init,
.timer  = omap2_timer,
@@ -103,7 +92,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened Device 
Tree))
.reserve= omap_reserve,
.map_io = omap3_map_io,
.init_early = omap3430_init_early,
-   .init_irq   = omap_init_irq,
+   .init_irq   = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine   = omap_generic_init,
.timer  = omap3_timer,
@@ -122,7 +111,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened 
Device Tree))
.reserve= omap_reserve,
.map_io = am33xx_map_io,
.init_early = am33xx_init_early,
-   .init_irq   = omap_init_irq,
+   .init_irq   = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine   = omap_generic_init,
.timer  = omap3_am33xx_timer,
@@ -140,7 +129,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened Device 
Tree))
.reserve= omap_reserve,
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
-   .init_irq   = omap_init_irq,
+   .init_irq   = omap_gic_of_init,
.handle_irq = gic_handle_irq,
.init_machine   = omap_generic_init,
.init_late  = omap4430_init_late,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 367e1fe..7f93cf0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -234,6 +234,8 @@ void omap3_intc_prepare_idle(void);
 void omap3_intc_resume_idle(void);
 void omap2_intc_handle_irq(struct pt_regs *regs);
 void omap3_intc_handle_irq(struct pt_regs *regs);
+void omap_intc_of_init(void);
+void omap_gic_of_init(void);
 
 #ifdef CONFIG_CACHE_L2X0
 extern void __iomem *omap4_get_l2cache_base(void);
@@ -241,10 +243,10 @@ extern void __iomem *omap4_get_l2cache_base(void);
 
 struct device_node;
 #ifdef CONFIG_OF
-int __init omap_intc_of_init(struct device_node *node,
+int __init intc_of_init(struct device_node *node,
 struct device_node *parent);
 #else
-int __init omap_intc_of_init(struct device_node *node,
+int __init intc_of_init(struct device_node *node,
 struct device_node *parent)
 {
return 0;
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index d5b34fe..8467beb 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -21,6 +21,7 @@
 #include 

[PATCH v1 13/14] ARM: OMAP5: Add the build support

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the build support required for OMAP5 soc
in to omap2+ config.

Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/configs/omap2plus_defconfig |1 +
 arch/arm/mach-omap2/Kconfig  |6 ++
 arch/arm/plat-omap/Kconfig   |4 ++--
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 9854ff4..5c90370 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -236,3 +236,4 @@ CONFIG_CRC_T10DIF=y
 CONFIG_CRC_ITU_T=y
 CONFIG_CRC7=y
 CONFIG_LIBCRC32C=y
+CONFIG_SOC_OMAP5=y
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 042f157..21ef501 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -56,6 +56,12 @@ config ARCH_OMAP4
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
 
+config SOC_OMAP5
+   bool TI OMAP5
+   select CPU_V7
+   select ARM_GIC
+   select HAVE_SMP
+
 comment OMAP Core Type
depends on ARCH_OMAP2
 
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..dcfb506 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -29,7 +29,7 @@ config ARCH_OMAP2PLUS
select USE_OF
select PROC_DEVICETREE if PROC_FS
help
- Systems based on OMAP2, OMAP3 or OMAP4
+ Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
 
 endchoice
 
@@ -150,7 +150,7 @@ config OMAP_32K_TIMER
  This timer saves power compared to the OMAP_MPU_TIMER, and has
  support for no tick during idle. The 32KHz timer provides less
  intra-tick resolution than OMAP_MPU_TIMER. The 32KHz timer is
- currently only available for OMAP16XX, 24XX, 34XX and OMAP4.
+ currently only available for OMAP16XX, 24XX, 34XX and OMAP4/5.
 
 config OMAP3_L2_AUX_SECURE_SAVE_RESTORE
bool OMAP3 HS/EMU save and restore for L2 AUX control register
-- 
1.7.9.5

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

[PATCH v1 02/14] ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme.

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

OMAP socs has a legacy and a highlander version of the
32k sync counter IP. The register offsets vary between the
highlander and the legacy scheme. So use the 'SCHEME'
bits(30-31) of the revision register to distinguish between
the two versions and choose the CR register offset accordingly.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/plat-omap/counter_32k.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index 2132c4f..dbf1e03 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -29,7 +29,10 @@
 #include plat/clock.h
 
 /* OMAP2_32KSYNCNT_CR_OFF: offset of 32ksync counter register */
-#define OMAP2_32KSYNCNT_CR_OFF 0x10
+#define OMAP2_32KSYNCNT_REV_OFF0x0
+#define OMAP2_32KSYNCNT_REV_SCHEME (0x3  30)
+#define OMAP2_32KSYNCNT_CR_OFF_LOW 0x10
+#define OMAP2_32KSYNCNT_CR_OFF_HIGH0x30
 
 /*
  * 32KHz clocksource ... always available, on pretty most chips except
@@ -84,9 +87,16 @@ int __init omap_init_clocksource_32k(void __iomem *vbase)
int ret;
 
/*
-* 32k sync Counter register offset is at 0x10
+* 32k sync Counter IP register offsets vary between the
+* highlander version and the legacy ones.
+* The 'SCHEME' bits(30-31) of the revision register is used
+* to identify the version.
 */
-   sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF;
+   if (__raw_readl(vbase + OMAP2_32KSYNCNT_REV_OFF) 
+   OMAP2_32KSYNCNT_REV_SCHEME)
+   sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_HIGH;
+   else
+   sync32k_cnt_reg = vbase + OMAP2_32KSYNCNT_CR_OFF_LOW;
 
/*
 * 12 rough estimate from the calculations in
-- 
1.7.9.5

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

[PATCH 2/5] ARM: OMAP5: board-generic: Add device tree support.

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the minimal support for OMAP5 evm board
with device tree.

Reviewed-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/omap.txt  |3 +++
 arch/arm/mach-omap2/board-generic.c|   19 +++
 arch/arm/mach-omap2/omap4-common.c |1 +
 3 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index e78e8bc..3d450f6 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -47,3 +47,6 @@ Boards:
 
 - AM335X EVM : Software Developement Board for AM335x
   compatible = ti,am335x-evm, ti,am33xx, ti,omap3
+
+- OMAP5 EVM : Evaluation Module
+  compatible = ti,omap5-evm, ti,omap5
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 716e6b1..6f93a20 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,3 +138,22 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened 
Device Tree))
.restart= omap_prcm_restart,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_OMAP5
+static const char *omap5_boards_compat[] __initdata = {
+   ti,omap5,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap5_map_io,
+   .init_early = omap5_init_early,
+   .init_irq   = omap_gic_of_init,
+   .handle_irq = gic_handle_irq,
+   .init_machine   = omap_generic_init,
+   .timer  = omap5_timer,
+   .dt_compat  = omap5_boards_compat,
+   .restart= omap_prcm_restart,
+MACHINE_END
+#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index f38d659..c29dee9 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -214,6 +214,7 @@ early_initcall(omap4_sar_ram_init);
 
 static struct of_device_id irq_match[] __initdata = {
{ .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+   { .compatible = arm,cortex-a15-gic, .data = gic_of_init, },
{ }
 };
 
-- 
1.7.9.5

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

[PATCH v1 14/14] ARM: Kconfig update to support additional GPIOs in OMAP5

[Santosh Shilimkar]

From: Tarun Kanti DebBarma tarun.ka...@ti.com

OMAP5 has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.

Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Reported-by: Govindraj.R govindraj.r...@ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..02fae9a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1581,6 +1581,7 @@ config ARCH_NR_GPIO
default 1024 if ARCH_SHMOBILE || ARCH_TEGRA
default 355 if ARCH_U8500
default 264 if MACH_H4700
+   default 512 if SOC_OMAP5
default 0
help
  Maximum number of GPIOs in the system.
-- 
1.7.9.5

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

[PATCH 3/5] arm/dts: OMAP5: Add omap5 dts files

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the minimum device tree files required for
OMAP5 to boot.

Reviewed-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/boot/dts/omap5-evm.dts |   20 +
 arch/arm/boot/dts/omap5.dtsi|  184 +++
 2 files changed, 204 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-evm.dts
 create mode 100644 arch/arm/boot/dts/omap5.dtsi

diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
new file mode 100644
index 000..200c39a
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap5.dtsi
+
+/ {
+   model = TI OMAP5 EVM board;
+   compatible = ti,omap5-evm, ti,omap5;
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x4000; /* 1 GB */
+   };
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
new file mode 100644
index 000..57e5270
--- /dev/null
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -0,0 +1,184 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on omap4.dtsi
+ */
+
+/*
+ * Carveout for multimedia usecases
+ * It should be the last 48MB of the first 512MB memory part
+ * In theory, it should not even exist. That zone should be reserved
+ * dynamically during the .reserve callback.
+ */
+/memreserve/ 0x9d00 0x0300;
+
+/include/ skeleton.dtsi
+
+/ {
+   compatible = ti,omap5;
+   interrupt-parent = gic;
+
+   aliases {
+   serial0 = uart1;
+   serial1 = uart2;
+   serial2 = uart3;
+   serial3 = uart4;
+   serial4 = uart5;
+   serial5 = uart6;
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = arm,cortex-a15;
+   };
+   cpu@1 {
+   compatible = arm,cortex-a15;
+   };
+   };
+
+   /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+   soc {
+   compatible = ti,omap-infra;
+   mpu {
+   compatible = ti,omap5-mpu;
+   ti,hwmods = mpu;
+   };
+   };
+
+   /*
+* XXX: Use a flat representation of the OMAP3 interconnect.
+* The real OMAP interconnect network is quite complex.
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+   ocp {
+   compatible = ti,omap4-l3-noc, simple-bus;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+
+   gic: interrupt-controller@48211000 {
+   compatible = arm,cortex-a15-gic;
+   interrupt-controller;
+   #interrupt-cells = 3;
+   reg = 0x48211000 0x1000,
+ 0x48212000 0x1000;
+   };
+
+   gpio1: gpio@4ae1 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio1;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio2: gpio@48055000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio2;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio3: gpio@48057000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio3;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio4: gpio@48059000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio4;
+   gpio-controller;
+   

[PATCH v1 09/14] ARM: OMAP5: Add SMP support.

[Santosh Shilimkar]

Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/common.h   |1 +
 arch/arm/mach-omap2/omap-headsmp.S |   21 +
 arch/arm/mach-omap2/omap-smp.c |   35 +++
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 53c87ab..367e1fe 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -271,6 +271,7 @@ extern void omap_secondary_startup(void);
 extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
 extern void omap_auxcoreboot_addr(u32 cpu_addr);
 extern u32 omap_read_auxcoreboot0(void);
+extern void omap5_secondary_startup(void);
 #endif
 
 #if defined(CONFIG_SMP)  defined(CONFIG_PM)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
b/arch/arm/mach-omap2/omap-headsmp.S
index 503ac77..502e313 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -19,6 +19,27 @@
 #include linux/init.h
 
__CPUINIT
+
+/* Physical address needed since MMU not enabled yet on secondary core */
+#define AUX_CORE_BOOT0_PA  0x48281800
+
+/*
+ * OMAP5 specific entry point for secondary CPU to jump from ROM
+ * code.  This routine also provides a holding flag into which
+ * secondary core is held until we're ready for it to initialise.
+ * The primary core will update this flag using a hardware
++ * register AuxCoreBoot0.
+ */
+ENTRY(omap5_secondary_startup)
+wait:  ldr r2, =AUX_CORE_BOOT0_PA  @ read from AuxCoreBoot0
+   ldr r0, [r2]
+   mov r0, r0, lsr #5
+   mrc p15, 0, r4, c0, c0, 5
+   and r4, r4, #0x0f
+   cmp r0, r4
+   bne wait
+   b   secondary_startup
+END(omap5_secondary_startup)
 /*
  * OMAP4 specific entry point for secondary CPU to jump from ROM
  * code.  This routine also provides a holding flag into which
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index badfe39..7d118b9 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,12 @@
 #include common.h
 #include clockdomain.h
 
+#define CPU_MASK   0xff00
+#define CPU_CORTEX_A9  0x410FC090
+#define CPU_CORTEX_A15 0x410FC0F0
+
+#define OMAP5_CORE_COUNT   0x2
+
 /* SCU base address */
 static void __iomem *scu_base;
 
@@ -133,7 +139,6 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 static void __init wakeup_secondary(void)
 {
void __iomem *base = omap_get_wakeupgen_base();
-
/*
 * Write the address of secondary startup routine into the
 * AuxCoreBoot1 where ROM code will jump and start executing
@@ -162,16 +167,21 @@ static void __init wakeup_secondary(void)
  */
 void __init smp_init_cpus(void)
 {
-   unsigned int i, ncores;
-
-   /*
-* Currently we can't call ioremap here because
-* SoC detection won't work until after init_early.
-*/
-   scu_base =  OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);
-   BUG_ON(!scu_base);
-
-   ncores = scu_get_core_count(scu_base);
+   unsigned int i = 0, ncores = 1, cpu_id;
+
+   /* Use ARM cpuid check here, as SoC detection will not work so early */
+   cpu_id = read_cpuid(CPUID_ID)  CPU_MASK;
+   if (cpu_id == CPU_CORTEX_A9) {
+   /*
+* Currently we can't call ioremap here because
+* SoC detection won't work until after init_early.
+*/
+   scu_base =  OMAP2_L4_IO_ADDRESS(OMAP44XX_SCU_BASE);
+   BUG_ON(!scu_base);
+   ncores = scu_get_core_count(scu_base);
+   } else if (cpu_id == CPU_CORTEX_A15) {
+   ncores = OMAP5_CORE_COUNT;
+   }
 
/* sanity check */
if (ncores  nr_cpu_ids) {
@@ -193,6 +203,7 @@ void __init platform_smp_prepare_cpus(unsigned int max_cpus)
 * Initialise the SCU and wake up the secondary core using
 * wakeup_secondary().
 */
-   scu_enable(scu_base);
+   if (scu_base)
+   scu_enable(scu_base);
wakeup_secondary();
 }
-- 
1.7.9.5

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

[PATCH v1 00/14] ARM: OMAP5: Add minimal OMAP5 SOC support

[Santosh Shilimkar]

Tony,

The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15
based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks
with OMAP4 SOCS and hence large part of the peripherals are re-used.

OMAP5432 is another variant of OMAP5430, with a memory controller supporting
DDR3 and SATA.

Series is generated against cleanup-part2 branch at commit 74dd9ec6.

BOOT tested:
- OMAP4430 SDP
- OMAP3430 SDP
- OMAP3430 SDP
- OMAP5430 EVM with OMAP5 hwmod/PRM?CM data files.

Build testd:
- OMAP1 only build, OMAP[2/3/4/5] Only builds.

The following changes since commit 74dd9ec627582bfd4477f01ceeaaa3f54e3748b8:

  ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe() (2012-07-05 
02:15:55 -0700)

are available in the git repository at:

  git://github.com/SantoshShilimkar/linux.git for_3.6/omap5_minimal_support

for you to fetch changes up to c78c1186f5c88fe16070a6860d4843ce74200bcd:

  ARM: Kconfig update to support additional GPIOs in OMAP5 (2012-07-05 16:18:44 
+0530)



R Sricharan (11):
  ARM: OMAP2+: Move stubbed secure_sram_reserve function to a common.c
and call it __weak
  ARM: OMAP: counter-32k: Select the CR register offset using the IP
scheme.
  ARM: OMAP5: id: Add cpu id for ES versions
  ARM: OMAP5: Add minimal support for OMAP5430 SOC
  ARM: OMAP5: timer: Add clocksource, clockevent support
  ARM: OMAP5: gpmc: Update gpmc_init()
  ARM: OMAP5: l3: Add l3 error handler support for omap5.
  ARM: omap2+: board-generic: clean up the irq data from board file.
  ARM: OMAP5: board-generic: Add device tree support.
  arm/dts: OMAP5: Add omap5 dts files
  ARM: OMAP5: Add the build support

Santosh Shilimkar (2):
  ARM: OMAP5: Add the WakeupGen IP updates
  ARM: OMAP5: Add SMP support.

Tarun Kanti DebBarma (1):
  ARM: Kconfig update to support additional GPIOs in OMAP5

 .../devicetree/bindings/arm/omap/omap.txt  |3 +
 arch/arm/Kconfig   |1 +
 arch/arm/boot/dts/omap5-evm.dts|   20 +++
 arch/arm/boot/dts/omap5.dtsi   |  184 
 arch/arm/configs/omap2plus_defconfig   |1 +
 arch/arm/mach-omap2/Kconfig|6 +
 arch/arm/mach-omap2/Makefile   |   24 ++-
 arch/arm/mach-omap2/board-generic.c|   42 +++--
 arch/arm/mach-omap2/common.c   |   24 +++
 arch/arm/mach-omap2/common.h   |   19 +-
 arch/arm/mach-omap2/control.h  |4 +
 arch/arm/mach-omap2/devices.c  |2 +-
 arch/arm/mach-omap2/gpmc.c |3 +-
 arch/arm/mach-omap2/id.c   |   42 -
 arch/arm/mach-omap2/include/mach/debug-macro.S |8 +-
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h  |7 +
 arch/arm/mach-omap2/io.c   |   44 +
 arch/arm/mach-omap2/iomap.h|   27 +++
 arch/arm/mach-omap2/irq.c  |   13 +-
 arch/arm/mach-omap2/omap-headsmp.S |   21 +++
 arch/arm/mach-omap2/omap-hotplug.c |   24 ++-
 arch/arm/mach-omap2/omap-smp.c |   52 --
 arch/arm/mach-omap2/omap-wakeupgen.c   |  114 +---
 arch/arm/mach-omap2/omap4-common.c |   14 ++
 arch/arm/mach-omap2/omap4-sar-layout.h |   12 +-
 arch/arm/mach-omap2/omap_hwmod.c   |2 +-
 arch/arm/mach-omap2/omap_l3_noc.h  |   22 ++-
 arch/arm/mach-omap2/prcm-common.h  |2 +-
 arch/arm/mach-omap2/prcm.c |2 +-
 arch/arm/mach-omap2/timer.c|5 +
 arch/arm/plat-omap/Kconfig |4 +-
 arch/arm/plat-omap/Makefile|4 +-
 arch/arm/plat-omap/common.c|9 +
 arch/arm/plat-omap/counter_32k.c   |   16 +-
 arch/arm/plat-omap/include/plat/clkdev_omap.h  |1 +
 arch/arm/plat-omap/include/plat/clock.h|1 +
 arch/arm/plat-omap/include/plat/cpu.h  |   22 ++-
 arch/arm/plat-omap/include/plat/hardware.h |1 +
 arch/arm/plat-omap/include/plat/multi.h|9 +
 arch/arm/plat-omap/include/plat/omap-secure.h  |5 -
 arch/arm/plat-omap/include/plat/omap54xx.h |   32 
 arch/arm/plat-omap/include/plat/serial.h   |   10 ++
 arch/arm/plat-omap/include/plat/uncompress.h   |6 +
 arch/arm/plat-omap/sram.c  |   11 +-
 44 files changed, 775 insertions(+), 100 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap5-evm.dts
 create mode 100644 arch/arm/boot/dts/omap5.dtsi
 create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h

-- 
1.7.9.5

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

[PATCH v1 12/14] arm/dts: OMAP5: Add omap5 dts files

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the minimum device tree files required for
OMAP5 to boot.

Reviewed-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/boot/dts/omap5-evm.dts |   20 +
 arch/arm/boot/dts/omap5.dtsi|  184 +++
 2 files changed, 204 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap5-evm.dts
 create mode 100644 arch/arm/boot/dts/omap5.dtsi

diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
new file mode 100644
index 000..200c39a
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -0,0 +1,20 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap5.dtsi
+
+/ {
+   model = TI OMAP5 EVM board;
+   compatible = ti,omap5-evm, ti,omap5;
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x4000; /* 1 GB */
+   };
+};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
new file mode 100644
index 000..57e5270
--- /dev/null
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -0,0 +1,184 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on omap4.dtsi
+ */
+
+/*
+ * Carveout for multimedia usecases
+ * It should be the last 48MB of the first 512MB memory part
+ * In theory, it should not even exist. That zone should be reserved
+ * dynamically during the .reserve callback.
+ */
+/memreserve/ 0x9d00 0x0300;
+
+/include/ skeleton.dtsi
+
+/ {
+   compatible = ti,omap5;
+   interrupt-parent = gic;
+
+   aliases {
+   serial0 = uart1;
+   serial1 = uart2;
+   serial2 = uart3;
+   serial3 = uart4;
+   serial4 = uart5;
+   serial5 = uart6;
+   };
+
+   cpus {
+   cpu@0 {
+   compatible = arm,cortex-a15;
+   };
+   cpu@1 {
+   compatible = arm,cortex-a15;
+   };
+   };
+
+   /*
+* The soc node represents the soc top level view. It is uses for IPs
+* that are not memory mapped in the MPU view or for the MPU itself.
+*/
+   soc {
+   compatible = ti,omap-infra;
+   mpu {
+   compatible = ti,omap5-mpu;
+   ti,hwmods = mpu;
+   };
+   };
+
+   /*
+* XXX: Use a flat representation of the OMAP3 interconnect.
+* The real OMAP interconnect network is quite complex.
+* Since that will not bring real advantage to represent that in DT for
+* the moment, just use a fake OCP bus entry to represent the whole bus
+* hierarchy.
+*/
+   ocp {
+   compatible = ti,omap4-l3-noc, simple-bus;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+
+   gic: interrupt-controller@48211000 {
+   compatible = arm,cortex-a15-gic;
+   interrupt-controller;
+   #interrupt-cells = 3;
+   reg = 0x48211000 0x1000,
+ 0x48212000 0x1000;
+   };
+
+   gpio1: gpio@4ae1 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio1;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio2: gpio@48055000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio2;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio3: gpio@48057000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio3;
+   gpio-controller;
+   #gpio-cells = 2;
+   interrupt-controller;
+   #interrupt-cells = 1;
+   };
+
+   gpio4: gpio@48059000 {
+   compatible = ti,omap4-gpio;
+   ti,hwmods = gpio4;
+   gpio-controller;
+   

[PATCH v1 05/14] ARM: OMAP5: timer: Add clocksource, clockevent support

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the Initialisaton for clocksource and clockevent device
on OMAP5 Socs.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/common.h |1 +
 arch/arm/mach-omap2/timer.c  |5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 9f9a4aa..53c87ab 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -130,6 +130,7 @@ extern struct sys_timer omap3_timer;
 extern struct sys_timer omap3_secure_timer;
 extern struct sys_timer omap3_am33xx_timer;
 extern struct sys_timer omap4_timer;
+extern struct sys_timer omap5_timer;
 
 void omap2420_init_early(void);
 void omap2430_init_early(void);
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b5b5d92..280b8de 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -394,6 +394,11 @@ static void __init omap4_timer_init(void)
 OMAP_SYS_TIMER(4)
 #endif
 
+#ifdef CONFIG_SOC_OMAP5
+OMAP_SYS_TIMER_INIT(5, 1, OMAP4_CLKEV_SOURCE, 2, OMAP4_MPU_SOURCE)
+OMAP_SYS_TIMER(5)
+#endif
+
 /**
  * omap_timer_init - build and register timer device with an
  * associated timer hwmod
-- 
1.7.9.5

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

[PATCH v1 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.

OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.

Patch includes:
 - The machine specific headers and sources updates.
 - Platform header updates.
 - Minimum initialisation support for serial.
 - IO table init

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/Makefile   |   23 ++---
 arch/arm/mach-omap2/common.c   |   24 +
 arch/arm/mach-omap2/common.h   |   11 ++
 arch/arm/mach-omap2/include/mach/debug-macro.S |8 ++---
 arch/arm/mach-omap2/io.c   |   44 
 arch/arm/mach-omap2/iomap.h|   27 +++
 arch/arm/mach-omap2/omap_hwmod.c   |2 +-
 arch/arm/mach-omap2/prcm-common.h  |2 +-
 arch/arm/mach-omap2/prcm.c |2 +-
 arch/arm/plat-omap/Makefile|4 +--
 arch/arm/plat-omap/include/plat/clkdev_omap.h  |1 +
 arch/arm/plat-omap/include/plat/clock.h|1 +
 arch/arm/plat-omap/include/plat/hardware.h |1 +
 arch/arm/plat-omap/include/plat/multi.h|9 +
 arch/arm/plat-omap/include/plat/omap54xx.h |   32 +
 arch/arm/plat-omap/include/plat/serial.h   |   10 ++
 arch/arm/plat-omap/include/plat/uncompress.h   |6 
 arch/arm/plat-omap/sram.c  |   11 --
 18 files changed, 201 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/omap54xx.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 54ad3a4..bb6b364 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -16,6 +16,7 @@ secure-common = omap-smc.o 
omap-secure.o
 obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(hwmod-common)
 obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(hwmod-common) $(secure-common)
 obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common)
+obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common)
 
 ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),)
 obj-y += mcbsp.o
@@ -27,8 +28,10 @@ obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
 
 obj-$(CONFIG_SMP)  += omap-smp.o omap-headsmp.o
 obj-$(CONFIG_HOTPLUG_CPU)  += omap-hotplug.o
-obj-$(CONFIG_ARCH_OMAP4)   += omap4-common.o omap-wakeupgen.o
-obj-$(CONFIG_ARCH_OMAP4)   += sleep44xx.o
+omap-4-5-common=  omap4-common.o 
omap-wakeupgen.o \
+  sleep44xx.o
+obj-$(CONFIG_ARCH_OMAP4)   += $(omap-4-5-common)
+obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common)
 
 plus_sec := $(call as-instr,.arch_extension sec,+sec)
 AFLAGS_omap-headsmp.o  :=-Wa,-march=armv7-a$(plus_sec)
@@ -68,6 +71,7 @@ obj-$(CONFIG_ARCH_OMAP2)  += sleep24xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += cpuidle34xx.o
 obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o
+obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o
 obj-$(CONFIG_ARCH_OMAP4)   += cpuidle44xx.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
 obj-$(CONFIG_OMAP_SMARTREFLEX)  += sr_device.o smartreflex.o
@@ -83,14 +87,16 @@ endif
 endif
 
 # PRCM
+omap-prcm-4-5-common   =  prcm.o cminst44xx.o cm44xx.o \
+  prcm_mpu44xx.o prminst44xx.o \
+  vc44xx_data.o vp44xx_data.o
 obj-y  += prm_common.o
 obj-$(CONFIG_ARCH_OMAP2)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)   += prcm.o cm2xxx_3xxx.o prm2xxx_3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)   += vc3xxx_data.o vp3xxx_data.o
-obj-$(CONFIG_ARCH_OMAP4)   += prcm.o cminst44xx.o cm44xx.o
-obj-$(CONFIG_ARCH_OMAP4)   += prcm_mpu44xx.o prminst44xx.o
-obj-$(CONFIG_ARCH_OMAP4)   += vc44xx_data.o vp44xx_data.o prm44xx.o
 obj-$(CONFIG_SOC_AM33XX)   += prcm.o prm33xx.o cm33xx.o
+obj-$(CONFIG_ARCH_OMAP4)   += $(omap-prcm-4-5-common) prm44xx.o
+obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common)
 
 # OMAP voltage domains
 voltagedomain-common   := voltage.o vc.o vp.o
@@ -101,6 +107,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= 
voltagedomains3xxx_data.o
 obj-$(CONFIG_ARCH_OMAP4)   += $(voltagedomain-common)
 obj-$(CONFIG_ARCH_OMAP4)   += voltagedomains44xx_data.o
 

[PATCH v1 11/14] ARM: OMAP5: board-generic: Add device tree support.

[Santosh Shilimkar]

From: R Sricharan r.sricha...@ti.com

Adding the minimal support for OMAP5 evm board
with device tree.

Reviewed-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 .../devicetree/bindings/arm/omap/omap.txt  |3 +++
 arch/arm/mach-omap2/board-generic.c|   19 +++
 arch/arm/mach-omap2/omap4-common.c |1 +
 3 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index e78e8bc..3d450f6 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -47,3 +47,6 @@ Boards:
 
 - AM335X EVM : Software Developement Board for AM335x
   compatible = ti,am335x-evm, ti,am33xx, ti,omap3
+
+- OMAP5 EVM : Evaluation Module
+  compatible = ti,omap5-evm, ti,omap5
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 716e6b1..6f93a20 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,3 +138,22 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened 
Device Tree))
.restart= omap_prcm_restart,
 MACHINE_END
 #endif
+
+#ifdef CONFIG_SOC_OMAP5
+static const char *omap5_boards_compat[] __initdata = {
+   ti,omap5,
+   NULL,
+};
+
+DT_MACHINE_START(OMAP5_DT, Generic OMAP5 (Flattened Device Tree))
+   .reserve= omap_reserve,
+   .map_io = omap5_map_io,
+   .init_early = omap5_init_early,
+   .init_irq   = omap_gic_of_init,
+   .handle_irq = gic_handle_irq,
+   .init_machine   = omap_generic_init,
+   .timer  = omap5_timer,
+   .dt_compat  = omap5_boards_compat,
+   .restart= omap_prcm_restart,
+MACHINE_END
+#endif
diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index f38d659..c29dee9 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -214,6 +214,7 @@ early_initcall(omap4_sar_ram_init);
 
 static struct of_device_id irq_match[] __initdata = {
{ .compatible = arm,cortex-a9-gic, .data = gic_of_init, },
+   { .compatible = arm,cortex-a15-gic, .data = gic_of_init, },
{ }
 };
 
-- 
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

Re: [PATCH v1 00/14] ARM: OMAP5: Add minimal OMAP5 SOC support

[Shilimkar, Santosh]

On Thu, Jul 5, 2012 at 5:38 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
 Tony,

 The series adds minimal OMAP5 support. OMAP5430 has a dual core Cortex-A15
 based MPU subsystem with 2MB L2 cache. The SOC has many compatible blocks
 with OMAP4 SOCS and hence large part of the peripherals are re-used.

 OMAP5432 is another variant of OMAP5430, with a memory controller supporting
 DDR3 and SATA.

 Series is generated against cleanup-part2 branch at commit 74dd9ec6.

4 patches are repeated with [PATCH x/5] while posting. Just ignore them.

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: Help required on N900

[Grazvydas Ignotas]

On Thu, Jul 5, 2012 at 10:21 AM, Mohammed, Afzal af...@ti.com wrote:
 Hi,

 Can someone please provide me with a link to N900 board schematics.

 It would be really helpful if information on how to do Numonyx
 OneNAND reset on N900 (i.e. like how long reset signal should
 be asserted), and gpio pin number connected (if connected) to
 OneNAND reset pin can be provided.

I guess this should help:
http://maemo.jacekowski.org/docs/


-- 
Gražvydas
--
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 REPOST 4/4] ARM: OMAP2+: dmtimer: cleanup fclk usage

[Tarun Kanti DebBarma]

With omap_hwmod_get_main_clk() now available, this can be passed to
clk_get() to extract the fclk and thus avoid construction of fclk name.
Corrected the timer fck name mis-match between clock44xx_data.c and
omap_hwmod_44xx_data.c. For other platforms this is already taken care.

Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com

Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
Branch: cleanup-part2

Tested on ZOOM3, BLAZE, PANDA.

 arch/arm/mach-omap2/clock44xx_data.c |   22 +++---
 arch/arm/mach-omap2/timer.c  |3 +--
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index ba6f9a0..f9d4f58 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3299,17 +3299,17 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL,   smartreflex_core_fck, smartreflex_core_fck,  
CK_443X),
CLK(NULL,   smartreflex_iva_fck,  smartreflex_iva_fck,   
CK_443X),
CLK(NULL,   smartreflex_mpu_fck,  smartreflex_mpu_fck,   
CK_443X),
-   CLK(NULL,   gpt1_fck, timer1_fck,
CK_443X),
-   CLK(NULL,   gpt10_fck,timer10_fck,   
CK_443X),
-   CLK(NULL,   gpt11_fck,timer11_fck,   
CK_443X),
-   CLK(NULL,   gpt2_fck, timer2_fck,
CK_443X),
-   CLK(NULL,   gpt3_fck, timer3_fck,
CK_443X),
-   CLK(NULL,   gpt4_fck, timer4_fck,
CK_443X),
-   CLK(NULL,   gpt5_fck, timer5_fck,
CK_443X),
-   CLK(NULL,   gpt6_fck, timer6_fck,
CK_443X),
-   CLK(NULL,   gpt7_fck, timer7_fck,
CK_443X),
-   CLK(NULL,   gpt8_fck, timer8_fck,
CK_443X),
-   CLK(NULL,   gpt9_fck, timer9_fck,
CK_443X),
+   CLK(NULL,   timer1_fck,   timer1_fck,
CK_443X),
+   CLK(NULL,   timer10_fck,  timer10_fck,   
CK_443X),
+   CLK(NULL,   timer11_fck,  timer11_fck,   
CK_443X),
+   CLK(NULL,   timer2_fck,   timer2_fck,
CK_443X),
+   CLK(NULL,   timer3_fck,   timer3_fck,
CK_443X),
+   CLK(NULL,   timer4_fck,   timer4_fck,
CK_443X),
+   CLK(NULL,   timer5_fck,   timer5_fck,
CK_443X),
+   CLK(NULL,   timer6_fck,   timer6_fck,
CK_443X),
+   CLK(NULL,   timer7_fck,   timer7_fck,
CK_443X),
+   CLK(NULL,   timer8_fck,   timer8_fck,
CK_443X),
+   CLK(NULL,   timer9_fck,   timer9_fck,
CK_443X),
CLK(NULL,   uart1_fck,uart1_fck, 
CK_443X),
CLK(NULL,   uart2_fck,uart2_fck, 
CK_443X),
CLK(NULL,   uart3_fck,uart3_fck, 
CK_443X),
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 840929b..4c9ef35 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -173,8 +173,7 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
return -ENXIO;
 
/* After the dmtimer is using hwmod these clocks won't be needed */
-   sprintf(name, gpt%d_fck, gptimer_id);
-   timer-fclk = clk_get(NULL, name);
+   timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
if (IS_ERR(timer-fclk))
return -ENODEV;
 
-- 
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

RFC: Simplification of Power Domain Control

[Rajendra Nayak]

Hi,

This RFC is aimed at simplifying the powerdomain control
(in software) for OMAP. Powerdomains on OMAP have been
fairly complex to program (as compared to other SoCs)
mainly due to the multiple memory/logic control exposed
to software. These controls are limited to achieving
whats know as 'OSWR: Open Switch Retention' state in OMAP.
Rest of the states supported (ON, INACTIVE, CSWR, OFF) are
fairly easy to program needing just a target power state
to be configured.

While in theory, the hardware does expose multiple ways/
combinations in which OSWR can be achieved, we in software
have always been  using just *one* combination all along.
OSWR has always been configured as *logic lost, all memory
retained* for all current OMAPs supported.

With future OMAPs planning to get rid of all the memory/logic
control altogether it makes sense to look at the apis exposed 
through the current powerdomain framework to its users (like
cpuilde, suspend etc) and see if those could also be simplified.

The RFC is suspend tested on OMAP4430sdp and 
OMAP3630Beagle-Xm.

regards,
Rajendra


From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayak rna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits internally

Powerdomain framework exposes various apis for memory and logic
control for powerdomains, for its users to program OSWR: Open SWitch
Retention state. While in theory, there are various combinations of
memory and logic states possible which can be configured as OSWR,
in practice all OMAPs use just one combination. Logic lost, memory retained.

This can very easily be handled within the powerdomain framework itself,
without exposing all complex memory/logic control apis to upper layer
drivers like cpuidle and suspend.

To do this, introduce 2 new power domain states PWRDM_POWER_CSWR and
PWRDM_POWER_OSWR usable by the users of powerdomain framework and
make all memory/logic control apis internal to powerdomain framework.
Change all users of powerdomain framework to get rid of all usage
of memory/logic control apis and use the newly defined states for
CSWR and OSWR with the already used powerstate control apis.

Some functions (which are now made internal) are forward declared
to avoid moving functions around in the file (which can be done in a
later patch) to help keep the patch reviewable.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/mach-omap2/cpuidle44xx.c|9 +---
 arch/arm/mach-omap2/omap-mpuss-lowpower.c|7 +--
 arch/arm/mach-omap2/pm24xx.c |   17 +--
 arch/arm/mach-omap2/pm34xx.c |8 ++--
 arch/arm/mach-omap2/pm44xx.c |   11 +---
 arch/arm/mach-omap2/powerdomain-private.h|   17 +++
 arch/arm/mach-omap2/powerdomain.c|   54 +++---
 arch/arm/mach-omap2/powerdomain.h|   14 +-
 arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |1 +
 arch/arm/mach-omap2/powerdomains2xxx_data.c  |1 +
 arch/arm/mach-omap2/powerdomains3xxx_data.c  |1 +
 arch/arm/mach-omap2/powerdomains44xx_data.c  |1 +
 12 files changed, 85 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/mach-omap2/powerdomain-private.h

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..d40fe90 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -27,7 +27,6 @@
 /* Machine specific information */
 struct omap4_idle_statedata {
u32 cpu_state;
-   u32 mpu_logic_state;
u32 mpu_state;
 };
 
@@ -35,17 +34,14 @@ static struct omap4_idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
-   .mpu_logic_state = PWRDM_POWER_RET,
},
{
.cpu_state = PWRDM_POWER_OFF,
-   .mpu_state = PWRDM_POWER_RET,
-   .mpu_logic_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_POWER_CSWR,
},
{
.cpu_state = PWRDM_POWER_OFF,
-   .mpu_state = PWRDM_POWER_RET,
-   .mpu_logic_state = PWRDM_POWER_OFF,
+   .mpu_state = PWRDM_POWER_OSWR,
},
 };
 
@@ -95,7 +91,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (cx-cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
 
-   pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
 
/*
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13670aa..41d559b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -125,7 +125,7 @@ static void scu_pwrst_prepare(unsigned int cpu_id, unsigned 
int cpu_state)
u32 scu_pwr_st;
 

Re: RFC: Simplification of Power Domain Control

[Rajendra Nayak]

Just to give more context, the though of doing something like
what the below RFC does came up as part of the patch review of
Jean's Functional power state series. There was also some
offline discussion about this between me, Santosh Shilimkar and
Paul Walmsley.

On Thursday 05 July 2012 06:17 PM, Rajendra Nayak wrote:

Hi,

This RFC is aimed at simplifying the powerdomain control
(in software) for OMAP. Powerdomains on OMAP have been
fairly complex to program (as compared to other SoCs)
mainly due to the multiple memory/logic control exposed
to software. These controls are limited to achieving
whats know as 'OSWR: Open Switch Retention' state in OMAP.
Rest of the states supported (ON, INACTIVE, CSWR, OFF) are
fairly easy to program needing just a target power state
to be configured.

While in theory, the hardware does expose multiple ways/
combinations in which OSWR can be achieved, we in software
have always been  using just *one* combination all along.
OSWR has always been configured as *logic lost, all memory
retained* for all current OMAPs supported.

With future OMAPs planning to get rid of all the memory/logic
control altogether it makes sense to look at the apis exposed
through the current powerdomain framework to its users (like
cpuilde, suspend etc) and see if those could also be simplified.

The RFC is suspend tested on OMAP4430sdp and
OMAP3630Beagle-Xm.

regards,
Rajendra


 From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayakrna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits internally

Powerdomain framework exposes various apis for memory and logic
control for powerdomains, for its users to program OSWR: Open SWitch
Retention state. While in theory, there are various combinations of
memory and logic states possible which can be configured as OSWR,
in practice all OMAPs use just one combination. Logic lost, memory retained.

This can very easily be handled within the powerdomain framework itself,
without exposing all complex memory/logic control apis to upper layer
drivers like cpuidle and suspend.

To do this, introduce 2 new power domain states PWRDM_POWER_CSWR and
PWRDM_POWER_OSWR usable by the users of powerdomain framework and
make all memory/logic control apis internal to powerdomain framework.
Change all users of powerdomain framework to get rid of all usage
of memory/logic control apis and use the newly defined states for
CSWR and OSWR with the already used powerstate control apis.

Some functions (which are now made internal) are forward declared
to avoid moving functions around in the file (which can be done in a
later patch) to help keep the patch reviewable.

Signed-off-by: Rajendra Nayakrna...@ti.com
---
  arch/arm/mach-omap2/cpuidle44xx.c|9 +---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c|7 +--
  arch/arm/mach-omap2/pm24xx.c |   17 +--
  arch/arm/mach-omap2/pm34xx.c |8 ++--
  arch/arm/mach-omap2/pm44xx.c |   11 +---
  arch/arm/mach-omap2/powerdomain-private.h|   17 +++
  arch/arm/mach-omap2/powerdomain.c|   54 +++---
  arch/arm/mach-omap2/powerdomain.h|   14 +-
  arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |1 +
  arch/arm/mach-omap2/powerdomains2xxx_data.c  |1 +
  arch/arm/mach-omap2/powerdomains3xxx_data.c  |1 +
  arch/arm/mach-omap2/powerdomains44xx_data.c  |1 +
  12 files changed, 85 insertions(+), 56 deletions(-)
  create mode 100644 arch/arm/mach-omap2/powerdomain-private.h

diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index be1617c..d40fe90 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -27,7 +27,6 @@
  /* Machine specific information */
  struct omap4_idle_statedata {
u32 cpu_state;
-   u32 mpu_logic_state;
u32 mpu_state;
  };

@@ -35,17 +34,14 @@ static struct omap4_idle_statedata omap4_idle_data[] = {
{
.cpu_state = PWRDM_POWER_ON,
.mpu_state = PWRDM_POWER_ON,
-   .mpu_logic_state = PWRDM_POWER_RET,
},
{
.cpu_state = PWRDM_POWER_OFF,
-   .mpu_state = PWRDM_POWER_RET,
-   .mpu_logic_state = PWRDM_POWER_RET,
+   .mpu_state = PWRDM_POWER_CSWR,
},
{
.cpu_state = PWRDM_POWER_OFF,
-   .mpu_state = PWRDM_POWER_RET,
-   .mpu_logic_state = PWRDM_POWER_OFF,
+   .mpu_state = PWRDM_POWER_OSWR,
},
  };

@@ -95,7 +91,6 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (cx-cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();

-   pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
omap_set_pwrdm_state(mpu_pd, cx-mpu_state);

/*
diff --git 

RE: [PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot

[Bedia, Vaibhav]

Hello,

On Wed, Jul 04, 2012 at 21:24:01, Zumeng Chen wrote:
 Does the following fix make sense?
 
 WDIOC_GETBOOTSTATUS always return 0 even if the machine
 comes from omap-wdt reboot. Because WKUP_MOD is not right
 for OMAP3, so give the right addr 0xA00 of PRM_RSTST for
 get_reset_sources, which inputs the signal from omap-wdt
 reboot, and return 1 when coming from omap-wdt reboot for
 WDIOC_GETBOOTSTATUS.
 
 Signed-off-by: Zumeng Chen zumeng.c...@windriver.com
 ---
  arch/arm/mach-omap2/prcm.c  |4 +++-
  drivers/watchdog/omap_wdt.c |3 +++
  drivers/watchdog/omap_wdt.h |3 +++
  3 files changed, 9 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
 index 480f40a..43f3feb 100644
 --- a/arch/arm/mach-omap2/prcm.c
 +++ b/arch/arm/mach-omap2/prcm.c
 @@ -49,8 +49,10 @@ void __iomem *prcm_mpu_base;
  u32 omap_prcm_get_reset_sources(void)
  {
   /* XXX This presumably needs modification for 34XX */
 - if (cpu_is_omap24xx() || cpu_is_omap34xx())
 + if (cpu_is_omap24xx())
   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)  0x7f;
 + if (cpu_is_omap34xx())
 + return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST)  0x7f;
   if (cpu_is_omap44xx())
   return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)  0x7f;

Instead of adding more cpu_is_* checks maybe you could switch to a
function pointers based approach here?

  
 diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
 index 8285d65..ea57078 100644
 --- a/drivers/watchdog/omap_wdt.c
 +++ b/drivers/watchdog/omap_wdt.c
 @@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file, unsigned 
 int cmd,
   if (cpu_is_omap24xx())
   return put_user(omap_prcm_get_reset_sources(),
   (int __user *)arg);
 + if (cpu_is_omap34xx())
 + return put_user(omap_prcm_get_reset_sources()  0x10 
 + OMAP3_PRM_RSTST_BIT, (int __user *)arg);
   return put_user(0, (int __user *)arg);

Usage of PRCM bit masks in the driver looks wrong. Why not
introduce an API like omap_prcm_check_reset_reason() which
returns true or false based on the reset reason being checked?

In case of WDT, the driver can then pass the right flag to
userspace.

Regards,
Vaibhav B.

   case WDIOC_KEEPALIVE:
   pm_runtime_get_sync(wdev-dev);
 diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
 index 09b774c..d8d5daa 100644
 --- a/drivers/watchdog/omap_wdt.h
 +++ b/drivers/watchdog/omap_wdt.h
 @@ -40,6 +40,9 @@
  #define OMAP_WATCHDOG_WPS(0x34)
  #define OMAP_WATCHDOG_SPR(0x48)
  
 +/* PRM_RSTST MPU_WD_RST bit */
 +#define OMAP3_PRM_RSTST_BIT  4
 +
  /* Using the prescaler, the OMAP watchdog could go for many
   * months before firing.  These limits work without scaling,
   * with the 60 second default assumed by most tools and docs.
 -- 
 1.7.5.4
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 

--
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: Simplification of Power Domain Control

[Jean Pihet]

On Thu, Jul 5, 2012 at 3:03 PM, Rajendra Nayak rna...@ti.com wrote:
 Just to give more context, the though of doing something like
 what the below RFC does came up as part of the patch review of
 Jean's Functional power state series.
My reply crossed yours...

 There was also some
 offline discussion about this between me, Santosh Shilimkar and
 Paul Walmsley.
Good to know!
And... ?

Jean.



 On Thursday 05 July 2012 06:17 PM, Rajendra Nayak wrote:

 Hi,

 This RFC is aimed at simplifying the powerdomain control
 (in software) for OMAP. Powerdomains on OMAP have been
 fairly complex to program (as compared to other SoCs)
 mainly due to the multiple memory/logic control exposed
 to software. These controls are limited to achieving
 whats know as 'OSWR: Open Switch Retention' state in OMAP.
 Rest of the states supported (ON, INACTIVE, CSWR, OFF) are
 fairly easy to program needing just a target power state
 to be configured.

 While in theory, the hardware does expose multiple ways/
 combinations in which OSWR can be achieved, we in software
 have always been  using just *one* combination all along.
 OSWR has always been configured as *logic lost, all memory
 retained* for all current OMAPs supported.

 With future OMAPs planning to get rid of all the memory/logic
 control altogether it makes sense to look at the apis exposed
 through the current powerdomain framework to its users (like
 cpuilde, suspend etc) and see if those could also be simplified.

 The RFC is suspend tested on OMAP4430sdp and
 OMAP3630Beagle-Xm.

 regards,
 Rajendra

 
  From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
 From: Rajendra Nayakrna...@ti.com
 Date: Thu, 5 Jul 2012 17:33:28 +0530
 Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits
 internally

 Powerdomain framework exposes various apis for memory and logic
 control for powerdomains, for its users to program OSWR: Open SWitch
 Retention state. While in theory, there are various combinations of
 memory and logic states possible which can be configured as OSWR,
 in practice all OMAPs use just one combination. Logic lost, memory
 retained.

 This can very easily be handled within the powerdomain framework itself,
 without exposing all complex memory/logic control apis to upper layer
 drivers like cpuidle and suspend.

 To do this, introduce 2 new power domain states PWRDM_POWER_CSWR and
 PWRDM_POWER_OSWR usable by the users of powerdomain framework and
 make all memory/logic control apis internal to powerdomain framework.
 Change all users of powerdomain framework to get rid of all usage
 of memory/logic control apis and use the newly defined states for
 CSWR and OSWR with the already used powerstate control apis.

 Some functions (which are now made internal) are forward declared
 to avoid moving functions around in the file (which can be done in a
 later patch) to help keep the patch reviewable.

 Signed-off-by: Rajendra Nayakrna...@ti.com
 ---
   arch/arm/mach-omap2/cpuidle44xx.c|9 +---
   arch/arm/mach-omap2/omap-mpuss-lowpower.c|7 +--
   arch/arm/mach-omap2/pm24xx.c |   17 +--
   arch/arm/mach-omap2/pm34xx.c |8 ++--
   arch/arm/mach-omap2/pm44xx.c |   11 +---
   arch/arm/mach-omap2/powerdomain-private.h|   17 +++
   arch/arm/mach-omap2/powerdomain.c|   54
 +++---
   arch/arm/mach-omap2/powerdomain.h|   14 +-
   arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |1 +
   arch/arm/mach-omap2/powerdomains2xxx_data.c  |1 +
   arch/arm/mach-omap2/powerdomains3xxx_data.c  |1 +
   arch/arm/mach-omap2/powerdomains44xx_data.c  |1 +
   12 files changed, 85 insertions(+), 56 deletions(-)
   create mode 100644 arch/arm/mach-omap2/powerdomain-private.h

 diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
 b/arch/arm/mach-omap2/cpuidle44xx.c
 index be1617c..d40fe90 100644
 --- a/arch/arm/mach-omap2/cpuidle44xx.c
 +++ b/arch/arm/mach-omap2/cpuidle44xx.c
 @@ -27,7 +27,6 @@
   /* Machine specific information */
   struct omap4_idle_statedata {
 u32 cpu_state;
 -   u32 mpu_logic_state;
 u32 mpu_state;
   };

 @@ -35,17 +34,14 @@ static struct omap4_idle_statedata omap4_idle_data[] =
 {
 {
 .cpu_state = PWRDM_POWER_ON,
 .mpu_state = PWRDM_POWER_ON,
 -   .mpu_logic_state = PWRDM_POWER_RET,
 },
 {
 .cpu_state = PWRDM_POWER_OFF,
 -   .mpu_state = PWRDM_POWER_RET,
 -   .mpu_logic_state = PWRDM_POWER_RET,
 +   .mpu_state = PWRDM_POWER_CSWR,
 },
 {
 .cpu_state = PWRDM_POWER_OFF,
 -   .mpu_state = PWRDM_POWER_RET,
 -   .mpu_logic_state = PWRDM_POWER_OFF,
 +   .mpu_state = PWRDM_POWER_OSWR,
 },
   };

 @@ -95,7 +91,6 @@ static int omap4_enter_idle(struct 

Re: RFC: Simplification of Power Domain Control

[Rajendra Nayak]

Hi Jean,

On Thursday 05 July 2012 06:36 PM, Jean Pihet wrote:

Hi Rajendra,

On Thu, Jul 5, 2012 at 2:47 PM, Rajendra Nayakrna...@ti.com  wrote:

Hi,

This RFC is aimed at simplifying the powerdomain control
(in software) for OMAP. Powerdomains on OMAP have been
fairly complex to program (as compared to other SoCs)
mainly due to the multiple memory/logic control exposed
to software. These controls are limited to achieving
whats know as 'OSWR: Open Switch Retention' state in OMAP.
Rest of the states supported (ON, INACTIVE, CSWR, OFF) are
fairly easy to program needing just a target power state
to be configured.

While in theory, the hardware does expose multiple ways/
combinations in which OSWR can be achieved, we in software
have always been  using just *one* combination all along.
OSWR has always been configured as *logic lost, all memory
retained* for all current OMAPs supported.

With future OMAPs planning to get rid of all the memory/logic
control altogether it makes sense to look at the apis exposed
through the current powerdomain framework to its users (like
cpuilde, suspend etc) and see if those could also be simplified.

The RFC is suspend tested on OMAP4430sdp and
OMAP3630Beagle-Xm.

This looks very similar to the functional power states patches that I
submitted a few times for review [1].


Sorry, I should have mentioned the context in which this RFC was
developed. Yes, its very similar to the functional power state
approach, infact some of these thoughts came up as part of the
discussion between me and Santosh while doing the review for
that very series.

regards,
Rajendra


The idea is to simplify the external API to program the power domains
states. The code has been used to implement the OMAP4 device OFF
support (from Tero) and the per-device PM QoS implementation for OMAP
[2].

[1] http://marc.info/?l=linux-omapm=133968580905048w=2
[2] http://marc.info/?l=linux-omapm=133968657005566w=2

Now that we have more than one implementation, I let it to the
maintainers for decision.

Paul, what do you think?

A few remarks here below.

Thanks for your RFC!



regards,
Rajendra


 From 5f5e4eb342110286bf719c7d9d7c1959f53e34f9 Mon Sep 17 00:00:00 2001
From: Rajendra Nayakrna...@ti.com
Date: Thu, 5 Jul 2012 17:33:28 +0530
Subject: [RFC] ARM: OMAP: Powerdomain: control memory and logic bits internally

Powerdomain framework exposes various apis for memory and logic
control for powerdomains, for its users to program OSWR: Open SWitch
Retention state. While in theory, there are various combinations of
memory and logic states possible which can be configured as OSWR,
in practice all OMAPs use just one combination. Logic lost, memory retained.

This can very easily be handled within the powerdomain framework itself,
without exposing all complex memory/logic control apis to upper layer
drivers like cpuidle and suspend.

To do this, introduce 2 new power domain states PWRDM_POWER_CSWR and
PWRDM_POWER_OSWR usable by the users of powerdomain framework and
make all memory/logic control apis internal to powerdomain framework.
Change all users of powerdomain framework to get rid of all usage
of memory/logic control apis and use the newly defined states for
CSWR and OSWR with the already used powerstate control apis.

Some functions (which are now made internal) are forward declared
to avoid moving functions around in the file (which can be done in a
later patch) to help keep the patch reviewable.

Signed-off-by: Rajendra Nayakrna...@ti.com
---
  arch/arm/mach-omap2/cpuidle44xx.c|9 +---
  arch/arm/mach-omap2/omap-mpuss-lowpower.c|7 +--
  arch/arm/mach-omap2/pm24xx.c |   17 +--
  arch/arm/mach-omap2/pm34xx.c |8 ++--
  arch/arm/mach-omap2/pm44xx.c |   11 +---
  arch/arm/mach-omap2/powerdomain-private.h|   17 +++
  arch/arm/mach-omap2/powerdomain.c|   54 +++---
  arch/arm/mach-omap2/powerdomain.h|   14 +-
  arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c |1 +
  arch/arm/mach-omap2/powerdomains2xxx_data.c  |1 +
  arch/arm/mach-omap2/powerdomains3xxx_data.c  |1 +
  arch/arm/mach-omap2/powerdomains44xx_data.c  |1 +
  12 files changed, 85 insertions(+), 56 deletions(-)
  create mode 100644 arch/arm/mach-omap2/powerdomain-private.h


...


diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c 
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13670aa..41d559b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c

...

@@ -243,7 +243,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int 
power_state)
 case PWRDM_POWER_OFF:
 save_state = 1;
 break;
-   case PWRDM_POWER_RET:
+   case PWRDM_POWER_CSWR:
 default:
 /*
  * CPUx CSWR is invalid hardware state. Also CPUx OSWR
@@ -262,8 +262,7 

Re: RFC: Simplification of Power Domain Control

[Rajendra Nayak]

On Thursday 05 July 2012 06:38 PM, Jean Pihet wrote:

There was also some
  offline discussion about this between me, Santosh Shilimkar and
  Paul Walmsley.

Good to know!
And... ?


oh, the discussion was just about the approach and there was nothing
concluded. So I just cooked up this RFC so there can be some more
discussion.
--
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

PM/UART 3.5-rc5: UART Rx wakeups not quite right?

[Joe Woodward]

Are there any patches floating around to fix UART Rx wakeups for 3.5?

I have a GUMSTIX Overo with various things hanging off the UARTs, one
of which (on ttyO0) sends in periodic (GPS) data.

I don't want this data to wake the OMAP from system suspend.

I would normally disable UART Rx wakeup for ttyO0:
# echo disabled  /sys/devices/platform/omap_uart.0/power/wakeup

This works on 3.5-rc5 (i.e. I can suspend, and not immediately wake) UNTIL
I run an application that opens /dev/ttyO0.

At this point when entering system suspend ttyO0 wakes the OMAP up
immediately, even though the SYSFS reports the wakeup as disabled.

Any ideas?

Cheers,
Joe


--
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: [RESEND/PATCHv5 1/2] drivers: input: keypad: Add device tree support

[Poddar, Sourav]

Hi Dmitry,
On Tue, Jun 19, 2012 at 7:55 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
 +cc linux-omap

 On Fri, Jun 8, 2012 at 4:22 PM, Sourav Poddar sourav.pod...@ti.com wrote:
 Update the Documentation with omap4 keypad device tree
 binding information.
 Add device tree support for omap4 keypad driver.

 Tested on omap4430 sdp.

 Cc: Andrew Morton a...@linux-foundation.org
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Rob Herring rob.herr...@calxeda.com
 Cc: Grant Likely grant.lik...@secretlab.ca
 Cc: Felipe Balbi ba...@ti.com
 Cc: Dmitry Torokhov d...@mail.ru
 Cc: Randy Dunlap rdun...@xenotime.net
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 changes since v4:
 - Developed it on top of dmitry's 'next' branch due to
 dependency on generic matrix_keypad_build_keymap api
 patches queued in that branch
 - Adapted the driver to fill keymap in device tree
 using matrix_keypad_build_keymap api defined in
 drivers/input/matrix-keymap.c
  .../devicetree/bindings/input/omap-keypad.txt  |   31 ++
  drivers/input/keyboard/omap4-keypad.c  |  108 
 +++-
  2 files changed, 111 insertions(+), 28 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/input/omap-keypad.txt

 diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt 
 b/Documentation/devicetree/bindings/input/omap-keypad.txt
 new file mode 100644
 index 000..722425b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/omap-keypad.txt
 @@ -0,0 +1,31 @@
 +* TI's Keypad Controller device tree bindings
 +
 +TI's Keypad controller is used to interface a SoC with a matrix-type
 +keypad device. The keypad controller supports multiple row and column lines.
 +A key can be placed at each intersection of a unique row and a unique 
 column.
 +The keypad controller can sense a key-press and key-release and report the
 +event using a interrupt to the cpu.
 +
 +Required SoC Specific Properties:
 +- compatible: should be one of the following
 +   - ti,omap4-keypad: For controllers compatible with omap4 keypad
 +  controller.
 +
 +Required Board Specific Properties, in addition to those specified by
 +the shared matrix-keyboard bindings:
 +- keypad,num-rows: Number of row lines connected to the keypad
 +  controller.
 +
 +- keypad,num-columns: Number of column lines connected to the
 +  keypad controller.
 +
 +Optional Properties specific to linux:
 +- linux,keypad-no-autorepeat: do no enable autorepeat feature.
 +
 +Example:
 +keypad@4ae1c000{
 +compatible = ti,omap4-keypad;
 +keypad,num-rows = 2;
 +keypad,num-columns = 8;
 +   linux,keypad-no-autorepeat;
 +   };
 diff --git a/drivers/input/keyboard/omap4-keypad.c 
 b/drivers/input/keyboard/omap4-keypad.c
 index aed5f69..d5a2d1a 100644
 --- a/drivers/input/keyboard/omap4-keypad.c
 +++ b/drivers/input/keyboard/omap4-keypad.c
 @@ -27,6 +27,7 @@
  #include linux/platform_device.h
  #include linux/errno.h
  #include linux/io.h
 +#include linux/of.h
  #include linux/input.h
  #include linux/slab.h
  #include linux/pm_runtime.h
 @@ -75,6 +76,7 @@ enum {

  struct omap4_keypad {
struct input_dev *input;
 +   struct matrix_keymap_data *keymap_data;

void __iomem *base;
unsigned int irq;
 @@ -84,6 +86,7 @@ struct omap4_keypad {
u32 reg_offset;
u32 irqreg_offset;
unsigned int row_shift;
 +   bool no_autorepeat;
unsigned char key_state[8];
unsigned short keymap[];
  };
 @@ -208,25 +211,74 @@ static void omap4_keypad_close(struct input_dev *input)
pm_runtime_put_sync(input-dev.parent);
  }

 +static struct omap4_keypad *omap_keypad_parse_dt(struct device *dev,
 +   uint32_t rows, uint32_t cols,
 +   struct input_dev *input_dev)
 +{
 +   struct device_node *np = dev-of_node;
 +   struct platform_device *pdev = to_platform_device(dev);
 +   struct omap4_keypad *keypad_data = platform_get_drvdata(pdev);
 +   int error;
 +
 +   error = matrix_keypad_build_keymap(NULL, linux,keymap,
 +   rows, cols, keypad_data-keymap, input_dev);
 +   if (error) {
 +   dev_err(pdev-dev, failed to build keymap\n);
 +   input_free_device(input_dev);
 +   }
 +
 +   if (of_get_property(np, linux,input-no-autorepeat, NULL))
 +   keypad_data-no_autorepeat = true;
 +
 +   return keypad_data;
 +}
 +
  static int __devinit omap4_keypad_probe(struct platform_device *pdev)
  {
 +   struct device *dev = pdev-dev;
 +   struct device_node *np = dev-of_node;
const struct omap4_keypad_platform_data *pdata;
struct omap4_keypad *keypad_data;
struct input_dev *input_dev;
struct resource *res;
resource_size_t size;
 -   unsigned int row_shift, max_keys;
 +   unsigned int row_shift = 0, max_keys = 0;
 +   uint32_t num_rows = 0, 

Re: [PATCH v1 03/14] ARM: OMAP5: id: Add cpu id for ES versions

[Tony Lindgren]

Hi,

* Santosh Shilimkar santosh.shilim...@ti.com [120705 05:13]:
 From: R Sricharan r.sricha...@ti.com
 
 Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
 detection support.
 
 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -50,6 +50,11 @@ int omap_type(void)
   val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
   } else if (cpu_is_omap44xx()) {
   val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
 + } else if (cpu_is_omap54xx()) {
 + val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
 + val = OMAP5_DEVICETYPE_MASK;
 + val = 6;
 + goto out;
   } else {
   pr_err(Cannot detect omap type!\n);
   goto out;
 @@ -100,7 +105,7 @@ static u16 tap_prod_id;
  
  void omap_get_die_id(struct omap_die_id *odi)
  {
 - if (cpu_is_omap44xx()) {
 + if (cpu_is_omap44xx() || cpu_is_omap54xx()) {

Please update all these patches to use soc_is_omap54xx()
instead of cpu_is_omap54xx() as that's where we are heading.

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 v1 03/14] ARM: OMAP5: id: Add cpu id for ES versions

[Shilimkar, Santosh]

On Thu, Jul 5, 2012 at 7:56 PM, Tony Lindgren t...@atomide.com wrote:
 Hi,

 * Santosh Shilimkar santosh.shilim...@ti.com [120705 05:13]:
 From: R Sricharan r.sricha...@ti.com

 Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
 detection support.

 --- a/arch/arm/mach-omap2/id.c
 +++ b/arch/arm/mach-omap2/id.c
 @@ -50,6 +50,11 @@ int omap_type(void)
   val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
   } else if (cpu_is_omap44xx()) {
   val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
 + } else if (cpu_is_omap54xx()) {
 + val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
 + val = OMAP5_DEVICETYPE_MASK;
 + val = 6;
 + goto out;
   } else {
   pr_err(Cannot detect omap type!\n);
   goto out;
 @@ -100,7 +105,7 @@ static u16 tap_prod_id;

  void omap_get_die_id(struct omap_die_id *odi)
  {
 - if (cpu_is_omap44xx()) {
 + if (cpu_is_omap44xx() || cpu_is_omap54xx()) {

 Please update all these patches to use soc_is_omap54xx()
 instead of cpu_is_omap54xx() as that's where we are heading.

Damn. We missed to update this. Will fix this and update the
branch. Thanks for pointing it out.

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 v1 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

[Tony Lindgren]

* Santosh Shilimkar santosh.shilim...@ti.com [120705 05:13]:
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -10,9 +10,7 @@ obj-n :=
  obj-  :=
  
  # omap_device support (OMAP2+ only at the moment)
 -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
 -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
 -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
 +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o
  
  obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
  obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o

FYI, this we already have as commit b4cb410d in devel-am33xx-part2.
I can merge first few patches in devel-am33xx-part2 branch into
cleanup-part2 so this part can be just left out.

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 v1 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

[Shilimkar, Santosh]

On Thu, Jul 5, 2012 at 8:03 PM, Tony Lindgren t...@atomide.com wrote:
 * Santosh Shilimkar santosh.shilim...@ti.com [120705 05:13]:
 --- a/arch/arm/plat-omap/Makefile
 +++ b/arch/arm/plat-omap/Makefile
 @@ -10,9 +10,7 @@ obj-n :=
  obj-  :=

  # omap_device support (OMAP2+ only at the moment)
 -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
 -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
 -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
 +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o

  obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
  obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o

 FYI, this we already have as commit b4cb410d in devel-am33xx-part2.
 I can merge first few patches in devel-am33xx-part2 branch into
 cleanup-part2 so this part can be just left out.

Ok. Once you update the branch this can be easily dropped.

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 v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Tony Lindgren]

* Mohammed, Afzal af...@ti.com [120705 05:03]:
 Hi Tony,
 
 On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
  * Mohammed, Afzal af...@ti.com [120705 03:29]:
 
   Initially I thought you were suggesting that all peripheral drivers
   connected to gpmc should register their retime function (where
 
  Yes that's what I was suggesting.
 
 To understand you better, peripheral drivers above refers to
 driver created out of present gpmc platform init code like
 gpmc-smsc911x.c. You were not referring to
 drivers/net/ethernet/smsc/smsc911x.c, right ?

Yes arch/arm/mach-omap2/gpmc-smsc911x.c for now, but eventually
that too should probably be just a regular driver. Just how it
will work together with drivers/net/ethernet/smsc/smsc911x.c is
still a bit open though :)

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 v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration

[Mohammed, Afzal]

Hi Tony,

On Thu, Jul 05, 2012 at 16:25:35, Tony Lindgren wrote:
 * Mohammed, Afzal af...@ti.com [120705 03:29]:

  I have a doubt whether we are talking about the same thing, presently
  our main issue is in eliminating the necessity of peripheral specific
  functions like gpmc_onenand_init, tusb_setup_interface (which calls
  tusb6010_platform_retime), etc., which calculate gpmc timings by
  processing peripheral specific timings over gpmc clock period and
  these processing were required before gpmc driver probe gets invoked
  as gpmc driver needed timings which gpmc can understand to configure
  gpmc.
 
 Right. The issue is that both the gpmc clock and the peripheral clock
 may change, and both cause the need to reprogram the gpmc timings.

Presently bigger issue that I am facing w.r.t driver conversion is the
requirement of peripheral specific gpmc timing calculation before probe.
I believe currently in mainline runtime gpmc clock changes are not
handled

  By we should be able to do it at gpmc level, I am unable to
  understand what you are suggesting.
 
 Right, gpmc should be able to handle things alone with the registered
 retime function for smsc911x, where the driver does not even know about
 the bus. With DT, the platform init code gpmc-smsc911x.c should become
 a driver that registers with gpmc and provides the retime function.

So then we would be having two devices  drivers to represent gpmc
peripheral like smsc911x, one existing ethernet driver and other one
for handling gpmc timings, right ?. And with DT, so we need two nodes
to represent a gpmc peripheral ?

  So timing information that would be passed from DT should be for
  exact gpmc timings like cs_on, cs_off etc., right ?, in that case
  should we manually calculate (like as now done by Kernel in
  gpmc-onenand.c etc) it by having the knowledge of connected
  peripheral  gpmc frequency at boot time and update it in DT ?, as
  we can't apply retime on it as we don't know the connected
  peripheral in gpmc driver. Or do you want another field through DT
  to decide retime that is to be used, then I think passing timing
  from DT would not be needed
 
 The timings values should be passed to gpmc from DT. We need to
 be able to pass both cycle and time based values. If no cycle based
 value is passed, the time based value should be used. This is because
 some peripheral timings can be cycle based, while others can be time
 based.

If we can describe gpmc timings purely based on time and cycles field
for all the peripherals, can we not remove all the retime functions like
timing calculation done in gpmc-onenand.c ?
 
 The peripheral driver can register it's retime function with gpmc and
 get a cookie back that allows getting the DT provided timings from gpmc.
 And after that the initial timings can be set.

If timings peripheral timings can be fully contained in driver, should
we try to pass the same timings translated in terms of gpmc timings
through DT ?, and how do we get equivalent gpmc timings to update DT,
manually calculate similar to platform init code ?, or I misunderstood
you

Sorry to trouble you with more questions, I wanted to understand the way
you want to deal with the issue.

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

Re: [PATCH 1/1] Watchdog: OMAP3: fix wrong boot status from wdt reboot

[zumeng.chen]

On 2012年07月05日 21:05, Bedia, Vaibhav wrote:

Hello,

On Wed, Jul 04, 2012 at 21:24:01, Zumeng Chen wrote:

Does the following fix make sense?

WDIOC_GETBOOTSTATUS always return 0 even if the machine
comes from omap-wdt reboot. Because WKUP_MOD is not right
for OMAP3, so give the right addr 0xA00 of PRM_RSTST for
get_reset_sources, which inputs the signal from omap-wdt
reboot, and return 1 when coming from omap-wdt reboot for
WDIOC_GETBOOTSTATUS.

Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
---
  arch/arm/mach-omap2/prcm.c  |4 +++-
  drivers/watchdog/omap_wdt.c |3 +++
  drivers/watchdog/omap_wdt.h |3 +++
  3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index 480f40a..43f3feb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -49,8 +49,10 @@ void __iomem *prcm_mpu_base;
  u32 omap_prcm_get_reset_sources(void)
  {
/* XXX This presumably needs modification for 34XX */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
+   if (cpu_is_omap24xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP2_RM_RSTST)  0x7f;
+   if (cpu_is_omap34xx())
+   return omap2_prm_read_mod_reg(0xA00, OMAP2_RM_RSTST)  0x7f;
if (cpu_is_omap44xx())
return omap2_prm_read_mod_reg(WKUP_MOD, OMAP4_RM_RSTST)  0x7f;

Instead of adding more cpu_is_* checks maybe you could switch to a
function pointers based approach here?
I don't see any more checks VS before like ( cpu_is_omap24xx() || 
cpu_is_omap34xx())


Actually what we want is just to read a register with different offset
responding to the different SOC.


diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 8285d65..ea57078 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -234,6 +234,9 @@ static long omap_wdt_ioctl(struct file *file, unsigned int 
cmd,
if (cpu_is_omap24xx())
return put_user(omap_prcm_get_reset_sources(),
(int __user *)arg);
+   if (cpu_is_omap34xx())
+   return put_user(omap_prcm_get_reset_sources()  0x10
+   OMAP3_PRM_RSTST_BIT, (int __user *)arg);
return put_user(0, (int __user *)arg);

Usage of PRCM bit masks in the driver looks wrong. Why not

Maybe the not proper definition causes looks wrong.
It should be MPU_WD_RST_BIT, so you see, it is about
watchdog bit.

Anyway, I'll try to send V2 patch with Hubhrajyoti's and your
comments

Regards,
Zumeng

introduce an API like omap_prcm_check_reset_reason() which
returns true or false based on the reset reason being checked?

In case of WDT, the driver can then pass the right flag to
userspace.

Regards,
Vaibhav B.


case WDIOC_KEEPALIVE:
pm_runtime_get_sync(wdev-dev);
diff --git a/drivers/watchdog/omap_wdt.h b/drivers/watchdog/omap_wdt.h
index 09b774c..d8d5daa 100644
--- a/drivers/watchdog/omap_wdt.h
+++ b/drivers/watchdog/omap_wdt.h
@@ -40,6 +40,9 @@
  #define OMAP_WATCHDOG_WPS (0x34)
  #define OMAP_WATCHDOG_SPR (0x48)

+/* PRM_RSTST MPU_WD_RST bit */
+#define OMAP3_PRM_RSTST_BIT4
+
  /* Using the prescaler, the OMAP watchdog could go for many
   * months before firing.  These limits work without scaling,
   * with the 60 second default assumed by most tools and docs.
--
1.7.5.4


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



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

PM/RTC 3.5-rc5: System suspends fails when not built with RTC?

[Joe Woodward]

I've got 3.5-rc5 with the following patches applied to get system suspend 
working on OMAP3:
  - fix the DSS: OMAPDSS: Use PM notifiers for system suspend
  - fix the 32KHz clock: ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync 
timer

This has been built with the omap2plus_defconfig.

However, If I disable the RTC (i.e. CONFIG_RTC_CLASS/CONFIG_RTC_DRV_TWL4030) 
and rebuild then when suspending the device never wakes up.

That is, I can't get any wakeups to happen (either through the console, or GPIO 
buttons) hence I'm assuming the kernel has crashed...

Any ideas?

As far as I know there is no dependency on the RTC in 3.4, and with the RTC 
compiled in I never see a problem on 3.5-rc5.

Cheers,
Joe


--
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: [RESEND PATCH] ARM: OMAP2+: am33xx: Make am33xx as a separate class

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [120704 01:20]:
 * Tony Lindgren t...@atomide.com [120704 00:29]:
  * Vaibhav Hiremath hvaib...@ti.com [120703 06:12]:
   Initially, we decided to make am33xx family of device to fall
   under omap3 class (cpu_is_omap34xx() = true), since it carries
   Cortex-A8 core. But while adding complete baseport support
   (like, clock, power and hwmod) support, it is observed that,
   we are creating more and more problems by treating am33xx device
   as omap3 family, as nothing matches between them
   (except cortex-A8 mpu).
   
   So,  after long discussion we have came to the conclusion that,
   we should not consider am33xx device as omap3 family, instead
   create separate class (SOC_AM33XX) under OMAP2PLUS.
   This means, for am33xx device, cpu_is_omap34xx() will return false,
   and only cpu_is_am33xx() will be true.
  
  Thanks applying both.
 
 I believe all your patches are now applied. I've pushed them out
 into devel-am33xx-part2 branch. Can you please check and send
 additional patches as needed?

I ended up moving some patches into cleanup-part2 branch as omap5
patches also need those. So the new branch for am33xx is called
devel-am33xx-data at commit 79ab2664. The old devel-am33xx-part2
branch should be ignored now.

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 v1 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [120705 07:41]:
 On Thu, Jul 5, 2012 at 8:03 PM, Tony Lindgren t...@atomide.com wrote:
  * Santosh Shilimkar santosh.shilim...@ti.com [120705 05:13]:
  --- a/arch/arm/plat-omap/Makefile
  +++ b/arch/arm/plat-omap/Makefile
  @@ -10,9 +10,7 @@ obj-n :=
   obj-  :=
 
   # omap_device support (OMAP2+ only at the moment)
  -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o
  -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o
  -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o
  +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o
 
   obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o
   obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o
 
  FYI, this we already have as commit b4cb410d in devel-am33xx-part2.
  I can merge first few patches in devel-am33xx-part2 branch into
  cleanup-part2 so this part can be just left out.
 
 Ok. Once you update the branch this can be easily dropped.

Updated cleanup-part2 at commit ecc46cfd now has it.

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 V2 07/10] ARM: OMAP4: CLKDM: Update supported transition modes

[Jon Hunter]

Hi Paul,

On 07/04/2012 10:38 AM, Paul Walmsley wrote:
 On Thu, 7 Jun 2012, Jon Hunter wrote:
 
 For OMAP3+ devices, the clock domains (CLKDMs) support one or more of the
 following transition modes ...
 
 Thanks, queued.

Thanks. Any comments on patch 8/10 of this series?

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 RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function

[Ruslan Bilovol]

Hi,

On Tue, Jul 3, 2012 at 7:13 PM, Felipe Balbi ba...@ti.com wrote:

 Hi,

 On Mon, Jul 02, 2012 at 08:10:49PM +0300, Ruslan Bilovol wrote:
  Hi,
 
 
  On Mon, Jul 2, 2012 at 11:13 AM, Felipe Balbi ba...@ti.com wrote:
  
   Hi,
  
   On Tue, Jun 12, 2012 at 08:36:21PM +0300, Ruslan Bilovol wrote:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
   
Fix this - so now if we try to enable already enabled clocks
it works correctly.
   
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
 arch/arm/mach-omap2/omap_phy_internal.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
   
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0196683 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,7 +97,7 @@ int omap4430_phy_set_clk(struct device *dev, int
on)
  clk_enable(clk48m);
  clk_enable(clk32k);
  state = 1;
- } else if (state) {
+ } else if (!on  state) {
  
   why don't you let clocks be enabled twice then ? That would cut down
   the
   churn.
 
  Currently we have unbalanced call of this function.
  I meet first during musb initialization - it tries to disable the phy
  that leads to disabling already disabled clocks.
  Next goal is to use internal clocks counter and to throw static
  variable 'state'.

 don't even go that way... what you need is to fix the unbalanced calls
 instead of hacking around some generic API.

Okay Felipe, I understand your position and agree with you. However,
right now the 'hack' that I'm fixing works incorrectly.
So while we do not have replacement of the 'hack', it will be good to
have at least fixed version of this 'hack'.

--
Best regards,
Ruslan Bilovol
--
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: Current state of AM33xx patches

[N, Mugunthan V]

 -Original Message-
 From: Daniel Mack [mailto:zon...@gmail.com]
 Sent: Wednesday, July 04, 2012 4:52 PM
 To: Hiremath, Vaibhav
 Cc: Paul Walmsley; Nori, Sekhar; Jason Kridner; Tony Lindgren; Hilman,
 Kevin; Hernandez, Carlos; Maupin, Chase; linux-omap@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org; Kridner, Jason; N, Mugunthan V
 Subject: Re: Current state of AM33xx patches
 
 On 04.07.2012 12:50, Hiremath, Vaibhav wrote:
  On Wed, Jul 04, 2012 at 15:37:31, Paul Walmsley wrote:
  On Sat, 30 Jun 2012, Daniel Mack wrote:
 
  Ok, thanks for the explaining this. For now, I'll add hwmod stubs for
  the components I need.
 
  Hmm.  Which drivers are you working on?  Vaibhav Hiremath has hwmod
 data
  for the AM33xx.  There might be some missing integration code to build
 the
  devices for the newer IP blocks, though.
 
 
  I would also be interested to know more here.
 
 
  Btw, has anyone yet worked on getting the MDIO/EMAC driver merged?
 
  Mainline has:
 
  drivers/net/ethernet/ti/davinci_emac.c
 
  Not required for AM335X.
 
  drivers/net/ethernet/ti/davinci_mdio.c
 
  Those might work for you.
 
 
  Few more files,
 
  drivers/net/ethernet/ti/cpsw.c
  drivers/net/ethernet/ti/davinci_cpdma.c
 
 
  Wanted to highlight one point,
  You still have to add platform device code to get it working.
 
 Exactly. And a hwmod binding for DT. Do you have patches for that?
 
 
 Daniel

I am working on DT support for cpsw and will be submitting the patch by 
July 20, 2012

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

Re: [RFC] ARM: OMAP: Remove nodes dynamically at runtime

[Jon Hunter]

Hi Rob,

Thanks for the feedback. Some how our mail server appeared to filter out your
response!

 On 06/21/2012 06:50 PM, Jon Hunter wrote:
 
 On 06/21/2012 02:15 PM, Jon Hunter wrote:
 Hi all,

 I am in the process of adding a device-tree binding for OMAP timers and
 I have encountered a scenario where ideally it would be useful to remove
 a device-tree node at runtime.

 The scenario is this ...

 1. OMAP3 devices may or may not have security features enabled. Security
enabled devices are known as high-secure (HS) and devices without 
security are known as general purpose (GP).
 2. For OMAP3 devices there are 12 general purpose timers available.
 3. On secure devices the 12th timer is reserved for secure usage and so
cannot be used by the kernel, where as for a GP device it is available.
 4. We can detect the OMAP device type, secure or GP, at runtime via an
on-chip register.
 5. Today, when not using DT, we do not register the 12th timer as a linux
device if the device is secure.

 When migrating the timers to DT, I need a way to prevent this 12th timer
 from being registered as a device on a secure device. The options I have
 considered are ...

 a. Have separate a omap3.dtsi for GP and secure devices or place the
node for the 12th timer in a omap3-gp.dtsi that is only used for
boards with GP devices. The downside of this is that for boards
that can support GP and secure device (such as the omap3 SDP) we
require a separate dtb blob.

 That's certainly not ideal since you can distinguish which device you
 are on. Does omap have a custom register for this because determining
 secure vs. non-secure mode is a common problem without a standard way to
 determine it.

Yes, unfortunately the register I was referring to is a custom OMAP register. 


 b. Remove the timer node dynamically at runtime using the
of_node_detach() API. In this solution we define a ti,timer-secure
property that the 12th timer on omap3 devices would have and at
runtime if we are a secure omap3 device, we search the timer nodes
for any nodes with this property and remove them.

 Option B, seems to be the better option but requires me to enable 
 CONFIG_OF_DYNAMIC for all omap devices and I was not sure if there is any
 downside to doing so. Enabling this feature does not seem to add much code
 as far as I can tell, however, I  wanted to get some feedback before
 proposing this. Also if there are any other options I should consider then
 please let me know.


 I would wonder if of_node_get/put calls are all properly implemented.
 They don't really matter until OF_DYNAMIC is enabled, but it would
 affect all ARM DT platforms once we enable multi-platform support.

 Option C - have the bootloader set nodes status property to disabled.
 
 Option D - same as C, but do it in the kernel with prom_add_property.

Option D, sounds good to me. I will look into this.

Thanks
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 1/2] remoteproc: maintain a generic child device for each rproc

[Stephen Boyd]

On 07/02/12 12:54, Ohad Ben-Cohen wrote:
 On Mon, Jul 2, 2012 at 10:06 PM, Stephen Boyd sb...@codeaurora.org wrote:
 Great! It looks like device_type doesn't have any list iteration support
 though. Is that requirement gone?
 Pretty much, yeah. I'll soon post a separate patch which removes the
 get_by_name functionality (together with its related klist).

 Will you resend this as part of a series? It will be easier to review then.
 Not sure. There's a collection of discrete patches that I've been
 posting, but they really aren't an organic series: as long as the
 dependencies are met, each and every one of them is applicable even if
 applied alone.

 So I'd prefer (when possible) to treat patches in a discrete fashion
 so we can start applying them and unblock others who depend on them
 (e.g. Fernando's runtime PM work depends on this one).

 But if you prefer me to send this one patch differently to make it
 easier to review, let me know!


Ok then. Please add

Reviewed-by: Stephen Boyd sb...@codeaurora.org

It would be nice if you got an ack from Greg or Kay on the device_type
usage too.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
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 02/12] ARM: OMAP2+: hwmod code/data: fix 32K sync timer

[Kevin Hilman]

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

 Hi Benoît

 On Wed, 4 Jul 2012, Benoit Cousson wrote:

  @@ -1141,8 +1144,16 @@ static void _enable_sysc(struct omap_hwmod *oh)
 sf = oh-class-sysc-sysc_flags;
   
 if (sf  SYSC_HAS_SIDLEMODE) {
  -  idlemode = (oh-flags  HWMOD_SWSUP_SIDLE) ?
  -  HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
  +  clkdm_act = ((oh-clkdm 
  +oh-clkdm-flags  CLKDM_ACTIVE_WITH_MPU) ||
  +   (oh-_clk-clkdm 
 
 This is crashing on OMAP4 due to a NULL oh-_clk that can happen on some
 hwmod.
 
 + (oh-_clk  oh-_clk-clkdm 
 
 Is fixing the issue.

 Thanks, just made the change and pushed the patch up to 
 git://git.pwsan.com/linux-2.6 in the branch 'omap_fixes_c_3.5rc'

OK, to ensure this fix gets into v3.5-rc, I'm taking the version from
this branch and queuing up as a PM fix Tony.

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

[GIT PULL] OMAP: PM: one more fix for 3.5-rc

[Kevin Hilman]

Tony,

Hopefully this is the last one.

This one fixes a problem where the CORE power domain does not hit
retention during suspend.  This has been known since v3.5 came out, but
there has been some discussion about the proper fix.  The solution has
now been agreed upon, so I'd like to see this make it for v3.5-rc.

Thanks,

Kevin



The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678:

  Linux 3.5-rc5 (2012-06-30 16:08:57 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
for_3.5/fixes/pm-3

for you to fetch changes up to 006c7f18449a06027b0165e938c67b3a029813c9:

  ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer (2012-07-05 
17:25:38 -0700)


Paul Walmsley (1):
  ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

 arch/arm/mach-omap2/clockdomain.h|4 +++
 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |1 +
 arch/arm/mach-omap2/clockdomains44xx_data.c  |2 +-
 arch/arm/mach-omap2/omap_hwmod.c |   32 --
 4 files changed, 30 insertions(+), 9 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 V2 01/10] ARM: PMU: Add runtime PM Support

[Jon Hunter]

Hi Will,

On 07/02/2012 05:01 PM, Will Deacon wrote:
 On Mon, Jul 02, 2012 at 05:50:38PM +0100, Jon Hunter wrote:
 On 07/02/2012 04:55 AM, Will Deacon wrote:

 Did you have any luck getting to the bottom of this?

 I am still waiting for feedback from design. They were trying to confirm
 my observations. Unfortunately, it is taking some time. I will ping them
 again.
 
 Ok, thanks. If pinging doesn't work, bribery can be quite effective with
 hardware guys :)

Yes looks like I am going to need to get creative :-)

 It would be good to take your PMU suspend/resume patches once we know that
 they will get used.

 Yes that would be good. I could drop the 4460 specific changes for now
 and make 4460 work in the same way as 4430 (using CTI) for the time
 being and see if we can get these in. However, I recall that was not
 working for you, but it was working fine for me.
 
 Indeed, that hack didn't help me and I'd rather not commit it if it only
 partially fixes the problem. A better bet might just be to go with your
 original approach and see how many bug reports we receive. That might also
 help us narrow down the problem, but it's your call.

Ok, I think that that is best.

 In the meantime, I pushed what I think is the latest drop of your series to
 a new branch on kernel.org:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4-dev

Looks good.

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

[PATCH 5 1/2] NET ethernet introduce eth-mac-platform helper

[Andy Green]

From: Andy Green a...@warmcat.com

This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed to be assigned to the device when it appears.

This allows platform code to enforce valid, consistent MAC addresses on to
devices that have not been probed at boot-time, but due to being wired on the
board are always present at the same interface.  It has been tested with USB
and SDIO probed devices.

Other parts of this series provide an OMAP API that computes a valid
locally administered MAC address from CPU ID bits that are unique for each
physical SoC, and register those against devices wired to the board.

This solves a longstanding problem in at least Panda case that there are no
reserved MACs for either onboard Ethernet nor onboard WLAN module, and without
this patch a randomized MAC is assigned to Ethernet and 00:00:00:00:00:00 or
0xdeadbeef is assigned as the WLAN MAC address.  The series provides sane,
constant locally-administered MAC addresses that have a high probability of
differing between boards.

To make use of this safely you also need to make sure that any drivers that
may compete for the bus ordinal you are using (eg, mUSB and ehci in Panda
case) are loaded in a deterministic order.

At registration it makes a copy of the incoming data, so the data may be
__initdata or otherwise transitory.  Registration can be called multiple times
so registrations from Device Tree and platform may be mixed.

Since it needs to be called quite early in boot and there is no lifecycle for
what it does, it could not be modular and is not a driver.

Via suggestions from Arnd Bergmann and Tony Lindgren (and Alan Cox for the
network notifier concept).

Cc: net...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
 include/net/eth-mac-platform.h  |   40 ++
 net/Kconfig |5 +
 net/ethernet/Makefile   |3 +
 net/ethernet/eth-mac-platform.c |  150 +++
 4 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 include/net/eth-mac-platform.h
 create mode 100644 net/ethernet/eth-mac-platform.c

diff --git a/include/net/eth-mac-platform.h b/include/net/eth-mac-platform.h
new file mode 100644
index 000..752f1de
--- /dev/null
+++ b/include/net/eth-mac-platform.h
@@ -0,0 +1,40 @@
+/*
+ * eth-mac-platform.h:  Enforces platform-defined MAC for Async probed devices
+ */
+
+#ifndef __ETH_NET_MAC_PLATFORM_H__
+#define __ETH_NET_MAC_PLATFORM_H__
+
+#include linux/if_ether.h
+
+/**
+ * struct eth_mac_platform - associates asynchronously probed device path with
+ *  MAC address to be assigned to the device when it
+ *  is created
+ *
+ * @device_path: device path name of network device
+ * @mac: MAC address to assign to network device matching device path
+ * @list: can be left uninitialized when passing from platform
+ */
+
+struct eth_mac_platform {
+   char *device_path;
+   u8 mac[ETH_ALEN];
+   struct list_head list; /* unused in platform data usage */
+};
+
+#ifdef CONFIG_NET
+/**
+ * eth_mac_platform_register_device_macs - add an array of device path to
+ *  monitor and MAC to apply when the network
+ *  device at the device path appears
+ * @macs: array of struct eth_mac_platform terminated by entry with
+ *   NULL device_path
+ */
+int eth_mac_platform_register_device_macs(const struct eth_mac_platform *macs);
+#else
+static inline int eth_mac_platform_register_device_macs(
+const struct eth_mac_platform *macs) { return 0; }
+#endif /* !CONFIG_NET */
+
+#endif /* __ETH_NET_MAC_PLATFORM_H__ */
diff --git a/net/Kconfig b/net/Kconfig
index 245831b..dd8ab96 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -335,9 +335,12 @@ source net/caif/Kconfig
 source net/ceph/Kconfig
 source net/nfc/Kconfig
 
-
 endif   # if NET
 
+# used by board / dt platform to enforce Ethernet MACs for Async-probed devices
+config ETH_MAC_PLATFORM
+   bool
+
 # Used by archs to tell that they support BPF_JIT
 config HAVE_BPF_JIT
bool
diff --git a/net/ethernet/Makefile b/net/ethernet/Makefile
index 7cef1d8..7362f46 100644
--- a/net/ethernet/Makefile
+++ b/net/ethernet/Makefile
@@ -5,3 +5,6 @@
 obj-y  += eth.o
 obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
 obj-$(subst m,y,$(CONFIG_ATALK))   += pe2.o
+ifneq ($(CONFIG_NET),)
+obj-$(CONFIG_ETH_MAC_PLATFORM) += eth-mac-platform.o
+endif
diff --git a/net/ethernet/eth-mac-platform.c b/net/ethernet/eth-mac-platform.c
new file mode 100644
index 000..9b2ad69
--- /dev/null
+++ b/net/ethernet/eth-mac-platform.c
@@ -0,0 +1,150 @@
+/*
+ * Helper to allow platform code to 

[PATCH 5 2/2] OMAP4 PANDA register ethernet and wlan for automatic mac allocation

[Andy Green]

From: Andy Green a...@warmcat.com

This provides the board-specific device paths needed to get
the panda boardfile working with the eth-mac-platform api.

On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding randomized MAC per-boot and consequent DHCP problems,
or in the case of wlan0 a MAC set by a firmware file in the rootfs
which unless customized yields a MAC of 00:00:00:00:00:00.  No
official MAC is reserved for either network device even if you do
take the approach to customize the firmware file.

This gets sane, consistent MAC addresses on both devices which
should stand a good probability of differing between PandaBoards.

Signed-off-by: Andy Green andy.gr...@linaro.org
---
 arch/arm/mach-omap2/Kconfig|1 +
 arch/arm/mach-omap2/board-omap4panda.c |   30 ++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 83fb31c..61c6a3d 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+   select ETH_MAC_PLATFORM
 
 config MACH_PCM049
bool OMAP4 based phyCORE OMAP4
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..75d93cc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -32,7 +32,10 @@
 #include linux/wl12xx.h
 #include linux/platform_data/omap-abe-twl6040.h
 
+#include net/eth-mac-platform.h
+
 #include mach/hardware.h
+#include mach/id.h
 #include asm/hardware/gic.h
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -486,16 +489,43 @@ static void omap4_panda_init_rev(void)
}
 }
 
+/*
+ * These device paths represent onboard network devices which have
+ * no MAC address set at boot, and need synthetic ones assigning
+ */
+static __initdata struct eth_mac_platform panda_eth_mac_platform[] = {
+
+   { /* smsc USB - Ethernet bridge */
+   .device_path = usb1/1-1/1-1.1/1-1.1:1.0,
+   },
+   { /* wlan0 module */
+   .device_path = wl12xx,
+   },
+   { /* terminator */
+   }
+};
+
 static void __init omap4_panda_init(void)
 {
int package = OMAP_PACKAGE_CBS;
int ret;
+   int n;
 
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
 
omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+   /*
+* provide MAC addresses computed from device ID for network
+* devices that have no MAC address otherwise on Panda
+*/
+   for (n = 0; n  ARRAY_SIZE(panda_eth_mac_platform) - 1; n++)
+   omap_die_id_to_ethernet_mac(panda_eth_mac_platform[n].mac, n);
+   if (eth_mac_platform_register_device_macs(panda_eth_mac_platform))
+   pr_err(Unable to register eth_mac_platform devices\n);
+
ret = wl12xx_set_platform_data(omap_panda_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);

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

RE: [PATCH v3 2/5] usb: musb: twl: use mailbox API to send VBUS or ID events

[Matcovschi, Oleg]

Hi Kishon,


-Original Message-
From: ABRAHAM, KISHON VIJAY 
Sent: Tuesday, July 03, 2012 10:48 PM
To: Matcovschi, Oleg
Cc: gre...@linuxfoundation.org; linux-omap@vger.kernel.org; 
linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; Balbi, Felipe
Subject: Re: [PATCH v3 2/5] usb: musb: twl: use mailbox API to send VBUS or ID 
events

Hi Oleg,

On Tue, Jul 3, 2012 at 11:09 PM, Matcovschi, Oleg oleg.matcovs...@ti.com 
wrote:
From: linux-omap-ow...@vger.kernel.org 
[linux-omap-ow...@vger.kernel.org] on behalf of ABRAHAM, KISHON VIJAY
Sent: Friday, June 22, 2012 5:10 AM
To: gre...@linuxfoundation.org; ABRAHAM, KISHON VIJAY; 
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; 
linux-...@vger.kernel.org; Balbi, Felipe
Subject: [PATCH v3 2/5] usb: musb: twl: use mailbox API to send VBUS 
or ID events

The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID 
events, is replaced by a direct call to omap musb blue.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/musb/omap2430.c   |   94 
+---
 drivers/usb/otg/twl4030-usb.c |   46 ++--  
drivers/usb/otg/twl6030-usb.c |   47 +---  
include/linux/usb/musb-omap.h |   30 +
 4 files changed, 133 insertions(+), 84 deletions(-)  create mode 
100644 include/linux/usb/musb-omap.h
 .
 +enum omap_musb_vbus_id_status {
 +       OMAP_MUSB_UNKNOWN = 0,
 +       OMAP_MUSB_ID_GROUND,
 +       OMAP_MUSB_ID_FLOAT,
 +       OMAP_MUSB_VBUS_VALID,
 +       OMAP_MUSB_VBUS_OFF,
 +};
 +

 Why did you choose to introduce OMAP_MUSB specific VBUS, ID events?
 IMHO, it makes more sense to introduce mailbox functionality only without 
 extra translation layer.
 Same mailbox glue layer could be used for other PHY drivers, not just twl.

We've decided to make twl as a comparator driver since we have a separate phy 
driver (not yet merged). Hence we dint want twl to use usb_phy specific 
events. So if you have other PHY drivers, you can still use the OMAP_MUSB 
specific events.
Thanks
Kishon

In other words: you are proposing to have 2 flavors of other phy drivers(OMAP 
and not-OMAP platform specific)...
Do you think it is necessary?
Could you please provide full description of your original problem?

Regards,
 Oleg
--
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