Re: [PATCH] Add missing modules aliases to get sound working on omap devices

[Peter Ujfalusi]

On 07/04/2012 12:16 PM, Guillaume Gardet wrote:
 This patch add missing modules aliases to get sound working on omap devices.
 
 Tested on Beagleboard xM rev. B.
 
 This patch is against 3.5-rc5 vanilla.
 
 Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
 
 add-missing-modules-aliases-to-fix-audio-on-omap-devices.patch

Can you send the patch generated by git format-patch?
Since this is sound related patch, please send it to alsa-devel.
Please also CC the maintainers for the patches to be sure they are reaching
the right audience.

 --- ./sound/soc/omap/omap-pcm.c.orig  2012-07-04 10:30:13.611641186 +0200
 +++ ./sound/soc/omap/omap-pcm.c   2012-07-04 10:30:38.894034111 +0200
 @@ -441,3 +441,4 @@ module_platform_driver(omap_pcm_driver);
  MODULE_AUTHOR(Jarkko Nikula jarkko.nik...@bitmer.com);
  MODULE_DESCRIPTION(OMAP PCM DMA module);
  MODULE_LICENSE(GPL);
 +MODULE_ALIAS(platform:omap-pcm-audio);
 --- ./sound/soc/omap/omap-mcbsp.c.orig2012-07-04 10:29:14.240066817 
 +0200
 +++ ./sound/soc/omap/omap-mcbsp.c 2012-07-04 12:03:28.020756978 +0200
 @@ -820,3 +820,4 @@ module_platform_driver(asoc_mcbsp_driver
  MODULE_AUTHOR(Jarkko Nikula jarkko.nik...@bitmer.com);
  MODULE_DESCRIPTION(OMAP I2S SoC Interface);
  MODULE_LICENSE(GPL);
 +MODULE_ALIAS(platform:omap-mcbsp-dai);

This should be:
+MODULE_ALIAS(platform:omap-mcbsp);


-- 
Péter


--
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 [120705 04:46]:

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

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

OK thanks!

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 00/10] Prepare for GPMC driver conversion (w.r.t MTD)

[Tony Lindgren]

* Mohammed, Afzal af...@ti.com [120703 05:10]:
 Hi Tony,
 
 On Mon, Jul 02, 2012 at 13:05:47, Tony Lindgren wrote:
  * Artem Bityutskiy artem.bityuts...@linux.intel.com [120627 02:36]:
   On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote:
 
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/
   
   Dunno if Tony picked this, but the MTD changes look good an the quick
   glance. Feel free to add
   
   Acked-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
  
  Thanks will add to the drivers/mtd touching patches in this series.
 
 Can you please consider this series for inclusion in the coming merge
 window. This series can live by itself and is not dependent on any
 other patches.

Yes I have some of the gpmc patches applied locally on top of the
dmaengine changes from Russell. Will update and push out once we have
an immutable commit for the dmaengine changes available.

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] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.

[Shilimkar, Santosh]

(+ linux-omap, linux-watchdog)

Vaibhav,

On Thu, Jul 5, 2012 at 8:06 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
 Hi,

 On Mon, Jun 18, 2012 at 10:53:16, Vutla, Lokesh wrote:
 OMAP watchdong driver is adapted to runtime PM like a general device
 driver but it is not appropriate. It is causing couple of functional
 issues.


 A few questions based on the description given in the commit message.

 1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module,
 which constantly stays in in transition state. Value of register
 CM_WKUP_WDTIMER2_CLKCTRL is always 0x0001 in this case.
 Issue occurs immediately after first idle, when hwmod framework tries
 to disable WDTIMER2 functional clock - wd_timer2_fck. After this
 module falls to in transition state, and SYSCLK gating is blocked.


 From what I know, a value of 0x0001 for timers (WDT or DMTIMERs)
 indicates that the iclk is gated but the fclk is running. In fact,
 if the IP supports swakeup mechanism this is the value expected in the
 *_CLKCTRL registers of the timers for the swakeup to work.

Nope. That case will be 0x0002

Read 0x1: Module is performing transition: wakeup, or
sleep, or sleep abortion
Read 0x2: Module is in idle mode (only INTRCONN part).
It is functional if using separate functional clock
Read 0x3: Module is disabled and cannot be accessed

 Sounds like on OMAP4 the WDT needs to be stopped first and then the
 PRCM idle request sent otherwise SYSCLK gating will be blocked.

Any module stuck in-transition will get the clock-domain from idle.

 2. Due to runtime PM, watchdog timer may be completely disabled.
 In current code base watchdog timer is not disabled only because of
 issue 1. Otherwise state of WDTIMER2 module will be Disabled, and there
 will be no interrupts from omap_wdt. In other words watchdog will not
 work at all.

 But the current driver doesn't make use of any interrupts, right?

How is the interrupt related. You enable that when you enable WDT
petting using delay_interrupt()

 If the WDT was never started, runtime PM handling for the WDT should be
 able to get the IP to a disabled state. Is the issue over here due
 to the WDT counter incrementing and still the PRCM idle request being
 sent for disabling it? If so, perhaps a better solution would be have
 a custom runtime PM handling for WDT which checks if the counter
 is incrementing or not. If it is not incrementing then it can just
 go ahead and disable the clocks. However, if the counter is incrementing
 then the runtime PM activities on the driver should be forbidden till
 an entry to a low power state where SYSCLK needs to be gated is required.

If you look at the test case mentioned, the watchdong is started. Your
first observation is not as per the hardware behavior, so other points
becomes not relevant.

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: [GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [120705 04:26]:

 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 ?

Hmm weird, I wonder how I managed to mess up the resolve like that..
I'll (re)apply the following fix as the branch has been pushed out already.

Regards,

Tony


Author: Tony Lindgren t...@atomide.com
Date:   Fri Jul 6 00:58:43 2012 -0700

ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API

Commit ac5b0ea3d (Merge tag 'omap-devel-f-for-3.6'...) had a merge
conflict that somehow got incorrecly resolved in a lossy way for
commit bed9d1bb (ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API).
Fix the issue by applying the missing pieces.

Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index ebdf001..ff76ef1 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3633,3 +3633,18 @@ void __init omap_hwmod_init(void)
 
inited = true;
 }
+
+/**
+ * omap_hwmod_get_main_clk - get pointer to main clock name
+ * @oh: struct omap_hwmod *
+ *
+ * Returns the main clock name assocated with @oh upon success,
+ * or NULL if @oh is NULL.
+ */
+const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh)
+{
+   if (!oh)
+   return NULL;
+
+   return oh-main_clk;
+}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 30f55eb..6132972 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -648,6 +648,8 @@ int omap_hwmod_pad_route_irq(struct omap_hwmod *oh, int 
pad_idx, int irq_idx);
 
 extern void __init omap_hwmod_init(void);
 
+const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
+
 /*
  * Chip variant-specific hwmod init routines - XXX should be converted
  * to use initcalls once the initial boot ordering is straightened out
--
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 REPOST 4/4] ARM: OMAP2+: dmtimer: cleanup fclk usage

[Tony Lindgren]

* Tarun Kanti DebBarma tarun.ka...@ti.com [120705 05:45]:
 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.

Thanks applying into cleanup-part2 branch.

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/2] arm/dts: Add AM33XX basic pinctrl support

[Tony Lindgren]

* AnilKumar Ch anilku...@ti.com [120705 02:18]:
 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;
 + };
 +

You might want to update to the latest version, which is now called
pinctrl-single instead of pinctrl-simple. Should be easy to update,
note that we're still waiting on people to comment on the binding,
so you might want to wait a bit before reposting so we have the
driver merged.

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: [GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 1:39 PM, Tony Lindgren t...@atomide.com wrote:
 * Shilimkar, Santosh santosh.shilim...@ti.com [120705 04:26]:

 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 ?

 Hmm weird, I wonder how I managed to mess up the resolve like that..
 I'll (re)apply the following fix as the branch has been pushed out already.

Sounds good to me. Can you update the barcnh please ?
I don't see that patch yet in cleanup-part2.

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] ARM: OMAP2: twl-common: fix compiler warnings

[Tony Lindgren]

* Tero Kristo t-kri...@ti.com [120628 03:54]:
 OMAP2 does not use the external voltage controller code for TWL, and
 thus OMAP2 only compilation generates following warnings:

Hmm well omap2420 does not have twl, but 2430 usually has. So do you
mean that 2430 does not use the external voltage controller code?

 arch/arm/mach-omap2/twl-common.c:51: warning: 'twl_set_voltage' defined but 
 not used
 arch/arm/mach-omap2/twl-common.c:57: warning: 'twl_get_voltage' defined but 
 not used
 
 This patch moves the code in question behind ARCH specific flags and
 eliminates these warnings.
...

 --- a/arch/arm/mach-omap2/twl-common.c
 +++ b/arch/arm/mach-omap2/twl-common.c
 @@ -48,6 +48,7 @@ static struct i2c_board_info __initdata 
 omap4_i2c1_board_info[] = {
   },
  };
  
 +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
  static int twl_set_voltage(void *data, int target_uV)
  {
   struct voltagedomain *voltdm = (struct voltagedomain *)data;
 @@ -59,6 +60,7 @@ static int twl_get_voltage(void *data)
   struct voltagedomain *voltdm = (struct voltagedomain *)data;
   return voltdm_get_voltage(voltdm);
  }
 +#endif

To avoid patching this piece of code for new SoCs, can we make it
ifndef CONFIG_ARCH_OMAP2? Also in the makefile we should not even
build twl-common.o for 2420 only builds..

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 2/2] ARM: OMAP: board-omap4panda: MUX configuration for sys_nirq2

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 2:19 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
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

[PATCH 2/2] ARM: OMAP: board-omap4panda: MUX configuration for sys_nirq2

[Peter Ujfalusi]

The sys_nirq2 is used for twl6040, make sure the pin is configured
correctly.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..6111b72 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -379,6 +379,9 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(DPM_EMU18, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
/* dispc2_data0 */
OMAP4_MUX(DPM_EMU19, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+   /* NIRQ2 for twl6040 */
+   OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE1 |
+ OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
-- 
1.7.8.6

--
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: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Peter Ujfalusi]

The sys_nirq2 is used for twl6040, make sure the pin is configured
correctly.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-omap2/board-4430sdp.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index c4e17641..050cc8e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -827,6 +827,9 @@ static void __init omap_4430sdp_display_init(void)
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+   /* NIRQ2 for twl6040 */
+   OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE1 |
+ OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
-- 
1.7.8.6

--
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 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 085e171..238c5a3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,6 +197,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..be3e059 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()  !soc_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 v2 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

