date:20130520

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
 Sent: Friday, May 17, 2013 11:49 PM
 To: Peter Korsgaard
 Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
 o...@vger.kernel.org; Tony Lindgren
 Subject: Re: reset handling in am335x hwmod data

 On 20:10-20130517, Peter Korsgaard wrote:
   Kevin == Kevin Hilman khil...@linaro.org writes:

In this case, we cannot reset that bank, otherwise Starter Kit
 will
never boot in mainline. Bad PCB design, I know, but it's not
 something
we can change now :-)

   Kevin FWIW, we've seen this before (GPIO connected to PMIC reset is
 a
   Kevin fun one), and this is why we have
 omap_hwmod_no_setup_reset().

  Yes, but there's no dts bindings for this, and from a quick test the
  reset handling happens before the device tree is probed.
 I have the same issue with TPS62361 on Palmas - GPIO controls the
 voltage register supplying MPU, without any driver setting things up,
 GPIO gets reset and obviously voltage value switches to an voltage
 where
 device does not function.

 Solution I am working on to solve this is [1]: snippet is part of a
 patch that I am working on atm.

 This is the right way to do it IMHO. Will allow the driver to exist
 when
 HWMOD will be eventually replaced by some other framework.

 [1]: http://pastebin.com/XPmAB1Zb

Both seems to be different to me. What we need is to
Avoid reset of whole GPIO bank during kernel boot. 

Ideally, it would have been much better if drivers starts handling
Idle, ocp reset and standby on their own (killing dependency on hwmod 
init layer).

But looking at current state,
I agree we need to use DT property here, so how about 
Adding DT property  to GPIO node itself. But we have to parse
It early during hwmod init stage. We should read all DT nodes 
Inside function __setup() function, that way can get rid of
HWMOD_INIT_NO_RESET flag completely. Also, this will handle
Both ocp_reset and domain reset.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe 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: reset handling in am335x hwmod data

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
 Sent: Monday, May 20, 2013 12:09 PM
 To: Menon, Nishanth; Peter Korsgaard
 Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
 o...@vger.kernel.org; Tony Lindgren
 Subject: RE: reset handling in am335x hwmod data

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
  Sent: Friday, May 17, 2013 11:49 PM
  To: Peter Korsgaard
  Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
  o...@vger.kernel.org; Tony Lindgren
  Subject: Re: reset handling in am335x hwmod data

  On 20:10-20130517, Peter Korsgaard wrote:
Kevin == Kevin Hilman khil...@linaro.org writes:

 In this case, we cannot reset that bank, otherwise Starter Kit
  will
 never boot in mainline. Bad PCB design, I know, but it's not
  something
 we can change now :-)

Kevin FWIW, we've seen this before (GPIO connected to PMIC reset
 is
  a
Kevin fun one), and this is why we have
  omap_hwmod_no_setup_reset().

   Yes, but there's no dts bindings for this, and from a quick test
 the
   reset handling happens before the device tree is probed.
  I have the same issue with TPS62361 on Palmas - GPIO controls the
  voltage register supplying MPU, without any driver setting things up,
  GPIO gets reset and obviously voltage value switches to an voltage
  where
  device does not function.

  Solution I am working on to solve this is [1]: snippet is part of a
  patch that I am working on atm.

  This is the right way to do it IMHO. Will allow the driver to exist
  when
  HWMOD will be eventually replaced by some other framework.

  [1]: http://pastebin.com/XPmAB1Zb

 Both seems to be different to me. What we need is to
 Avoid reset of whole GPIO bank during kernel boot.

 Ideally, it would have been much better if drivers starts handling
 Idle, ocp reset and standby on their own (killing dependency on hwmod
 init layer).

 But looking at current state,
 I agree we need to use DT property here, so how about
 Adding DT property  to GPIO node itself. But we have to parse
 It early during hwmod init stage. We should read all DT nodes
 Inside function __setup() function, that way can get rid of
 HWMOD_INIT_NO_RESET flag completely. Also, this will handle
 Both ocp_reset and domain reset.

Forgot to mention, 

Since this is kernel boot failure issue, I think,
By the time we reach to conclusion, another approach is to 
set HWMOD_INIT_NO_RESET flag For GPIO0 bank.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe 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/6] ARM: OMAP2+: Remove board-4430sdp.c

2013-05-20 Thread Russell King - ARM Linux

On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
 We can now boot with device tree. If you don't want to update u-boot,
 you can boot with appended DTB with the following instructions:
 
 1. Make sure you have the appended DTB support in .config
 
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
 
 2. Build the zImage
 
$ ARCH=arm CROSS_COMPILE=... make zImage
 
 3. Build the device tree blobs
 
$ ARCH=arm CROSS_COMPILE=... make dtbs
 
 4. Append the dtb to zImage
 
$ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb  /tmp/appended
 
 5. Use mkimage to produce the appended device tree uImage
 
$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
  -n Linux -d /tmp/appended /tmp/uImage
 
 Signed-off-by: Tony Lindgren t...@atomide.com

Okay, I'm removing the 4430SDP from the boot test system once this goes
in, because this will mean rewriting the build system to cope with this
stuff.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH-V2 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad

'clkout2' comes out on the device pad and is being used by various
external on-board peripherals like, Audio codecs, Wilink and stuff.
So enable the clkout2 by default during init sequence itself
along with right pinmux configuration clkout2 output.

Also, add the missing entry of clkout2_ck to the AM33xx clock table.

As far as enabling of clkout2 during init is concerned,
we can argue that it can be handled using DT property and enable
the clock only when specified; but not until OMAP clock-tree
migration to DT.

Changes from V1:
- Fixed spelling mistake in dts file
- Added Acked-by from 'Paul Walmsley'

Vaibhav Hiremath (2):
  ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init
  ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output

 arch/arm/boot/dts/am335x-bone.dts |8 +++-
 arch/arm/boot/dts/am335x-evm.dts  |8 +++-
 arch/arm/boot/dts/am335x-evmsk.dts|8 +++-
 arch/arm/mach-omap2/cclock33xx_data.c |2 ++
 4 files changed, 23 insertions(+), 3 deletions(-)

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

[PATCH-V2 1/2] ARM: OMAP AM33XX: clock data: Enable clkout2 as part of init

clkout2 comes out on the pad and is being used by various
external on-board peripherals like, Audio codecs and stuff.
So enable the clkout2 by default during init sequence itself.

Also, add the missing entry of clkout2_ck to the clock table.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/cclock33xx_data.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock33xx_data.c 
b/arch/arm/mach-omap2/cclock33xx_data.c
index 6fd0ed1..a8140b6 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -979,6 +979,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   trace_pmd_clk_mux_ck, trace_pmd_clk_mux_ck),
CLK(NULL,   stm_clk_div_ck,   stm_clk_div_ck),
CLK(NULL,   trace_clk_div_ck, trace_clk_div_ck),
+   CLK(NULL,   clkout2_ck,   clkout2_ck),
 };


@@ -989,6 +990,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+   clkout2_ck,   /* Required for external peripherals like, Audio codecs 
*/
 };

 int __init am33xx_clk_init(void)
--
1.7.0.4

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

[PATCH-V2 2/2] ARM: dts: AM33XX: Set pinmux for clkout2 pad used for clock output

xdma_event_intr1.clkout2 pad can be used to source clock
from either 32K OSC or any of the PLL (except MPU) outputs.
On the existing AM335x based boards (EVM, EVM-SK and Bone),
this pad is used to feed the clock to audio codes.

So, this patch configures the pinmux to get clkout2 on the pad.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/boot/dts/am335x-bone.dts  |8 +++-
 arch/arm/boot/dts/am335x-evm.dts   |8 +++-
 arch/arm/boot/dts/am335x-evmsk.dts |8 +++-
 3 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index bfba6fc..74bfcc6 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -26,7 +26,7 @@

am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
-   pinctrl-0 = ;
+   pinctrl-0 = clkout2_pin;