[PATCH v2 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

Re: [PATCH 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Peter Ujfalusi]

On 07/06/2012 11:02 AM, Shilimkar, Santosh wrote:
 On Fri, Jul 6, 2012 at 2:19 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
 Should remove the boot-loader pin-muxing dependency.
 Was this the reason, Audio had some issues on OMAP4430
 SDP as reported by Russell ?

The boot loader never configured the sys_nirq2, I have sent a patch for u-boot
to do this, but it is said that the kernel should take care of this.

We did not had jack detection working with upstream u-boot, kernel (I have
patched u-boot so I have not seen this issue).
Now if the board is booted without HS connected, upon connecting the HS we
will recognize it and it should be all fine.
So yes this was the reason why Russell had issues with audio.

-- 
Péter


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

[Santosh Shilimkar]

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

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

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/control.h |4 
 arch/arm/mach-omap2/id.c  |   42 -
 arch/arm/plat-omap/include/plat/cpu.h |   22 +++--
 3 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index 295b390..b8cdc85 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -253,6 +253,10 @@
 /* TI81XX CONTROL_DEVCONF register offsets */
 #define TI81XX_CONTROL_DEVICE_ID   (TI81XX_CONTROL_DEVCONF + 0x000)
 
+/* OMAP54XX CONTROL STATUS register */
+#define OMAP5XXX_CONTROL_STATUS0x134
+#define OMAP5_DEVICETYPE_MASK  (0x7  6)
+
 /*
  * REVISIT: This list of registers is not comprehensive - there are more
  * that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37eb95a..40373db 100644
--- 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 (soc_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() || soc_is_omap54xx()) {
odi-id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi-id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi-id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -513,6 +518,41 @@ void __init omap4xxx_check_revision(void)
((omap_rev()  12)  0xf), ((omap_rev()  8)  0xf));
 }
 
+void __init omap5xxx_check_revision(void)
+{
+   u32 idcode;
+   u16 hawkeye;
+   u8 rev;
+
+   idcode = read_tap_reg(OMAP_TAP_IDCODE);
+   hawkeye = (idcode  12)  0x;
+   rev = (idcode  28)  0xff;
+   switch (hawkeye) {
+   case 0xb942:
+   switch (rev) {
+   case 0:
+   default:
+   omap_revision = OMAP5430_REV_ES1_0;
+   }
+   break;
+
+   case 0xb998:
+   switch (rev) {
+   case 0:
+   default:
+   omap_revision = OMAP5432_REV_ES1_0;
+   }
+   break;
+
+   default:
+   /* Unknown default to latest silicon rev as default*/
+   omap_revision = OMAP5430_REV_ES1_0;
+   }
+
+   pr_info(OMAP%04x ES%d.0\n,
+   omap_rev()  16, ((omap_rev()  12)  0xf));
+}
+
 /*
  * Set up things for map_io and processor detection later on. Gets called
  * pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/plat-omap/include/plat/cpu.h 
b/arch/arm/plat-omap/include/plat/cpu.h
index 14f050f..e2d911d 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -9,7 +9,7 @@
  *
  * Written by Tony Lindgren tony.lindg...@nokia.com
  *
- * Added OMAP4 specific defines - Santosh Shilimkarsantosh.shilim...@ti.com
+ * Added OMAP4/5 specific defines - Santosh Shilimkarsantosh.shilim...@ti.com
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -70,6 +70,7 @@ unsigned int omap_rev(void);
  * cpu_is_omap443x():  True for OMAP4430
  * cpu_is_omap446x():  True for OMAP4460
  * cpu_is_omap447x():  True for OMAP4470
+ * soc_is_omap543x():  True for OMAP5430, OMAP5432
  */
 #define GET_OMAP_CLASS (omap_rev()  0xff)
 
@@ -122,6 +123,7 @@ IS_OMAP_CLASS(24xx, 0x24)
 IS_OMAP_CLASS(34xx, 0x34)
 IS_OMAP_CLASS(44xx, 0x44)
 IS_AM_CLASS(35xx, 0x35)
+IS_OMAP_CLASS(54xx, 0x54)
 IS_AM_CLASS(33xx, 0x33)
 
 IS_TI_CLASS(81xx, 0x81)
@@ -133,6 +135,7 @@ IS_OMAP_SUBCLASS(363x, 0x363)
 IS_OMAP_SUBCLASS(443x, 0x443)
 IS_OMAP_SUBCLASS(446x, 0x446)
 IS_OMAP_SUBCLASS(447x, 0x447)
+IS_OMAP_SUBCLASS(543x, 0x543)
 
 IS_TI_SUBCLASS(816x, 0x816)
 IS_TI_SUBCLASS(814x, 0x814)
@@ -156,6 +159,8 @@ IS_AM_SUBCLASS(335x, 0x335)
 #define cpu_is_omap443x()  0
 #define cpu_is_omap446x()  0
 #define cpu_is_omap447x()  0
+#define soc_is_omap54xx()  0
+#define soc_is_omap543x()  0
 
 #if defined(MULTI_OMAP1)
 # if defined(CONFIG_ARCH_OMAP730)
@@ -291,6 +296,7 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define cpu_is_omap2430()  0
 

[PATCH v2 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 v2 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 97e8792..960f984 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -276,6 +276,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 v2 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 960f984..1f65b18 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -239,6 +239,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);
@@ -246,10 +248,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 v2 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 v2 08/14] ARM: OMAP5: Add the WakeupGen IP updates

[Santosh Shilimkar]

OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.

Patch updates the WakeupGen code accordingly.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/include/mach/omap-wakeupgen.h |7 ++
 arch/arm/mach-omap2/omap-hotplug.c|   24 -
 arch/arm/mach-omap2/omap-smp.c|   19 +++-
 arch/arm/mach-omap2/omap-wakeupgen.c  |  114 -
 arch/arm/mach-omap2/omap4-sar-layout.h|   12 ++-
 5 files changed, 143 insertions(+), 33 deletions(-)

diff --git a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h 
b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
index 548de90b..b0fd16f 100644
--- a/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
+++ b/arch/arm/mach-omap2/include/mach/omap-wakeupgen.h
@@ -11,15 +11,20 @@
 #ifndef OMAP_ARCH_WAKEUPGEN_H
 #define OMAP_ARCH_WAKEUPGEN_H
 
+/* OMAP4 and OMAP5 has same base address */
+#define OMAP_WKUPGEN_BASE  0x48281000
+
 #define OMAP_WKG_CONTROL_0 0x00
 #define OMAP_WKG_ENB_A_0   0x10
 #define OMAP_WKG_ENB_B_0   0x14
 #define OMAP_WKG_ENB_C_0   0x18
 #define OMAP_WKG_ENB_D_0   0x1c
+#define OMAP_WKG_ENB_E_0   0x20
 #define OMAP_WKG_ENB_A_1   0x410
 #define OMAP_WKG_ENB_B_1   0x414
 #define OMAP_WKG_ENB_C_1   0x418
 #define OMAP_WKG_ENB_D_1   0x41c
+#define OMAP_WKG_ENB_E_1   0x420
 #define OMAP_AUX_CORE_BOOT_0   0x800
 #define OMAP_AUX_CORE_BOOT_1   0x804
 #define OMAP_PTMSYNCREQ_MASK   0xc00
@@ -28,4 +33,6 @@
 #define OMAP_TIMESTAMPCYCLEHI  0xc0c
 
 extern int __init omap_wakeupgen_init(void);
+extern void __iomem *omap_get_wakeupgen_base(void);
+extern int omap_secure_apis_support(void);
 #endif
diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
b/arch/arm/mach-omap2/omap-hotplug.c
index 56c345b..414083b 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -17,8 +17,10 @@
 #include linux/kernel.h
 #include linux/errno.h
 #include linux/smp.h
+#include linux/io.h
 
 #include asm/cacheflush.h
+#include mach/omap-wakeupgen.h
 
 #include common.h
 