user_leds_s0: user_leds_s0 {
pinctrl-single,pins = 
@@ -50,6 +50,12 @@
0x174 0x00  /* uart0_txd.uart0_txd PULLDOWN 
| MODE0 */
;
};
+
+   clkout2_pin: pinmux_clkout2_pin {
+   pinctrl-single,pins = 
+   0x1b4 0x03  /* xdma_event_intr1.clkout2 
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+   ;
+   };
};

ocp {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 7647c9d..896d392 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@

am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
-   pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+   pinctrl-0 = matrix_keypad_s0 volume_keys_s0 clkout2_pin;

matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins = 
@@ -65,6 +65,12 @@
0x174 0x00  /* uart0_txd.uart0_txd PULLDOWN 
| MODE0 */
;
};
+
+   clkout2_pin: pinmux_clkout2_pin {
+   pinctrl-single,pins = 
+   0x1b4 0x03  /* xdma_event_intr1.clkout2 
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+   ;
+   };
};

ocp {
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0eec644..4d81dbc 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@

am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
-   pinctrl-0 = gpio_keys_s0;
+   pinctrl-0 = gpio_keys_s0 clkout2_pin;

user_leds_s0: user_leds_s0 {
pinctrl-single,pins = 
@@ -65,6 +65,12 @@
0x174 0x00  /* uart0_txd.uart0_txd PULLDOWN 
| MODE0 */
;
};
+
+   clkout2_pin: pinmux_clkout2_pin {
+   pinctrl-single,pins = 
+   0x1b4 0x03  /* xdma_event_intr1.clkout2 
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+   ;
+   };
};

ocp {
--
1.7.0.4

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

[PATCH-V2] ARM: OMAP2+: AM33xx: Fix missing reset status data to GFX hwmod

GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
so update the GFX hwmod data with .rstst_off and .st_shift
information.

Although it doesn't have impact on kernel boot, but this is
regression fix from original hwmod commit.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
Changes from V1 (No code change):
- Updated commit description to mention its regression
  from original commit.

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index d1cf3ab..38c7b04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -329,7 +329,7 @@ static struct omap_hwmod_class am33xx_gfx_hwmod_class = {
 };

 static struct omap_hwmod_rst_info am33xx_gfx_resets[] = {
-   { .name = gfx, .rst_shift = 0 },
+   { .name = gfx, .rst_shift = 0, .st_shift = 0},
 };

 static struct omap_hwmod_irq_info am33xx_gfx_irqs[] = {
@@ -347,6 +347,7 @@ static struct omap_hwmod am33xx_gfx_hwmod = {
.omap4  = {
.clkctrl_offs   = AM33XX_CM_GFX_GFX_CLKCTRL_OFFSET,
.rstctrl_offs   = AM33XX_RM_GFX_RSTCTRL_OFFSET,
+   .rstst_offs = AM33XX_RM_GFX_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.7.0.4

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

Re: [PATCH-V2] ARM: OMAP2+: AM33xx: Fix missing reset status data to GFX hwmod

2013-05-20 Thread Paul Walmsley

On Mon, 20 May 2013, Vaibhav Hiremath wrote:

 GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
 so update the GFX hwmod data with .rstst_off and .st_shift
 information.
 
 Although it doesn't have impact on kernel boot, but this is
 regression fix from original hwmod commit.
 

Did it ever work?  If not, then it's not a regression, right?


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

Re: reset handling in am335x hwmod data

2013-05-20 Thread Nishanth Menon

On 01:55-20130520, Hiremath, Vaibhav wrote:

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
  ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
  Sent: Monday, May 20, 2013 12:09 PM
  To: Menon, Nishanth; Peter Korsgaard
  Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
  o...@vger.kernel.org; Tony Lindgren
  Subject: RE: reset handling in am335x hwmod data

   -Original Message-
   From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
   ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
   Sent: Friday, May 17, 2013 11:49 PM
   To: Peter Korsgaard
   Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
   o...@vger.kernel.org; Tony Lindgren
   Subject: Re: reset handling in am335x hwmod data

   On 20:10-20130517, Peter Korsgaard wrote:
 Kevin == Kevin Hilman khil...@linaro.org writes:

  In this case, we cannot reset that bank, otherwise Starter Kit
   will
  never boot in mainline. Bad PCB design, I know, but it's not
   something
  we can change now :-)

 Kevin FWIW, we've seen this before (GPIO connected to PMIC reset
  is
   a
 Kevin fun one), and this is why we have
   omap_hwmod_no_setup_reset().

Yes, but there's no dts bindings for this, and from a quick test
  the
reset handling happens before the device tree is probed.
   I have the same issue with TPS62361 on Palmas - GPIO controls the
   voltage register supplying MPU, without any driver setting things up,
   GPIO gets reset and obviously voltage value switches to an voltage
   where
   device does not function.

   Solution I am working on to solve this is [1]: snippet is part of a
   patch that I am working on atm.

   This is the right way to do it IMHO. Will allow the driver to exist
   when
   HWMOD will be eventually replaced by some other framework.

   [1]: http://pastebin.com/XPmAB1Zb

  Both seems to be different to me. What we need is to
  Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is requested and
set to the right level by the relevant driver, it is not unused and
hence not reset at late_init.

I am a little unclear as to why this needs to have anything to do with
the precise under-lying mechanism (hwmod or something else). May be
both seem to be different to me needs a little further elaboration?

Is this because there is no need for an EMIF driver to handle DDR? and
reset of the GPIO will occur as EMIF is configured at bootloader and
there is no need to do that in kernel, correspondingly there is no
driver to hold the gpio?

  Ideally, it would have been much better if drivers starts handling
  Idle, ocp reset and standby on their own (killing dependency on hwmod
  init layer).

  But looking at current state,
  I agree we need to use DT property here, so how about
  Adding DT property  to GPIO node itself. But we have to parse
I believe you mean at OMAP specific  DT property for hwmod?
something like ti,hwmod-no-init-reset?
  It early during hwmod init stage. We should read all DT nodes
  Inside function __setup() function, that way can get rid of
  HWMOD_INIT_NO_RESET flag completely. Also, this will handle
  Both ocp_reset and domain reset.

 Forgot to mention, 

 Since this is kernel boot failure issue, I think,
 By the time we reach to conclusion, another approach is to 
 set HWMOD_INIT_NO_RESET flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on another platform,
this wont work
b) for platforms that dont use gpio to hold DDR power, maybe this is not
even relevant and the GPIO bank can safely be reset?

 Thanks,
 Vaibhav

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

Re: [PATCH] ARM: OMAP2+: Fix multiple randconfig errors if no SoC is selected, take3

* Tony Lindgren t...@atomide.com [130517 14:08]:
 --- a/arch/arm/mach-omap2/Makefile
 +++ b/arch/arm/mach-omap2/Makefile
 @@ -6,7 +6,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := 
 -I$(srctree)/$(src)/include \
   -I$(srctree)/arch/arm/plat-omap/include
  
  # Common support
 -obj-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o 
 pm.o \
 +soc-y := id.o io.o control.o mux.o devices.o fb.o serial.o gpmc.o timer.o 
 pm.o \
common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o omap_hwmod.o \
omap_device.o sram.o
  
 @@ -85,7 +85,8 @@ obj-$(CONFIG_ARCH_OMAP2)+= sleep24xx.o
  obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
  obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o
  obj-$(CONFIG_SOC_OMAP5)  += omap-mpuss-lowpower.o
 -obj-$(CONFIG_PM_DEBUG)   += pm-debug.o
 +pm-$(CONFIG_ARCH_OMAP)   += pm-debug.o
 +obj-$(CONFIG_PM_DEBUG)   += $(pm-y)
  
  obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o
  obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
 @@ -201,7 +202,8 @@ obj-$(CONFIG_ARCH_OMAP4)  += 
 omap_hwmod_44xx_data.o
  
  # EMU peripherals
  obj-$(CONFIG_OMAP3_EMU)  += emu.o
 -obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
 +pmu-$(CONFIG_ARCH_OMAP)  += pmu.o
 +obj-$(CONFIG_HW_PERF_EVENTS) += $(pmu-y)
  
  obj-$(CONFIG_OMAP_MBOX_FWK)  += mailbox_mach.o
  mailbox_mach-objs:= mailbox.o

Oops, both pm-debug.o and pmu.o should now be just:

soc-$(CONFIG_PM_DEBUG)  += pm-debug.o
soc-$(CONFIG_ARCH_OMAP) += pmu.o

Will repost after running make randconfig for few hours today.

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 1/6] ARM: OMAP2+: Remove board-4430sdp.c

* Russell King - ARM Linux li...@arm.linux.org.uk [130520 03:00]:
 On Fri, May 17, 2013 at 12:17:51PM -0700, Tony Lindgren wrote:
  We can now boot with device tree. If you don't want to update u-boot,
  you can boot with appended DTB with the following instructions:
  
  1. Make sure you have the appended DTB support in .config
  
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y
  
  2. Build the zImage
  
 $ ARCH=arm CROSS_COMPILE=... make zImage
  
  3. Build the device tree blobs
  
 $ ARCH=arm CROSS_COMPILE=... make dtbs
  
  4. Append the dtb to zImage
  
 $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-sdp.dtb  
  /tmp/appended
  
  5. Use mkimage to produce the appended device tree uImage
  
 $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \
   -n Linux -d /tmp/appended /tmp/uImage
  
  Signed-off-by: Tony Lindgren t...@atomide.com
 
 Okay, I'm removing the 4430SDP from the boot test system once this goes
 in, because this will mean rewriting the build system to cope with this
 stuff.

OK, up to you. At least I check the results of your build system
occasionally though.

I know people don't want to have more uImage handling in the kernel,
but maybe we could add handling for board specific uImage targets
for compability?

Maybe something like dtbname.uImage-dtba:

$ make omap4-sdp.uImage-dtba

And then that would take care of steps 3 - 5 automatically?

Of course the alternative is to update u-boot, but that's not always
possible for some legacy boards.

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: [BISECTED] 3.10-rc1 OMAP1 GPIO IRQ regression

* Tony Lindgren t...@atomide.com [130516 14:50]:
 * Aaro Koskinen aaro.koski...@iki.fi [130516 14:05]:
  On Thu, May 16, 2013 at 11:09:34AM -0700, Tony Lindgren wrote:
   * Aaro Koskinen aaro.koski...@iki.fi [130513 13:58]:
I tested 3.10-rc1 on OMAP1 / Nokia 770, and Retu MFD probe is broken:

[2.264221] retu-mfd 2-0001: Retu v3.2 found
[2.281951] retu-mfd 2-0001: Failed to allocate IRQs: -12
[2.300140] retu-mfd: probe of 2-0001 failed with error -12

The error is coming from regmap code. According to git bisect, it is
caused by:

commit ede4d7a5b9835510fd1f724367f68d2fa4128453
Author: Jon Hunter jon-hun...@ti.com
Date:   Fri Mar 1 11:22:47 2013 -0600

gpio/omap: convert gpio irq domain to linear mapping

The commit does not anymore revert cleanly, and I haven't yet tried
crafting a manual revert, so any fix proposals/ideas are welcome...
   
   Hmm this might be a bit trickier to fix. Obviously the real solution
   is to convert omap1 to SPARSE_IRQ like we did for omap2+.
   
   For the -rc cycle, it might be possible to fix this by adding a
   different irq_to_gpio() and gpio_to_irq() functions for omap1.
  
  The commit reverts cleanly if we also revert
  3513cdeccc647d41c4a9ff923af17deaaac04a66 (gpio/omap: optimise interrupt
  service routine), which seems to be just some minor optimization. The
  result is below, and with it 770 works again.
 
 Hmm in this case it seems that we should just fix it rather than go back
 to the old code, so let's take a look at that first.

Does the following fix it for you or do we need to fix something else
there too?

Regards,

Tony


--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1094,6 +1094,7 @@ static int omap_gpio_probe(struct platform_device *pdev)
const struct omap_gpio_platform_data *pdata;
struct resource *res;
struct gpio_bank *bank;
+   int irq_base;
 
match = of_match_device(of_match_ptr(omap_gpio_match), dev);
 
@@ -1135,11 +1136,23 @@ static int omap_gpio_probe(struct platform_device *pdev)
pdata-get_context_loss_count;
}
 
-
-   bank-domain = irq_domain_add_linear(node, bank-width,
-irq_domain_simple_ops, NULL);
-   if (!bank-domain)
+   /*
+* REVISIT: Once we have omap1 supporting  SPARSE_IRQ, we can drop
+* irq_alloc_descs() and irq_domain_add_legacy() and just do:
+*
+* bank-domain = irq_domain_add_linear(node, bank-width,
+*   irq_domain_simple_ops, NULL);
+* if (!bank-domain)
+*  return -ENODEV;
+*/
+   irq_base = irq_alloc_descs(-1, 0, bank-width, 0);
+   if (irq_base  0) {
+   dev_err(dev, Couldn't allocate IRQ numbers\n);
return -ENODEV;
+   }
+
+   bank-domain = irq_domain_add_legacy(node, bank-width, irq_base,
+0, irq_domain_simple_ops, NULL);
 
if (bank-regs-set_dataout  bank-regs-clr_dataout)
bank-set_dataout = _set_gpio_dataout_reg;
--
To unsubscribe from this list: send the line unsubscribe 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: reset handling in am335x hwmod data

 -Original Message-
 From: Menon, Nishanth
 Sent: Monday, May 20, 2013 8:36 PM
 To: Hiremath, Vaibhav
 Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
 o...@vger.kernel.org; Tony Lindgren
 Subject: Re: reset handling in am335x hwmod data

 On 01:55-20130520, Hiremath, Vaibhav wrote:

   -Original Message-
   From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
   ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
   Sent: Monday, May 20, 2013 12:09 PM
   To: Menon, Nishanth; Peter Korsgaard
   Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
   o...@vger.kernel.org; Tony Lindgren
   Subject: RE: reset handling in am335x hwmod data

-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Friday, May 17, 2013 11:49 PM
To: Peter Korsgaard
Cc: Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
o...@vger.kernel.org; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data

On 20:10-20130517, Peter Korsgaard wrote:
  Kevin == Kevin Hilman khil...@linaro.org writes:

   In this case, we cannot reset that bank, otherwise Starter
 Kit
will
   never boot in mainline. Bad PCB design, I know, but it's
 not
something
   we can change now :-)

  Kevin FWIW, we've seen this before (GPIO connected to PMIC
 reset
   is
a
  Kevin fun one), and this is why we have