@@ -35,7 +37,8 @@ int platform_cpu_kill(unsigned int cpu)
  */
 void __ref platform_cpu_die(unsigned int cpu)
 {
-   unsigned int this_cpu;
+   unsigned int boot_cpu = 0;
+   void __iomem *base = omap_get_wakeupgen_base();
 
flush_cache_all();
dsb();
@@ -43,16 +46,27 @@ void __ref platform_cpu_die(unsigned int cpu)
/*
 * we're ready for shutdown now, so do it
 */
-   if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
-   pr_err(Secure clear status failed\n);
+   if (omap_secure_apis_support()) {
+   if (omap_modify_auxcoreboot0(0x0, 0x200) != 0x0)
+   pr_err(Secure clear status failed\n);
+   } else {
+   __raw_writel(0, base + OMAP_AUX_CORE_BOOT_0);
+   }
+
 
for (;;) {
/*
 * Enter into low power state
 */
omap4_hotplug_cpu(cpu, PWRDM_POWER_OFF);
-   this_cpu = smp_processor_id();
-   if (omap_read_auxcoreboot0() == this_cpu) {
+
+   if (omap_secure_apis_support())
+   boot_cpu = omap_read_auxcoreboot0();
+   else
+   boot_cpu =
+   __raw_readl(base + OMAP_AUX_CORE_BOOT_0)  5;
+
+   if (boot_cpu == smp_processor_id()) {
/*
 * OK, proper wakeup, we're done
 */
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index deffbf1..badfe39 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -26,6 +26,8 @@
 
 #include mach/hardware.h
 #include mach/omap-secure.h
+#include mach/omap-wakeupgen.h
+#include asm/cputype.h
 
 #include iomap.h
 #include common.h
@@ -73,6 +75,8 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 {
static struct clockdomain *cpu1_clkdm;
static bool booted;
+   void __iomem *base = omap_get_wakeupgen_base();
+
/*
 * Set synchronisation state between this boot processor
 * and the secondary one
@@ -85,7 +89,11 @@ int __cpuinit boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 * the AuxCoreBoot1 register is updated with cpu state
 * A barrier is added to ensure that 

[PATCH v2 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 399e5bb..97e8792 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 2b318ec..13d20c8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -393,6 +393,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 v2 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..b2b5759 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() || soc_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 v2 00/14] ARM: OMAP5: Add minimal OMAP5 SOC support

[Santosh Shilimkar]

Tony,

Here is the updated series with suggested corrections and generated against
the latest cleanup-part2 at commit ae6df418. 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.

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.

I observed one build break for OMAP4 only build on cleanup-part2 at
commit ae6df418. Will post a fix for it in a separate patch.

The following changes since commit ae6df418a21f3a361c5f9b878e32a8aba4e17692:

  ARM: OMAP2+: dmtimer: cleanup fclk usage (2012-07-06 01:13:52 -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 37f25749505963d0dce52dfacd6b085de2a8dbeb:

  ARM: Kconfig update to support additional GPIOs in OMAP5 (2012-07-06 14:18:35 
+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|8 +-
 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/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 +-
 43 files changed, 775 insertions(+), 98 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

[PATCH v2 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  |8 +++-
 arch/arm/plat-omap/Kconfig   |4 ++--
 3 files changed, 10 insertions(+), 3 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 6c93477..90d0f85 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -9,7 +9,7 @@ config ARCH_OMAP2PLUS_TYPICAL
select REGULATOR
select PM_RUNTIME
select VFP
-   select NEON if ARCH_OMAP3 || ARCH_OMAP4
+   select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
select SERIAL_OMAP
select SERIAL_OMAP_CONSOLE
select I2C
@@ -61,6 +61,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

Re: [PATCH 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Shilimkar, Santosh]

+ Russell

On Fri, Jul 6, 2012 at 2:52 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 On 07/06/2012 11:02 AM, Shilimkar, Santosh wrote:
 On Fri, Jul 6, 2012 at 2:19 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
 Should remove the boot-loader pin-muxing dependency.
 Was this the reason, Audio had some issues on OMAP4430
 SDP as reported by Russell ?

 The boot loader never configured the sys_nirq2, I have sent a patch for u-boot
 to do this, but it is said that the kernel should take care of this.

 We did not had jack detection working with upstream u-boot, kernel (I have
 patched u-boot so I have not seen this issue).
 Now if the board is booted without HS connected, upon connecting the HS we
 will recognize it and it should be all fine.
 So yes this was the reason why Russell had issues with audio.

Thanks Peter for tracking it down.

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

[cleanup-part2 PATCH] ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds.

[Santosh Shilimkar]

OMAP4 only build breaks with below error

arch/arm/mach-omap2/sdrc.c:135: error: redefinition of 'omap2_sdrc_init'
arch/arm/plat-omap/include/plat/sdrc.h:130: note: previous definition of 
'omap2_sdrc_init' was here
make[1]: *** [arch/arm/mach-omap2/sdrc.o] Error 1

Fix the same by using newly introduced CONFIG_SOC_HAS_OMAP2_SDRC marco.

Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/plat-omap/include/plat/sdrc.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/plat-omap/include/plat/sdrc.h 
b/arch/arm/plat-omap/include/plat/sdrc.h
index 9bb978e..36d6a76 100644
--- a/arch/arm/plat-omap/include/plat/sdrc.h
+++ b/arch/arm/plat-omap/include/plat/sdrc.h
@@ -123,7 +123,7 @@ struct omap_sdrc_params {
u32 mr;
 };
 
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
+#ifdef CONFIG_SOC_HAS_OMAP2_SDRC
 void omap2_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
 #else
-- 
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: [GIT PULL] ARM: OMAP2+: miscellaneous PRCM hwmod patches for 3.6

[Tony Lindgren]

* Shilimkar, Santosh santosh.shilim...@ti.com [120706 01:32]:
 On Fri, Jul 6, 2012 at 1:39 PM, Tony Lindgren t...@atomide.com wrote:
  * Shilimkar, Santosh santosh.shilim...@ti.com [120705 04:26]:
 
  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 ?
 
  Hmm weird, I wonder how I managed to mess up the resolve like that..
  I'll (re)apply the following fix as the branch has been pushed out already.
 
 Sounds good to me. Can you update the barcnh please ?
 I don't see that patch yet in cleanup-part2.

Pushed out now at commit ae6df418 (ARM: OMAP2+: dmtimer: cleanup fclk usage)
also applied. Might take a while for it to get mirrored.

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 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set

[Tony Lindgren]

* Zumeng Chen zumeng.c...@windriver.com [120620 02:19]:
 Since it's no more sense to set parent for dummy clock,
 so we can just ignore it to mute failed message.

This is something Paul should look at.

Regards,

Tony
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 Signed-off-by: Zumeng Chen zumeng.c...@gmail.com
 ---
  arch/arm/plat-omap/clock.c  |4 
  drivers/mfd/omap-usb-host.c |2 +-
  2 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
 index 62ec5c4..c7e26e4 100644
 --- a/arch/arm/plat-omap/clock.c
 +++ b/arch/arm/plat-omap/clock.c
 @@ -149,6 +149,10 @@ int clk_set_parent(struct clk *clk, struct clk *parent)
   if (!arch_clock || !arch_clock-clk_set_parent)
   return ret;
  
 + /* If the clock is a dummy clock just return */
 + if (clk == dummy_ck)
 + return 0;
 +
   spin_lock_irqsave(clockfw_lock, flags);
   if (clk-usecount == 0) {
   ret = arch_clock-clk_set_parent(clk, parent);
 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 7e96bb2..c9d27c4 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -699,7 +699,7 @@ static int __devinit usbhs_omap_probe(struct 
 platform_device *pdev)
   }
  
   if (is_ehci_phy_mode(pdata-port_mode[0])) {
 - /* for OMAP3 , the clk set paretn fails */
 + /* for OMAP3 , the clk set parent fails */
   ret = clk_set_parent(omap-utmi_p1_fck,
   omap-xclk60mhsp1_ck);
   if (ret != 0)
 -- 
 1.7.5.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 3/3] watchdog: omap_wdt: add device tree support

[Tony Lindgren]

Hi Wim,

* jgq...@gmail.com jgq...@gmail.com [120531 20:56]:
 From: Xiao Jiang jgq...@gmail.com
 
 Add device table for omap_wdt to support dt.

Care to ack this patch in the series?

Regards,

Tony

 
 Signed-off-by: Xiao Jiang jgq...@gmail.com
 ---
  drivers/watchdog/omap_wdt.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
 index 8285d65..02ebfd5 100644
 --- a/drivers/watchdog/omap_wdt.c
 +++ b/drivers/watchdog/omap_wdt.c
 @@ -430,6 +430,12 @@ static int omap_wdt_resume(struct platform_device *pdev)
  #define  omap_wdt_resume NULL
  #endif
  
 +static const struct of_device_id omap_wdt_of_match[] = {
 + { .compatible = ti,omap3-wdt, },
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, omap_wdt_of_match);
 +
  static struct platform_driver omap_wdt_driver = {
   .probe  = omap_wdt_probe,
   .remove = __devexit_p(omap_wdt_remove),
 @@ -439,6 +445,7 @@ static struct platform_driver omap_wdt_driver = {
   .driver = {
   .owner  = THIS_MODULE,
   .name   = omap_wdt,
 + .of_match_table = omap_wdt_of_match,
   },
  };
  
 -- 
 1.7.3
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver

[Tony Lindgren]

* Sergei Shtylyov sshtyl...@mvista.com [120620 05:10]:
 On 20-06-2012 13:14, Zumeng Chen wrote:
 
 This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.
...

 +/* Enable VBUS switch by setting TWL4030.GPIO2DIR as output
 + * for starting USB tranceiver
 + */
 +if (get_omap3_evm_rev()= OMAP3EVM_BOARD_GEN_2) {
 +u8 val;
 
Empty line after declaration block wouldn't hurt...
 

I'll apply these into devel-board branch with the extra line
added. Not taking the clock related patch 4/5 as that's something
Paul should queue.

Also note that the board-*.c files are being phased out with
devicetree support.

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

[Tony Lindgren]

Hi,

* AnilKumar, Chimata anilku...@ti.com [120705 01:21]:
 
 I realized that for mcspi and mmc, the compatible name supposed tobe close to
 omap4-mcspi. 
 These changes seems to went from my local branch, so could you please merge 
 below patch with this
 5fc0b42a98556bd9f01cecc6a64fcbd15ec363f0 arm/dts: Add initial DT
 support for AM33XX SoC family

I don't quite follow, do you mean you want to change some compatible names?
Your patch is just removing entries though?

Anyways, please just send a fix with a proper description and Signed-off-by
on top of the devel-dt branch.

Regards,

Tony 
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index 1e7b98f..258b10e 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -166,36 +166,5 @@
 #size-cells = 0;
 ti,hwmods = i2c3;
 };
 -
 -   mcspi1: spi@4803 {
 -   compatible = ti,omap2-mcspi;
 -   #address-cells = 1;
 -   #size-cells = 0;
 -   ti,hwmods = spi0;
 -   ti,spi-num-cs = 4;
 -   };
 -
 -   mcspi2: spi@481Aa000 {
 -   compatible = ti,omap2-mcspi;
 -   #address-cells = 1;
 -   #size-cells = 0;
 -   ti,hwmods = spi1;
 -   ti,spi-num-cs = 2;
 -   };
 -
 -   mmc1: mmc@4806 {
 -   compatible = ti,omap3-hsmmc;
 -   ti,hwmods = mmc1;
 -   };
 -
 -   mmc2: mmc@481D8000 {
 -   compatible = ti,omap3-hsmmc;
 -   ti,hwmods = mmc2;
 -   };
 -
 -   mmc3: mmc@4781 {
 -   compatible = ti,omap3-hsmmc;
 -   ti,hwmods = mmc3;
 -   };
 };
  };
 --
 
 Thanks
 AnilKumar
--
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]

On Fri, Jul 6, 2012 at 2:00 PM, Tony Lindgren t...@atomide.com wrote:
 * Shilimkar, Santosh santosh.shilim...@ti.com [120706 01:32]:
 On Fri, Jul 6, 2012 at 1:39 PM, Tony Lindgren t...@atomide.com wrote:
  * Shilimkar, Santosh santosh.shilim...@ti.com [120705 04:26]:
 
  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 ?
 
  Hmm weird, I wonder how I managed to mess up the resolve like that..
  I'll (re)apply the following fix as the branch has been pushed out already.
 
 Sounds good to me. Can you update the barcnh please ?
 I don't see that patch yet in cleanup-part2.

 Pushed out now at commit ae6df418 (ARM: OMAP2+: dmtimer: cleanup fclk usage)
 also applied. Might take a while for it to get mirrored.

Great. Thanks !!

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 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 2:19 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
Should remove the boot-loader pin-muxing dependency.
Was this the reason, Audio had some issues on OMAP4430
SDP as reported by Russell ?

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

[PATCH 1/1] ARM: add PROC_DEVICETREE support in Kconfig

[jgq516]

From: Xiao Jiang jgq...@gmail.com

Since more and more arm chips support device tree, it'd be better add 
PROC_DEVICETREE
in arch/arm/Kconfig to avoid duplicate code.

Signed-off-by: Xiao Jiang jgq...@gmail.com
---
 arch/arm/Kconfig   |1 +
 arch/arm/configs/at91_dt_defconfig |1 -
 arch/arm/configs/tegra_defconfig   |1 -
 arch/arm/plat-omap/Kconfig |1 -
 4 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..f68896e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1864,6 +1864,7 @@ config USE_OF
select OF
select OF_EARLY_FLATTREE
select IRQ_DOMAIN
+   select PROC_DEVICETREE if PROC_FS
help
  Include support for flattened device tree machine descriptions.
 
diff --git a/arch/arm/configs/at91_dt_defconfig 
b/arch/arm/configs/at91_dt_defconfig
index 67bc571..b856cb6 100644
--- a/arch/arm/configs/at91_dt_defconfig
+++ b/arch/arm/configs/at91_dt_defconfig
@@ -64,7 +64,6 @@ CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ATMEL=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_GLUEBI=y
-CONFIG_PROC_DEVICETREE=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_COUNT=4
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 1198dd6..43e7b65 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -72,7 +72,6 @@ CONFIG_IPV6_TUNNEL=y
 CONFIG_IPV6_MULTIPLE_TABLES=y
 # CONFIG_WIRELESS is not set
 # CONFIG_FIRMWARE_IN_KERNEL is not set
-CONFIG_PROC_DEVICETREE=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_AD525X_DPOT=y
 CONFIG_AD525X_DPOT_I2C=y
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..4e2cb17 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -27,7 +27,6 @@ config ARCH_OMAP2PLUS
select GENERIC_IRQ_CHIP
select OMAP_DM_TIMER
select USE_OF
-   select PROC_DEVICETREE if PROC_FS
help
  Systems based on OMAP2, OMAP3 or OMAP4
 
-- 
1.7.3

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

[Munegowda, Keshava]

On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 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.

Thanks Samuel

I will send the patches today.

regards
keshava
--
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: twl-common: fix compiler warnings

[Tero Kristo]

On Fri, 2012-07-06 at 01:53 -0700, Tony Lindgren wrote:
 * Tero Kristo t-kri...@ti.com [120628 03:54]:
  OMAP2 does not use the external voltage controller code for TWL, and
  thus OMAP2 only compilation generates following warnings:
 
 Hmm well omap2420 does not have twl, but 2430 usually has. So do you
 mean that 2430 does not use the external voltage controller code?

Well, at least currently the external controller code is not used on any
omap2xxx chip. I guess it might be possible to extend the support for
omap2 also, but I don't know who can do that (personally I have no
access to omap2 hw.)

 
  arch/arm/mach-omap2/twl-common.c:51: warning: 'twl_set_voltage' defined but 
  not used
  arch/arm/mach-omap2/twl-common.c:57: warning: 'twl_get_voltage' defined but 
  not used
  
  This patch moves the code in question behind ARCH specific flags and
  eliminates these warnings.
 ...
 
  --- a/arch/arm/mach-omap2/twl-common.c
  +++ b/arch/arm/mach-omap2/twl-common.c
  @@ -48,6 +48,7 @@ static struct i2c_board_info __initdata 
  omap4_i2c1_board_info[] = {
  },
   };
   
  +#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
   static int twl_set_voltage(void *data, int target_uV)
   {
  struct voltagedomain *voltdm = (struct voltagedomain *)data;
  @@ -59,6 +60,7 @@ static int twl_get_voltage(void *data)
  struct voltagedomain *voltdm = (struct voltagedomain *)data;
  return voltdm_get_voltage(voltdm);
   }
  +#endif
 
 To avoid patching this piece of code for new SoCs, can we make it
 ifndef CONFIG_ARCH_OMAP2? Also in the makefile we should not even
 build twl-common.o for 2420 only builds..

Can't make it ifndef CONFIG_ARCH_OMAP2, as this would break on
omap2plus_defconfig then... as it defines all ARCH_OMAP2...ARCH_OMAP4.

And... can't drop it from makefile either, as parts of the code from
twl-common.c are still used with omap2 (omap_pmic_init 
omap_pmic_late_init). These would need to be moved elsewhere first.

-Tero


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

Re: [PATCH] ARM: OMAP2: twl-common: fix compiler warnings

[Peter Ujfalusi]

Hi Tero,

On 06/28/2012 12:49 PM, Tero Kristo wrote:
 OMAP2 does not use the external voltage controller code for TWL, and
 thus OMAP2 only compilation generates following warnings:
 
 arch/arm/mach-omap2/twl-common.c:51: warning: 'twl_set_voltage' defined but 
 not used
 arch/arm/mach-omap2/twl-common.c:57: warning: 'twl_get_voltage' defined but 
 not used
 
 This patch moves the code in question behind ARCH specific flags and
 eliminates these warnings.
 
 Reported-by: Paul Walmsley p...@pwsan.com
 Signed-off-by: Tero Kristo t-kri...@ti.com

I did sent similar patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70432.html

Tony applied it to fixes I think already.

-- 
Péter


--
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] OMAP: PM: one more fix for 3.5-rc

[Tony Lindgren]

* Kevin Hilman khil...@ti.com [120705 17:35]:
 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 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 V3 1/2] of: Add generic device tree DMA helpers

[Guennadi Liakhovetski]

On Mon, 25 Jun 2012, Arnd Bergmann wrote:

[snip]

 The channel data in the device tree is still in a format
 that is specific to that dmaengine driver and interpreted
 by it. Using the regular dma_filter_fn prototype is not
 necessary, but it would be convenient because the dmaengine
 code already knows how to deal with it. If we don't use this
 method, how about adding another callback to struct dma_device
 like
 
 bool (*device_match)(struct dma_chan *chan, struct property *req);

I like this idea, but why don't we extend it to also cover the non-DT 
case? I.e., why don't we add the above callback (call it match or 
filter or anything else) to dmaengine operations and inside (the 
extended) dma_request_channel(), instead of calling the filter function, 
passed as a parameter, we loop over all registered DMAC devices and call 
their filter callbacks, until one of them returns true? In fact, it goes 
back to my earlier proposal from 
http://thread.gmane.org/gmane.linux.kernel/1246957
which I, possibly, failed to explain properly. So, the transformation 
chain from today's API would be (all code is approximate):

(today)

client driver
dma_request_channel(mask, filter, filter_arg);

dmaengine_core
for_each_channel() {
ret = (*filter)(chan, filter_arg);
if (ret) {
ret = chan-device-device_alloc_chan_resources(chan);
if (!ret)
return chan;
else
return NULL;
}
}

(can be transformed to)

client driver
dma_request_channel(mask, filter_arg);

dmaengine_core
for_each_channel() {
ret = chan-device-filter(chan, filter_arg);
if (ret) {
same as above
}
}

(which further could be simplified to)

client driver
dma_request_channel(mask, filter_arg);

dmaengine_core
for_each_channel() {
ret = chan-device-device_alloc_chan_resources(chan, 
filter_arg);
if (!ret)
return chan;
else if (ret != -ENODEV)
return ret;
/* -ENODEV - try the next channel */
}

Which is quite similar to my above mentioned proposal. Wouldn't this both 
improve the present API and prepare it for DT?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] OMAP: config : disable the usb host configuration in omap2plus_defconfig

[Keshava Munegowda]

The usb host is disabled in the omap2 build; This is because
usb host is causing the retention to break in cpu idle.

Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
 arch/arm/configs/omap2plus_defconfig |   11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 9854ff4..7b32da6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
 CONFIG_SND_SOC=m
 CONFIG_SND_OMAP_SOC=m
 CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
-CONFIG_USB=y
-CONFIG_USB_DEBUG=y
-CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
-CONFIG_USB_SUSPEND=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_WDM=y
-CONFIG_USB_STORAGE=y
-CONFIG_USB_LIBUSUAL=y
-CONFIG_USB_TEST=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
-- 
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] OMAP: config : disable the usb host configuration in omap2plus_defconfig

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com wrote:
 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DEBUG=y
  CONFIG_USB_GADGET_DEBUG_FILES=y
 --
 1.7.9.5


Sameo
please merge this patch ; this makes the core retention to work in
omap2plus_defconfig

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

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 3:30 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Thu, Jul 5, 2012 at 4:49 PM, Samuel Ortiz sa...@linux.intel.com wrote:
 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.

 Thanks Samuel

 I will send the patches today.

 regards
 keshava

Samuel
  I have sent that patch to disable the ehci in
omap2plus_defconfig; after merging that
please merge this patch too. This will fix the crashes in during boot
with NFS in beagleXM

regards
keshava
--
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: config : disable the usb host configuration in omap2plus_defconfig

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
 wrote:
 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DEBUG=y
  CONFIG_USB_GADGET_DEBUG_FILES=y
 --
 1.7.9.5


 Sameo
 please merge this patch ; this makes the core retention to work in
 omap2plus_defconfig

If at all this patch has to be merged, it should be via Tony's tree,
otherwise you
might have merge conflicts.

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] OMAP: config : disable the usb host configuration in omap2plus_defconfig

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 5:29 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
 On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
 On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
 wrote:
 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y
  CONFIG_USB_GADGET=y
  CONFIG_USB_GADGET_DEBUG=y
  CONFIG_USB_GADGET_DEBUG_FILES=y
 --
 1.7.9.5


 Sameo
 please merge this patch ; this makes the core retention to work in
 omap2plus_defconfig

 If at all this patch has to be merged, it should be via Tony's tree,
 otherwise you
 might have merge conflicts.

 Regards
 Santosh

Thanks Santosh
   looping Tony

regards
keshava
--
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 07:56]:
 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

Hmm I don't follow, why can't the timings be set during the peripheral
specific driver probe?
 
   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 ?

Well ideally we'd have some kind of bus glue setup eventually so we'll
have just one device for smsc911x.. But like I said, that part is a
bit open still. At least I don't have any clear solution in mind for
how to do the bus specific wrapper drivers.
 
   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 ?

No that's probably not enough because the time and cycles for a peripheral
may need to be different if the peripheral clock rate changes.
  
  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.

Well yes the timings should be passed via devicetree in a gpmc specific
format. But the peripheral specific retime function still needs to be
also registered for peripherals that need 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] OMAP: config : disable the usb host configuration in omap2plus_defconfig

[Tony Lindgren]

* Munegowda, Keshava keshava_mgo...@ti.com [120706 05:06]:
 On Fri, Jul 6, 2012 at 5:29 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
  wrote:
  The usb host is disabled in the omap2 build; This is because
  usb host is causing the retention to break in cpu idle.
...
  Sameo
  please merge this patch ; this makes the core retention to work in
  omap2plus_defconfig
 
  If at all this patch has to be merged, it should be via Tony's tree,
  otherwise you
  might have merge conflicts.

I think it's best to fix things properly, even if it means that it will
take longer and go into next kernel version.

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: config : disable the usb host configuration in omap2plus_defconfig

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren t...@atomide.com wrote:
 * Munegowda, Keshava keshava_mgo...@ti.com [120706 05:06]:
 On Fri, Jul 6, 2012 at 5:29 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:25 PM, Munegowda, Keshava
  keshava_mgo...@ti.com wrote:
  On Fri, Jul 6, 2012 at 5:19 PM, Keshava Munegowda keshava_mgo...@ti.com 
  wrote:
  The usb host is disabled in the omap2 build; This is because
  usb host is causing the retention to break in cpu idle.
 ...
  Sameo
  please merge this patch ; this makes the core retention to work in
  omap2plus_defconfig
 
  If at all this patch has to be merged, it should be via Tony's tree,
  otherwise you
  might have merge conflicts.

 I think it's best to fix things properly, even if it means that it will
 take longer and go into next kernel version.

 Tony

Hi tony

This requires ehci remote wakeup feature to be implemented, which
will take at least to 3 months to
get reviewed in opensource.
hence for now  kevin is also agreed to disable it by default;


regards
keshava
--
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] Watchdog: OMAP: Fix the runtime pm code to avoid module getting stuck intransition state.

[Bedia, Vaibhav]

Hi Santosh,

On Fri, Jul 06, 2012 at 12:51:03, Shilimkar, Santosh wrote:
[...]
 
  A few questions based on the description given in the commit message.
 
  1. On OMAP4 SYSCLK can't be gated, because of issue with WDTIMER2 module,
  which constantly stays in in transition state. Value of register
  CM_WKUP_WDTIMER2_CLKCTRL is always 0x0001 in this case.
  Issue occurs immediately after first idle, when hwmod framework tries
  to disable WDTIMER2 functional clock - wd_timer2_fck. After this
  module falls to in transition state, and SYSCLK gating is blocked.
 
 
  From what I know, a value of 0x0001 for timers (WDT or DMTIMERs)
  indicates that the iclk is gated but the fclk is running. In fact,
  if the IP supports swakeup mechanism this is the value expected in the
  *_CLKCTRL registers of the timers for the swakeup to work.
 
 Nope. That case will be 0x0002
 
 Read 0x1: Module is performing transition: wakeup, or
 sleep, or sleep abortion
 Read 0x2: Module is in idle mode (only INTRCONN part).
 It is functional if using separate functional clock
 Read 0x3: Module is disabled and cannot be accessed
 