omap_hwmod_no_setup_reset().

 Yes, but there's no dts bindings for this, and from a quick
 test
   the
 reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas - GPIO controls
 the
voltage register supplying MPU, without any driver setting things
 up,
GPIO gets reset and obviously voltage value switches to an
 voltage
where
device does not function.

Solution I am working on to solve this is [1]: snippet is part of
 a
patch that I am working on atm.

This is the right way to do it IMHO. Will allow the driver to
 exist
when
HWMOD will be eventually replaced by some other framework.

[1]: http://pastebin.com/XPmAB1Zb

   Both seems to be different to me. What we need is to
   Avoid reset of whole GPIO bank during kernel boot.
 Yes - that is what the above does - as long as the GPIO is requested
 and
 set to the right level by the relevant driver, it is not unused and
 hence not reset at late_init.

May be I am missing something here,

Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall.

 I am a little unclear as to why this needs to have anything to do with
 the precise under-lying mechanism (hwmod or something else). May be
 both seem to be different to me needs a little further elaboration?

GPIO is connected to the DDR VTT control pin, and we have observed that
Due to GPIO bank reset as part of hwmod init during bootup.

 Is this because there is no need for an EMIF driver to handle DDR? and
 reset of the GPIO will occur as EMIF is configured at bootloader and
 there is no need to do that in kernel, correspondingly there is no
 driver to hold the gpio?

   Ideally, it would have been much better if drivers starts handling
   Idle, ocp reset and standby on their own (killing dependency on
 hwmod
   init layer).

   But looking at current state,
   I agree we need to use DT property here, so how about
   Adding DT property  to GPIO node itself. But we have to parse
 I believe you mean at OMAP specific  DT property for hwmod?
 something like ti,hwmod-no-init-reset?

That’s the idea.

   It early during hwmod init stage. We should read all DT nodes
   Inside function __setup() function, that way can get rid of
   HWMOD_INIT_NO_RESET flag completely. Also, this will handle
   Both ocp_reset and domain reset.

  Forgot to mention,

  Since this is kernel boot failure issue, I think,
  By the time we reach to conclusion, another approach is to
  set HWMOD_INIT_NO_RESET flag For GPIO0 bank.
 a) if the GPIO gets moved over to some other GPIO bank on another
 platform,
 this wont work

Yes that’s true, but such schematic interface is not recommended.
And we have not seen any known side-effect of not resetting GPIO0 bank.

 b) for platforms that dont use gpio to hold DDR power, maybe this is
 not
 even relevant and the GPIO bank can safely be reset?

As I mentioned, there is no known side-effect of not resetting GPIO bank 0.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP2+: AM33xx: Fix missing reset status data to GFX hwmod

 -Original Message-
 From: Paul Walmsley [mailto:p...@pwsan.com]
 Sent: Monday, May 20, 2013 8:09 PM
 To: Hiremath, Vaibhav
 Cc: linux-omap@vger.kernel.org; t...@atomide.com; linux-arm-
 ker...@lists.infradead.org
 Subject: Re: [PATCH-V2] ARM: OMAP2+: AM33xx: Fix missing reset status
 data to GFX hwmod

 On Mon, 20 May 2013, Vaibhav Hiremath wrote:

  GFX has a reset status register (PRM_GFX.RM_GFX_RSTST),
  so update the GFX hwmod data with .rstst_off and .st_shift
  information.

  Although it doesn't have impact on kernel boot, but this is
  regression fix from original hwmod commit.

 Did it ever work?  If not, then it's not a regression, right?

As we know none of the GFX sw is available in the mainline, so never got
exercised so far; but kernel boots up fine without any issues.
I was also confused a bit on this, but then thought, this could be regression
As it is fixing wrong/missing data without which GFX will not work.
May be I was wrong.

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe 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: reset handling in am335x hwmod data

2013-05-20 Thread Nishanth Menon

On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]

 On 20:10-20130517, Peter Korsgaard wrote:
   Kevin == Kevin Hilman khil...@linaro.org writes:
 
In this case, we cannot reset that bank, otherwise Starter
  Kit
 will
never boot in mainline. Bad PCB design, I know, but it's
  not
 something
we can change now :-)
 
   Kevin FWIW, we've seen this before (GPIO connected to PMIC
  reset
is
 a
   Kevin fun one), and this is why we have
 omap_hwmod_no_setup_reset().
 
  Yes, but there's no dts bindings for this, and from a quick
  test
the
  reset handling happens before the device tree is probed.
 I have the same issue with TPS62361 on Palmas - GPIO controls
  the
 voltage register supplying MPU, without any driver setting things
  up,
 GPIO gets reset and obviously voltage value switches to an
  voltage
 where
 device does not function.

 Solution I am working on to solve this is [1]: snippet is part of
  a
 patch that I am working on atm.

 This is the right way to do it IMHO. Will allow the driver to
  exist
 when
 HWMOD will be eventually replaced by some other framework.


 [1]: http://pastebin.com/XPmAB1Zb


   
Both seems to be different to me. What we need is to
Avoid reset of whole GPIO bank during kernel boot.
  Yes - that is what the above does - as long as the GPIO is requested
  and
  set to the right level by the relevant driver, it is not unused and
  hence not reset at late_init.
  
 
 May be I am missing something here,
 
 Isn't _setup_reset() function asserts ocp_reset? And it is core_initcall.
Hmm.. You are right, I missed that :(
 
  I am a little unclear as to why this needs to have anything to do with
  the precise under-lying mechanism (hwmod or something else). May be
  both seem to be different to me needs a little further elaboration?
  
 
 GPIO is connected to the DDR VTT control pin, and we have observed that
 Due to GPIO bank reset as part of hwmod init during bootup.
 
  Is this because there is no need for an EMIF driver to handle DDR? and
  reset of the GPIO will occur as EMIF is configured at bootloader and
  there is no need to do that in kernel, correspondingly there is no
  driver to hold the gpio?
   
Ideally, it would have been much better if drivers starts handling
Idle, ocp reset and standby on their own (killing dependency on
  hwmod
init layer).
   
But looking at current state,
I agree we need to use DT property here, so how about
Adding DT property  to GPIO node itself. But we have to parse
  I believe you mean at OMAP specific  DT property for hwmod?
  something like ti,hwmod-no-init-reset?
 
 That’s the idea.
 
It early during hwmod init stage. We should read all DT nodes
Inside function __setup() function, that way can get rid of
HWMOD_INIT_NO_RESET flag completely. Also, this will handle
Both ocp_reset and domain reset.
   
  
   Forgot to mention,
  
   Since this is kernel boot failure issue, I think,
   By the time we reach to conclusion, another approach is to
   set HWMOD_INIT_NO_RESET flag For GPIO0 bank.
  a) if the GPIO gets moved over to some other GPIO bank on another
  platform,
  this wont work
 
 Yes that’s true, but such schematic interface is not recommended.
 And we have not seen any known side-effect of not resetting GPIO0 bank.
unless you mark the GPIO as taken, another driver could in-adverantly
take over the GPIO and set it to a wrong level (we had a similar story
with LED gpio between Panda Vs Panda-ES).

 
  b) for platforms that dont use gpio to hold DDR power, maybe this is
  not
  even relevant and the GPIO bank can safely be reset?
  
 
 As I mentioned, there is no known side-effect of not resetting GPIO bank 0.
It should depend on the platform.

There are other uses for hwmod-no-reset - Eg. boot logo displayed by
bootloader - if there is a reset of DSS block and re-configuration, we'd
notice a blank-out, which is not desirable either. There could be a few
other usage based on no-reset.

In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they
attempt ther'd at least be some form of warning.

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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: reset handling in am335x hwmod data

-Original Message-
From: Menon, Nishanth
Sent: Monday, May 20, 2013 11:34 PM
To: Hiremath, Vaibhav
Cc: Peter Korsgaard; Kevin Hilman; Balbi, Felipe; Paul Walmsley; linux-
o...@vger.kernel.org; Tony Lindgren
Subject: Re: reset handling in am335x hwmod data

On 12:47-20130520, Hiremath, Vaibhav wrote:
[...]