What you mentioned is obviously correct :)
I somehow recall seeing something else but mostly likely I am wrong here.

  Sounds like on OMAP4 the WDT needs to be stopped first and then the
  PRCM idle request sent otherwise SYSCLK gating will be blocked.
 
 Any module stuck in-transition will get the clock-domain from idle.
 

Yes agreed.

  2. Due to runtime PM, watchdog timer may be completely disabled.
  In current code base watchdog timer is not disabled only because of
  issue 1. Otherwise state of WDTIMER2 module will be Disabled, and there
  will be no interrupts from omap_wdt. In other words watchdog will not
  work at all.
 
  But the current driver doesn't make use of any interrupts, right?
 
 How is the interrupt related. You enable that when you enable WDT
 petting using delay_interrupt()
 

Even I don't understand the interrupt part here.

  If the WDT was never started, runtime PM handling for the WDT should be
  able to get the IP to a disabled state. Is the issue over here due
  to the WDT counter incrementing and still the PRCM idle request being
  sent for disabling it? If so, perhaps a better solution would be have
  a custom runtime PM handling for WDT which checks if the counter
  is incrementing or not. If it is not incrementing then it can just
  go ahead and disable the clocks. However, if the counter is incrementing
  then the runtime PM activities on the driver should be forbidden till
  an entry to a low power state where SYSCLK needs to be gated is required.
 
 If you look at the test case mentioned, the watchdong is started. Your
 first observation is not as per the hardware behavior, so other points
 becomes not relevant.
 

Ok. I'll double-check my observations on AM335x on Monday.

Regards,
Vaibhav B.
--
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 00/14] ARM: OMAP5: Add minimal OMAP5 SOC support

[Tony Lindgren]

* Santosh Shilimkar santosh.shilim...@ti.com [120706 02:26]:
 Tony,
 
 Here is the updated series with suggested corrections and generated against
 the latest cleanup-part2 at commit ae6df418. 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.

Looking good to me, just one cosmetic comment below:
 
   ARM: OMAP: counter-32k: Select the CR register offset using the IP scheme.
   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: OMAP5: Add SMP support.

Can you please remove the trailing period from the patch title lines?
That's not typically used..

Thanks,

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: config : disable the usb host configuration in omap2plus_defconfig

[Tony Lindgren]

* Munegowda, Keshava keshava_mgo...@ti.com [120706 05:30]:
 On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren t...@atomide.com wrote:
 
  I think it's best to fix things properly, even if it means that it will
  take longer and go into next kernel version.
 
 This requires ehci remote wakeup feature to be implemented, which
 will take at least to 3 months to
 get reviewed in opensource.
 hence for now  kevin is also agreed to disable it by default;

Why does echi need a remote wakeup feature? If you're talking about
echi wake-up events, I don't see how that would affect core retention.

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/1] ARM: add PROC_DEVICETREE support in Kconfig

[Rob Herring]

On 07/06/2012 05:38 AM, jgq...@gmail.com wrote:
 From: Xiao Jiang jgq...@gmail.com
 
 Since more and more arm chips support device tree, it'd be better add 
 PROC_DEVICETREE
 in arch/arm/Kconfig to avoid duplicate code.

I think this should remain user choice. If its going to be selected,
then you might as well just remove the option altogether. Perhaps just
make the option default to yes.

Rob

 Signed-off-by: Xiao Jiang jgq...@gmail.com
 ---
  arch/arm/Kconfig   |1 +
  arch/arm/configs/at91_dt_defconfig |1 -
  arch/arm/configs/tegra_defconfig   |1 -
  arch/arm/plat-omap/Kconfig |1 -
  4 files changed, 1 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index a91009c..f68896e 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1864,6 +1864,7 @@ config USE_OF
   select OF
   select OF_EARLY_FLATTREE
   select IRQ_DOMAIN
 + select PROC_DEVICETREE if PROC_FS
   help
 Include support for flattened device tree machine descriptions.
  
 diff --git a/arch/arm/configs/at91_dt_defconfig 
 b/arch/arm/configs/at91_dt_defconfig
 index 67bc571..b856cb6 100644
 --- a/arch/arm/configs/at91_dt_defconfig
 +++ b/arch/arm/configs/at91_dt_defconfig
 @@ -64,7 +64,6 @@ CONFIG_MTD_NAND=y
  CONFIG_MTD_NAND_ATMEL=y
  CONFIG_MTD_UBI=y
  CONFIG_MTD_UBI_GLUEBI=y
 -CONFIG_PROC_DEVICETREE=y
  CONFIG_BLK_DEV_LOOP=y
  CONFIG_BLK_DEV_RAM=y
  CONFIG_BLK_DEV_RAM_COUNT=4
 diff --git a/arch/arm/configs/tegra_defconfig 
 b/arch/arm/configs/tegra_defconfig
 index 1198dd6..43e7b65 100644
 --- a/arch/arm/configs/tegra_defconfig
 +++ b/arch/arm/configs/tegra_defconfig
 @@ -72,7 +72,6 @@ CONFIG_IPV6_TUNNEL=y
  CONFIG_IPV6_MULTIPLE_TABLES=y
  # CONFIG_WIRELESS is not set
  # CONFIG_FIRMWARE_IN_KERNEL is not set
 -CONFIG_PROC_DEVICETREE=y
  CONFIG_BLK_DEV_LOOP=y
  CONFIG_AD525X_DPOT=y
  CONFIG_AD525X_DPOT_I2C=y
 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
 index ad95c7a..4e2cb17 100644
 --- a/arch/arm/plat-omap/Kconfig
 +++ b/arch/arm/plat-omap/Kconfig
 @@ -27,7 +27,6 @@ config ARCH_OMAP2PLUS
   select GENERIC_IRQ_CHIP
   select OMAP_DM_TIMER
   select USE_OF
 - select PROC_DEVICETREE if PROC_FS
   help
 Systems based on OMAP2, OMAP3 or OMAP4
  
 


--
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] ARM: add PROC_DEVICETREE support in Kconfig

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:38 Fri 06 Jul , jgq...@gmail.com wrote:
 From: Xiao Jiang jgq...@gmail.com
 
 Since more and more arm chips support device tree, it'd be better add 
 PROC_DEVICETREE
 in arch/arm/Kconfig to avoid duplicate code.
 
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com

Best Regards,
J.
 Signed-off-by: Xiao Jiang jgq...@gmail.com
 ---
  arch/arm/Kconfig   |1 +
  arch/arm/configs/at91_dt_defconfig |1 -
  arch/arm/configs/tegra_defconfig   |1 -
  arch/arm/plat-omap/Kconfig |1 -
  4 files changed, 1 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index a91009c..f68896e 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1864,6 +1864,7 @@ config USE_OF
   select OF
   select OF_EARLY_FLATTREE
   select IRQ_DOMAIN
 + select PROC_DEVICETREE if PROC_FS
   help
 Include support for flattened device tree machine descriptions.
  
 diff --git a/arch/arm/configs/at91_dt_defconfig 
 b/arch/arm/configs/at91_dt_defconfig
 index 67bc571..b856cb6 100644
 --- a/arch/arm/configs/at91_dt_defconfig
 +++ b/arch/arm/configs/at91_dt_defconfig
 @@ -64,7 +64,6 @@ CONFIG_MTD_NAND=y
  CONFIG_MTD_NAND_ATMEL=y
  CONFIG_MTD_UBI=y
  CONFIG_MTD_UBI_GLUEBI=y
 -CONFIG_PROC_DEVICETREE=y
  CONFIG_BLK_DEV_LOOP=y
  CONFIG_BLK_DEV_RAM=y
  CONFIG_BLK_DEV_RAM_COUNT=4
 diff --git a/arch/arm/configs/tegra_defconfig 
 b/arch/arm/configs/tegra_defconfig
 index 1198dd6..43e7b65 100644
 --- a/arch/arm/configs/tegra_defconfig
 +++ b/arch/arm/configs/tegra_defconfig
 @@ -72,7 +72,6 @@ CONFIG_IPV6_TUNNEL=y
  CONFIG_IPV6_MULTIPLE_TABLES=y
  # CONFIG_WIRELESS is not set
  # CONFIG_FIRMWARE_IN_KERNEL is not set
 -CONFIG_PROC_DEVICETREE=y
  CONFIG_BLK_DEV_LOOP=y
  CONFIG_AD525X_DPOT=y
  CONFIG_AD525X_DPOT_I2C=y
 diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
 index ad95c7a..4e2cb17 100644
 --- a/arch/arm/plat-omap/Kconfig
 +++ b/arch/arm/plat-omap/Kconfig
 @@ -27,7 +27,6 @@ config ARCH_OMAP2PLUS
   select GENERIC_IRQ_CHIP
   select OMAP_DM_TIMER
   select USE_OF
 - select PROC_DEVICETREE if PROC_FS
   help
 Systems based on OMAP2, OMAP3 or OMAP4
  
 -- 
 1.7.3
 
--
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 00/14] ARM: OMAP5: Add minimal OMAP5 SOC support

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 6:06 PM, Tony Lindgren t...@atomide.com wrote:

 * Santosh Shilimkar santosh.shilim...@ti.com [120706 02:26]:
  Tony,
 
  Here is the updated series with suggested corrections and generated
  against
  the latest cleanup-part2 at commit ae6df418. 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.

 Looking good to me, just one cosmetic comment below:

Great.

ARM: OMAP: counter-32k: Select the CR register offset using the IP
  scheme.
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: OMAP5: Add SMP support.

 Can you please remove the trailing period from the patch title lines?
 That's not typically used..

I agree. Fixed it and update the branch.

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 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Peter Ujfalusi]

Hi,

On 07/06/2012 10:49 AM, Peter Ujfalusi wrote:
 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

Please ignore this two patch, I'll resend them with the correct MUX config.
By mistake I have set MUX_MODE1, while it must be set MUX_MODE0.
It was working with MUX_MODE1, but it is not aligned with the TRM...

Sorry,
Péter

 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index c4e17641..050cc8e 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -827,6 +827,9 @@ static void __init omap_4430sdp_display_init(void)
  #ifdef CONFIG_OMAP_MUX
  static struct omap_board_mux board_mux[] __initdata = {
   OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 + /* NIRQ2 for twl6040 */
 + OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE1 |
 +   OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
   { .reg_offset = OMAP_MUX_TERMINATOR },
  };
  
 


--
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: OMAP4 SDP/PandaBoard: Fix sys_nirq2 mux configuration

[Peter Ujfalusi]

Hello,

sys_nirq2 pin needs to be set to mode0 (instead of mode1 done in v1 patches).
To my surprise mode1 also worked, but it was not the correct mode.

I have kept the acks from Santosh since the idea behind of the patches are the
same, but now the mux mode is the correct one.

Regards,
Peter

---
Peter Ujfalusi (2):
  ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2
  ARM: OMAP: board-omap4panda: MUX configuration for sys_nirq2

 arch/arm/mach-omap2/board-4430sdp.c|3 +++
 arch/arm/mach-omap2/board-omap4panda.c |3 +++
 2 files changed, 6 insertions(+), 0 deletions(-)