On 20:10-20130517, Peter Korsgaard wrote:
Kevin == Kevin Hilman khil...@linaro.org writes:

In this case, we cannot reset that bank, otherwise
Starter
Kit
will
never boot in mainline. Bad PCB design, I know, but
it's
not
something
we can change now :-)

Kevin FWIW, we've seen this before (GPIO connected to
PMIC
reset
is
a
Kevin fun one), and this is why we have
omap_hwmod_no_setup_reset().

Yes, but there's no dts bindings for this, and from a quick
test
the
reset handling happens before the device tree is probed.
I have the same issue with TPS62361 on Palmas - GPIO
controls
the
voltage register supplying MPU, without any driver setting
things
up,
GPIO gets reset and obviously voltage value switches to an
voltage
where
device does not function.

Solution I am working on to solve this is [1]: snippet is
part of
a
patch that I am working on atm.

This is the right way to do it IMHO. Will allow the driver to
exist
when
HWMOD will be eventually replaced by some other framework.

[1]: http://pastebin.com/XPmAB1Zb

Both seems to be different to me. What we need is to
Avoid reset of whole GPIO bank during kernel boot.
Yes - that is what the above does - as long as the GPIO is
requested
and
set to the right level by the relevant driver, it is not unused
and
hence not reset at late_init.

May be I am missing something here,

Isn't _setup_reset() function asserts ocp_reset? And it is
core_initcall.
Hmm.. You are right, I missed that :(

I am a little unclear as to why this needs to have anything to do
with
the precise under-lying mechanism (hwmod or something else). May be
both seem to be different to me needs a little further
elaboration?

GPIO is connected to the DDR VTT control pin, and we have observed
that
Due to GPIO bank reset as part of hwmod init during bootup.

Is this because there is no need for an EMIF driver to handle DDR?
and
reset of the GPIO will occur as EMIF is configured at bootloader
and
there is no need to do that in kernel, correspondingly there is no
driver to hold the gpio?

Ideally, it would have been much better if drivers starts
handling
Idle, ocp reset and standby on their own (killing dependency on
hwmod
init layer).

But looking at current state,
I agree we need to use DT property here, so how about
Adding DT property to GPIO node itself. But we have to parse
I believe you mean at OMAP specific DT property for hwmod?
something like ti,hwmod-no-init-reset?

That’s the idea.

It early during hwmod init stage. We should read all DT nodes
Inside function __setup() function, that way can get rid of
HWMOD_INIT_NO_RESET flag completely. Also, this will handle
Both ocp_reset and domain reset.

Forgot to mention,

Since this is kernel boot failure issue, I think,
By the time we reach to conclusion, another approach is to
set HWMOD_INIT_NO_RESET flag For GPIO0 bank.
a) if the GPIO gets moved over to some other GPIO bank on another
platform,
this wont work

Yes that’s true, but such schematic interface is not recommended.
And we have not seen any known side-effect of not resetting GPIO0
bank.
unless you mark the GPIO as taken, another driver could in-adverantly
take over the GPIO and set it to a wrong level (we had a similar story
with LED gpio between Panda Vs Panda-ES).

b) for platforms that dont use gpio to hold DDR power, maybe this
is
not
even relevant and the GPIO bank can safely be reset?

As I mentioned, there is no known side-effect of not resetting GPIO
bank 0.
It should depend on the platform.

There are other uses for hwmod-no-reset - Eg. boot logo displayed by
bootloader - if there is a reset of DSS block and re-configuration,
we'd
notice a blank-out, which is not desirable either. There could be a few
other usage based on no-reset.

In all cases, you'd prefer to make this:
a) platform dependent (board dts)
b) reserve GPIO as well so that no other driver'd take it - if they
attempt ther'd at least be some form of warning.

Completely agree with you on both the points, and my point and all my comments
Were more related to option 'a' above.

Thanks,
Vaibhav
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Re: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.

* Andreas Fenkart andreas.fenk...@streamunlimited.com [130515 01:51]:
 Without functional clock the omap_hsmmc module can't forward SDIO IRQs to
 the system. This patch reconfigures dat1 line as a gpio while the fclk is
 off. When the fclk is present it uses the standard SDIO IRQ detection of
 the module.
 
 The gpio irq is managed via the 'disable_depth' ref counter of the irq
 subsystem, this driver simply calls enable_irq/disable_irq when needed.
 
   sdio irqsdio irq
   unmasked masked
-
 runtime default  |1 |   2
 runtime suspend  |0 |   1
 
   irq disable depth
 
 
 only when sdio irq is enabled AND the module is idle, the reference
 count drops to zero and the gpio irq is effectively armed.
 
 Patch was tested on AM335x/Stream800. Test setup was two modules
 with sdio wifi cards. Modules where connected to a dual-band AP, each
 module using a different band. One of module was running iperf as server
 the other as client connecting to the server in a while true loop. Test
 was running for 4+ weeks. There were about 60 Mio. suspend/resume
 transitions. Test was shut down regularly.

Looks like this somehow breaks detecting of eMMC on mmc2 for me at least
with the non-dt legacyboot. For a removable mmc1 still keeps working.

For mmc2 I have .nonremovable = true and no gpio_cd or gpio_wp.

Also few comments below.
 
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 + host-pinctrl = devm_pinctrl_get(pdev-dev);
 + if (IS_ERR(host-pinctrl)) {
 + ret = PTR_ERR(host-pinctrl);
 + goto err_pinctrl;
 + }
 +
 + host-active = pinctrl_lookup_state(host-pinctrl,
 + PINCTRL_STATE_DEFAULT);
 + if (IS_ERR(host-active)) {
 + dev_warn(mmc_dev(host-mmc), Unable to lookup active 
 pinmux\n);
 + ret = PTR_ERR(host-active);
 + goto err_pinctrl_state;
 + }