-- 
1.7.8.6

--
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: OMAP: board-omap4panda: MUX configuration for sys_nirq2

[Peter Ujfalusi]

The sys_nirq2 is used for twl6040, make sure the pin is configured
correctly.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-omap4panda.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index 982fb26..b627cdc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -379,6 +379,9 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(DPM_EMU18, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
/* dispc2_data0 */
OMAP4_MUX(DPM_EMU19, OMAP_PIN_OUTPUT | OMAP_MUX_MODE5),
+   /* NIRQ2 for twl6040 */
+   OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
+ OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
-- 
1.7.8.6

--
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: board-4430sdp: MUX configuration for sys_nirq2

[Peter Ujfalusi]

The sys_nirq2 is used for twl6040, make sure the pin is configured
correctly.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/board-4430sdp.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index c4e17641..72cd206 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -827,6 +827,9 @@ static void __init omap_4430sdp_display_init(void)
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+   /* NIRQ2 for twl6040 */
+   OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
+ OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 
-- 
1.7.8.6

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

[PATCH] ARM: OMAP: hwmod: Disable module when hwmod enable fails

[Rajendra Nayak]

From: Misael Lopez Cruz misael.lo...@ti.com

Clock and module mode are explictly enable when hwmod is enabled. But if
the hwmod doesn't get ready on time, clocks are disabled but module is left
enabled.

Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7731936..26888b6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1834,6 +1834,7 @@ static int _enable(struct omap_hwmod *oh)
_enable_sysc(oh);
}
} else {
+   _omap4_disable_module(oh);
_disable_clocks(oh);
pr_debug(omap_hwmod: %s: _wait_target_ready: %d\n,
 oh-name, r);
-- 
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: [PATCH] OMAP: config : disable the usb host configuration in omap2plus_defconfig

[Munegowda, Keshava]

On Fri, Jul 6, 2012 at 6:09 PM, Tony Lindgren t...@atomide.com wrote:
 * Munegowda, Keshava keshava_mgo...@ti.com [120706 05:30]:
 On Fri, Jul 6, 2012 at 5:37 PM, Tony Lindgren t...@atomide.com wrote:
 
  I think it's best to fix things properly, even if it means that it will
  take longer and go into next kernel version.

 This requires ehci remote wakeup feature to be implemented, which
 will take at least to 3 months to
 get reviewed in opensource.
 hence for now  kevin is also agreed to disable it by default;

 Why does echi need a remote wakeup feature? If you're talking about
 echi wake-up events, I don't see how that would affect core retention.

Hi Tony
 the cpu should hit the retention in idle; in this case,  up on
usb bus suspend ( no device connected) , if I cut the clock, then later
device detection happen through I/O wakeup, so implementing the
ehci remote wakeup using I/O chain handler ensure the retention in idle too.
now, with the existing ehci driver in mainline, whether device connected or not
the clocks are not cut and prevents the retention in idle.
so, I need to implement the ehci clock gating mechanism through I/O interrupts
in bus spend /resume . This activity will take some time.

regards
keshava
--
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] da8xx-fb: add missing FB_BLANK operations

[yegorslists]

From: Yegor Yefremov yegorsli...@googlemail.com

add FB_BLANK_NORMAL, FB_BLANK_VSYNC_SUSPEND and FB_BLANK_HSYNC_SUSPEND
modes (copy drivers/video/omap2/omapfb/omapfb-main.c implementation).
Otherwise X-server will complain about invalid parameter.

Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
v2: add linux-fbdev as recipient 

 drivers/video/da8xx-fb.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 47118c7..8d745bf 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1026,6 +1026,9 @@ static int cfb_blank(int blank, struct fb_info *info)
 
lcd_enable_raster();
break;
+   case FB_BLANK_NORMAL:
+   case FB_BLANK_VSYNC_SUSPEND:
+   case FB_BLANK_HSYNC_SUSPEND:
case FB_BLANK_POWERDOWN:
if (par-panel_power_ctrl)
par-panel_power_ctrl(0);
-- 
1.7.7

--
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: config : disable the usb host configuration in omap2plus_defconfig

[Kevin Hilman]

Keshava Munegowda keshava_mgo...@ti.com writes:

 The usb host is disabled in the omap2 build; This is because
 usb host is causing the retention to break in cpu idle.

... and causes warnings during boot, and hangs in suspend, can't suspend
using NFSroot, etc. etc.

Thank you for disabling this by default, But I don't think this fix
is targetted enough (more below.)

Tony, when v3.5 came out, I asked them to fix this properly, but nothing
was done.  So I've resorted to requesting that this feature be disabled
by default since it introduced PM regressions.  Of course, I'd like to
see this fixed properly instead, but we've run out of time for v3.5 and
IMO, this PM regression needs to be fixed for v3.5.  See my more
targetted patches below.

 Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 ---
  arch/arm/configs/omap2plus_defconfig |   11 ---
  1 file changed, 11 deletions(-)

 diff --git a/arch/arm/configs/omap2plus_defconfig 
 b/arch/arm/configs/omap2plus_defconfig
 index 9854ff4..7b32da6 100644
 --- a/arch/arm/configs/omap2plus_defconfig
 +++ b/arch/arm/configs/omap2plus_defconfig
 @@ -170,17 +170,6 @@ CONFIG_SND_USB_AUDIO=m
  CONFIG_SND_SOC=m
  CONFIG_SND_OMAP_SOC=m
  CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 -CONFIG_USB=y
 -CONFIG_USB_DEBUG=y
 -CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 -CONFIG_USB_DEVICEFS=y
 -CONFIG_USB_SUSPEND=y
 -CONFIG_USB_MON=y
 -CONFIG_USB_EHCI_HCD=y
 -CONFIG_USB_WDM=y
 -CONFIG_USB_STORAGE=y
 -CONFIG_USB_LIBUSUAL=y
 -CONFIG_USB_TEST=y

Why disable all of these?  With that, it's not terribly clear what is
going on, or why.

Instead, what you need is a targetted fix to just disable the problem
driver by default:

Either this:

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 9854ff4..11828e6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -176,7 +176,6 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_LIBUSUAL=y

or this:

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..3747826 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -825,7 +825,7 @@ config MFD_WL1273_CORE
 config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
-   default y
+   default n
help
  This is the core driver for the OAMP EHCI and OHCI drivers.
  This MFD driver does the required setup functionalities for

Will have the inteded affect with the benefit of being much clearer
about what is actually being disabled, and why.

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

Re: [PATCH v2 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Kevin Hilman]

Peter Ujfalusi peter.ujfal...@ti.com writes:

 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index c4e17641..72cd206 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -827,6 +827,9 @@ static void __init omap_4430sdp_display_init(void)
  #ifdef CONFIG_OMAP_MUX
  static struct omap_board_mux board_mux[] __initdata = {
   OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 + /* NIRQ2 for twl6040 */
 + OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
 +   OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),

Since this is TWL6030 specific, it should rather be done in TWL code
like I did for sys_nirq1:
   
   http://marc.info/?l=linux-omapm=134090312118873w=2

That would avoid having to do this in both board files.

I thought about adding sys_nirq2 in my patch too, but did not know how
to properly test it.

Kevin

   { .reg_offset = OMAP_MUX_TERMINATOR },
  };
--
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] drivers/rtc/rtc-twl.c: fix threaded IRQ to use IRQF_ONESHOT

[Hilman, Kevin]

Alessandro,

Gentle reminder ping on this one so it can make it in for v3.5-rc.   Thanks.

On Thu, Jun 28, 2012 at 9:17 AM, Kevin Hilman khil...@ti.com wrote:
 Requesting a threaded interrupt without a primary handler and without
 IRQF_ONESHOT is dangerous, and after commit 1c6c6952 (genirq: Reject
 bogus threaded irq requests), these requests are rejected.  This
 causes -probe() to fail, and the RTC driver not to be availble.

 To fix, add IRQF_ONESHOT to the IRQ flags.

 Tested on OMAP3730/OveroSTORM and OMAP4430/Panda board using rtcwake
 to wake from system suspend multiple times.

 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
 This fix is needed in v3.5.
 Applies on top of v3.5-rc4.

  drivers/rtc/rtc-twl.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
 index 258abea..c5d06fe 100644
 --- a/drivers/rtc/rtc-twl.c
 +++ b/drivers/rtc/rtc-twl.c
 @@ -510,7 +510,7 @@ static int __devinit twl_rtc_probe(struct platform_device 
 *pdev)
 }

 ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
 -  IRQF_TRIGGER_RISING,
 +  IRQF_TRIGGER_RISING | IRQF_ONESHOT,
dev_name(rtc-dev), rtc);
 if (ret  0) {
 dev_err(pdev-dev, IRQ is not free.\n);
 --
 1.7.9.2

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

Re: [PATCH v2 1/2] ARM: OMAP: board-4430sdp: MUX configuration for sys_nirq2

[Shilimkar, Santosh]

On Fri, Jul 6, 2012 at 7:46 PM, Kevin Hilman khil...@ti.com wrote:
 Peter Ujfalusi peter.ujfal...@ti.com writes:

 The sys_nirq2 is used for twl6040, make sure the pin is configured
 correctly.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c |3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
 b/arch/arm/mach-omap2/board-4430sdp.c
 index c4e17641..72cd206 100644
 --- a/arch/arm/mach-omap2/board-4430sdp.c
 +++ b/arch/arm/mach-omap2/board-4430sdp.c
 @@ -827,6 +827,9 @@ static void __init omap_4430sdp_display_init(void)
  #ifdef CONFIG_OMAP_MUX
  static struct omap_board_mux board_mux[] __initdata = {
   OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
 + /* NIRQ2 for twl6040 */
 + OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
 +   OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),

 Since this is TWL6030 specific, it should rather be done in TWL code
 like I did for sys_nirq1:

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

 That would avoid having to do this in both board files.

Though the pin is TWL specific, it need not be same on
different board with different SOCs. Especially when you need to
set MUX mode etc. So doing from board file is still better
since TWL6030/40 can be connected to non OMAP4 devices
where the muxing can be different.

With current know boards with TWL6030/40, this is not
a strong requirement though.

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 00/10] Prepare for GPMC driver conversion (w.r.t MTD)

[William F.]

I've requested several times to remove my e-mail from that list. I'll 
report it to legal authorities on this issue if no action is taken.


William.

* Mohammed, Afzalaf...@ti.com  [120703 05:10]:

Hi Tony,

On Mon, Jul 02, 2012 at 13:05:47, Tony Lindgren wrote:

* Artem Bityutskiyartem.bityuts...@linux.intel.com  [120627 02:36]:

On Wed, 2012-06-13 at 17:02 +0530, Afzal Mohammed wrote:

This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/

Dunno if Tony picked this, but the MTD changes look good an the quick
glance. Feel free to add

Acked-by: Artem Bityutskiyartem.bityuts...@linux.intel.com

Thanks will add to the drivers/mtd touching patches in this series.

Can you please consider this series for inclusion in the coming merge
window. This series can live by itself and is not dependent on any
other patches.

Yes I have some of the gpmc patches applied locally on top of the
dmaengine changes from Russell. Will update and push out once we have
an immutable commit for the dmaengine changes available.

Regards,

Tony

__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



--
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 00/10] Prepare for GPMC driver conversion (w.r.t MTD)

[David Woodhouse]

On Fri, 2012-07-06 at 11:35 -0300, William F. wrote:
 I've requested several times to remove my e-mail from that list. I'll 
 report it to legal authorities on this issue if no action is taken.

Have you tried following the link at the bottom of every mail you
receive from the list, and following the 'To unsubscribe from linux-mtd'
instructions you find there?

I'll report it to stupidity authorities on this issue if no such action
is taken :)

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Arnd Bergmann]

On Friday 06 July 2012, Guennadi Liakhovetski wrote:
 On Mon, 25 Jun 2012, Arnd Bergmann wrote:
 
 [snip]
 
  The channel data in the device tree is still in a format
  that is specific to that dmaengine driver and interpreted
  by it. Using the regular dma_filter_fn prototype is not
  necessary, but it would be convenient because the dmaengine
  code already knows how to deal with it. If we don't use this
  method, how about adding another callback to struct dma_device
  like
  
  bool (*device_match)(struct dma_chan *chan, struct property *req);
 
 I like this idea, but why don't we extend it to also cover the non-DT 
 case? I.e., why don't we add the above callback (call it match or 
 filter or anything else) to dmaengine operations and inside (the 
 extended) dma_request_channel(), instead of calling the filter function, 
 passed as a parameter, we loop over all registered DMAC devices and call 
 their filter callbacks, until one of them returns true? In fact, it goes 
 back to my earlier proposal from 
 http://thread.gmane.org/gmane.linux.kernel/1246957
 which I, possibly, failed to explain properly. So, the transformation 
 chain from today's API would be (all code is approximate):
 
 ...
 dmaengine_core
   for_each_channel() {
   ret = chan-device-device_alloc_chan_resources(chan, 
 filter_arg);
   if (!ret)
   return chan;
   else if (ret != -ENODEV)
   return ret;
   /* -ENODEV - try the next channel */
   }
 
 Which is quite similar to my above mentioned proposal. Wouldn't this both 
 improve the present API and prepare it for DT?

How would the individual driver know the size of the filter_arg? In the
device tree code, we would know if from #dma-cells of the engine node,
and that gets checked when reading the property, but when you have
a free-form data structure, it's much less clear.

Also, you could easily have an argument that looks valid for more than one
dmaengine, but really isn't.

I think for your proposal to work, we would need something like the
phandle for the dmaengine device that is at the start of the property
in the DT case.

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: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Guennadi Liakhovetski]

Hi Arnd

On Fri, 6 Jul 2012, Arnd Bergmann wrote:

 On Friday 06 July 2012, Guennadi Liakhovetski wrote:
  On Mon, 25 Jun 2012, Arnd Bergmann wrote:
  
  [snip]
  
   The channel data in the device tree is still in a format
   that is specific to that dmaengine driver and interpreted
   by it. Using the regular dma_filter_fn prototype is not
   necessary, but it would be convenient because the dmaengine
   code already knows how to deal with it. If we don't use this
   method, how about adding another callback to struct dma_device
   like
   
   bool (*device_match)(struct dma_chan *chan, struct property *req);
  
  I like this idea, but why don't we extend it to also cover the non-DT 
  case? I.e., why don't we add the above callback (call it match or 
  filter or anything else) to dmaengine operations and inside (the 
  extended) dma_request_channel(), instead of calling the filter function, 
  passed as a parameter, we loop over all registered DMAC devices and call 
  their filter callbacks, until one of them returns true? In fact, it goes 
  back to my earlier proposal from 
  http://thread.gmane.org/gmane.linux.kernel/1246957
  which I, possibly, failed to explain properly. So, the transformation 
  chain from today's API would be (all code is approximate):
  
  ...
  dmaengine_core
  for_each_channel() {
  ret = chan-device-device_alloc_chan_resources(chan, 
  filter_arg);
  if (!ret)
  return chan;
  else if (ret != -ENODEV)
  return ret;
  /* -ENODEV - try the next channel */
  }
  
  Which is quite similar to my above mentioned proposal. Wouldn't this both 
  improve the present API and prepare it for DT?
 
 How would the individual driver know the size of the filter_arg?

In exactly the same way as most dmaengine drivers do it today: they don't 
touch filter_arg until they're sure this is one of their channels. And 
this they typically do by comparing the driver pointer, e.g.:

bool sa11x0_dma_filter_fn(struct dma_chan *chan, void *param)
{
if (chan-device-dev-driver == sa11x0_dma_driver.driver) {

Thanks
Guennadi

 In the
 device tree code, we would know if from #dma-cells of the engine node,
 and that gets checked when reading the property, but when you have
 a free-form data structure, it's much less clear.
 
 Also, you could easily have an argument that looks valid for more than one
 dmaengine, but really isn't.
 
 I think for your proposal to work, we would need something like the
 phandle for the dmaengine device that is at the start of the property
 in the DT case.
 
   Arnd
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] drivers/rtc/rtc-twl.c: fix threaded IRQ to use IRQF_ONESHOT

[Kevin Hilman]

Requesting a threaded interrupt without a primary handler and without
IRQF_ONESHOT is dangerous, and after commit 1c6c6952 (genirq: Reject
bogus threaded irq requests), these requests are rejected.  This
causes -probe() to fail, and the RTC driver not to be availble.

To fix, add IRQF_ONESHOT to the IRQ flags.

Tested on OMAP3730/OveroSTORM and OMAP4430/Panda board using rtcwake
to wake from system suspend multiple times.

Signed-off-by: Kevin Hilman khil...@ti.com
---
Resending to broader audience and including Andrew.  Since, I understand
that drivers/rtc is somewhat orphaned, Andrew, can you queue this fix for
v3.5.  Thanks.

 drivers/rtc/rtc-twl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 258abea..c5d06fe 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -510,7 +510,7 @@ static int __devinit twl_rtc_probe(struct platform_device 
*pdev)
}
 
ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
-  IRQF_TRIGGER_RISING,
+  IRQF_TRIGGER_RISING | IRQF_ONESHOT,
   dev_name(rtc-dev), rtc);
if (ret  0) {
dev_err(pdev-dev, IRQ is not free.\n);
-- 
1.7.9.2

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

[PATCH] ARM: OMAP2+: omap2plus_defconfig: EHCI driver is not stable, disable it

[Kevin Hilman]

The EHCI driver is not stable enough to be enabled by default.  In v3.5,
it has at least the following problems:

- warning dump during bootup
- hang during suspend
- prevents CORE powerdomain from entering retention during idle (even
  when no USB devices connected.)

This demonstrates that this driver has not been thoroughly tested and
therfore should not be enabled in the default defconfig.

In addition, the problems above cause new PM regressions which need be
addressed before this driver should be enabled in the default
defconfig.

Signed-off-by: Kevin Hilman khil...@ti.com
---
Tony, this applies to your current fixes branch.   Please queue up for v3.5-rc
so this PM regression is fixed in v3.5.  Thanks.

 arch/arm/configs/omap2plus_defconfig |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 9854ff4..11828e6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -176,7 +176,6 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_LIBUSUAL=y
-- 
1.7.9.2

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

Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Arnd Bergmann]