This should be checked, we have systems with all muxing done statically
in the bootloader. And we also have systems that provide the default
pinctrl state only as they don't need remuxing. So at most a warning should
be printed.

  static int omap_hsmmc_runtime_resume(struct device *dev)
  {
   struct omap_hsmmc_host *host;
 + unsigned long flags;
 + int ret = 0;
  
   host = platform_get_drvdata(to_platform_device(dev));
   omap_hsmmc_context_restore(host);
   dev_dbg(dev, enabled\n);
  
 - return 0;
 + if (mmc_slot(host).sdio_irq  host-pinctrl) {
 + disable_irq(mmc_slot(host).sdio_irq);
 +
 + ret = pinctrl_select_state(host-pinctrl, host-active);
 + if (ret  0) {
 + dev_warn(mmc_dev(host-mmc), Unable to select active 
 pinmux\n);
 + return ret;
 + }
 +
 + spin_lock_irqsave(host-irq_lock, flags);
 + host-active_pinmux = true;
 +
 + if (host-sdio_irq_en) {
 + OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
 + OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
 + OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
 + }
 + spin_unlock_irqrestore(host-irq_lock, flags);
 + }
 + return ret;
  }

The check for sdio_irq  host-pinctrl looks broken too as we may
have not dynamic muxing via pinctrl needed for let's say omap3 based
systems.

Other than that, looks good to me.

Regards,

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

Re: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703

* Yegor Yefremov yegorsli...@googlemail.com [130517 14:34]:
 On Fri, May 17, 2013 at 8:56 PM, Mark A. Greer mgr...@animalcreek.com wrote:
  On Thu, May 16, 2013 at 12:19:20PM +0200, Yegor Yefremov wrote:
  On 15.05.2013 23:50, Mark A. Greer wrote:
   On Wed, May 15, 2013 at 10:07:35AM -0700, Tony Lindgren wrote:
 
   Mark, do you have some omap3 with no iva (other than am3703) to test the
   idle states with?
  
   I have an am35xx which isn't supposed to have an IVA so I can test with 
   it
   (although, I'm not sure how well the kernel works on the am35xx these 
   days).
  
   I'm a bit busy today but I'll try booting the am35xx tomorrow and if it
   comes up, see what I can figure out.
 
  I think this issue is relevant to am3517 as you can see from this thread: 
  http://thread.gmane.org/gmane.linux.ports.arm.omap/97903
  I could boot only with your patch 
  http://www.spinics.net/lists/arm-kernel/msg168865.html
 
  I have such a system running, so if you have any other patches/ideas to 
  test, I would do it.
 
  Yegor, since I've so far been unable to get my am3517evm to fire up, can
  you play around with the 3517 to see if there appears to be iva registers
  that can be read/written to safely?  In particular, can the code that idles
  the iva be run safely on an am3517?
 
 I'll look into this next week. am3517 and IVA seems to be a really big
 mystery. In the TI forum will be stated, there is no IVA:
 http://e2e.ti.com/support/arm/sitara_arm/f/791/t/150961.aspx, but TRM
 has various appearances of IVA2 registers, but no real
 description/explanation of what is IVA and how to eat it.

On 3703 it looks like the whole omap3_iva_idle() reset is needed, except
for setting the iva2 bootmode to idle. So I'm planning to merge the following
patch with just comments update this week unless somebody has a better fix
in mind.

Regards,

Tony


From: Tony Lindgren t...@atomide.com
Date: Tue, 14 May 2013 20:28:15 -0700
Subject: [PATCH] ARM: OMAP3: Fix iva2_pwrdm settings for 3703

Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on omaps that don't have
them. Turns out we still need to idle iva2 as otherwise
iva2_pwrdm will stay on and block deeper idle states.

It seems that the only part of the reset that may not be needed
is the setting of the iva2 boot mode to idle. But as that register
seems to be there and is harmless if no iva2 is on the SoC, it's
probably safest to do the complete reset.

Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -546,8 +546,10 @@ static void __init prcm_setup_regs(void)
/* Clear any pending PRCM interrupts */
omap2_prm_write_mod_reg(0, OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
 
-   if (omap3_has_iva())
-   omap3_iva_idle();
+   /*
+* We need to idle iva2_pwrdm even on am3703 with no iva2.
+*/
+   omap3_iva_idle();
 
omap3_d2d_idle();
 }
--
To unsubscribe from this list: send the line unsubscribe 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 01/19] drivers/usb/musb: add missing platform_driver owner

2013-05-20 Thread Libo Chen

set the owner of platform_driver, to ensure that the
caller of driver holds a module refernece