On Friday 06 July 2012, Guennadi Liakhovetski wrote:
   dmaengine_core
   for_each_channel() {
   ret = chan-device-device_alloc_chan_resources(chan, 
   filter_arg);
   if (!ret)
   return chan;
   else if (ret != -ENODEV)
   return ret;
   /* -ENODEV - try the next channel */
   }
   
   Which is quite similar to my above mentioned proposal. Wouldn't this both 
   improve the present API and prepare it for DT?
  
  How would the individual driver know the size of the filter_arg?
 
 In exactly the same way as most dmaengine drivers do it today: they don't 
 touch filter_arg until they're sure this is one of their channels. And 
 this they typically do by comparing the driver pointer, e.g.:
 
 bool sa11x0_dma_filter_fn(struct dma_chan *chan, void *param)
 {
 if (chan-device-dev-driver == sa11x0_dma_driver.driver) {

I don't understand. This already matches because we're calling the
device_alloc_chan_resources() function of the specific device that
matches the channel. However, we do the same for each channel, with the
same data, but different controllers, each of which will think they match
the channel.

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: [PATCH V3 1/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
 I like this idea, but why don't we extend it to also cover the non-DT 
 case? I.e., why don't we add the above callback (call it match or 
 filter or anything else) to dmaengine operations and inside (the 
 extended) dma_request_channel(), instead of calling the filter function, 
 passed as a parameter, we loop over all registered DMAC devices and call 
 their filter callbacks, until one of them returns true? In fact, it goes 
 back to my earlier proposal from 
 http://thread.gmane.org/gmane.linux.kernel/1246957
 which I, possibly, failed to explain properly. So, the transformation 
 chain from today's API would be (all code is approximate):
 
 (today)
 
 client driver
   dma_request_channel(mask, filter, filter_arg);
 
 dmaengine_core
   for_each_channel() {
   ret = (*filter)(chan, filter_arg);
   if (ret) {
   ret = chan-device-device_alloc_chan_resources(chan);
   if (!ret)
   return chan;
   else
   return NULL;
   }
   }
 
 (can be transformed to)
 
 client driver
   dma_request_channel(mask, filter_arg);
 
 dmaengine_core
   for_each_channel() {
   ret = chan-device-filter(chan, filter_arg);
   if (ret) {
   same as above
   }
   }
 
 (which further could be simplified to)
 
 client driver
   dma_request_channel(mask, filter_arg);
 
 dmaengine_core
   for_each_channel() {
   ret = chan-device-device_alloc_chan_resources(chan, 
 filter_arg);

This looks like you're re-purposing a perfectly good API for something that
it wasn't designed to do, namely providing a channel selection mechanism,
rather than allocating channel resources.  The hint is in the bloody
name, please take a look sometime!

If you want to call into the DMA engine driver for channel selection,
then create an _explicit_ API for it.  Don't bugger around with existing
APIs.

Moreover, the *big* problem that your proposal above creates is this.
What _type_ is filter_arg?  If it's void *, then your suggestion is
nonsense, even if you associate it with a size argument.  You have no
idea what the bytestream that would be passed via that pointer means,
even if the size just happens to look like it's what you expect.

If it's something else, then your mistake above was not defining it, so
there's no way to evaluate your proposal given that lack of critical
information.  And if you define it, whatever you come up with _must_
be suitable for every single DMA engine driver we have today.
--
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/2] of: Add generic device tree DMA helpers

[Russell King - ARM Linux]

On Fri, Jul 06, 2012 at 05:43:38PM +0200, Guennadi Liakhovetski wrote:
 Hi Arnd
 
 On Fri, 6 Jul 2012, Arnd Bergmann wrote:
  How would the individual driver know the size of the filter_arg?
 
 In exactly the same way as most dmaengine drivers do it today: they don't 
 touch filter_arg until they're sure this is one of their channels. And 
 this they typically do by comparing the driver pointer, e.g.:
 
 bool sa11x0_dma_filter_fn(struct dma_chan *chan, void *param)
 {
   if (chan-device-dev-driver == sa11x0_dma_driver.driver) {

That's utter rubbish, I'm afraid.

Let's say you move that code into sa11x0's alloc_chan_resources() function.
It will _never_ be called for a channel which isn't owned by the sa11x0
DMA driver - look at what __dma_request_channel() does:

list_for_each_entry_safe(device, _d, dma_device_list, global_node) {

This walks the list of DMA devices.

chan = private_candidate(mask, device, fn, fn_param);

This walks the channels _on_ _that_ dma device.  Those channels can only
be owned by the DMA device, which is in turn owned by the driver, which
in turn is owned by the struct driver that the above filter function
is checking.

So, all in all, this check inside chan_alloc_resources() tells you
absolutely _nothing_ about the suitability of dereferencing your
filter_arg data.  At all.
--
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

Infinite looping in omap2430.c USB driver

[NeilBrown]

Hello `./scripts/get_maintainer.pl -f drivers/usb/musb/omap2430.c`

omap2430_musb_set_vbus in omap2430.c contains:

while (musb_readb(musb-mregs, MUSB_DEVCTL)  0x80) {

cpu_relax();

if (time_after(jiffies, timeout)) {
dev_err(musb-controller,
configured as A device timeout);
ret = -EINVAL;
break;
}
}

having set
unsigned long timeout = jiffies + msecs_to_jiffies(1000);

so it can busy-loop for up to 1 second.  Probably not ideal, but if it works
I wouldn't complain.

The
if (int_usb  MUSB_INTR_SESSREQ) {
branch of musb_stage0_irq() called from musb_interrupt (from
generic_interrupt) calls this:

if (musb-int_usb)
retval |= musb_stage0_irq(musb, musb-int_usb,
devctl, power);

so the busy loop can happen in an interrupt handler (not a threaded interrupt
handler), which is probably less ideal.

However this can be called with interrupt disabled, as happens at least
during resume when resume_irqs() calls:

raw_spin_lock_irqsave(desc-lock, flags);
__enable_irq(desc, irq, true);
raw_spin_unlock_irqrestore(desc-lock, flags);

and an interrupt is found to be IRQS_PENDING.

In this case interrupts are disabled so 'jiffies' never changes so this loop
can continue forever.

This happens on my (GTA04) phone fairly regularly - between 1 in 10 and 1 in
30 resumes. The musb-hdrc interrupt is pending and reports

[ 4957.624176] musb-hdrc musb-hdrc: ** IRQ peripheral usb0040 tx rx

'usb0040' is MUSB_INTR_SESSREQ.  I think this is triggered by detecting a
voltage change on the USB ID pin - is that right?  A short-to-earth would be
a request to switch to host mode, which is why it tries to enable VBUS.
Maybe there is some electrical noise which is being picked up?

In any case I get the interrupt despite nothing being plugged in, and the 0x80
bit of MUSB_DEVCTL never gets cleared.

I've added a simple loop counter which aborts the loop after 1000 loops -
this takes about 5 seconds, but includes some printks which probably slow it
down.

In 2 out of 2 cases, subsequent messages show that the hsmmc driver for the
uSD card that holds my root filesystem is messed up.  It seems to be waiting
for a request that is never going to complete.
So maybe the hsmmc is causing the noise that triggers the musb issue.

I can send a patch which add a loop count if you like, but I suspect you can
come up with a much better approach.

Thanks,
NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 4 2/4] NET ethernet introduce mac_platform helper

[Ben Hutchings]

On Thu, 2012-07-05 at 10:44 +0800, Andy Green wrote:
[...]
 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.
[...]

This seems very restrictive... would it be practical to also allow a
driver name as a path component?

[...]
 --- /dev/null
 +++ b/include/net/mac-platform.h
 @@ -0,0 +1,39 @@
 +/*
 + * mac-platform.h:  Enforces platform-defined MAC for Async probed devices
 + */
 +
 +#ifndef __NET_MAC_PLATFORM_H__
 +#define __NET_MAC_PLATFORM_H__
 +
 +#include linux/if_ether.h
 +
 +/**
 + * struct mac_platform - associates asynchronously probed device path with
 + *MAC address to be assigned to the device when it
 + *is created

A kernel-doc summary is strictly limited to one line.  The longer
explanation can go in a paragraph under the field descriptions.

 + * @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 mac_platform {
 + char *device_path;
 + u8 mac[ETH_ALEN];
 + struct list_head list; /* unused in platform data usage */
 +};
[...]
 --- /dev/null
 +++ b/net/ethernet/mac-platform.c
[...]
 +static struct mac_platform *__mac_platform_check(struct device *dev)
 +{
 + const char *path;
 + const char *p;
 + const char *try;
 + int len;
 + struct device *devn;
 + struct mac_platform *tmp;
 + struct list_head *pos;
 +
 + list_for_each(pos, mac_platform_list) {
 +
 + tmp = list_entry(pos, struct mac_platform, list);
 +
 + try = tmp-device_path;
 +
 + p = try + strlen(try);
 + devn = dev;
 +
 + while (devn) {
 +
 + path = dev_name(devn);
 + len = strlen(path);
 +
 + if ((p - try)  len) {
 + devn = NULL;
 + continue;
 + }
 +
 + p -= len;
[...]

There are so many blank lines here, it's hard to see much code at once.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


--
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/2] of: Add generic device tree DMA helpers

[Guennadi Liakhovetski]

On Fri, 6 Jul 2012, Russell King - ARM Linux wrote:

 On Fri, Jul 06, 2012 at 01:36:32PM +0200, Guennadi Liakhovetski wrote:
  I like this idea, but why don't we extend it to also cover the non-DT 
  case? I.e., why don't we add the above callback (call it match or 
  filter or anything else) to dmaengine operations and inside (the 
  extended) dma_request_channel(), instead of calling the filter function, 
  passed as a parameter, we loop over all registered DMAC devices and call 
  their filter callbacks, until one of them returns true? In fact, it goes 
  back to my earlier proposal from 
  http://thread.gmane.org/gmane.linux.kernel/1246957
  which I, possibly, failed to explain properly. So, the transformation 
  chain from today's API would be (all code is approximate):
  
  (today)
  
  client driver
  dma_request_channel(mask, filter, filter_arg);
  
  dmaengine_core
  for_each_channel() {
  ret = (*filter)(chan, filter_arg);
  if (ret) {
  ret = chan-device-device_alloc_chan_resources(chan);
  if (!ret)
  return chan;
  else
  return NULL;
  }
  }
  
  (can be transformed to)
  
  client driver
  dma_request_channel(mask, filter_arg);
  
  dmaengine_core
  for_each_channel() {
  ret = chan-device-filter(chan, filter_arg);
  if (ret) {
  same as above
  }
  }
  
  (which further could be simplified to)
  
  client driver
  dma_request_channel(mask, filter_arg);
  
  dmaengine_core
  for_each_channel() {
  ret = chan-device-device_alloc_chan_resources(chan, 
  filter_arg);
 
 This looks like you're re-purposing a perfectly good API for something that
 it wasn't designed to do, namely providing a channel selection mechanism,
 rather than allocating channel resources.  The hint is in the bloody
 name, please take a look sometime!
 
 If you want to call into the DMA engine driver for channel selection,
 then create an _explicit_ API for it.  Don't bugger around with existing
 APIs.

Sure, it's better to create a new call-back.

 Moreover, the *big* problem that your proposal above creates is this.
 What _type_ is filter_arg?  If it's void *, then your suggestion is
 nonsense, even if you associate it with a size argument.  You have no
 idea what the bytestream that would be passed via that pointer means,
 even if the size just happens to look like it's what you expect.

Right, thanks to you and Arnd, who has pointed this out too.

Then it seems to me, that we need to introduce a notion of a mux device. 
We could of course try to just use some strings instead, arrays of 
acceptable DMA devices and channels, and most likely we would even be able 
to find such an approach, that would work for all existing configurations. 
But it still wouldn't be really fully generic, right? Whereas creating a 
mux driver we really could cover all possible cases. DMA clients in this 
case would always be hard wired to only one pin of such a mux, the DMA 
device on the other side also only has to care about its physical 
channels. The dmaengine core would then query the mux driver, where it can 
route specific client request lines?

A separate mux is needed, because several clients can have their DMA 
handshake lines routed to several DMAC instances, so, this muxing 
functionality can neither reside on the client nor on the CMAC.

Is this a right direction now? Shall I try to prototype such a DMA mux 
API?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] MFD: twl-core: move device_init_wakeup to after platform_device_add.

[NeilBrown]

device_init_wakeup uses the dev_name() of the device to set the
name of the wakeup_source which appears in
/sys/kernel/debug/wakeup_sources.

For a platform device, that name is not set until platform_device_add
calls dev_set_name.

So the call to device_init_wakeup() must be after the call to
platform_device_add().
Making this change causes correct names to appear in the
wakeup_sources file.


Signed-off-by: NeilBrown ne...@suse.de

diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 6fc90be..b012efd 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -568,7 +568,6 @@ add_numbered_child(unsigned chip, const char *name, int num,
goto err;
}
 
-   device_init_wakeup(pdev-dev, can_wakeup);
pdev-dev.parent = twl-client-dev;
 
if (pdata) {
@@ -593,6 +592,8 @@ add_numbered_child(unsigned chip, const char *name, int num,
}
 
status = platform_device_add(pdev);
+   if (status == 0)
+   device_init_wakeup(pdev-dev, can_wakeup);
 
 err:
if (status  0) {


signature.asc
Description: PGP signature

Re: [PATCH 1/1] ARM: add PROC_DEVICETREE support in Kconfig

[Olof Johansson]

On Fri, Jul 6, 2012 at 4:15 PM, Xiao Jiang jgq...@gmail.com wrote:
 2012/7/6 Rob Herring robherri...@gmail.com

 On 07/06/2012 05:38 AM, jgq...@gmail.com wrote:
  From: Xiao Jiang jgq...@gmail.com
 
  Since more and more arm chips support device tree, it'd be better add
  PROC_DEVICETREE
  in arch/arm/Kconfig to avoid duplicate code.

 I think this should remain user choice. If its going to be selected,
 then you might as well just remove the option altogether. Perhaps just
 make the option default to yes.

 Hmm, sounds reasonable from your point. So the better choice is to set the
 option default to Y if the board has dt support just like tegra_defconfig
 and at91_dt_defconfig,  right? thanks.

Why bother? If the defconfigs select it then most users basing their
config from that will be just fine.

PROC_DEVICETREE is 100% optional, it's useful to get runtime access to
the contents of the device tree but it's not required for the kernel
to boot.


-Olof
--
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] gpio/omap: final fixes for v3.5

[Kevin Hilman]

Hi Grant,

Here's a couple (hopefully) final OMAP GPIO fixes for v3.5-rc.

Thanks,

Kevin


The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc:

  Linux 3.5-rc4 (2012-06-24 12:53:04 -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/gpio-3

for you to fetch changes up to 7b86cef34afceeecf57d4d07f3cfab06f8b60b13:

  gpio/omap: fix invalid context restore of gpio bank-0 (2012-07-03 09:41:39 
-0700)


Grazvydas Ignotas (1):
  gpio/omap: fix irq loss while in idle with debounce on

Jon Hunter (1):
  gpio/omap: fix invalid context restore of gpio bank-0

 drivers/gpio/gpio-omap.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)
--
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