Signed-off-by: Libo Chen libo.c...@huawei.com
---
 drivers/usb/musb/am35x.c|1 +
 drivers/usb/musb/blackfin.c |1 +
 drivers/usb/musb/da8xx.c|1 +
 drivers/usb/musb/davinci.c  |1 +
 drivers/usb/musb/omap2430.c |1 +
 drivers/usb/musb/tusb6010.c |1 +
 drivers/usb/musb/ux500.c|1 +
 7 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 2231850..1efe7c6 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -631,6 +631,7 @@ static struct platform_driver am35x_driver = {
.remove = am35x_remove,
.driver = {
.name   = musb-am35x,
+   .owner  = THIS_MODULE,
.pm = DEV_PM_OPS,
},
 };
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 5e63b16..483f388 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -563,6 +563,7 @@ static struct platform_driver bfin_driver = {
.remove = __exit_p(bfin_remove),
.driver = {
.name   = musb-blackfin,
+   .owner  = THIS_MODULE,
.pm = DEV_PM_OPS,
},
 };
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b903b74..d38f41c 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -575,6 +575,7 @@ static struct platform_driver da8xx_driver = {
.remove = da8xx_remove,
.driver = {
.name   = musb-da8xx,
+   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index bea6cc3..acac555 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -607,6 +607,7 @@ static struct platform_driver davinci_driver = {
.remove = davinci_remove,
.driver = {
.name   = musb-davinci,
+   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3551f1a..2538fc7 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -668,6 +668,7 @@ static struct platform_driver omap2430_driver = {
.remove = omap2430_remove,
.driver = {
.name   = musb-omap2430,
+   .owner  = THIS_MODULE,
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(omap2430_id_table),
},
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 7369ba3..96696dc 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1231,6 +1231,7 @@ static struct platform_driver tusb_driver = {
.remove = tusb_remove,
.driver = {
.name   = musb-tusb,
+   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/usb/musb/ux500.c b/drivers/usb/musb/ux500.c
index 2c80004..aaae79e 100644
--- a/drivers/usb/musb/ux500.c
+++ b/drivers/usb/musb/ux500.c
@@ -325,6 +325,7 @@ static struct platform_driver ux500_driver = {
.remove = ux500_remove,
.driver = {
.name   = musb-ux500,
+   .owner  = THIS_MODULE,
.pm = DEV_PM_OPS,
},
 };
-- 
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 04/19] drivers/usb/dwc3: add missing platform_driver owner

2013-05-20 Thread Libo Chen

set the owner of platform_driver, to ensure that the
caller of driver holds a module refernece

Signed-off-by: Libo Chen libo.c...@huawei.com
---
 drivers/usb/dwc3/core.c|1 +
 drivers/usb/dwc3/dwc3-exynos.c |1 +
 drivers/usb/dwc3/dwc3-omap.c   |1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..570c2df 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -766,6 +766,7 @@ static struct platform_driver dwc3_driver = {
.remove = dwc3_remove,
.driver = {
.name   = dwc3,
+   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(of_dwc3_match),
.pm = DWC3_PM_OPS,
},
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index a8afe6e..831aa81 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -219,6 +219,7 @@ static struct platform_driver dwc3_exynos_driver = {
.remove = dwc3_exynos_remove,
.driver = {
.name   = exynos-dwc3,
+   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(exynos_dwc3_match),
.pm = DEV_PM_OPS,
},
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34638b9..3aaf87f 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -468,6 +468,7 @@ static struct platform_driver dwc3_omap_driver = {
.remove = dwc3_omap_remove,
.driver = {
.name   = omap-dwc3,
+   .owner  = THIS_MODULE,
.of_match_table = of_dwc3_match,
.pm = DEV_PM_OPS,
},
-- 
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 02/19] drivers/usb/host: add missing platform_driver owner

2013-05-20 Thread Libo Chen

set the owner of platform_driver, to ensure that the
caller of driver holds a module refernece

Signed-off-by: Libo Chen libo.c...@huawei.com
---
 drivers/usb/host/ehci-atmel.c   |1 +
 drivers/usb/host/ehci-msm.c |1 +
 drivers/usb/host/ehci-mv.c  |1 +
 drivers/usb/host/ehci-mxc.c |1 +
 drivers/usb/host/ehci-omap.c|1 +
 drivers/usb/host/ehci-spear.c   |1 +
 drivers/usb/host/isp1760-if.c   |1 +
 drivers/usb/host/oxu210hp-hcd.c |1 +
 drivers/usb/host/xhci-plat.c|1 +
 9 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 6642009..4fbb59b 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -182,6 +182,7 @@ static struct platform_driver ehci_atmel_driver = {
.shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name   = atmel-ehci,
+   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(atmel_ehci_dt_ids),
},
 };
diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
index 0f717dc..03e94d7 100644
--- a/drivers/usb/host/ehci-msm.c
+++ b/drivers/usb/host/ehci-msm.c
@@ -191,6 +191,7 @@ static struct platform_driver ehci_msm_driver = {
.remove = ehci_msm_remove,
.driver = {
   .name = msm_hsusb_host,
+  .owner = THIS_MODULE,
   .pm = ehci_msm_dev_pm_ops,
},
 };
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index 4020629..ba12653 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -335,6 +335,7 @@ static struct platform_driver ehci_mv_driver = {
.shutdown = mv_ehci_shutdown,
.driver = {
   .name = mv-ehci,
+  .owner = THIS_MODULE,
   .bus = platform_bus_type,
   },
.id_table = ehci_id_table,
diff --git a/drivers/usb/host/ehci-mxc.c b/drivers/usb/host/ehci-mxc.c
index c369767..e9c9651 100644
--- a/drivers/usb/host/ehci-mxc.c
+++ b/drivers/usb/host/ehci-mxc.c
@@ -214,6 +214,7 @@ static struct platform_driver ehci_mxc_driver = {
.shutdown = ehci_mxc_drv_shutdown,
.driver = {
   .name = mxc-ehci,
+  .owner   = THIS_MODULE,
},
 };
 
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 3d1491b..f630e62 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -294,6 +294,7 @@ static struct platform_driver ehci_hcd_omap_driver = {
/*.resume   = ehci_hcd_omap_resume, */
.driver = {
.name   = hcd_name,
+   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(omap_ehci_dt_ids),
}
 };
diff --git a/drivers/usb/host/ehci-spear.c b/drivers/usb/host/ehci-spear.c
index 61ecfb3..2df73be 100644
--- a/drivers/usb/host/ehci-spear.c
+++ b/drivers/usb/host/ehci-spear.c
@@ -172,6 +172,7 @@ static struct platform_driver spear_ehci_hcd_driver = {
.shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name = spear-ehci,
+   .owner  = THIS_MODULE,
.bus = platform_bus_type,
.pm = ehci_spear_pm_ops,
.of_match_table = of_match_ptr(spear_ehci_id_table),
diff --git a/drivers/usb/host/isp1760-if.c b/drivers/usb/host/isp1760-if.c
index bbb791b..9c572da 100644
--- a/drivers/usb/host/isp1760-if.c
+++ b/drivers/usb/host/isp1760-if.c
@@ -435,6 +435,7 @@ static struct platform_driver isp1760_plat_driver = {
.remove = isp1760_plat_remove,
.driver = {
.name   = isp1760,
+   .owner  = THIS_MODULE,
},
 };
 
diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
index 4f0f033..c5e1d1f 100644
--- a/drivers/usb/host/oxu210hp-hcd.c
+++ b/drivers/usb/host/oxu210hp-hcd.c
@@ -3947,6 +3947,7 @@ static struct platform_driver oxu_driver = {
.resume = oxu_drv_resume,
.driver = {
.name = oxu210hp-hcd,
+   .owner  = THIS_MODULE,
.bus = platform_bus_type
}
 };
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..34a6067 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -190,6 +190,7 @@ static struct platform_driver usb_xhci_driver = {
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
+   .owner  = THIS_MODULE,
},
 };
 MODULE_ALIAS(platform:xhci-hcd);
-- 
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: [RESEND PATCH v2 1/3] mmc: omap_hsmmc: Enable SDIO IRQ using a GPIO in idle mode.