Re: ARM: OMAP2: Delete unnecessary checks before three function calls

[SF Markus Elfring]

 I have to say, I am a bit leery about applying the omap_device.c and
 omap_hwmod.c changes, since the called functions -- omap_device_delete()
 and clk_disable() -- don't explicitly document that NULLs are allowed
 to be passed in.

How are the chances to improve documentation around such implementation details?


 So there's no explicit contract that callers can rely upon, to (at least
 in theory) prevent those internal NULL pointer checks from being removed.

Are there any additional variations to consider for source files from different
processor architectures?


 So I would suggest that those two functions' kerneldoc be patched first to 
 explicitly state that passing in a NULL pointer is allowed.

Should my static source code analysis approach help you any more to clarify
further open issues?


 So I'll apply that change now for v4.3, touching up the commit message 
 accordingly.

Thanks for your constructive feedback.


  arch/arm/mach-omap2/omap_device.c | 3 +--
  arch/arm/mach-omap2/omap_hwmod.c  | 5 +
  arch/arm/mach-omap2/timer.c   | 3 +--

Did Tony Lindgren pick a similar update suggestion up, too?
https://lkml.org/lkml/2015/7/15/112

Regards,
Markus
--
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] add pwm capability to dm816x

[Paul Walmsley]

Hello Brian,

On Mon, 15 Jun 2015, Brian Hutchinson wrote:

 Clocks 4-7 are capable of PWM output on dm816x.
 
 This adds the pwm capability to those timers.
 
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Signed-off-by: Brian Hutchinson b.hutch...@gmail.com t...@atomide.com

This patch seems to be corrupted.  The above line doesn't look right; 
there are some spurious newlines in the patch header, and tabs seem to 
have been converted to whitespace.  Some of these issues may be due to 
mailer problems.  Could you please fix and try again?


- Paul

 
 --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c_orig 2015-06-15
 13:20:43.174343431 -0400
 +++ arch/arm/mach-omap2/omap_hwmod_81xx_data.c  2015-06-15
 13:34:51.770551392 -0400
 @@ -546,6 +546,14 @@ static struct omap_timer_capability_dev_
 .timer_capability   = OMAP_TIMER_ALWON,
  };
 
 +/* pwm timers dev attribute.
 + * timers 4-7 may be used for PWM output - see datasheet timer terminal
 + * functions table
 + */
 +static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = {
 +   .timer_capability   = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_PWM,
 +};
 +
  static struct omap_hwmod dm816x_timer1_hwmod = {
 .name   = timer1,
 .clkdm_name = alwon_l3s_clkdm,
 @@ -619,7 +627,7 @@ static struct omap_hwmod dm816x_timer4_h
 .modulemode = MODULEMODE_SWCTRL,
 },
 },
 -   .dev_attr   = capability_alwon_dev_attr,
 +   .dev_attr   = capability_pwm_dev_attr,
 .class  = dm816x_timer_hwmod_class,
  };
 
 @@ -640,7 +648,7 @@ static struct omap_hwmod dm816x_timer5_h
 .modulemode = MODULEMODE_SWCTRL,
 },
 },
 -   .dev_attr   = capability_alwon_dev_attr,
 +   .dev_attr   = capability_pwm_dev_attr,
 .class  = dm816x_timer_hwmod_class,
  };
 
 @@ -661,7 +669,7 @@ static struct omap_hwmod dm816x_timer6_h
 .modulemode = MODULEMODE_SWCTRL,
 },
 },
 -   .dev_attr   = capability_alwon_dev_attr,
 +   .dev_attr   = capability_pwm_dev_attr,
 .class  = dm816x_timer_hwmod_class,
  };
 
 @@ -682,7 +690,7 @@ static struct omap_hwmod dm816x_timer7_h
 .modulemode = MODULEMODE_SWCTRL,
 },
 },
 -   .dev_attr   = capability_alwon_dev_attr,
 +   .dev_attr   = capability_pwm_dev_attr,
 .class  = dm816x_timer_hwmod_class,
  };
 


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

Re: [GIT PULL] clk: ti: clock driver code migration to drivers

[Tero Kristo]

On 07/16/2015 04:51 AM, Paul Walmsley wrote:

On Tue, 14 Jul 2015, Tony Lindgren wrote:


* Tero Kristo t-kri...@ti.com [150714 03:34]:

On 07/14/2015 12:54 PM, Tony Lindgren wrote:

* Tero Kristo t-kri...@ti.com [150714 01:56]:


This pull request contains the TI clock driver set to move the clock
implementations under clock driver. Some small portions of the clock driver
code still remain under mach-omap2 after this, it should be decided whether
this code is now obsolete and should be deleted or should someone try to fix
it.


Hmm care to clarify what is obsolete or broken after this series?


Not after this series, was broken/obsolete already before.

A couple of omap2/omap3 specific clock files still remain under mach-omap2,
they are DVFS related. OMAP3 core dvfs support is currently completely
unused (this could probably be removed, or shall we re-introduce the painful
core dvfs at some point again?), and parts of the omap2 core dpll handling
code should probably be re-written; or at least verified that it actually
works properly. I can't test OMAP2 DVFS myself so don't dare to fiddle with
it I could probably try to get some sort of DVFS test case to work on
the board farm OMAP2 board I have access to though, I can investigate this.


People seem to still want the 1 GiHz support, but I think that only
depends on the SmartReflex and some kind of replacement for
voltagedomains. So if the core DVFS support is unused, I doubt it's
very high on anybody's list right now.


At least several years ago, basic CORE DVFS support was working on OMAP3.
The clock source changed rate, DRAM parameters were
changed on the SDRC, etc.  What was not implemented was pre-rate-change
and post-rate-change notifiers in many of the device drivers, because the
infrastructure didn't exist at the time in the clock code.


Yes this is true, Nokia did an internal implementation for the pre/post 
notifier stuff which was never accepted upstream. The core dvfs code is 
no longer used in kernel for anything, it is just built in. The 
usefulness of the whole feature can be debated also, the use cases where 
it actually gives power savings is rather limited.


I'll post a patch to remove the 'dead' core-dvfs code to the list, we 
can debate the issue there.


-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: Delete unnecessary checks before three function calls

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [150715 22:58]:
 Hello Markus
 
 On Tue, 30 Jun 2015, SF Markus Elfring wrote:
 
  From: Markus Elfring elfr...@users.sourceforge.net
  Date: Tue, 30 Jun 2015 14:00:16 +0200
  
  The functions clk_disable(), of_node_put() and omap_device_delete() test
  whether their argument is NULL and then return immediately.
  Thus the test around the call is not needed.
  
  This issue was detected by using the Coccinelle software.
  
  Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
 
 Thanks for the patch.  I have to say, I am a bit leery about applying the 
 omap_device.c and omap_hwmod.c changes, since the called functions -- 
 omap_device_delete() and clk_disable() -- don't explicitly document that 
 NULLs are allowed to be passed in.  So there's no explicit contract that 
 callers can rely upon, to (at least in theory) prevent those internal NULL 
 pointer checks from being removed.
 
 So I would suggest that those two functions' kerneldoc be patched first to 
 explicitly state that passing in a NULL pointer is allowed.  Then I would 
 feel a bit more comfortable applying the omap_device.c and omap_hwmod.c 
 changes.
 
 The kerneldoc for of_node_put() does explicitly allow NULLs to be passed 
 in.  So I'll apply that change now for v4.3, touching up the commit 
 message accordingly.

I have them applied from a later thread already, but will drop both in
my branch as I have not pushed them out yet.

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] Input: tsc2005 - convert to regmap

[Dmitry Torokhov]

On Wed, Jul 15, 2015 at 02:13:26PM +0200, Sebastian Reichel wrote:
 -static int tsc2005_write(struct tsc2005 *ts, u8 reg, u16 value)
 -{
 - u32 tx = ((reg | TSC2005_REG_PND0)  16) | value;
 - struct spi_transfer xfer = {
 - .tx_buf = tx,
 - .len= 4,
 - .bits_per_word  = 24,
 - };

I wonder why the original code used 24 bit-sized-words for transfers...

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

Re: [PATCH 4/4] ARM: omap2: restore OMAP4 barrier behaviour

[Tony Lindgren]

Hi,

* Russell King rmk+ker...@arm.linux.org.uk [150715 10:50]:
 Restore the OMAP4 barrier behaviour using the new implementation which
 allows multiplatform systems to hook into the mb() and wmb() ARM
 implementations to perform any necessary additional barrier maintanence.

I'm getthing this with omap2plus_defconfig with the last patch
applied:

arch/arm/mach-omap2/omap4-common.c: In function ‘omap4_sram_init’:
arch/arm/mach-omap2/omap4-common.c:138:14: error: implicit declaration of 
function ‘of_get_named_gen_pool’ [-Werror=implicit-function-declaration]
  sram_pool = of_get_named_gen_pool(np, sram, 0);
  ^
arch/arm/mach-omap2/omap4-common.c:138:12: warning: assignment makes pointer 
from integer without a cast [-Wint-conversion]
  sram_pool = of_get_named_gen_pool(np, sram, 0);
^
Regards,

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

Re: [PATCH] ARM: DRA7: Provide proper IO map table

[Tony Lindgren]

* Nishanth Menon n...@ti.com [150715 06:44]:
 On 07/15/2015 01:26 AM, Tony Lindgren wrote:
  * Nishanth Menon n...@ti.com [150622 08:14]:
  DRA7 uses OMAP5 IO table at the moment. This is purely spurious since
  the OMAP5 and DRA7 register maps are different in many aspects.
 
  AM57xx/DRA7 TRM Reference: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf
 
  NOTE: Most of the drivers are already doing ioremap, so, there should'nt
  be any functional improvement involved here, other than making the
  initial iotable more accurate.
 
  Fixes: a3a9384a1157 (ARM: DRA7: Reuse io tables and add a new 
  .init_early)
  Signed-off-by: Nishanth Menon n...@ti.com
  
  Is this needed for v4.2-rc or can this wait for v4.3 merge window?
 
 
 It can wait till 4.3 for sure. there is no known functional issue traced
 to this.

OK thanks applying into omap-for-v4.3/soc.

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 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

[Paul Walmsley]

On Thu, 16 Jul 2015, Tero Kristo wrote:

 On 07/16/2015 03:15 AM, Paul Walmsley wrote:
  On Tue, 14 Jul 2015, Tero Kristo wrote:
  
   On 07/14/2015 01:09 PM, Lokesh Vutla wrote:
Hi,
On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote:
 Some IP blocks like RTC, needs an additional unlocking mechanism for
 writing to its registers. This patch adds optional lock and unlock
 function pointers to the IP block's hwmod data which gets executed
 before and after writing into IP sysconfig register.
 And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod
 data,
 so that sysconfig registers are updated properly.
ping on this series.

Thanks and regards,
Lokesh
   
  
  [...]
  
   It is also racy, as there is no locking in place to avoid concurrent
   access to
   the lock/unlock registers across hwmod+driver.
  
  I don't see the race.  Where is it?
 
 See drivers/rtc/rtc-omap.c, am3352_rtc_unlock and am3352_rtc_lock.
 
 That code is accessing the exact same registers.

I guess my question is, when is it possible that code could race with the 
hwmod code for the same device?


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

Re: [PATCH v3 04/11] otg-fsm: move usb_bus_start_enum into otg-fsm-ops

[Roger Quadros]

On 16/07/15 03:54, Peter Chen wrote:
 On Wed, Jul 15, 2015 at 04:30:27PM +0300, Roger Quadros wrote:
 On 14/07/15 03:34, Peter Chen wrote:
 On Mon, Jul 13, 2015 at 01:13:54PM +0300, Roger Quadros wrote:
 Peter,

 On 13/07/15 04:58, Peter Chen wrote:
 On Wed, Jul 08, 2015 at 01:19:30PM +0300, Roger Quadros wrote:
 This is to prevent missing symbol build error if OTG is
 enabled (built-in) and HCD core (CONFIG_USB) is module.


 We may let the OTG-DRD/OTG-FSM depends on CONFIG_USB to fix it.

 CONFIG_OTG already depends on CONFIG_USB as it is a sub-option of
 CONFIG_USB. It doesn't depend on CONFIG_USB_GADGET and that can
 be fixed.

 But dependency is not the problem here. Symbols not available to
 OTG driver when USB/GADGET is 'm' is the problem.

 e.g.
 CONFIG_USB_OTG is always built-in.
 we need to work if CONFIG_USB is 'm'/'y'
 _and_ if CONFIG_USB_GADGET is 'm'/'y'


 below should fix this issue, but we may need to make some
 changes for code which are defined by CONFIG_USB_OTG.

 diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
 index a99c89e..5e374ad 100644
 --- a/drivers/usb/core/Kconfig
 +++ b/drivers/usb/core/Kconfig
 @@ -42,8 +42,9 @@ config USB_DYNAMIC_MINORS
   If you are unsure about this, say N here.

 config USB_OTG
 -   bool OTG support
 +   tristate OTG support
 depends on PM
 +   depends on USB  USB_GADGET
 default n
help
  The most notable feature of
  USB OTG is support for a

 With this USB_OTG will become 'm' when either USB or USB_GADGET is m
 and will break if either USB or USB_GADGET is made y as all OTG core
 API symbols won't be available. :)

 
 Ok, after thinking more, seems we can't handle properly if USB_OTG as
 'm', your idea that using host/gadget/fsm-ops to call hcd/gadget API
 and the controller driver will defines these ops (due to it will use
 hcd/gadget function) is proper way currently.
 

Can I take this as your Ack for this patch? :)

cheers,
-roger
--
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 05/12] ARM: OMAP2+: Add support for initializing dm814x clocks

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [150604 15:30]:
 * Stephen Boyd sb...@codeaurora.org [150604 11:44]:
  On 06/03, Tony Lindgren wrote:
   +#include linux/list.h
  
  Is list.h used?
...
   +static const char *enable_init_clks[] = {
   +};
  
  delete?
  
   +
   +int __init dm814x_dt_clk_init(void)
   +{
   + ti_dt_clocks_register(dm814_clks);
   + omap2_clk_disable_autoidle_all();
   + omap2_clk_enable_init_clocks(enable_init_clks,
   +  ARRAY_SIZE(enable_init_clks));
  
  And pass NULL and 0 here?
 
 Sure will remove, we can add those back once the PLL parts are
 working and if/when some boot time clocks are needed.

Here's this patch updated with the above removed.

Regards,

Tony

8 -
From: Tony Lindgren t...@atomide.com
Date: Thu, 16 Jul 2015 01:55:57 -0700
Subject: [PATCH] ARM: OMAP2+: Add support for initializing dm814x clocks

Let's add a minimal clocks for dm814x to get it booted. This is
mostly a placeholder and relies on the PLLs being on from the
bootloader.

Note that the divider clocks work the same way as on dm816x and
am335x.

Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -558,7 +558,7 @@ void __init ti814x_init_early(void)
ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
-   omap_clk_soc_init = ti81xx_dt_clk_init;
+   omap_clk_soc_init = dm814x_dt_clk_init;
 }
 
 void __init ti816x_init_early(void)
@@ -575,7 +575,7 @@ void __init ti816x_init_early(void)
ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
-   omap_clk_soc_init = ti81xx_dt_clk_init;
+   omap_clk_soc_init = dm816x_dt_clk_init;
 }
 #endif
 
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -2,7 +2,7 @@ obj-y   += clk.o autoidle.o 
clockdomain.o
 clk-common = dpll.o composite.o divider.o gate.o \
  fixed-factor.o mux.o apll.o
 obj-$(CONFIG_SOC_AM33XX)   += $(clk-common) clk-33xx.o
-obj-$(CONFIG_SOC_TI81XX)   += $(clk-common) fapll.o clk-816x.o
+obj-$(CONFIG_SOC_TI81XX)   += $(clk-common) fapll.o clk-814x.o 
clk-816x.o
 obj-$(CONFIG_ARCH_OMAP2)   += $(clk-common) interface.o clk-2xxx.o
 obj-$(CONFIG_ARCH_OMAP3)   += $(clk-common) interface.o \
   clk-3xxx.o
--- /dev/null
+++ b/drivers/clk/ti/clk-814x.c
@@ -0,0 +1,31 @@
+/*
+ * 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 the Free Software Foundation version 2.
+ */
+
+#include linux/kernel.h
+#include linux/clk-provider.h
+#include linux/clk/ti.h
+
+static struct ti_dt_clk dm814_clks[] = {
+   DT_CLK(NULL, devosc_ck, devosc_ck),
+   DT_CLK(NULL, mpu_ck, mpu_ck),
+   DT_CLK(NULL, sysclk4_ck, sysclk4_ck),
+   DT_CLK(NULL, sysclk6_ck, sysclk6_ck),
+   DT_CLK(NULL, sysclk10_ck, sysclk10_ck),
+   DT_CLK(NULL, sysclk18_ck, sysclk18_ck),
+   DT_CLK(NULL, timer_sys_ck, devosc_ck),
+   DT_CLK(NULL, cpsw_125mhz_gclk, cpsw_125mhz_gclk),
+   DT_CLK(NULL, cpsw_cpts_rft_clk, cpsw_cpts_rft_clk),
+   { .node_name = NULL },
+};
+
+int __init dm814x_dt_clk_init(void)
+{
+   ti_dt_clocks_register(dm814_clks);
+   omap2_clk_disable_autoidle_all();
+   omap2_clk_enable_init_clocks(NULL, 0);
+
+   return 0;
+}
--- a/drivers/clk/ti/clk-816x.c
+++ b/drivers/clk/ti/clk-816x.c
@@ -42,7 +42,7 @@ static const char *enable_init_clks[] = {
ddr_pll_clk3,
 };
 
-int __init ti81xx_dt_clk_init(void)
+int __init dm816x_dt_clk_init(void)
 {
ti_dt_clocks_register(dm816x_clks);
omap2_clk_disable_autoidle_all();
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -329,7 +329,8 @@ int ti_clk_add_component(struct device_node *node, struct 
clk_hw *hw, int type);
 int omap3430_dt_clk_init(void);
 int omap3630_dt_clk_init(void);
 int am35xx_dt_clk_init(void);
-int ti81xx_dt_clk_init(void);
+int dm814x_dt_clk_init(void);
+int dm816x_dt_clk_init(void);
 int omap4xxx_dt_clk_init(void);
 int omap5xxx_dt_clk_init(void);
 int dra7xx_dt_clk_init(void);
--
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+: hwmod: Fix _wait_target_ready() for hwmods without sysc

[Roger Quadros]

Paul,

On 16/07/15 04:47, Paul Walmsley wrote:
 Hi Roger
 
 On Mon, 13 Jul 2015, Roger Quadros wrote:
 
 There are quite a few hwmods that don't have sysconfig register and so
 _find_mpu_rt_port(oh) will return NULL thus preventing ready state check
 on those modules after the module is enabled.

 This can potentially cause a bus access error if the module is accessed
 before the module is ready.

 Get rid of the redundant _find_mpu_rt_port() check from the 
 _wait_target_ready()
 funcion for all the SoCs. The following PRCM register access that checks the
 module ready state has nothing to do with module's SYSCONFIG or mpu_rt_port.

 e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.
 
 Could you update this patch to align with the discussion we had the 
 last time this was posted in December?  e.g., 
 
 http://www.spinics.net/lists/arm-kernel/msg388002.html
 
 You can ignore the problems with the VAR-SOM-OM that were discussed; those 
 were indeed due to an old DT file in use, as Suman suspected.
 
 Let me know if you have any questions about it -

My bad. I forgot that I had posted this earlier and totally missed that thread. 
:P

cheers,
-roger
--
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/4] Input: tsc2005 - convert to gpiod

[Sebastian Reichel]

On Wed, Jul 15, 2015 at 05:25:32PM -0700, Dmitry Torokhov wrote:
 On Thu, Jul 16, 2015 at 12:09:41AM +0200, Sebastian Reichel wrote:
  On Wed, Jul 15, 2015 at 02:34:04PM -0700, Dmitry Torokhov wrote:
   [...]
if (np) {
-   ts-reset_gpio = of_get_named_gpio(np, reset-gpios, 
0);
-   if (ts-reset_gpio == -EPROBE_DEFER)
-   return ts-reset_gpio;
-   if (ts-reset_gpio  0) {
+   ts-reset_gpio = devm_gpiod_get(spi-dev, reset,
+   GPIOD_OUT_HIGH);
   
   I think we should treat the gpio as optional and try to get the
   descriptor event on non-OF boards.
  
  As I wrote in the cover letter, I suggest to change this once the
  Nokia N900 board code has been removed. At that point changing the
  board code API is much easier, since it won't affect multiple trees.
 
 I do not see why it has be wait for Nokia board code. Just make it
 devm_gpiod_get_optional() and call it unconditionally and fall back onto
 custom reset function (if one is supplied).

Right. I guess the same could be done for vio regulator. I will
add this change in the next version of the patchset.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 02/12] ARM: OMAP2+: Fix scrm compatible for dm814x

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [150603 12:39]:
 * Sergei Shtylyov sergei.shtyl...@cogentembedded.com [150603 12:10]:
  Hello.
  
  On 06/03/2015 07:23 PM, Tony Lindgren wrote:
  
  Fix scrm compatible for dm814x.
  
 So, scrm...
  
  Cc: Matthijs van Duin matthijsvand...@gmail.com
  Signed-off-by: Tony Lindgren t...@atomide.com
  ---
arch/arm/mach-omap2/control.c | 1 +
1 file changed, 1 insertion(+)
  
  diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
  index af95a62..364925c 100644
  --- a/arch/arm/mach-omap2/control.c
  +++ b/arch/arm/mach-omap2/control.c
  @@ -649,6 +649,7 @@ static const struct of_device_id 
  omap_scrm_dt_match_table[] = {
 { .compatible = ti,am4-scm, .data = ctrl_data },
 { .compatible = ti,omap2-scm, .data = omap2_ctrl_data },
 { .compatible = ti,omap3-scm, .data = omap2_ctrl_data },
  +  { .compatible = ti,dm814-scm, .data = ctrl_data },
  
 ... or scm? :-)
  
 { .compatible = ti,dm816-scrm, .data = ctrl_data },
 { .compatible = ti,omap4-scm-core, .data = ctrl_data },
 { .compatible = ti,omap5-scm-core, .data = ctrl_data },
 
 Thanks, yeah we should standardize on scm.

Below is this one updated to use scm instead of scrm in the
description.

Regards,

Tony

8 ---
From: Tony Lindgren t...@atomide.com
Date: Thu, 16 Jul 2015 01:55:57 -0700
Subject: [PATCH] ARM: OMAP2+: Fix scm compatible for dm814x

Fix scm compatible for dm814x.

Cc: Matthijs van Duin matthijsvand...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -652,6 +652,7 @@ static const struct of_device_id omap_scrm_dt_match_table[] 
= {
{ .compatible = ti,am4-scm, .data = ctrl_data },
{ .compatible = ti,omap2-scm, .data = omap2_ctrl_data },
{ .compatible = ti,omap3-scm, .data = omap2_ctrl_data },
+   { .compatible = ti,dm814-scm, .data = ctrl_data },
{ .compatible = ti,dm816-scrm, .data = ctrl_data },
{ .compatible = ti,omap4-scm-core, .data = ctrl_data },
{ .compatible = ti,omap5-scm-core, .data = ctrl_data },
--
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 0/4] ARM: omap2plus_defconfig updates

[Tony Lindgren]

* Sekhar Nori nsek...@ti.com [150708 08:30]:
 Hi Tony,
 
 Here are some defconfig updates for commonly
 used drivers on platforms supported by
 omap2plus_defconfig.
 
 Applies to v4.2-rc1
 
 Thanks,
 Sekhar
 
 Sekhar Nori (4):
   ARM: omap2plus_defconfig: enable support for TI ADC
   ARM: omap2plus_defconfig: enable support for TI touchscreen
   ARM: omap2plus_defconfig: enable support for TI CPTS
   ARM: omap2plus_defconfig: enable support for M25P80 SPI NOR
 
  arch/arm/configs/omap2plus_defconfig | 7 +++
  1 file changed, 7 insertions(+)

Applying all into omap-for-v4.3/defconfig 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

[PATCH] ARM: OMAP3: clock: remove un-used core dpll re-program code

[Tero Kristo]

Remove the OMAP3 core DPLL re-program code, and the associated SRAM
code that does the low-level programming of the DPLL divider, idling
of the SDRAM etc.

This code was never fully implemented in the kernel; things missing
were driver side handling of core clock changes (they need to account
for their functional clock rate being changed on-the-fly), and the whole
framework required for handling this. Thus, there is not much point
to keep carrying the low-level support code either.

Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/Makefile   |3 +-
 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |  119 ---
 arch/arm/mach-omap2/sram.c |   25 ---
 arch/arm/mach-omap2/sram.h |   14 --
 arch/arm/mach-omap2/sram34xx.S |  346 
 5 files changed, 1 insertion(+), 506 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/clkt34xx_dpll3m2.c
 delete mode 100644 arch/arm/mach-omap2/sram34xx.S

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 903c85b..66129b6 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -49,7 +49,6 @@ AFLAGS_sleep44xx.o
:=-Wa,-march=armv7-a$(plus_sec)
 # Functions loaded to SRAM
 obj-$(CONFIG_SOC_OMAP2420) += sram242x.o
 obj-$(CONFIG_SOC_OMAP2430) += sram243x.o
-obj-$(CONFIG_ARCH_OMAP3)   += sram34xx.o
 
 AFLAGS_sram242x.o  :=-Wa,-march=armv6
 AFLAGS_sram243x.o  :=-Wa,-march=armv6
@@ -188,7 +187,7 @@ obj-$(CONFIG_ARCH_OMAP2)+= 
clkt2xxx_virt_prcm_set.o
 obj-$(CONFIG_ARCH_OMAP2)   += clkt2xxx_dpll.o clkt_iclk.o
 obj-$(CONFIG_SOC_OMAP2430) += clock2430.o
 obj-$(CONFIG_ARCH_OMAP3)   += $(clock-common) clock3xxx.o
-obj-$(CONFIG_ARCH_OMAP3)   += clock34xx.o clkt34xx_dpll3m2.o
+obj-$(CONFIG_ARCH_OMAP3)   += clock34xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += clock3517.o clock36xx.o
 obj-$(CONFIG_ARCH_OMAP3)   += dpll3xxx.o
 obj-$(CONFIG_ARCH_OMAP3)   += clkt_iclk.o
diff --git a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c 
b/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
deleted file mode 100644
index eb69acf..000
--- a/arch/arm/mach-omap2/clkt34xx_dpll3m2.c
+++ /dev/null
@@ -1,119 +0,0 @@
-/*
- * OMAP34xx M2 divider clock code
- *
- * Copyright (C) 2007-2008 Texas Instruments, Inc.
- * Copyright (C) 2007-2010 Nokia Corporation
- *
- * Paul Walmsley
- * Jouni Högander
- *
- * Parts of this code are based on code written by
- * Richard Woodruff, Tony Lindgren, Tuukka Tikkanen, Karthik Dasu
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#undef DEBUG
-
-#include linux/kernel.h
-#include linux/errno.h
-#include linux/clk.h
-#include linux/io.h
-
-#include clock.h
-#include clock3xxx.h
-#include clock34xx.h
-#include sdrc.h
-#include sram.h
-
-#define CYCLES_PER_MHZ 100
-
-/*
- * CORE DPLL (DPLL3) M2 divider rate programming functions
- *
- * These call into SRAM code to do the actual CM writes, since the SDRAM
- * is clocked from DPLL3.
- */
-
-/**
- * omap3_core_dpll_m2_set_rate - set CORE DPLL M2 divider
- * @clk: struct clk * of DPLL to set
- * @rate: rounded target rate
- *
- * Program the DPLL M2 divider with the rounded target rate.  Returns
- * -EINVAL upon error, or 0 upon success.
- */
-int omap3_core_dpll_m2_set_rate(struct clk_hw *hw, unsigned long rate,
-   unsigned long parent_rate)
-{
-   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
-   u32 new_div = 0;
-   u32 unlock_dll = 0;
-   u32 c;
-   unsigned long validrate, sdrcrate, _mpurate;
-   struct omap_sdrc_params *sdrc_cs0;
-   struct omap_sdrc_params *sdrc_cs1;
-   int ret;
-   unsigned long clkrate;
-
-   if (!clk || !rate)
-   return -EINVAL;
-
-   validrate = omap2_clksel_round_rate_div(clk, rate, new_div);
-   if (validrate != rate)
-   return -EINVAL;
-
-   sdrcrate = __clk_get_rate(sdrc_ick_p);
-   clkrate = __clk_get_rate(hw-clk);
-   if (rate  clkrate)
-   sdrcrate = ((rate / clkrate)  1);
-   else
-   sdrcrate = ((clkrate / rate)  1);
-
-   ret = omap2_sdrc_get_params(sdrcrate, sdrc_cs0, sdrc_cs1);
-   if (ret)
-   return -EINVAL;
-
-   if (sdrcrate  MIN_SDRC_DLL_LOCK_FREQ) {
-   pr_debug(clock: will unlock SDRC DLL\n);
-   unlock_dll = 1;
-   }
-
-   /*
-* XXX This only needs to be done when the CPU frequency changes
-*/
-   _mpurate = __clk_get_rate(arm_fck_p) / CYCLES_PER_MHZ;
-   c = (_mpurate  SDRC_MPURATE_SCALE)  

Re: [4.2-rc1][PATCH] gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type

[Linus Walleij]

On Wed, Jun 24, 2015 at 4:54 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:

 From: Grygorii Strashko grygorii.stras...@linaro.org

 Add missed spin_unlock_irqrestore in omap_gpio_irq_type when
 omap_set_gpio_triggering() is failed.

 It fixes static checker warning:

 drivers/gpio/gpio-omap.c:523 omap_gpio_irq_type()
 warn: inconsistent returns 'spin_lock:bank-lock'.

 This fixes commit:
 1562e4618ded ('gpio: omap: fix error handling in omap_gpio_irq_type')

 Reported-by: Javier Martinez Canillas jav...@dowhile0.org
 Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org

Patch applied for fixes.

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

Re: [PATCH 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

[Tero Kristo]

On 07/16/2015 03:15 AM, Paul Walmsley wrote:

On Tue, 14 Jul 2015, Tero Kristo wrote:


On 07/14/2015 01:09 PM, Lokesh Vutla wrote:

Hi,
On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote:

Some IP blocks like RTC, needs an additional unlocking mechanism for
writing to its registers. This patch adds optional lock and unlock
function pointers to the IP block's hwmod data which gets executed
before and after writing into IP sysconfig register.
And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod data,
so that sysconfig registers are updated properly.

ping on this series.

Thanks and regards,
Lokesh




[...]


It is also racy, as there is no locking in place to avoid concurrent access to
the lock/unlock registers across hwmod+driver.


I don't see the race.  Where is it?


See drivers/rtc/rtc-omap.c, am3352_rtc_unlock and am3352_rtc_lock.

That code is accessing the exact same registers.

-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

[PATCH 2/2] ARM: dts: Add phyBOARD-WEGA-AM335x rdk

[Teresa Remmet]

phyBOARD-WEGA-AM335x represents a direct soldered
combination of a phyCORE-AM335x SoM and carrier board.

Different kind of SoM options can be connected to
the wega carrier board. So we created a separate
wega dtsi file. The final dts contains the actual
SoM on the carrier board.

WEGA carrier board features:
* ETH phy on carrier board: 1x MII
* 1x CAN
* 2x UART
* USB0 (device)
* USB1 (host)
* mSD slot

Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
 .../devicetree/bindings/arm/omap/omap.txt  |   3 +
 arch/arm/boot/dts/Makefile |   3 +-
 arch/arm/boot/dts/am335x-wega-rdk.dts  |  22 +++
 arch/arm/boot/dts/am335x-wega.dtsi | 151 +
 4 files changed, 178 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/am335x-wega-rdk.dts
 create mode 100644 arch/arm/boot/dts/am335x-wega.dtsi

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt 
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 4f6a82c..9f4e513 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -135,6 +135,9 @@ Boards:
 - AM335X OrionLXm : Substation Automation Platform
   compatible = novatech,am335x-lxm, ti,am33xx
 
+- AM335X phyBOARD-WEGA: Single Board Computer dev kit
+  compatible = phytec,am335x-wega, phytec,am335x-phycore-som, ti,am33xx
+
 - OMAP5 EVM : Evaluation Module
   compatible = ti,omap5-evm, ti,omap5
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..b6393df 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -438,7 +438,8 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-nano.dtb \
am335x-pepper.dtb \
am335x-lxm.dtb \
-   am335x-chiliboard.dtb
+   am335x-chiliboard.dtb \
+   am335x-wega-rdk.dtb
 dtb-$(CONFIG_ARCH_OMAP4) += \
omap4-duovero-parlor.dtb \
omap4-panda.dtb \
diff --git a/arch/arm/boot/dts/am335x-wega-rdk.dts 
b/arch/arm/boot/dts/am335x-wega-rdk.dts
new file mode 100644
index 000..6431b7d
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-wega-rdk.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet t.rem...@phytec.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include am335x-phycore-som.dtsi
+#include am335x-wega.dtsi
+
+/* SoM */
+i2c_eeprom {
+   status = okay;
+};
+
+i2c_rtc {
+   status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi 
b/arch/arm/boot/dts/am335x-wega.dtsi
new file mode 100644
index 000..5e541bd
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet t.rem...@phytec.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/ {
+   model = Phytec AM335x phyBOARD-WEGA;
+   compatible = phytec,am335x-wega, phytec,am335x-phycore-som, 
ti,am33xx;
+
+};
+
+/* CAN Busses */
+am33xx_pinmux {
+   dcan1_pins: pinmux_dcan1 {
+   pinctrl-single,pins = 
+   0x168 (PIN_OUTPUT_PULLUP | MUX_MODE2) /* 
uart0_ctsn.d_can1_tx */
+   0x16c (PIN_INPUT_PULLUP | MUX_MODE2) /* 
uart0_rtsn.d_can1_rx */
+   ;
+   };
+};
+
+dcan1 {
+   pinctrl-names = default;
+   pinctrl-0 = dcan1_pins;
+   status = okay;
+};
+
+/* Ethernet */
+am33xx_pinmux {
+   ethernet1_pins: pinmux_ethernet1 {
+   pinctrl-single,pins = 
+   0x40 (PIN_OUTPUT | MUX_MODE1)   /* 
gpmc_a0.mii2_txen */
+   0x44 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a1.mii2_rxdv */
+   0x48 (PIN_OUTPUT | MUX_MODE1)   /* 
gpmc_a2.mii2_txd3 */
+   0x4c (PIN_OUTPUT | MUX_MODE1)   /* 
gpmc_a3.mii2_txd2 */
+   0x50 (PIN_OUTPUT | MUX_MODE1)   /* 
gpmc_a4.mii2_txd1 */
+   0x54 (PIN_OUTPUT | MUX_MODE1)   /* 
gpmc_a5.mii2_txd0 */
+   0x58 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a6.mii2_txclk */
+   0x5c (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a7.mii2_rxclk */
+   0x60 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a8.mii2_rxd3 */
+   0x64 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a9.mii2_rxd2 */
+   0x68 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a10.mii2_rxd1 */
+   0x6c (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_a11.mii2_rxd0 */
+   0x74 (PIN_INPUT_PULLDOWN | MUX_MODE1)   /* 
gpmc_wpn.mii2_rxerr */
+  

Re: [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer

[Tony Lindgren]

* Suman Anna s-a...@ti.com [150710 13:45]:
 The OMAP IOMMU driver has been adapted to the IOMMU framework
 for a while now, and it no longer supports being built as a
 module. Cleanup all the module related references both from
 the code and in the build.
 
 While at it, also relocate a comment around the initcall to
 avoid a checkpatch strict warning about using a blank line
 after function/struct/union/enum declarations.

OK applying into omap-for-v4.3/soc.

You may want to check few things after this:

- Does it still need to be omap_subsys_initcall or can it
  happen later? Anything we can initialize later on is worth
  doing as then we have proper debug console available.

- For multi_v7_defconfig it would be nice to be able to
  make the driver/iommu components into standard Linux
  loadable modules.

- Actually you can probably get rid of mach-omap2/omap-iommu.c
  completely by implementing PM runtime and and possibly
  reset controller.

Regrds,

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

[PATCH 1/1] ARM: dts: omap3: correct the format of u16 values for tsc2046 node

[Fugang Duan]

From: Fugang Duan b38...@freescale.com

In tsc2046 touch driver, the values such as ti,x-min is defined as a u16
value. the driver use API of_property_read_u16() read the value. For these
u16 value, the dts entry should be like:
property = /bits/ 16 0x5000;
This describes the property as a u16 value.

Signed-off-by: Fugang Duan b38...@freescale.com
---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index e631333..d0dd036 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -319,12 +319,12 @@
pinctrl-names = default;
pinctrl-0 = tsc2048_pins;
 
-   ti,x-min = 300;
-   ti,x-max = 3000;
-   ti,y-min = 600;
-   ti,y-max = 3600;
-   ti,x-plate-ohms = 80;
-   ti,pressure-max = 255;
+   ti,x-min = /bits/ 16 300;
+   ti,x-max = /bits/ 16 3000;
+   ti,y-min = /bits/ 16 600;
+   ti,y-max = /bits/ 16 3600;
+   ti,x-plate-ohms = /bits/ 16 80;
+   ti,pressure-max = /bits/ 16 255;
ti,swap-xy;
 
linux,wakeup;
-- 
1.9.1

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

[PATCH 1/2] ARM: dts: Add support for phyCORE-AM335x SoM

[Teresa Remmet]

phyCORE-AM335x is a SoM (System on Module) containing
a AM335x SOC. The module can be connected to different
carrier boards.

Some hardware parts are configurable on the phyCORE-AM335x.
So they are disabled on default in this som dtsi file.
They will be enabled in the board dts files, when populated.

* RAM up to 1GiB
* PMIC
* NAND flash up to 1GiB
* Eth PHY on SOM: 1x RMII
* SPI NOR flash 8MiB (optional)
* i2c RTC (optional)
* i2c EEPROM 4kiB (optional)

Signed-off-by: Teresa Remmet t.rem...@phytec.de
---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 368 ++
 1 file changed, 368 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-phycore-som.dtsi

diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi 
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
new file mode 100644
index 000..4d28fc3
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,368 @@
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet t.rem...@phytec.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include am33xx.dtsi
+
+/ {
+   model = Phytec AM335x phyCORE;
+   compatible = phytec,am335x-phycore-som, ti,am33xx;
+
+   aliases {
+   rtc0 = i2c_rtc;
+   rtc1 = rtc;
+   };
+
+   cpus {
+   cpu@0 {
+   cpu0-supply = vdd1_reg;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x1000; /* 256 MB */
+   };
+
+   vbat: fixedregulator@0 {
+   compatible = regulator-fixed;
+   };
+};
+
+/* Crypto Module */
+aes {
+   status = okay;
+};
+
+sham {
+   status = okay;
+};
+
+/* Ethernet */
+am33xx_pinmux {
+   ethernet0_pins: pinmux_ethernet0 {
+   pinctrl-single,pins = 
+   0x10c (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* 
mii1_crs.rmii1_crs_dv */
+   0x110 (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* 
mii1_rxerr.rmii1_rxerr */
+   0x114 (PIN_OUTPUT | MUX_MODE1)  /* 
mii1_txen.rmii1_txen */
+   0x124 (PIN_OUTPUT | MUX_MODE1)  /* 
mii1_txd1.rmii1_txd1 */
+   0x128 (PIN_OUTPUT | MUX_MODE1)  /* 
mii1_txd0.rmii1_txd0 */
+   0x13c (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* 
mii1_rxd1.rmii1_rxd1 */
+   0x140 (PIN_INPUT_PULLDOWN | MUX_MODE1)  /* 
mii1_rxd0.rmii1_rxd0 */
+   0x144 (PIN_INPUT_PULLDOWN | MUX_MODE0)  /* 
rmii1_refclk.rmii1_refclk */
+   ;
+   };
+
+   mdio_pins: pinmux_mdio {
+   pinctrl-single,pins = 
+   /* MDIO */
+   0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+   0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)   
/* mdio_clk.mdio_clk */
+   ;
+   };
+};
+
+cpsw_emac0 {
+   phy_id = davinci_mdio, 0;
+   phy-mode = rmii;
+   dual_emac_res_vlan = 1;
+};
+
+davinci_mdio {
+   pinctrl-names = default;
+   pinctrl-0 = mdio_pins;
+   status = okay;
+};
+
+mac {
+   slaves = 1;
+   pinctrl-names = default;
+   pinctrl-0 = ethernet0_pins;
+   status = okay;
+};
+
+phy_sel {
+   rmii-clock-ext;
+};
+
+/* I2C Busses */
+am33xx_pinmux {
+   i2c0_pins: pinmux_i2c0 {
+   pinctrl-single,pins = 
+   0x188 (PIN_INPUT | MUX_MODE0)   /* i2c0_sda.i2c0_sda */
+   0x18c (PIN_INPUT | MUX_MODE0)   /* i2c0_scl.i2c0_scl */
+   ;
+   };
+};
+
+i2c0 {
+   pinctrl-names = default;
+   pinctrl-0 = i2c0_pins;
+   clock-frequency = 40;
+   status = okay;
+
+   tps: pmic@2d {
+   reg = 0x2d;
+   };
+
+   i2c_eeprom: eeprom@52 {
+   compatible = atmel,24c32;
+   pagesize = 32;
+   reg = 0x52;
+   status = disabled;
+   };
+
+   i2c_rtc: rtc@68 {
+   compatible = rv4162;
+   reg = 0x68;
+   status = disabled;
+   };
+};
+
+/* NAND memory */
+am33xx_pinmux {
+   nandflash_pins: pinmux_nandflash {
+   pinctrl-single,pins = 
+   0x0 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad0.gpmc_ad0 */
+   0x4 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad1.gpmc_ad1 */
+   0x8 (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad2.gpmc_ad2 */
+   0xc (PIN_INPUT_PULLUP | MUX_MODE0)  /* 
gpmc_ad3.gpmc_ad3 */
+   0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad4.gpmc_ad4 */
+   0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /* 
gpmc_ad5.gpmc_ad5 */
+ 

Re: [PATCH 3/3] ARM: AMx3xx: hwmod: RTC: Add lock and unlock functions

[Lokesh Vutla]

Hi Paul,
On Thursday 16 July 2015 05:44 AM, Paul Walmsley wrote:

Hi

On Wed, 10 Jun 2015, Lokesh Vutla wrote:


RTC IP have kicker feature which prevents spurious writes to its registers.
In order to write into any of the RTC registers, KICK values has to be
written to KICK registers.

omap_hwmod_rtc_unlock/lock functions writes into these KICK registers
inorder to lock and unlock RTC registers.
This patch hooks omap_hwmod_rtc_unlock/lock functions into RTC hwmod,
so that SYSCONFIG register is updated properly.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index cabc569..2d92958 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -904,6 +904,8 @@ static struct omap_hwmod_class_sysconfig am33xx_rtc_sysc = {
  static struct omap_hwmod_class am33xx_rtc_hwmod_class = {
.name   = rtc,
.sysc   = am33xx_rtc_sysc,
+   .unlock = omap_hwmod_rtc_unlock,
+   .lock   = omap_hwmod_rtc_lock,
  };

  struct omap_hwmod am33xx_rtc_hwmod = {


The DRA7xx integration from the previous patch should either be combined
with this patch, or moved into a separate patch like this one (your
preference).

Ill make a separate patch for DRA7xx integration and repost it.

Thanks and regards,
Lokesh



- Paul


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

[PATCH 0/2] omap3isp: Remove legacy platform data support

[Laurent Pinchart]

Hello,

Now that all users of the OMAP3 ISP have switched to DT, this patch series
removes support for legacy platform data support in the omap3isp driver. It
also drops the OMAP3 ISP device instantiation board code that is now unused.

Patch 2/2 depends on 1/2. From a conflict resolution point of view it would be
easier to merge the whole series through the linux-media tree. Tony, would
that be fine with you ? If so could you please ack patch 1/2 ?

Laurent Pinchart (2):
  ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
  v4l: omap3isp: Drop platform data support

 arch/arm/mach-omap2/devices.c   |  53 --
 arch/arm/mach-omap2/devices.h   |  19 
 drivers/media/platform/Kconfig  |   2 +-
 drivers/media/platform/omap3isp/isp.c   | 133 ---
 drivers/media/platform/omap3isp/isp.h   |   7 +-
 drivers/media/platform/omap3isp/ispcsiphy.h |   2 +-
 drivers/media/platform/omap3isp/ispvideo.c  |   9 +-
 drivers/media/platform/omap3isp/omap3isp.h  | 132 +++
 include/media/omap3isp.h| 158 
 9 files changed, 158 insertions(+), 357 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/devices.h
 create mode 100644 drivers/media/platform/omap3isp/omap3isp.h
 delete mode 100644 include/media/omap3isp.h

-- 
Regards,

Laurent Pinchart

--
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: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Laurent Pinchart]

The OMAP3 ISP is now fully supported in DT, remove its instantiation
from C code.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 arch/arm/mach-omap2/devices.c | 53 ---
 arch/arm/mach-omap2/devices.h | 19 
 2 files changed, 72 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/devices.h

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index a69bd67e9028..9374da313e8e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -33,7 +33,6 @@
 #include common.h
 #include mux.h
 #include control.h
-#include devices.h
 #include display.h
 
 #define L3_MODULES_MAX_LEN 12
@@ -67,58 +66,6 @@ static int __init omap3_l3_init(void)
 }
 omap_postcore_initcall(omap3_l3_init);
 
-#if defined(CONFIG_IOMMU_API)
-
-#include linux/platform_data/iommu-omap.h
-
-static struct resource omap3isp_resources[] = {
-   {
-   .start  = OMAP3430_ISP_BASE,
-   .end= OMAP3430_ISP_BASE + 0x12fc,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = OMAP3430_ISP_BASE2,
-   .end= OMAP3430_ISP_BASE2 + 0x0600,
-   .flags  = IORESOURCE_MEM,
-   },
-   {
-   .start  = 24 + OMAP_INTC_START,
-   .flags  = IORESOURCE_IRQ,
-   }
-};
-
-static struct platform_device omap3isp_device = {
-   .name   = omap3isp,
-   .id = -1,
-   .num_resources  = ARRAY_SIZE(omap3isp_resources),
-   .resource   = omap3isp_resources,
-};
-
-static struct omap_iommu_arch_data omap3_isp_iommu = {
-   .name = mmu_isp,
-};
-
-int omap3_init_camera(struct isp_platform_data *pdata)
-{
-   if (of_have_populated_dt())
-   omap3_isp_iommu.name = 480bd400.mmu;
-
-   omap3isp_device.dev.platform_data = pdata;
-   omap3isp_device.dev.archdata.iommu = omap3_isp_iommu;
-
-   return platform_device_register(omap3isp_device);
-}
-
-#else /* !CONFIG_IOMMU_API */
-
-int omap3_init_camera(struct isp_platform_data *pdata)
-{
-   return 0;
-}
-
-#endif
-
 #if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
 static inline void __init omap_init_mbox(void)
 {
diff --git a/arch/arm/mach-omap2/devices.h b/arch/arm/mach-omap2/devices.h
deleted file mode 100644
index f61eb6e5d136..
--- a/arch/arm/mach-omap2/devices.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/*
- * arch/arm/mach-omap2/devices.h
- *
- * OMAP2 platform device setup/initialization
- *
- * 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
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#ifndef __ARCH_ARM_MACH_OMAP_DEVICES_H
-#define __ARCH_ARM_MACH_OMAP_DEVICES_H
-
-struct isp_platform_data;
-
-int omap3_init_camera(struct isp_platform_data *pdata);
-
-#endif
-- 
2.3.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 0/2] ARM: dts: dra7x-evm: fix incorrect compatibles

[Sekhar Nori]

Hi Tony,

Here non-critical compatible name fix
for DRA7x EVM for v4.3

Thanks,
Sekhar

Sekhar Nori (2):
  ARM: dts: dra7-evm: fix compatible name for pcf8575
  ARM: dts: dra72-evm: fix compatible name for pcf8575

 arch/arm/boot/dts/dra7-evm.dts  | 2 +-
 arch/arm/boot/dts/dra72-evm.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.4.4.408.g16da57c

--
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: OMAP2+: Remove legacy booting support for Pandora

[Tony Lindgren]

We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

This board has support for device tree based booting, and we've been
printing warnings about the legacy booting being deprecated for a
few merge cycles now. Let's attempt to remove the legacy booting
for it.

The reason for removing the legacy booting support now rather than
later is we can simply revert this patch if necessary if we run
into some unexpected issues that are not trivial to fix for the
device tree based booting.

Cc: Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Makefile |   1 -
 arch/arm/mach-omap2/board-omap3pandora.c | 633 ---
 2 files changed, 634 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9e4b17a..9bb78a8 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -243,7 +243,6 @@ obj-$(CONFIG_SOC_OMAP2420)  += msdi.o
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o 
pdata-quirks.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
-obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o sdram-nokia.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51-peripherals.o
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c 
b/arch/arm/mach-omap2/board-omap3pandora.c
deleted file mode 100644
index 969e100..000
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ /dev/null
@@ -1,633 +0,0 @@
-/*
- * board-omap3pandora.c (Pandora Handheld Console)
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include linux/init.h
-#include linux/kernel.h
-#include linux/platform_device.h
-
-#include linux/spi/spi.h
-#include linux/regulator/machine.h
-#include linux/i2c/twl.h
-#include linux/omap-gpmc.h
-#include linux/wl12xx.h
-#include linux/mtd/partitions.h
-#include linux/mtd/nand.h
-#include linux/leds.h
-#include linux/input.h
-#include linux/input/matrix_keypad.h
-#include linux/gpio.h
-#include linux/gpio_keys.h
-#include linux/mmc/host.h
-#include linux/mmc/card.h
-#include linux/regulator/fixed.h
-#include linux/usb/phy.h
-#include linux/platform_data/spi-omap2-mcspi.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-#include video/omapdss.h
-#include video/omap-panel-data.h
-#include linux/platform_data/mtd-nand-omap2.h
-
-#include mux.h
-#include sdram-micron-mt46h32m32lf-6.h
-#include hsmmc.h
-#include common-board-devices.h
-
-#define PANDORA_WIFI_IRQ_GPIO  21
-#define PANDORA_WIFI_NRESET_GPIO   23
-#define OMAP3_PANDORA_TS_GPIO  94
-
-static struct mtd_partition omap3pandora_nand_partitions[] = {
-   {
-   .name   = xloader,
-   .offset = 0,
-   .size   = 4 * NAND_BLOCK_SIZE,
-   .mask_flags = MTD_WRITEABLE
-   }, {
-   .name   = uboot,
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 15 * NAND_BLOCK_SIZE,
-   }, {
-   .name   = uboot-env,
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 1 * NAND_BLOCK_SIZE,
-   }, {
-   .name   = boot,
-   .offset = MTDPART_OFS_APPEND,
-   .size   = 80 * NAND_BLOCK_SIZE,
-   }, {
-   .name   = rootfs,
-   .offset = MTDPART_OFS_APPEND,
-   .size   = MTDPART_SIZ_FULL,
-   },
-};
-
-static struct omap_nand_platform_data pandora_nand_data = {
-   .cs = 0,
-   .devsize= NAND_BUSWIDTH_16,
-   .xfer_type  = NAND_OMAP_PREFETCH_DMA,
-   .parts  = omap3pandora_nand_partitions,
-   .nr_parts   = ARRAY_SIZE(omap3pandora_nand_partitions),
-};
-
-static struct gpio_led pandora_gpio_leds[] = {
-   {
-   .name 

[PATCH 1/2] ARM: OMAP2+: Remove legacy booting support for LogicPD Torpedo

[Tony Lindgren]

We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

This board has support for device tree based booting, and we've been
printing warnings about the legacy booting being deprecated for a
few merge cycles now. Let's attempt to remove the legacy booting
for it.

The reason for removing the legacy booting support now rather than
later is we can simply revert this patch if necessary if we run
into some unexpected issues that are not trivial to fix for the
device tree based booting.

Cc: Tim Nordell tim.nord...@logicpd.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/Kconfig|  20 ---
 arch/arm/mach-omap2/Makefile   |   2 -
 arch/arm/mach-omap2/board-omap3logic.c | 249 -
 3 files changed, 271 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-omap3logic.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index ecc04ff..e68ad9f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -177,26 +177,6 @@ config MACH_OMAP_LDP
default y
select OMAP_PACKAGE_CBB
 
-config MACH_OMAP3530_LV_SOM
-   bool OMAP3 Logic 3530 LV SOM board
-   depends on ARCH_OMAP3
-   default y
-   select OMAP_PACKAGE_CBB
-   help
-Support for the LogicPD OMAP3530 SOM Development kit
-for full description please see the products webpage at
-
http://www.logicpd.com/products/development-kits/texas-instruments-zoom%E2%84%A2-omap35x-development-kit
-
-config MACH_OMAP3_TORPEDO
-   bool OMAP3 Logic 35x Torpedo board
-   depends on ARCH_OMAP3
-   default y
-   select OMAP_PACKAGE_CBB
-   help
-Support for the LogicPD OMAP35x Torpedo Development kit
-for full description please see the products webpage at
-
http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit
-
 config MACH_OMAP3517EVM
bool OMAP3517/ AM3517 EVM board
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 903c85b..9e4b17a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -243,8 +243,6 @@ obj-$(CONFIG_SOC_OMAP2420)  += msdi.o
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o 
pdata-quirks.o
 obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o
-obj-$(CONFIG_MACH_OMAP3530_LV_SOM)  += board-omap3logic.o
-obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o
 obj-$(CONFIG_MACH_OMAP3_PANDORA)   += board-omap3pandora.o
 obj-$(CONFIG_MACH_NOKIA_N8X0)  += board-n8x0.o
 obj-$(CONFIG_MACH_NOKIA_RX51)  += board-rx51.o sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3logic.c 
b/arch/arm/mach-omap2/board-omap3logic.c
deleted file mode 100644
index 6049f60..000
--- a/arch/arm/mach-omap2/board-omap3logic.c
+++ /dev/null
@@ -1,249 +0,0 @@
-/*
- * linux/arch/arm/mach-omap2/board-omap3logic.c
- *
- * Copyright (C) 2010 Li-Pro.Net
- * Stephan Linz l...@li-pro.net
- *
- * Copyright (C) 2010-2012 Logic Product Development, Inc.
- * Peter Barada peter.bar...@logicpd.com
- * Ashwin BIhari ashwin.bih...@logicpd.com
- *
- * Modified from Beagle, EVM, and RX51
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/gpio.h
-
-#include linux/regulator/fixed.h
-#include linux/regulator/machine.h
-
-#include linux/i2c/twl.h
-#include linux/mmc/host.h
-#include linux/usb/phy.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include common.h
-#include mux.h
-#include hsmmc.h
-#include control.h
-#include common-board-devices.h
-#include gpmc.h
-#include gpmc-smsc911x.h
-
-#define OMAP3LOGIC_SMSC911X_CS 1
-
-#define OMAP3530_LV_SOM_MMC_GPIO_CD110
-#define OMAP3530_LV_SOM_MMC_GPIO_WP126
-#define OMAP3530_LV_SOM_SMSC911X_GPIO_IRQ  152
-
-#define OMAP3_TORPEDO_MMC_GPIO_CD  127
-#define OMAP3_TORPEDO_SMSC911X_GPIO_IRQ129
-
-static struct regulator_consumer_supply omap3logic_vmmc1_supply[] = {
-   REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
-};
-
-/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA) */
-static struct regulator_init_data omap3logic_vmmc1 = {
-   .constraints = {
-   .name   = VMMC1,
-   .min_uV = 185,
-   .max_uV = 315,
- 

[PATCH 0/2] Drop two more omap3 legacy board files for v4.3 merge window

[Tony Lindgren]

Hi all,

I think we can drop these now. This just leaves n900 and ldp with
n900 pending patches for legacy proc support.

Regards,

Tony

Tony Lindgren (2):
  ARM: OMAP2+: Remove legacy booting support for LogicPD Torpedo
  ARM: OMAP2+: Remove legacy booting support for Pandora

 arch/arm/mach-omap2/Kconfig  |  20 -
 arch/arm/mach-omap2/Makefile |   3 -
 arch/arm/mach-omap2/board-omap3logic.c   | 249 
 arch/arm/mach-omap2/board-omap3pandora.c | 633 ---
 4 files changed, 905 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/board-omap3logic.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c

-- 
2.1.4

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

Re: [PATCH 2/3] ARM: DRA: hwmod: RTC: Add lock and unlock functions

[Lokesh Vutla]

Hi Paul,
On Thursday 16 July 2015 05:43 AM, Paul Walmsley wrote:

Hi,

some comments.

On Wed, 10 Jun 2015, Lokesh Vutla wrote:


RTC IP have kicker feature which prevents spurious writes to its registers.
In order to write into any of the RTC registers, KICK values has to be
written to KICK registers.

Introduce omap_hwmod_rtc_unlock/lock functions, which  writes into these
KICK registers inorder to lock and unlock RTC registers.
Also hook these functions to RTC hwmod.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
  arch/arm/mach-omap2/omap_hwmod.h  |  2 ++
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  2 ++
  arch/arm/mach-omap2/omap_hwmod_reset.c| 47 +++
  3 files changed, 51 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 44c7db9..04855ab 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -742,6 +742,8 @@ const char *omap_hwmod_get_main_clk(struct omap_hwmod *oh);
   */

  extern int omap_hwmod_aess_preprogram(struct omap_hwmod *oh);
+void omap_hwmod_rtc_unlock(struct omap_hwmod *oh);
+void omap_hwmod_rtc_lock(struct omap_hwmod *oh);

  /*
   * Chip variant-specific hwmod init routines - XXX should be converted
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0e64c2f..983042f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1548,6 +1548,8 @@ static struct omap_hwmod_class_sysconfig 
dra7xx_rtcss_sysc = {
  static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
.name   = rtcss,
.sysc   = dra7xx_rtcss_sysc,
+   .unlock = omap_hwmod_rtc_unlock,
+   .lock   = omap_hwmod_rtc_lock,
  };

  /* rtcss */


Is the DRA7xx the only chip that has this lock/unlock feature, or do other
OMAP chips use the same RTC IP block?


diff --git a/arch/arm/mach-omap2/omap_hwmod_reset.c 
b/arch/arm/mach-omap2/omap_hwmod_reset.c
index 65e186c..1fb106d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_reset.c
+++ b/arch/arm/mach-omap2/omap_hwmod_reset.c
@@ -25,11 +25,20 @@
   */
  #include linux/kernel.h
  #include linux/errno.h
+#include linux/delay.h

  #include sound/aess.h

  #include omap_hwmod.h

+#define OMAP_RTC_STATUS_REG0x44
+#define OMAP_RTC_KICK0_REG 0x6c
+#define OMAP_RTC_KICK1_REG 0x70
+
+#define OMAP_RTC_KICK0_VALUE   0x83E70B13
+#define OMAP_RTC_KICK1_VALUE   0x95A4F1E0
+#define OMAP_RTC_STATUS_BUSY   BIT(0)
+
  /**
   * omap_hwmod_aess_preprogram - enable AESS internal autogating
   * @oh: struct omap_hwmod *
@@ -51,3 +60,41 @@ int omap_hwmod_aess_preprogram(struct omap_hwmod *oh)

return 0;
  }
+
+static void omap_rtc_wait_not_busy(struct omap_hwmod *oh)


This function is missing kerneldoc and desperately needs it.

I should have written it, sorry about that.
For updating certain RTC registers, the MPU must wait for the BUSY 
status to become zero. Once the BUSY flag is zero, there is a 15-μs 
access period in which the MPU can program.





+{
+   int count;
+   u8 status;
+
+   /* BUSY may stay active for 1/32768 second (~30 usec) */
+   for (count = 0; count  50; count++) {


OK, I give up.  Where does 50 come from?  This should be moved into a
macro with a comment, at the very least.


+   status = omap_hwmod_read(oh, OMAP_RTC_STATUS_REG);
+   if (!(status  OMAP_RTC_STATUS_BUSY))
+   break;
+   udelay(1);
+   }
+   /* now we have ~15 usec to read/write various registers */
+}
+
+/**
+ * omap_hwmod_rtc_unlock - Reset and unlock the Kicker mechanism.
+ * @oh: struct omap_hwmod *
+ *
+ * RTC IP have kicker feature.  This prevents spurious writes to its registers.
+ * In order to write into any of the RTC registers, KICK values has te be
+ * written in respective KICK registers. This is needed for hwmod to write into
+ * sysconfig register.
+ */
+void omap_hwmod_rtc_unlock(struct omap_hwmod *oh)
+{
+   omap_rtc_wait_not_busy(oh);


What prevents the CPU from context-switching away after the BUSY bit test
and not returning back here by the time the ~15 µs interval has ended?
Looks to me like this whole thing needs to run with interrupts disabled.

Yes, you are correct. Ill update it and repost.

Thanks and regards,
Lokesh



+   omap_hwmod_write(OMAP_RTC_KICK0_VALUE, oh, OMAP_RTC_KICK0_REG);
+   omap_hwmod_write(OMAP_RTC_KICK1_VALUE, oh, OMAP_RTC_KICK1_REG);
+}
+
+void omap_hwmod_rtc_lock(struct omap_hwmod *oh)
+{
+   omap_rtc_wait_not_busy(oh);


Same comment as the above.


+   omap_hwmod_write(0x0, oh, OMAP_RTC_KICK0_REG);
+   omap_hwmod_write(0x0, oh, OMAP_RTC_KICK1_REG);
+}
--
1.9.1




- Paul


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

[PATCH 2/2] v4l: omap3isp: Drop platform data support

[Laurent Pinchart]

Platforms using the OMAP3 ISP have all switched to DT, drop platform
data support.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/platform/Kconfig  |   2 +-
 drivers/media/platform/omap3isp/isp.c   | 133 ---
 drivers/media/platform/omap3isp/isp.h   |   7 +-
 drivers/media/platform/omap3isp/ispcsiphy.h |   2 +-
 drivers/media/platform/omap3isp/ispvideo.c  |   9 +-
 drivers/media/platform/omap3isp/omap3isp.h  | 132 +++
 include/media/omap3isp.h| 158 
 7 files changed, 158 insertions(+), 285 deletions(-)
 create mode 100644 drivers/media/platform/omap3isp/omap3isp.h
 delete mode 100644 include/media/omap3isp.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f6bed197130c..ea07c6f793cb 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -86,7 +86,7 @@ config VIDEO_M32R_AR_M64278
 config VIDEO_OMAP3
tristate OMAP 3 Camera support
depends on VIDEO_V4L2  I2C  VIDEO_V4L2_SUBDEV_API  ARCH_OMAP3
-   depends on HAS_DMA
+   depends on HAS_DMA  OF
depends on OMAP_IOMMU
select ARM_DMA_USE_IOMMU
select VIDEOBUF2_DMA_CONTIG
diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 12be830d704f..56e683b19a73 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -101,7 +101,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
0x, /* csi2a, len 0x0170 */
0x0170, /* csiphy2, len 0x000c */
},
-   .syscon_offset = 0xdc,
.phy_type = ISP_PHY_TYPE_3430,
},
{
@@ -124,7 +123,6 @@ static const struct isp_res_mapping isp_res_maps[] = {
0x0570, /* csiphy1, len 0x000c */
0x05c0, /* csi2c, len 0x0040 (2nd area) */
},
-   .syscon_offset = 0x2f0,
.phy_type = ISP_PHY_TYPE_3630,
},
 };
@@ -1796,47 +1794,6 @@ static void isp_unregister_entities(struct isp_device 
*isp)
media_device_unregister(isp-media_dev);
 }
 
-/*
- * isp_register_subdev - Register a sub-device
- * @isp: OMAP3 ISP device
- * @isp_subdev: platform data related to a sub-device
- *
- * Register an I2C sub-device which has not been registered by other
- * means (such as the Device Tree).
- *
- * Return a pointer to the sub-device if it has been successfully
- * registered, or NULL otherwise.
- */
-static struct v4l2_subdev *
-isp_register_subdev(struct isp_device *isp,
-   struct isp_platform_subdev *isp_subdev)
-{
-   struct i2c_adapter *adapter;
-   struct v4l2_subdev *sd;
-
-   if (isp_subdev-board_info == NULL)
-   return NULL;
-
-   adapter = i2c_get_adapter(isp_subdev-i2c_adapter_id);
-   if (adapter == NULL) {
-   dev_err(isp-dev,
-   %s: Unable to get I2C adapter %d for device %s\n,
-   __func__, isp_subdev-i2c_adapter_id,
-   isp_subdev-board_info-type);
-   return NULL;
-   }
-
-   sd = v4l2_i2c_new_subdev_board(isp-v4l2_dev, adapter,
-  isp_subdev-board_info, NULL);
-   if (sd == NULL) {
-   dev_err(isp-dev, %s: Unable to register subdev %s\n,
-   __func__, isp_subdev-board_info-type);
-   return NULL;
-   }
-
-   return sd;
-}
-
 static int isp_link_entity(
struct isp_device *isp, struct media_entity *entity,
enum isp_interface_type interface)
@@ -1910,8 +1867,6 @@ static int isp_link_entity(
 
 static int isp_register_entities(struct isp_device *isp)
 {
-   struct isp_platform_data *pdata = isp-pdata;
-   struct isp_platform_subdev *isp_subdev;
int ret;
 
isp-media_dev.dev = isp-dev;
@@ -1968,37 +1923,6 @@ static int isp_register_entities(struct isp_device *isp)
if (ret  0)
goto done;
 
-   /*
-* Device Tree --- the external sub-devices will be registered
-* later. The same goes for the sub-device node registration.
-*/
-   if (isp-dev-of_node)
-   return 0;
-
-   /* Register external entities */
-   for (isp_subdev = pdata ? pdata-subdevs : NULL;
-isp_subdev  isp_subdev-board_info; isp_subdev++) {
-   struct v4l2_subdev *sd;
-
-   sd = isp_register_subdev(isp, isp_subdev);
-
-   /*
-* No bus information --- this is either a flash or a
-* lens subdev.
-*/
-   if (!sd || !isp_subdev-bus)
-   continue;
-
-   sd-host_priv = isp_subdev-bus;
-
-   ret = isp_link_entity(isp, sd-entity,
-   

Re: [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch

[Mark Brown]

On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:

Please submit patches in the format covered in SubmittingPatches,
version information goes inside the [].

 Add support for writing sequences of registers / patches with specified
 delays (in microseconds). Logically separates the functionality using
 sequences of register writes from the functions that take register
 defaults, as adding a delay field on the reg_defaults can increase
 memory usage substantially.

This change doesn't do what the above changelog says.  It introduces a
new struct reg_sequence and updates the multi write and patch APIs to
use that but it doesn't implement any delay functionality.  Please
resend with a clearer changelog that describes why the struct is being
split out from the reg_defaults struct and makes it clear that this is
just a rename.  It's probably best to also defer the addition of the
delay field until the second patch where this function is actually
implemented.

 +/**
 + * Register / Value pairs for sequences of writes, incorporating an optional

Register/value.

 + * delay in microseconds.
 + *
 + * @reg: Register address.
 + * @def: Register default value.
 + * @delay_us: Delay in microseconds
 + */
 +
 +struct reg_sequence {

No blank line between the kerneldoc and the struct (as is the style for
other kernel code).


signature.asc
Description: Digital signature

[PATCH 2/2] ARM: dts: dra72-evm: fix compatible name for pcf8575

[Sekhar Nori]

Compatible name ti,pcf8575 used in dra72-evm.dts is not
documented in binding definitions nor is used by the
gpio-pcf857x driver.

The correct compatible to use is nxp,pcf8575. Fix it.

The existing .dtb still works because i2c_device_match()
falls back to id table based matching if compatible match
fails.

Reported-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/dra72-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4e1b60581782..746acce940c3 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -334,7 +334,7 @@
};
 
pcf_gpio_21: gpio@21 {
-   compatible = ti,pcf8575;
+   compatible = nxp,pcf8575;
reg = 0x21;
lines-initial-states = 0x1408;
gpio-controller;
-- 
2.4.4.408.g16da57c

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

[PATCH 1/2] ARM: dts: dra7-evm: fix compatible name for pcf8575

[Sekhar Nori]

Compatible name ti,pcf8575 used in dra7-evm.dts is not
documented in binding definitions nor is used by the
gpio-pcf857x driver.

The correct compatible to use is nxp,pcf8575. Fix it.

The existing .dtb works in spite of this issue because
i2c_device_match() falls back to id table based matching
if compatible match fails.

Reported-by: Tero Kristo t-kri...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
 arch/arm/boot/dts/dra7-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index aa465904f6cc..5f33556175da 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -401,7 +401,7 @@
};
 
pcf_gpio_21: gpio@21 {
-   compatible = ti,pcf8575;
+   compatible = nxp,pcf8575;
reg = 0x21;
lines-initial-states = 0x1408;
gpio-controller;
-- 
2.4.4.408.g16da57c

--
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 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

[Tero Kristo]

On 07/16/2015 01:13 PM, Paul Walmsley wrote:

On Thu, 16 Jul 2015, Tero Kristo wrote:


On 07/16/2015 03:15 AM, Paul Walmsley wrote:

On Tue, 14 Jul 2015, Tero Kristo wrote:


On 07/14/2015 01:09 PM, Lokesh Vutla wrote:

Hi,
On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote:

Some IP blocks like RTC, needs an additional unlocking mechanism for
writing to its registers. This patch adds optional lock and unlock
function pointers to the IP block's hwmod data which gets executed
before and after writing into IP sysconfig register.
And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod
data,
so that sysconfig registers are updated properly.

ping on this series.

Thanks and regards,
Lokesh




[...]


It is also racy, as there is no locking in place to avoid concurrent
access to
the lock/unlock registers across hwmod+driver.


I don't see the race.  Where is it?


See drivers/rtc/rtc-omap.c, am3352_rtc_unlock and am3352_rtc_lock.

That code is accessing the exact same registers.


I guess my question is, when is it possible that code could race with the
hwmod code for the same device?


Hmm yea I think you are right, this only gets potentially called within 
pm_runtime_get/put_sync for RTC.


The current sequence is highly inefficient though, as we are doing 
multiple lock/unlock operations to the RTC from multiple sources. See 
following rtcwake trace on am43xx-gp-evm as an example.



/ # rtcwake -s 4 -m mem
[7.425322] am3352_rtc_unlock
[7.428330] am3352_rtc_lock
[7.431139] am3352_rtc_unlock
[7.434116] am3352_rtc_lock
wakeup from mem at Sat Jan  1 00:00:11 2000
[7.448549] PM: Syncing filesystems ... done.
[7.455425] Freezing user space processes ... (elapsed 0.001 seconds) 
done.
[7.463738] Freezing remaining freezable tasks ... (elapsed 0.001 
seconds) do

ne.
[7.472532] Suspending console(s) (use no_console_suspend to debug)
[7.481878] am3352_rtc_unlock
[7.481889] am3352_rtc_lock
[7.482307] PM: suspend of devices complete after 2.713 msecs
[7.483479] PM: late suspend of devices complete after 1.153 msecs
[7.484727] omap_hwmod_rtc_unlock
[7.484733] omap_hwmod_rtc_lock
[7.485182] PM: noirq suspend of devices complete after 1.685 msecs
[7.485190] Disabling non-boot CPUs ...
[7.485199] PM: Successfully put all powerdomains to target state
[7.485199] PM: Wakeup source RTC Alarm
[7.499853] PM: noirq resume of devices complete after 14.558 msecs
[7.500047] am3352_rtc_unlock
[7.500052] am3352_rtc_lock
[7.500123] am3352_rtc_unlock
[7.500128] am3352_rtc_lock
[7.501019] PM: early resume of devices complete after 0.809 msecs
[7.501464] am3352_rtc_unlock
[7.501472] am3352_rtc_lock
[7.558046] PM: resume of devices complete after 57.007 msecs
[7.638807] Restarting tasks ... done.
[7.643173] am3352_rtc_unlock
[7.646162] am3352_rtc_lock

But, I guess this is for some interested party to optimize if needed, 
and it is mostly an issue with the RTC driver itself.


-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 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Tony Lindgren]

* Laurent Pinchart laurent.pinch...@ideasonboard.com [150716 05:57]:
 The OMAP3 ISP is now fully supported in DT, remove its instantiation
 from C code.

Please feel to queue this along with the second patch in this series,
this should not cause any merge conflicts:

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

Re: [alsa-devel] [PATCH 2/2] V4 regmap: Apply optional delay in multi_reg_write/register_patch

[Takashi Iwai]

On Tue, 14 Jul 2015 16:45:52 +0200,
Nariman Poushin wrote:
 
 We treat a delay in a sequence the same way we treat a page change as
 they are logically similar in that you can coalesce all write before
 a delay (in the same way you can coalesce all writes before a page
 change is needed)
 
 Signed-off-by: Nariman Poushin nari...@opensource.wolfsonmicro.com
 ---
  drivers/base/regmap/regmap.c | 65 
 
  1 file changed, 59 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
 index 0a849ee..a67473c2 100644
 --- a/drivers/base/regmap/regmap.c
 +++ b/drivers/base/regmap/regmap.c
 @@ -18,6 +18,7 @@
  #include linux/of.h
  #include linux/rbtree.h
  #include linux/sched.h
 +#include linux/delay.h
  
  #define CREATE_TRACE_POINTS
  #include trace.h
 @@ -47,6 +48,17 @@ static int _regmap_bus_reg_write(void *context, unsigned 
 int reg,
  static int _regmap_bus_raw_write(void *context, unsigned int reg,
unsigned int val);
  
 +static void regmap_sequence_delay(unsigned int delay_us)
 +{
 + /* For small delays it isn't worth setting up the hrtimers
 +  * so fall back on udelay
 +  */
 + if (delay_us  10)
 + udelay(delay_us);
 + else
 + usleep_range(delay_us, delay_us * 2);
 +}

I think usleep_range() can't be used for fast_io, which is performed
inside a spinlock.  And, the locking can't be known explicitly,
e.g. the caller may set its own config-lock, so even the check for
fast_io isn't enough.


Takashi
--
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 v3] ARM: OMAP2+: hwmod: Fix _wait_target_ready() for hwmods without sysc

[Roger Quadros]

For hwmods without sysc, _init_mpu_rt_base(oh) won't be called and so
_find_mpu_rt_port(oh) will return NULL thus preventing ready state check
on those modules after the module is enabled.

This can potentially cause a bus access error if the module is accessed
before the module is ready.

Fix this by unconditionally calling _init_mpu_rt_base() during hwmod
_init(). Do ioremap only if we need SYSC access.

Eventhough _wait_target_ready() check doesn't really need MPU RT port but
just the PRCM registers, we still mandate that the hwmod must have an
MPU RT port if ready state check needs to be done. Else it would mean that
the module is not accessible by MPU so there is no point in waiting
for target to be ready.

e.g. this fixes the below DCAN bus access error on AM437x-gp-evm.

[   16.672978] [ cut here ]
[   16.677885] WARNING: CPU: 0 PID: 1580 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x234/0x35c()
[   16.687946] 4400.ocp:L3 Custom Error: MASTER M2 (64-bit) TARGET L4_PER_0 
(Read): Data Access in User mode during Functional access
[   16.700654] Modules linked in: xhci_hcd btwilink ti_vpfe dwc3 videobuf2_core 
ov2659 bluetooth v4l2_common videodev ti_am335x_adc kfifo_buf industrialio 
c_can_platform videobuf2_dma_contig media snd_soc_tlv320aic3x pixcir_i2c_ts 
c_can dc
[   16.731144] CPU: 0 PID: 1580 Comm: rpc.statd Not tainted 
3.14.26-02561-gf733aa036398 #180
[   16.739747] Backtrace:
[   16.742336] [c0011108] (dump_backtrace) from [c00112a4] 
(show_stack+0x18/0x1c)
[   16.750285]  r6:0093 r5:0009 r4:eab5b8a8 r3:
[   16.756252] [c001128c] (show_stack) from [c05a4418] 
(dump_stack+0x20/0x28)
[   16.763870] [c05a43f8] (dump_stack) from [c0037120] 
(warn_slowpath_common+0x6c/0x8c)
[   16.772408] [c00370b4] (warn_slowpath_common) from [c00371e4] 
(warn_slowpath_fmt+0x38/0x40)
[   16.781550]  r8:c05d1f90 r7:c0730844 r6:c0730448 r5:80080003 r4:ed0cd210
[   16.788626] [c00371b0] (warn_slowpath_fmt) from [c027fa94] 
(l3_interrupt_handler+0x234/0x35c)
[   16.797968]  r3:ed0cd480 r2:c0730508
[   16.801747] [c027f860] (l3_interrupt_handler) from [c0063758] 
(handle_irq_event_percpu+0x54/0x1bc)
[   16.811533]  r10:ed005600 r9:c084855b r8:002a r7: r6: 
r5:002a
[   16.819780]  r4:ed0e6d80
[   16.822453] [c0063704] (handle_irq_event_percpu) from [c00638f0] 
(handle_irq_event+0x30/0x40)
[   16.831789]  r10:eb2b6938 r9:eb2b6960 r8:bf011420 r7:fa240100 r6: 
r5:002a
[   16.840052]  r4:ed005600
[   16.842744] [c00638c0] (handle_irq_event) from [c00661d8] 
(handle_fasteoi_irq+0x74/0x128)
[   16.851702]  r4:ed005600 r3:
[   16.855479] [c0066164] (handle_fasteoi_irq) from [c0063068] 
(generic_handle_irq+0x28/0x38)
[   16.864523]  r4:002a r3:c0066164
[   16.868294] [c0063040] (generic_handle_irq) from [c000ef60] 
(handle_IRQ+0x38/0x8c)
[   16.876612]  r4:c081c640 r3:0202
[   16.880380] [c000ef28] (handle_IRQ) from [c00084f0] 
(gic_handle_irq+0x30/0x5c)
[   16.888328]  r6:eab5ba38 r5:c0804460 r4:fa24010c r3:0100
[   16.894303] [c00084c0] (gic_handle_irq) from [c05a8d80] 
(__irq_svc+0x40/0x50)
[   16.902193] Exception stack(0xeab5ba38 to 0xeab5ba80)
[   16.907499] ba20:   
 0006
[   16.916108] ba40: fa1d fa1d0008 ed3d3000 eab5bab4 ed3d3460 c0842af4 
bf011420 eb2b6960
[   16.924716] ba60: eb2b6938 eab5ba8c eab5ba90 eab5ba80 bf035220 bf07702c 
600f0013 
[   16.933317]  r7:eab5ba6c r6: r5:600f0013 r4:bf07702c
[   16.939317] [bf077000] (c_can_plat_read_reg_aligned_to_16bit 
[c_can_platform]) from [bf035220] (c_can_get_berr_counter+0x38/0x64 [c_can])
[   16.952696] [bf0351e8] (c_can_get_berr_counter [c_can]) from [bf010294] 
(can_fill_info+0x124/0x15c [can_dev])
[   16.963480]  r5:ec8c9740 r4:ed3d3000
[   16.967253] [bf010170] (can_fill_info [can_dev]) from [c0502fa8] 
(rtnl_fill_ifinfo+0x58c/0x8fc)
[   16.976749]  r6:ec8c9740 r5:ed3d3000 r4:eb2b6780
[   16.981613] [c0502a1c] (rtnl_fill_ifinfo) from [c0503408] 
(rtnl_dump_ifinfo+0xf0/0x1dc)
[   16.990401]  r10:ec8c9740 r9: r8: r7: r6:ebd4d1b4 
r5:ed3d3000
[   16.998671]  r4:
[   17.001342] [c0503318] (rtnl_dump_ifinfo) from [c050e6e4] 
(netlink_dump+0xa8/0x1e0)
[   17.009772]  r10: r9: r8:c0503318 r7:ebf3e6c0 r6:ebd4d1b4 
r5:ec8c9740
[   17.018050]  r4:ebd4d000
[   17.020714] [c050e63c] (netlink_dump) from [c050ec10] 
(__netlink_dump_start+0x104/0x154)
[   17.029591]  r6:eab5bd34 r5:ec8c9980 r4:ebd4d000
[   17.034454] [c050eb0c] (__netlink_dump_start) from [c0505604] 
(rtnetlink_rcv_msg+0x110/0x1f4)
[   17.043778]  r7: r6:ec8c9980 r5:0f40 r4:ebf3e6c0
[   17.049743] [c05054f4] (rtnetlink_rcv_msg) from [c05108e8] 
(netlink_rcv_skb+0xb4/0xc8)
[   17.058449]  r8:eab5bdac r7:ec8c9980 r6:c05054f4 r5:ec8c9980 r4:ebf3e6c0
[   17.065534] [c0510834] (netlink_rcv_skb) from [c0504134] 
(rtnetlink_rcv+0x24/0x2c)
[   17.073854]  r6:ebd4d000 

Re: [PATCH 0/3] ARM: OMAP2+: hwmod: RTC: Add lock and unlock hooks

[Lokesh Vutla]

Hi Tero,
On Thursday 16 July 2015 05:33 PM, Tero Kristo wrote:

On 07/16/2015 01:13 PM, Paul Walmsley wrote:

On Thu, 16 Jul 2015, Tero Kristo wrote:


On 07/16/2015 03:15 AM, Paul Walmsley wrote:

On Tue, 14 Jul 2015, Tero Kristo wrote:


On 07/14/2015 01:09 PM, Lokesh Vutla wrote:

Hi,
On Wednesday 10 June 2015 02:56 PM, Lokesh Vutla wrote:

Some IP blocks like RTC, needs an additional unlocking mechanism for
writing to its registers. This patch adds optional lock and unlock
function pointers to the IP block's hwmod data which gets executed
before and after writing into IP sysconfig register.
And also hook lock and unlock functions to AMx3xx, DRA7 RTC hwmod
data,
so that sysconfig registers are updated properly.

ping on this series.

Thanks and regards,
Lokesh




[...]


It is also racy, as there is no locking in place to avoid concurrent
access to
the lock/unlock registers across hwmod+driver.


I don't see the race.  Where is it?


See drivers/rtc/rtc-omap.c, am3352_rtc_unlock and am3352_rtc_lock.

That code is accessing the exact same registers.


I guess my question is, when is it possible that code could race with the
hwmod code for the same device?


Hmm yea I think you are right, this only gets potentially called within
pm_runtime_get/put_sync for RTC.

Yes, sysc is written from hwmod_init code and pm_runtime_get/put_sysnc.
And we write into rtc registers only after pm_runtime_get_sync and 
rtc_unlock.

There cannot be a race condition here.


The current sequence is highly inefficient though, as we are doing
multiple lock/unlock operations to the RTC from multiple sources. See
following rtcwake trace on am43xx-gp-evm as an example.
Initially I had a patch which leaves rtc unlocked at hwmod_init instead 
of doing

unlock and lock for each set of register writes in the driver.
But it was rejected stating that deviates the purpose of locking mechanism.
So I updated the driver for adapting this locking and unlocking mechanism.

Thanks and regards,
Lokesh




/ # rtcwake -s 4 -m mem
[7.425322] am3352_rtc_unlock
[7.428330] am3352_rtc_lock
[7.431139] am3352_rtc_unlock
[7.434116] am3352_rtc_lock
wakeup from mem at Sat Jan  1 00:00:11 2000
[7.448549] PM: Syncing filesystems ... done.
[7.455425] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[7.463738] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) do
ne.
[7.472532] Suspending console(s) (use no_console_suspend to debug)
[7.481878] am3352_rtc_unlock
[7.481889] am3352_rtc_lock
[7.482307] PM: suspend of devices complete after 2.713 msecs
[7.483479] PM: late suspend of devices complete after 1.153 msecs
[7.484727] omap_hwmod_rtc_unlock
[7.484733] omap_hwmod_rtc_lock
[7.485182] PM: noirq suspend of devices complete after 1.685 msecs
[7.485190] Disabling non-boot CPUs ...
[7.485199] PM: Successfully put all powerdomains to target state
[7.485199] PM: Wakeup source RTC Alarm
[7.499853] PM: noirq resume of devices complete after 14.558 msecs
[7.500047] am3352_rtc_unlock
[7.500052] am3352_rtc_lock
[7.500123] am3352_rtc_unlock
[7.500128] am3352_rtc_lock
[7.501019] PM: early resume of devices complete after 0.809 msecs
[7.501464] am3352_rtc_unlock
[7.501472] am3352_rtc_lock
[7.558046] PM: resume of devices complete after 57.007 msecs
[7.638807] Restarting tasks ... done.
[7.643173] am3352_rtc_unlock
[7.646162] am3352_rtc_lock

But, I guess this is for some interested party to optimize if needed,
and it is mostly an issue with the RTC driver itself.

-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] pinctrl: single: ensure pcs irq will not be forced threaded

[Linus Walleij]

On Mon, Jul 6, 2015 at 5:13 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:

 The PSC IRQ is requested using request_irq() API and as result it can
 be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
 is enabled for pinctrl domain.

 As result, following 'possible irq lock inversion dependency' report
 can be seen:
 =
 [ INFO: possible irq lock inversion dependency detected ]
 3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted
 -
 irq/369-pinctrl/927 just changed the state of lock:
  (pcs-lock){+.}, at: [c0375b54] pcs_irq_handle+0x48/0x9c
 but this lock was taken by another, HARDIRQ-safe lock in the past:
  (irq_desc_lock_class){-.}

 and interrupts could create inverse lock ordering between them.

 other info that might help us debug this:
  Possible interrupt unsafe locking scenario:

CPU0CPU1

   lock(pcs-lock);
local_irq_disable();
lock(irq_desc_lock_class);
lock(pcs-lock);
   Interrupt
 lock(irq_desc_lock_class);

  *** DEADLOCK ***

 no locks held by irq/369-pinctrl/927.

 the shortest dependencies between 2nd lock and 1st lock:
   - (irq_desc_lock_class){-.} ops: 58724 {
  IN-HARDIRQ-W at:
[c0090040] lock_acquire+0x9c/0x158
[c07065c8] _raw_spin_lock+0x48/0x58
[c009edac] handle_fasteoi_irq+0x24/0x15c
[c009abb0] generic_handle_irq+0x3c/0x4c
[c000f83c] handle_IRQ+0x50/0xa0
[c0008674] gic_handle_irq+0x3c/0x6c
[c0707a04] __irq_svc+0x44/0x8c
[c000fc44] arch_cpu_idle+0x40/0x4c
[c009aadc] cpu_startup_entry+0x270/0x2e0
[c06fcbf8] rest_init+0xd4/0xe4
[c0a44bfc] start_kernel+0x3d0/0x3dc
[80008084] 0x80008084
  INITIAL USE at:
   [c0090040] lock_acquire+0x9c/0x158
   [c070674c] _raw_spin_lock_irqsave+0x54/0x68
   [c009aff8] __irq_get_desc_lock+0x64/0xa4
   [c009e38c] irq_set_chip+0x30/0x78
   [c009ec30] irq_set_chip_and_handler_name+0x24/0x3c
   [c036ca10] gic_irq_domain_map+0x48/0xb4
   [c00a0a80] irq_domain_associate+0x84/0x1d4
   [c00a1154] irq_create_mapping+0x80/0x11c
   [c00a1270] irq_create_of_mapping+0x80/0x120
   [c05cdaa8] irq_of_parse_and_map+0x34/0x3c
   [c0a4ea24] omap_dm_timer_init_one+0x90/0x30c
   [c0a4eef0] omap5_realtime_timer_init+0x8c/0x48c
   [c0a486b0] time_init+0x28/0x38
   [c0a44a6c] start_kernel+0x240/0x3dc
   [80008084] 0x80008084
}
... key  at: [c1049ce0] irq_desc_lock_class+0x0/0x8
... acquired at:
[c07065c8] _raw_spin_lock+0x48/0x58
[c0375a90] pcs_irq_unmask+0x58/0xa0
[c009ea48] irq_enable+0x38/0x48
[c009ead0] irq_startup+0x78/0x7c
[c009d440] __setup_irq+0x4a8/0x4f4
[c009d5dc] request_threaded_irq+0xb8/0x138
[c0415a5c] omap_8250_startup+0x4c/0x148
[c041276c] serial8250_startup+0x24/0x30
[c040d0ec] uart_startup.part.9+0x5c/0x1b4
[c040dbcc] uart_open+0xf4/0x16c
[c03f0540] tty_open+0x170/0x61c
[c0157028] chrdev_open+0xbc/0x1b4
[c0150494] do_dentry_open+0x1e8/0x2bc
[c0150a84] finish_open+0x44/0x5c
[c0160d50] do_last.isra.47+0x710/0xca0
[c01613a4] path_openat+0xc4/0x640
[c0162904] do_filp_open+0x3c/0x98
[c0151bdc] do_sys_open+0x114/0x1d8
[c0151cc8] SyS_open+0x28/0x2c
[c0a44d70] kernel_init_freeable+0x168/0x1e4
[c06fcc24] kernel_init+0x1c/0xf8
[c000eee8] ret_from_fork+0x14/0x20

 - (pcs-lock){+.} ops: 65 {
HARDIRQ-ON-W at:
 [c0090040] lock_acquire+0x9c/0x158
 [c07065c8] _raw_spin_lock+0x48/0x58
 [c0375b54] pcs_irq_handle+0x48/0x9c
 [c0375c5c] pcs_irq_handler+0x1c/0x28
 [c009c458] irq_forced_thread_fn+0x30/0x74
 [c009c784] irq_thread+0x158/0x1c4
 [c0063fc4] kthread+0xd4/0xe8
 [c000eee8] ret_from_fork+0x14/0x20
INITIAL USE at:
[c0090040] lock_acquire+0x9c/0x158
[c070674c] _raw_spin_lock_irqsave+0x54/0x68
[c0375344] pcs_enable+0x7c/0xe8
[c0372a44] pinmux_enable_setting+0x178/0x220
[c036fecc] pinctrl_select_state+0x110/0x194
[c04732dc] pinctrl_bind_pins+0x7c/0x108
[c045853c] 

[PATCH v4 2/4] ARM: dts: AM4372: Add PRCM IRQ entry

[Keerthy]

Add PRCM IRQ entry. This is needed for IO wake up interrupts as the interrupt
generated is a prcm interrupt.

Signed-off-by: Keerthy j-keer...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ade28c79..359a3b6 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -86,6 +86,7 @@
prcm: prcm@1f {
compatible = ti,am4-prcm;
reg = 0x1f 0x11000;
+   interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
 
prcm_clocks: clocks {
#address-cells = 1;
-- 
1.9.1

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

[PATCH v4 0/4] AM437x: Add IO wake up support

[Keerthy]

The patch series adds IO wake up support for AM437x series
making use of the existing OMAP4 support. Adds the AM437x
specifics.

Note: Previous series patch 2 and 4 of the previous series are already
queued for v4.3 by Paul. Fixed the comments on the remaining patches
and posting them.

Changes in v4:

Added more details to commit logs and kernel documentation for the added
field in a structure.

Changes in v3:

Fixed a bug. Assigned nr_regs = 1 for am437x

Changes in v2:

Removed inefficient way of using arrays for irq ack and masks.

Keerthy (4):
  ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register
  ARM: dts: AM4372: Add PRCM IRQ entry
  ARM: OMAP4+: PRM: Add AM437x specific data
  ARM: PRM: AM437x: Enable IO wakeup feature

 arch/arm/boot/dts/am4372.dtsi |  1 +
 arch/arm/mach-omap2/prcm-common.h |  2 ++
 arch/arm/mach-omap2/prm44xx.c | 23 +--
 arch/arm/mach-omap2/prm_common.c  |  1 +
 4 files changed, 21 insertions(+), 6 deletions(-)

-- 
1.9.1

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

[PATCH v4 3/4] ARM: OMAP4+: PRM: Add AM437x specific data

[Keerthy]

The register offsets for some of the PRM Registers are different
hence populating the differing fields. This is needed to support
IO wake up feature for am437x family.

Signed-off-by: Keerthy j-keer...@ti.com
---
 arch/arm/mach-omap2/prm44xx.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 8149e5a..8035089 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -18,13 +18,14 @@
 #include linux/err.h
 #include linux/io.h
 #include linux/of_irq.h
-
+#include linux/of.h
 
 #include soc.h
 #include iomap.h
 #include common.h
 #include vp.h
 #include prm44xx.h
+#include prcm43xx.h
 #include prm-regbits-44xx.h
 #include prcm44xx.h
 #include prminst44xx.h
@@ -720,6 +721,15 @@ int __init omap44xx_prm_init(const struct 
omap_prcm_init_data *data)
 
omap4_prminst_set_prm_dev_inst(data-device_inst_offset);
 
+   /* Add AM437X specific differences */
+   if (of_device_is_compatible(data-np, ti,am4-prcm)) {
+   omap4_prcm_irq_setup.nr_irqs = 1;
+   omap4_prcm_irq_setup.nr_regs = 1;
+   omap4_prcm_irq_setup.pm_ctrl = AM43XX_PRM_IO_PMCTRL_OFFSET;
+   omap4_prcm_irq_setup.ack = AM43XX_PRM_IRQSTATUS_MPU_OFFSET;
+   omap4_prcm_irq_setup.mask = AM43XX_PRM_IRQENABLE_MPU_OFFSET;
+   }
+
return prm_register(omap44xx_prm_ll_data);
 }
 
-- 
1.9.1

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

[PATCH v4 1/4] ARM: OMAP4: PRM: Remove hardcoding of PRM_IO_PMCTRL_OFFSET register

[Keerthy]

PRM_IO_PMCTRL_OFFSET need not be same for all SOCs hence
remove hardcoding and use the value provided by the omap_prcm_irq_setup
structure. This is done to support IO wakeup on am437x series.

Signed-off-by: Keerthy j-keer...@ti.com
---
 arch/arm/mach-omap2/prcm-common.h |  2 ++
 arch/arm/mach-omap2/prm44xx.c | 11 ++-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/prcm-common.h 
b/arch/arm/mach-omap2/prcm-common.h
index 6ae0b3a..af0cee0 100644
--- a/arch/arm/mach-omap2/prcm-common.h
+++ b/arch/arm/mach-omap2/prcm-common.h
@@ -472,6 +472,7 @@ struct omap_prcm_irq {
  * struct omap_prcm_irq_setup - PRCM interrupt controller details
  * @ack: PRM register offset for the first PRM_IRQSTATUS_MPU register
  * @mask: PRM register offset for the first PRM_IRQENABLE_MPU register
+ * @pm_ctrl: PRM register offset for the PRM_IO_PMCTRL register
  * @nr_regs: number of PRM_IRQ{STATUS,ENABLE}_MPU* registers
  * @nr_irqs: number of entries in the @irqs array
  * @irqs: ptr to an array of PRCM interrupt bits (see @nr_irqs)
@@ -494,6 +495,7 @@ struct omap_prcm_irq {
 struct omap_prcm_irq_setup {
u16 ack;
u16 mask;
+   u16 pm_ctrl;
u8 nr_regs;
u8 nr_irqs;
const struct omap_prcm_irq *irqs;
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 4541700..8149e5a 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -45,6 +45,7 @@ static const struct omap_prcm_irq omap4_prcm_irqs[] = {
 static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
.ack= OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.mask   = OMAP4_PRM_IRQENABLE_MPU_OFFSET,
+   .pm_ctrl= OMAP4_PRM_IO_PMCTRL_OFFSET,
.nr_regs= 2,
.irqs   = omap4_prcm_irqs,
.nr_irqs= ARRAY_SIZE(omap4_prcm_irqs),
@@ -306,10 +307,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
OMAP4430_WUCLK_CTRL_MASK,
inst,
-   OMAP4_PRM_IO_PMCTRL_OFFSET);
+   omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
-  OMAP4_PRM_IO_PMCTRL_OFFSET) 
+  omap4_prcm_irq_setup.pm_ctrl) 
   OMAP4430_WUCLK_STATUS_MASK) 
  OMAP4430_WUCLK_STATUS_SHIFT) == 1),
MAX_IOPAD_LATCH_TIME, i);
@@ -319,10 +320,10 @@ static void omap44xx_prm_reconfigure_io_chain(void)
/* Trigger WUCLKIN disable */
omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
inst,
-   OMAP4_PRM_IO_PMCTRL_OFFSET);
+   omap4_prcm_irq_setup.pm_ctrl);
omap_test_timeout(
(((omap4_prm_read_inst_reg(inst,
-  OMAP4_PRM_IO_PMCTRL_OFFSET) 
+  omap4_prcm_irq_setup.pm_ctrl) 
   OMAP4430_WUCLK_STATUS_MASK) 
  OMAP4430_WUCLK_STATUS_SHIFT) == 0),
MAX_IOPAD_LATCH_TIME, i);
@@ -350,7 +351,7 @@ static void __init omap44xx_prm_enable_io_wakeup(void)
omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
OMAP4430_GLOBAL_WUEN_MASK,
inst,
-   OMAP4_PRM_IO_PMCTRL_OFFSET);
+   omap4_prcm_irq_setup.pm_ctrl);
 }
 
 /**
-- 
1.9.1

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

[PATCH v4 4/4] ARM: PRM: AM437x: Enable IO wakeup feature

[Keerthy]

Enable IO wakeup feature. This enables am437x pads to generate daisy
chained wake ups(eventually generates aprcm Interrupt) especially
when in low power modes.

Signed-off-by: Keerthy j-keer...@ti.com
---
 arch/arm/mach-omap2/prm_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 7add799..1730fc4 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -696,6 +696,7 @@ static struct omap_prcm_init_data am4_prm_data __initdata = 
{
.index = TI_CLKM_PRM,
.init = omap44xx_prm_init,
.device_inst_offset = AM43XX_PRM_DEVICE_INST,
+   .flags = PRM_HAS_IO_WAKEUP,
 };
 #endif
 
-- 
1.9.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] pinctrl: single: dra7: remove PCS_QUIRK_SHARED_IRQ

[Linus Walleij]

On Mon, Jul 6, 2015 at 5:11 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:

 On DRA7 there is one pinctrl domain (dra7_pmx_core) and
 PRCM wake-up IRQ is not shared, so remove quirk.

 Cc: Nishanth Menon n...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Fixes: 31320beaa3d3 ('pinctrl: single: Add DRA7 pinctrl compatibility')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com

Patch applied with the ACKs.

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

Re: [PATCH 4/4] ARM: omap2: restore OMAP4 barrier behaviour

[Russell King - ARM Linux]

On Wed, Jul 15, 2015 at 11:48:54PM -0700, Tony Lindgren wrote:
 Hi,
 
 * Russell King rmk+ker...@arm.linux.org.uk [150715 10:50]:
  Restore the OMAP4 barrier behaviour using the new implementation which
  allows multiplatform systems to hook into the mb() and wmb() ARM
  implementations to perform any necessary additional barrier maintanence.
 
 I'm getthing this with omap2plus_defconfig with the last patch
 applied:
 
 arch/arm/mach-omap2/omap4-common.c: In function ‘omap4_sram_init’:
 arch/arm/mach-omap2/omap4-common.c:138:14: error: implicit declaration of 
 function ‘of_get_named_gen_pool’ [-Werror=implicit-function-declaration]
   sram_pool = of_get_named_gen_pool(np, sram, 0);
   ^
 arch/arm/mach-omap2/omap4-common.c:138:12: warning: assignment makes pointer 
 from integer without a cast [-Wint-conversion]
   sram_pool = of_get_named_gen_pool(np, sram, 0);
 ^

I'd forgotten to merge in the merge window fixes for this... which have now
been lost.  This needs to become of_gen_pool_get() in 4.2-rc1 and later.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
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: Delete unnecessary checks before three function calls

[Paul Walmsley]

On Wed, 15 Jul 2015, Tony Lindgren wrote:

 * Paul Walmsley p...@pwsan.com [150715 22:58]:
  Hello Markus
  
  On Tue, 30 Jun 2015, SF Markus Elfring wrote:
  
   From: Markus Elfring elfr...@users.sourceforge.net
   Date: Tue, 30 Jun 2015 14:00:16 +0200
   
   The functions clk_disable(), of_node_put() and omap_device_delete() test
   whether their argument is NULL and then return immediately.
   Thus the test around the call is not needed.
   
   This issue was detected by using the Coccinelle software.
   
   Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
  
  Thanks for the patch.  I have to say, I am a bit leery about applying the 
  omap_device.c and omap_hwmod.c changes, since the called functions -- 
  omap_device_delete() and clk_disable() -- don't explicitly document that 
  NULLs are allowed to be passed in.  So there's no explicit contract that 
  callers can rely upon, to (at least in theory) prevent those internal NULL 
  pointer checks from being removed.
  
  So I would suggest that those two functions' kerneldoc be patched first to 
  explicitly state that passing in a NULL pointer is allowed.  Then I would 
  feel a bit more comfortable applying the omap_device.c and omap_hwmod.c 
  changes.
  
  The kerneldoc for of_node_put() does explicitly allow NULLs to be passed 
  in.  So I'll apply that change now for v4.3, touching up the commit 
  message accordingly.
 
 I have them applied from a later thread already, but will drop both in
 my branch as I have not pushed them out yet.

Oops sorry about stepping on your toes - I obviously missed that followup.

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

Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO

[Roger Quadros]

On 16/07/15 04:25, Paul Walmsley wrote:
 Hi
 
 On Tue, 23 Jun 2015, Roger Quadros wrote:
 
 For some hwmods (e.g. DCAN on DRA7) we need the possibility to
 disable HW_AUTO for the clockdomain while the module is active.

 To achieve this there needs to be a refcounting mechanism to
 indicate whether any module in the clockdomain has requested
 to disable HW_AUTO. We keep track of this in 'noidlecount'.

 Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
 HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.

 It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
 the future clkdm_hwmod_hwauto() calls.

 Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
 to request HW_AUTO of any clockdomain. (Typically after it has
 enabled the module).
 
 How about just modifying clkdm_{allow,deny}_idle*() to do the 
 idle-block-counting?  The default state would be to allow idle, assuming 
 that the clockdomain flags support that state, and then clkdm_deny_idle*() 
 would increment the idle-blocking count, clkdm_allow_idle*() would 
 decrement it.  Then on the 0 - 1 or 1 - 0 transitions, the hardware 
 would be reprogrammed appropiately.

That is not possible with current hwmod code as clkdm_allow_idle() and 
clkdm_deny_idle()
are not symmetrically placed.

The usual flow is
clkdm_enable_hwmod();
if (hwsup)
clkdm_allow_idle();

This is mainly because it is redundant to disable auto idle before enableing
(SW_WKUP) the clockdomain.

If we take your proposal above then we have to modify all users like so.

if (hwsup)
clkdm_deny_idle();
clkdm_enable_hwmod();
if (hwsup)
clkdm_allow_idle();

Is this really what we want?

 
 Anyway, seems like that would avoid races with any 
 clkdm_{allow,deny}_idle*() users.  
 
 A few other comments below:
 
 

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  arch/arm/mach-omap2/clockdomain.c | 71 
 +++
  arch/arm/mach-omap2/clockdomain.h |  5 +++
  2 files changed, 76 insertions(+)

 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 2da3b5e..a7190d2 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -1212,6 +1212,77 @@ ccd_exit:
  return 0;
  }
  
 +/*
 + * prevent future hwauto for this clkdm. If clkdm-usecount becomes hwauto 
 isn't prevented.
 + * It will only prevnt future hwauto but not bring it out of hwauto.
 + */
 
 If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue 
 - but all of the function comments should be fixed so that they are 
 understandable and follow kernel-doc-nano specs.

OK for updating the comments.


cheers,
-roger

 
 +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct omap_hwmod 
 *oh)
 +{
 +/* The clkdm attribute does not exist yet prior OMAP4 */
 +if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +return 0;
 +
 +if (!clkdm || !oh || !arch_clkdm || !arch_clkdm-clkdm_clk_disable)
 +return -EINVAL;
 +
 +
 +pwrdm_lock(clkdm-pwrdm.ptr);
 +clkdm-noidlecount++;
 +pwrdm_unlock(clkdm-pwrdm.ptr);
 +
 +return 0;
 +}
 +
 +/*
 + * allow future hwauto for this clkdm
 + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
 + */
 +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod 
 *oh)
 +{
 +/* The clkdm attribute does not exist yet prior OMAP4 */
 +if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +return 0;
 +
 +if (!clkdm || !oh || !arch_clkdm || !arch_clkdm-clkdm_clk_disable)
 +return -EINVAL;
 +
 +
 +pwrdm_lock(clkdm-pwrdm.ptr);
 +
 +if (clkdm-noidlecount == 0) {
 +pwrdm_unlock(clkdm-pwrdm.ptr);
 +WARN_ON(1); /* underflow */
 +return -ERANGE;
 +}
 +
 +clkdm-noidlecount--;
 +pwrdm_unlock(clkdm-pwrdm.ptr);
 +
 +return 0;
 +}
 +
 +/*
 + * put clkdm in hwauto if we can. checks noidlecount to see if we can.
 + */
 +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh)
 +{
 +/* The clkdm attribute does not exist yet prior OMAP4 */
 +if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +return 0;
 +
 +if (!clkdm || !oh || !arch_clkdm || !arch_clkdm-clkdm_clk_disable)
 +return -EINVAL;
 +
 +
 +pwrdm_lock(clkdm-pwrdm.ptr);
 +if (clkdm-noidlecount == 0)
 +clkdm_allow_idle_nolock(clkdm);
 +
 +pwrdm_unlock(clkdm-pwrdm.ptr);
 +
 +return 0;
 +}
 +
  /**
   * clkdm_hwmod_enable - add an enabled downstream hwmod to this clkdm
   * @clkdm: struct clockdomain *
 diff --git a/arch/arm/mach-omap2/clockdomain.h 
 b/arch/arm/mach-omap2/clockdomain.h
 index 77bab5f..8c491be 100644
 --- a/arch/arm/mach-omap2/clockdomain.h
 +++ b/arch/arm/mach-omap2/clockdomain.h
 @@ -114,6 +114,7 @@ struct omap_hwmod;
   * @wkdep_srcs: Clockdomains that can be told to wake 

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy booting support for Pandora

[Grazvydas Ignotas]

Hi,

On Thu, Jul 16, 2015 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
 We've been moving all omap2+ based systems to boot in device tree only
 mode for a few years now. Only omap3 has legacy booting support
 remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
 files for booting with device tree.

 This board has support for device tree based booting, and we've been
 printing warnings about the legacy booting being deprecated for a
 few merge cycles now. Let's attempt to remove the legacy booting
 for it.

 The reason for removing the legacy booting support now rather than
 later is we can simply revert this patch if necessary if we run
 into some unexpected issues that are not trivial to fix for the
 device tree based booting.

It seems we lose wifi, backlight, audio and usb host mainline support
with this as pandora's .dts currently lacks all that stuff.
That said I'm not aware of any mainline users (everyone seems to be on
our vendor kernel), so maybe we can add those later.


 Cc: Signed-off-by: Grazvydas Ignotas nota...@gmail.com

I have not signed this off...

 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  arch/arm/mach-omap2/Makefile |   1 -
  arch/arm/mach-omap2/board-omap3pandora.c | 633 
 ---
  2 files changed, 634 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c



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

Re: [PATCH v2 1/5] ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP

[R, Vignesh]

Hi,

On 07/16/2015 01:57 AM, Paul Walmsley wrote:
 On Wed, 15 Jul 2015, Paul Walmsley wrote:
 
 On Wed, 3 Jun 2015, Vignesh R wrote:

 Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
 smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
 program clock domain to SW_WKUP.

 Signed-off-by: Vignesh R vigne...@ti.com
 ---
  arch/arm/mach-omap2/clockdomains7xx_data.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/mach-omap2/clockdomains7xx_data.c 
 b/arch/arm/mach-omap2/clockdomains7xx_data.c
 index 57d5df0c1fbd..7581e036bda6 100644
 --- a/arch/arm/mach-omap2/clockdomains7xx_data.c
 +++ b/arch/arm/mach-omap2/clockdomains7xx_data.c
 @@ -331,7 +331,7 @@ static struct clockdomain l4per2_7xx_clkdm = {
 .dep_bit  = DRA7XX_L4PER2_STATDEP_SHIFT,
 .wkdep_srcs   = l4per2_wkup_sleep_deps,
 .sleepdep_srcs= l4per2_wkup_sleep_deps,
 -   .flags= CLKDM_CAN_HWSUP_SWSUP,
 +   .flags= CLKDM_CAN_SWSUP,
  };
  
  static struct clockdomain mpu0_7xx_clkdm = {

 Thanks, queued for v4.2-rc fixes.  Note that I cannot test this, since I 
 don't have a DRA7xx board.
 
 You know, upon further thought, this doesn't make sense.  If the bug
 is with the PWMSS IP block specifically, why not just set 
 HWMOD_SWSUP_SIDLE on all the IP blocks where the hardware folks didn't 
 implement hardware smart-idle?  At least that way, if those legacy IP 
 blocks aren't in use, the clockdomain can still enter hardware-supervised 
 idle?

According to hardware folks, HW_AUTO (for clockdomain) and
HWMOD_SWSUP_SIDLE (PWMSS in NO-IDLE) for PWMSS *is not* a good
combination. If clockdomain is in HW_AUTO and PWMSS is put in NO-IDLE,
then IDLEST of PWMSSx_CLKCTRL reads stuck in wakeup/ sleep transition
which is not a consistent state (this is because of problems with PWM
IP). Hence, it is recommended to program the clock domain to SW_WKUP and
leave the PWMSS idlemode as smart-idle.

-- 
Regards
Vignesh
--
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 V5] regmap: Use reg_sequence for multi_reg_write / register_patch

[Nariman Poushin]

Separate the functionality using sequences of register writes from the
functions that take register defaults. This change renames the arguments
in order to support the extension of reg_sequence to take an optional
delay to be applied after any given register in a sequence is written.
This avoids adding an int to all register defaults, which could
substantially increase memory usage for regmaps with large default tables.

This also updates all the clients of multi_reg_write/register_patch.

Signed-off-by: Nariman Poushin nari...@opensource.wolfsonmicro.com
---
 drivers/base/regmap/internal.h |  2 +-
 drivers/base/regmap/regmap.c   | 22 +++---
 drivers/gpu/drm/i2c/adv7511.c  |  2 +-
 drivers/input/misc/drv260x.c   |  6 +++---
 drivers/input/misc/drv2665.c   |  2 +-
 drivers/input/misc/drv2667.c   |  4 ++--
 drivers/mfd/arizona-core.c |  2 +-
 drivers/mfd/twl6040.c  |  2 +-
 drivers/mfd/wm5102-tables.c|  6 +++---
 drivers/mfd/wm5110-tables.c|  6 +++---
 drivers/mfd/wm8994-core.c  |  8 
 drivers/mfd/wm8997-tables.c|  2 +-
 include/linux/regmap.h | 17 ++---
 sound/soc/codecs/arizona.c |  2 +-
 sound/soc/codecs/cs35l32.c |  2 +-
 sound/soc/codecs/cs42l52.c |  2 +-
 sound/soc/codecs/da7210.c  |  4 ++--
 sound/soc/codecs/rt5640.c  |  2 +-
 sound/soc/codecs/rt5645.c  |  4 ++--
 sound/soc/codecs/rt5651.c  |  2 +-
 sound/soc/codecs/rt5670.c  |  2 +-
 sound/soc/codecs/rt5677.c  |  2 +-
 sound/soc/codecs/tlv320aic3x.c |  2 +-
 sound/soc/codecs/wm2200.c  |  2 +-
 sound/soc/codecs/wm5100.c  |  2 +-
 sound/soc/codecs/wm8962.c  |  2 +-
 sound/soc/codecs/wm8993.c  |  2 +-
 27 files changed, 62 insertions(+), 51 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index b2b2849..873ddf9 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -136,7 +136,7 @@ struct regmap {
/* if set, the HW registers are known to match map-reg_defaults */
bool no_sync_defaults;
 
-   struct reg_default *patch;
+   struct reg_sequence *patch;
int patch_regs;
 
/* if set, converts bulk rw to single rw */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index dd63bcb..0a849ee 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1755,7 +1755,7 @@ EXPORT_SYMBOL_GPL(regmap_bulk_write);
  * relative. The page register has been written if that was neccessary.
  */
 static int _regmap_raw_multi_reg_write(struct regmap *map,
-  const struct reg_default *regs,
+  const struct reg_sequence *regs,
   size_t num_regs)
 {
int ret;
@@ -1812,12 +1812,12 @@ static unsigned int _regmap_register_page(struct regmap 
*map,
 }
 
 static int _regmap_range_multi_paged_reg_write(struct regmap *map,
-  struct reg_default *regs,
+  struct reg_sequence *regs,
   size_t num_regs)
 {
int ret;
int i, n;
-   struct reg_default *base;
+   struct reg_sequence *base;
unsigned int this_page = 0;
/*
 * the set of registers are not neccessarily in order, but
@@ -1855,7 +1855,7 @@ static int _regmap_range_multi_paged_reg_write(struct 
regmap *map,
 }
 
 static int _regmap_multi_reg_write(struct regmap *map,
-  const struct reg_default *regs,
+  const struct reg_sequence *regs,
   size_t num_regs)
 {
int i;
@@ -1907,8 +1907,8 @@ static int _regmap_multi_reg_write(struct regmap *map,
struct regmap_range_node *range;
range = _regmap_range_lookup(map, reg);
if (range) {
-   size_t len = sizeof(struct reg_default)*num_regs;
-   struct reg_default *base = kmemdup(regs, len,
+   size_t len = sizeof(struct reg_sequence)*num_regs;
+   struct reg_sequence *base = kmemdup(regs, len,
   GFP_KERNEL);
if (!base)
return -ENOMEM;
@@ -1941,7 +1941,7 @@ static int _regmap_multi_reg_write(struct regmap *map,
  * A value of zero will be returned on success, a negative errno will be
  * returned in error cases.
  */
-int regmap_multi_reg_write(struct regmap *map, const struct reg_default *regs,
+int regmap_multi_reg_write(struct regmap *map, const struct reg_sequence *regs,
   int num_regs)
 {
int ret;
@@ -1974,7 +1974,7 @@ EXPORT_SYMBOL_GPL(regmap_multi_reg_write);
  * be returned in error cases.
  */
 int regmap_multi_reg_write_bypassed(struct regmap *map,
- 

[PATCH 2/2 V5] regmap: Apply optional delay in multi_reg_write/register_patch

[Nariman Poushin]

Add an optional delay_us field in reg_sequence to allow the client to
specify a delay (in microseconds) to be applied after any given write
in a sequence of writes.

We treat a delay in a sequence the same way we treat a page change as
they are logically similar in that you can coalesce all write before
a delay (in the same way you can coalesce all writes before a page
change is needed)

Signed-off-by: Nariman Poushin nari...@opensource.wolfsonmicro.com
---
 drivers/base/regmap/regmap.c | 54 +++-
 include/linux/regmap.h   |  5 +++-
 2 files changed, 52 insertions(+), 7 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 0a849ee..fd4dac9 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -18,6 +18,7 @@
 #include linux/of.h
 #include linux/rbtree.h
 #include linux/sched.h
+#include linux/delay.h
 
 #define CREATE_TRACE_POINTS
 #include trace.h
@@ -1819,10 +1820,12 @@ static int _regmap_range_multi_paged_reg_write(struct 
regmap *map,
int i, n;
struct reg_sequence *base;
unsigned int this_page = 0;
+   unsigned int page_change = 0;
/*
 * the set of registers are not neccessarily in order, but
 * since the order of write must be preserved this algorithm
-* chops the set each time the page changes
+* chops the set each time the page changes. This also applies
+* if there is a delay required at any point in the sequence.
 */
base = regs;
for (i = 0, n = 0; i  num_regs; i++, n++) {
@@ -1838,16 +1841,48 @@ static int _regmap_range_multi_paged_reg_write(struct 
regmap *map,
this_page = win_page;
if (win_page != this_page) {
this_page = win_page;
+   page_change = 1;
+   }
+   }
+
+   /* If we have both a page change and a delay make sure to
+* write the regs and apply the delay before we change the
+* page.
+*/
+
+   if (page_change || regs[i].delay_us) {
+
+   /* For situations where the first write requires
+* a delay we need to make sure we don't call
+* raw_multi_reg_write with n=0
+* This can't occur with page breaks as we
+* never write on the first iteration
+*/
+   if (regs[i].delay_us  i == 0)
+   n = 1;
+
ret = _regmap_raw_multi_reg_write(map, base, n);
if (ret != 0)
return ret;
+
+   if (regs[i].delay_us)
+   udelay(regs[i].delay_us);
+
base += n;
n = 0;
-   }
-   ret = _regmap_select_page(map, base[n].reg, range, 1);
-   if (ret != 0)
-   return ret;
+
+   if (page_change) {
+   ret = _regmap_select_page(map,
+ base[n].reg,
+ range, 1);
+   if (ret != 0)
+   return ret;
+
+   page_change = 0;
+   }
+
}
+
}
if (n  0)
return _regmap_raw_multi_reg_write(map, base, n);
@@ -1866,6 +1901,9 @@ static int _regmap_multi_reg_write(struct regmap *map,
ret = _regmap_write(map, regs[i].reg, regs[i].def);
if (ret != 0)
return ret;
+
+   if (regs[i].delay_us)
+   udelay(regs[i].delay_us);
}
return 0;
}
@@ -1905,8 +1943,12 @@ static int _regmap_multi_reg_write(struct regmap *map,
for (i = 0; i  num_regs; i++) {
unsigned int reg = regs[i].reg;
struct regmap_range_node *range;
+
+   /* Coalesce all the writes between a page break or a delay
+* in a sequence
+*/
range = _regmap_range_lookup(map, reg);
-   if (range) {
+   if (range || regs[i].delay_us) {
size_t len = sizeof(struct reg_sequence)*num_regs;
struct reg_sequence *base = kmemdup(regs, len,
   GFP_KERNEL);

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[R, Vignesh]

Hi,

On 07/16/2015 03:24 AM, Paul Walmsley wrote:
 Hi,
 
 some comments.
 
 On Wed, 3 Jun 2015, Vignesh R wrote:
 
 Add hwmod entries for the PWMSS on DRA7.

 Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
 equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
 As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
 clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
 L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
 
 Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
 HSPCLKDIV a separate divider after the divide-by-2 you mention above?

No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
the clock input for PWMSS. This will be updated in TRM soon.

 
 [1] www.ti.com/lit/ug/spruhz6/spruhz6.pdf

 Signed-off-by: Vignesh R vigne...@ti.com
 ---

 v2:
  * add TRM references.

  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 239 
 ++
  1 file changed, 239 insertions(+)

 diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
 b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 index 0e64c2fac0b5..86a7ac9a3138 100644
 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
 @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
  },
  };
  
 +/* pwmss  */
 +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
 +.rev_offs   = 0x0,
 +.sysc_offs  = 0x4,
 +.sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
 
 This doesn't match SPRUHZ6 Table 29-13 PWMSS_SYSCONFIG.  There's no 
 RESETSTATUS bit.  There is a SOFTRESET bit. 
 
 Could you please confirm whether this is intentional?

sorry my bad... I will change this in v3.

 
 +.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 +.sysc_fields= omap_hwmod_sysc_type2,
 +};
 +
 +struct omap_hwmod_class dra7xx_epwmss_hwmod_class = {
 +.name   = epwmss,
 +.sysc   = dra7xx_epwmss_sysc,
 +};
 +
 +static struct omap_hwmod_class dra7xx_ecap_hwmod_class = {
 +.name   = ecap,
 +};
 +
 +static struct omap_hwmod_class dra7xx_eqep_hwmod_class = {
 +.name   = eqep,
 +};
 +
 +struct omap_hwmod_class dra7xx_ehrpwm_hwmod_class = {
 +.name   = ehrpwm,
 +};
 +
 +/* epwmss0 */
 +struct omap_hwmod dra7xx_epwmss0_hwmod = {
 +.name   = epwmss0,
 +.class  = dra7xx_epwmss_hwmod_class,
 +.clkdm_name = l4per2_clkdm,
 +.main_clk   = l4_root_clk_div,
 +.prcm   = {
 +.omap4  = {
 +.modulemode = MODULEMODE_SWCTRL,
 +.clkctrl_offs   = 
 DRA7XX_CM_L4PER2_PWMSS1_CLKCTRL_OFFSET,
 +.context_offs   = 
 DRA7XX_RM_L4PER2_PWMSS1_CONTEXT_OFFSET,
 +},
 +},
 
 Per my comment on the previous patch, sounds like it might be better to 
 mark this as HWMOD_SWSUP_SIDLE?  Then again, see the next comment below 
 re: main_clk.
 
 +};
 +
 +/* ecap0 */
 +struct omap_hwmod dra7xx_ecap0_hwmod = {
 +.name   = ecap0,
 +.class  = dra7xx_ecap_hwmod_class,
 +.clkdm_name = l4per2_clkdm,
 +.main_clk   = l4_root_clk_div,
 
 Looking at SPRUHZ6 Section 29.1.4.2 PWMSS Modules Local Clock Gating, 
 there appears to be a local mini-PRCM for the PWMSS which implements 
 clock gating and reports back on the status of what I'd guess is the local 
 clock gating FSM.
 
 So from that point of view, you should probably create a clock driver that 
 manages both the clock gate request bit and the FSM status bit.  It should 
 be something that can be reused for the other PWMSS IP blocks.  Then 
 you'd create per-IP block clock nodes and set the main_clk to point to 
 that node.
 

Since, this register is within the config space of PWMSS, the individual
gating and reporting for the modules within PWMSS
(PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
the sole function this driver is doing). It has been the same since
am335x. Adding new clock nodes will result in driver changes and also
changes to am335x, am437x (and other platforms) hwmod files. It also
involves adding new nodes to clocks.dtsi and it will be difficult to
maintain backward compatibility for older platforms. Is it not better to
keep this as is, in order to maintain consistency (with am335x, am437x
etc) and also that these clock bits are within IP's config space?



-- 
Regards
Vignesh
--
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: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Sakari Ailus]

Hi Laurent,

Laurent Pinchart wrote:
 The OMAP3 ISP is now fully supported in DT, remove its instantiation
 from C code.
 
 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  arch/arm/mach-omap2/devices.c | 53 
 ---
  arch/arm/mach-omap2/devices.h | 19 
  2 files changed, 72 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/devices.h

If you remove the definitions, arch/arm/mach-omap2/board-cm-t35.c will
no longer compile. Could you remove the camera support there as well?

My understanding is the board might be supported in DT but I'm not sure
about camera.

Cc Mike and Igor.

-- 
Regards,

Sakari Ailus
sakari.ai...@iki.fi
--
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: remoteproc: wkup_m3: suspend/resume for am335x bbone

[Andreas Fenkart]

Dave,

thanks for rebasing your branch

2015-07-15 23:28 GMT+02:00 Dave Gerlach d-gerl...@ti.com:
 I tried to merge that branch into current v4.2-rc2, but I made quite a mess 
 out
 of it. I'll try probably try cherry-picking next or will just wait for an 
 update

 Yes, there are some additional patches, wkup_m3_rproc is just part of the 
 whole
 collection. However I did rebase my pm branch on v4.2-rc2 today in preparation
 of sending the next series so you can check that out here:
 https://github.com/dgerlach/linux-pm/tree/pm-v4.2-rc2-amx3-suspend.

 The firmware you need can be found here:
 https://git.ti.com/ti-cm3-pm-firmware/amx3-cm3/commits/next-upstream.

The file '/sys/power/state' is still empty, it seems that
suspend_set_ops are never
installed.

[1.617027] omap_hsmmc 4806.mmc: unable to get vmmc regulator -517
[1.652116]  remoteproc0: wkup_m3 is available
[1.657149]  remoteproc0: Note: remoteproc is still under
development and considered experimental.
[1.47]  remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED,
and backward compatibility isn't yet guaranteed.
[1.686648] usbcore: registered new interface driver snd-usb-audio
[1.699828] Initializing XFRM netlink socket
[1.707462] NET: Registered protocol family 10
[1.716910] sit: IPv6 over IPv4 tunneling driver
[1.724229] NET: Registered protocol family 17
[1.729231] NET: Registered protocol family 15
[1.734582] Key type dns_resolver registered
[1.739342] omap_voltage_late_init: Voltage driver support not added
[1.747483] ThumbEE CPU extension supported.
[1.752018] Registering SWP/SWPB emulation handler
[1.757140] am33xx_pm_init !!!
[1.760720] am33xx_pm_init 1
[1.763739] am33xx_pm_init 2
[1.766790] PM: am33xx_push_sram_idle: EMIF function copy failed
^^^
next line in am33xx_pm_init would have installed the callbacks

[1.830732] tps65217 0-0024: TPS65217 ID 0xf version 1.1
[1.838295] at24 0-0050: 1024 byte 24c08 EEPROM, writable, 16 bytes/write
[1.845933] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 100 kHz
[1.855157] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 400 kHz
[1.862975] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xda
[1.870123]  remoteproc0: powering up wkup_m3
[1.874734]  remoteproc0: Booting fw image am335x-pm-firmware.elf,
size 153943
[1.882387] nand: Toshiba NAND 256MiB 3,3V 8-bit
[1.887269] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[1.895290] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme
[1.901368]  remoteproc0: remote processor wkup_m3 is now up
[1.901394] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 0x191
[1.915177] 9 ofpart partitions found on MTD device omap2-nand.0

kind regards,
Andi
--
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: [alsa-devel] [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch

[Nariman Poushin]

On Thu, Jul 16, 2015 at 01:52:54PM +0100, Mark Brown wrote:
 On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:
 
 Please submit patches in the format covered in SubmittingPatches,
 version information goes inside the [].
 
  Add support for writing sequences of registers / patches with specified
  delays (in microseconds). Logically separates the functionality using
  sequences of register writes from the functions that take register
  defaults, as adding a delay field on the reg_defaults can increase
  memory usage substantially.
 
 This change doesn't do what the above changelog says.  It introduces a
 new struct reg_sequence and updates the multi write and patch APIs to
 use that but it doesn't implement any delay functionality.  Please
 resend with a clearer changelog that describes why the struct is being
 split out from the reg_defaults struct and makes it clear that this is
 just a rename.  It's probably best to also defer the addition of the
 delay field until the second patch where this function is actually
 implemented.
 
  +/**
  + * Register / Value pairs for sequences of writes, incorporating an 
  optional
 
 Register/value.
 
  + * delay in microseconds.
  + *
  + * @reg: Register address.
  + * @def: Register default value.
  + * @delay_us: Delay in microseconds
  + */
  +
  +struct reg_sequence {
 
 No blank line between the kerneldoc and the struct (as is the style for
 other kernel code).

I realized that I resent my patches with out outlining the changes from
the previous patch set (V5 vs V4), not sure if it is best to resend
with a cover letter (which would increase noise)?

Anyway, I addressed your both your and Takashi's comments, thanks both
for your feedback.

I will resend with a cover letter explaining the change from the previous
patch set if that is the right thing to do.

Thanks
Nariman

 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

Re: [PATCH] gpio: omap: prevent module from being unloaded while in use

[Linus Walleij]

On Thu, Jun 25, 2015 at 5:13 PM, Grygorii Strashko
grygorii.stras...@ti.com wrote:

 OMAP GPIO driver allowed to be built as loadable module, but it
 doesn't set owner field in GPIO chip structure. As result,
 module_get/put() API is not working and it's possible to unload
 OMAP driver while in use:

   omap_gpio 48051000.gpio: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED

 Hence, add missing configuration.

 Cc: Tony Lindgren t...@atomide.com
 Fixes: cac089f9026e ('gpio: omap: Allow building as a loadable module')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
 ---
 Hi Linus,

 Seems this one is for 4.2-rc.

Yup applied for fixes with Alex' ACK.

The bigger fix is applied for devel and the best way to handle this
is open for discussion.

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

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy booting support for Pandora

[Tony Lindgren]

* Grazvydas Ignotas nota...@gmail.com [150716 07:16]:
 Hi,
 
 On Thu, Jul 16, 2015 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
  We've been moving all omap2+ based systems to boot in device tree only
  mode for a few years now. Only omap3 has legacy booting support
  remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
  files for booting with device tree.
 
  This board has support for device tree based booting, and we've been
  printing warnings about the legacy booting being deprecated for a
  few merge cycles now. Let's attempt to remove the legacy booting
  for it.
 
  The reason for removing the legacy booting support now rather than
  later is we can simply revert this patch if necessary if we run
  into some unexpected issues that are not trivial to fix for the
  device tree based booting.
 
 It seems we lose wifi, backlight, audio and usb host mainline support
 with this as pandora's .dts currently lacks all that stuff.
 That said I'm not aware of any mainline users (everyone seems to be on
 our vendor kernel), so maybe we can add those later.

Hmm wifi should be easy, isn't that just libertas_sdio?

  Cc: Signed-off-by: Grazvydas Ignotas nota...@gmail.com
 
 I have not signed this off...

Oops sorry I copied your email address from git log.


--
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: Delete unnecessary checks before three function calls

[Tony Lindgren]

* Paul Walmsley p...@pwsan.com [150716 07:09]:
 On Wed, 15 Jul 2015, Tony Lindgren wrote:
 
  * Paul Walmsley p...@pwsan.com [150715 22:58]:
   Hello Markus
   
   On Tue, 30 Jun 2015, SF Markus Elfring wrote:
   
From: Markus Elfring elfr...@users.sourceforge.net
Date: Tue, 30 Jun 2015 14:00:16 +0200

The functions clk_disable(), of_node_put() and omap_device_delete() test
whether their argument is NULL and then return immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
   
   Thanks for the patch.  I have to say, I am a bit leery about applying the 
   omap_device.c and omap_hwmod.c changes, since the called functions -- 
   omap_device_delete() and clk_disable() -- don't explicitly document that 
   NULLs are allowed to be passed in.  So there's no explicit contract that 
   callers can rely upon, to (at least in theory) prevent those internal 
   NULL 
   pointer checks from being removed.
   
   So I would suggest that those two functions' kerneldoc be patched first 
   to 
   explicitly state that passing in a NULL pointer is allowed.  Then I would 
   feel a bit more comfortable applying the omap_device.c and omap_hwmod.c 
   changes.
   
   The kerneldoc for of_node_put() does explicitly allow NULLs to be passed 
   in.  So I'll apply that change now for v4.3, touching up the commit 
   message accordingly.
  
  I have them applied from a later thread already, but will drop both in
  my branch as I have not pushed them out yet.
 
 Oops sorry about stepping on your toes - I obviously missed that followup.

No problem :)

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: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Sakari Ailus]

Laurent Pinchart wrote:
 Hi Sakari,
 
 On Thursday 16 July 2015 18:45:22 Sakari Ailus wrote:
 Laurent Pinchart wrote:
 The OMAP3 ISP is now fully supported in DT, remove its instantiation
 from C code.

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---

  arch/arm/mach-omap2/devices.c | 53 --
  arch/arm/mach-omap2/devices.h | 19 
  2 files changed, 72 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/devices.h

 If you remove the definitions, arch/arm/mach-omap2/board-cm-t35.c will
 no longer compile. Could you remove the camera support there as well?

 My understanding is the board might be supported in DT but I'm not sure
 about camera.

 Cc Mike and Igor.
 
 commit 11cd7b8c2773d01e4b40e38568ae62c471a2ea10
 Author: Tony Lindgren t...@atomide.com
 Date:   Mon May 4 10:48:07 2015 -0700
 
 ARM: OMAP2+: Remove legacy booting support for cm-t35
 
 
 Merged in v4.2-rc1 :-)

Oh, I missed that one. Good!

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
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: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Laurent Pinchart]

Hi Sakari,

On Thursday 16 July 2015 18:45:22 Sakari Ailus wrote:
 Laurent Pinchart wrote:
  The OMAP3 ISP is now fully supported in DT, remove its instantiation
  from C code.
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
  
   arch/arm/mach-omap2/devices.c | 53 --
   arch/arm/mach-omap2/devices.h | 19 
   2 files changed, 72 deletions(-)
   delete mode 100644 arch/arm/mach-omap2/devices.h
 
 If you remove the definitions, arch/arm/mach-omap2/board-cm-t35.c will
 no longer compile. Could you remove the camera support there as well?
 
 My understanding is the board might be supported in DT but I'm not sure
 about camera.
 
 Cc Mike and Igor.

commit 11cd7b8c2773d01e4b40e38568ae62c471a2ea10
Author: Tony Lindgren t...@atomide.com
Date:   Mon May 4 10:48:07 2015 -0700

ARM: OMAP2+: Remove legacy booting support for cm-t35


Merged in v4.2-rc1 :-)

-- 
Regards,

Laurent Pinchart

--
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: remoteproc: wkup_m3: suspend/resume for am335x bbone

[Andreas Fenkart]

here the full dmesg output, it contains a deadlock warning from lockdep

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.2.0-rc2-00284-gc11a8fb-dirty
(afenkart@sandwurm) (gcc version 4.9.2 (Buildroot
2014.11-00099-g8d0fd78-dirty) ) #1175 PREEMPT Thu Jul 16 17:06:34 5
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: StreamUnlimited Board (AM33xx)
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c088dad8,
node_mem_map cfcf9000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8
root=/dev/nfs nfsroot=192.168.13.1:/home/afenkart/OE/rootfs/yocto-mine,nolock
rw ip=192.168.13.141
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 241448K/261120K available (6027K kernel code,
371K rwdata, 2088K rodata, 240K init, 8278K bss, 19672K reserved, 0K
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc07f51c8   (8117 kB)
[0.00]   .init : 0xc07f6000 - 0xc0832000   ( 240 kB)
[0.00]   .data : 0xc0832000 - 0xc088ed40   ( 372 kB)
[0.00].bss : 0xc088ed40 - 0xc10a47a8   (8279 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Running RCU self tests
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU lockdep checking is enabled.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with
128 interrupts
[0.00] OMAP clockevent source: timer2 at 2500 Hz
[0.18] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps
every 85899345900ns
[0.46] clocksource: timer1: mask: 0x max_cycles:
0x, max_idle_ns: 76450417870 ns
[0.98] OMAP clocksource: timer1 at 2500 Hz
[0.000659] Console: colour dummy device 80x30
[0.000729] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[0.000740] ... MAX_LOCKDEP_SUBCLASSES:  8
[0.000749] ... MAX_LOCK_DEPTH:  48
[0.000758] ... MAX_LOCKDEP_KEYS:8191
[0.000767] ... CLASSHASH_SIZE:  4096
[0.000776] ... MAX_LOCKDEP_ENTRIES: 32768
[0.000785] ... MAX_LOCKDEP_CHAINS:  65536
[0.000794] ... CHAINHASH_SIZE:  32768
[0.000803]  memory used by lock dependency info: 5167 kB
[0.000812]  per task-struct memory footprint: 1536 bytes
[0.000861] Calibrating delay loop... 718.02 BogoMIPS (lpj=3590144)
[0.098513] pid_max: default: 4096 minimum: 301
[0.098768] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.098785] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.102097] CPU: Testing write buffer coherency: ok
[0.103688] Setting up static identity map for 0x80008200 - 0x80008258
[0.110245] devtmpfs: initialized
[0.148748] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[0.199835] omap_hwmod: tptc0 using broken dt data from edma
[0.200398] omap_hwmod: tptc1 using broken dt data from edma
[0.200930] omap_hwmod: tptc2 using broken dt data from edma
[0.210914] omap_hwmod: debugss: _wait_target_disable failed
[0.267841] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275 ns
[0.269374] pinctrl core: initialized pinctrl subsystem
[0.275990] NET: Registered protocol family 16
[0.277140] DMA: preallocated 256 KiB pool for atomic coherent allocations
[0.308667] cpuidle: using governor ladder
[0.338536] cpuidle: using governor menu
[0.348684] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[0.349714] OMAP GPIO hardware version 0.1
[0.351787] 

Re: [PATCH 0/2] omap3isp: Remove legacy platform data support

[Sakari Ailus]

Laurent Pinchart wrote:
 Hello,
 
 Now that all users of the OMAP3 ISP have switched to DT, this patch series
 removes support for legacy platform data support in the omap3isp driver. It
 also drops the OMAP3 ISP device instantiation board code that is now unused.
 
 Patch 2/2 depends on 1/2. From a conflict resolution point of view it would be
 easier to merge the whole series through the linux-media tree. Tony, would
 that be fine with you ? If so could you please ack patch 1/2 ?
 
 Laurent Pinchart (2):
   ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
   v4l: omap3isp: Drop platform data support
 
  arch/arm/mach-omap2/devices.c   |  53 --
  arch/arm/mach-omap2/devices.h   |  19 
  drivers/media/platform/Kconfig  |   2 +-
  drivers/media/platform/omap3isp/isp.c   | 133 ---
  drivers/media/platform/omap3isp/isp.h   |   7 +-
  drivers/media/platform/omap3isp/ispcsiphy.h |   2 +-
  drivers/media/platform/omap3isp/ispvideo.c  |   9 +-
  drivers/media/platform/omap3isp/omap3isp.h  | 132 +++
  include/media/omap3isp.h| 158 
 
  9 files changed, 158 insertions(+), 357 deletions(-)
  delete mode 100644 arch/arm/mach-omap2/devices.h
  create mode 100644 drivers/media/platform/omap3isp/omap3isp.h
  delete mode 100644 include/media/omap3isp.h

For the set:

Acked-by: Sakari Ailus sakari.ai...@iki.fi

-- 
Sakari Ailus
sakari.ai...@iki.fi
--
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 00/11] USB: OTG/DRD Core functionality

[Andrew Bresticker]

Hi Roger,

On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros rog...@ti.com wrote:
 Hi Andrew,

 On 13/07/15 22:14, Andrew Bresticker wrote:
 Hi Roger,

 On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros rog...@ti.com wrote:
 Usage model:
 ---

 - The OTG controller device is assumed to be the parent of
 the host and gadget controller. It must call usb_otg_register()
 before populating the host and gadget devices so that the OTG
 core is aware that it is an OTG device before the host  gadget
 register. The OTG controller must provide struct otg_fsm_ops *
 which will be called by the OTG core depending on OTG bus state.

 I'm wondering if the requirement that the OTG controller be the parent
 of the USB host/device-controllers makes sense.  For some context, I'm
 working on adding dual-role support for Tegra210, specifically on a
 system with USB Type-C.  On Tegra, the USB host-controller and USB
 device-controller are two separate IP blocks (XUSB host and XUSB
 device) with another, separate, IP block (XUSB padctl) for the USB PHY
 and OTG support.  In the non-Type-C case, your OTG framework could
 work well, though it's debatable as to whether or not the XUSB padctl
 device should be a parent to the XUSB host/device-controller devices
 (currently it isn't - it's just a PHY provider).  But in the Type-C
 case, it's an off-chip embedded controller that determines the
 dual-role status of the Type-C port, so the above requirement doesn't
 make sense at all.

 My idea was to have the OTG/DRD controller explicitly specify its host
 and device controllers, so in DT, something like:

 otg-controller {
 ...
 device-controller = usb_device;
 host-controller = usb_host;
 ...
 };

 usb_device: usb-device@ {
 ...
 };

 usb_host: usb-host@... {
 ...
 };

 What do you think?

 I agree that we need to support your use case but how to do it
 is not yet clear to me.

 In your above example the otg controller knows what are the host
 and gadget controllers but the host/gadget devices don't
 know who is their otg controller.

 So the problem is that when usb_otg_register_hcd/gadget() is called
 we need to get a handle to the otg controller.

 One solution I see is to iterate over the registered otg_controller_list
 and check if we match the host/gadget controller in there.

 Then there is also a possibility that host/gadget controllers get
 registered before the OTG controller. Then we can't know for sure if
 the host/gadget controller was meant for dual-role operation or not
 and it will resort to single role operation.

 Any idea to prevent the above situation?

 Maybe we need to add some logic in host/gadget cores to check if the port
 is meant for dual-role use and defer probe if OTG controller is not yet
 registered?

In the DT case, I think we could add an otg-controller property to
the host and gadget nodes, and in usb_otg_register_{hcd,gadget}()
check for that property and defer probe if the referenced OTG
controller has not yet been registered.  Not sure how to indicate that
a host/gadget is meant for dual-role operation on non-DT platforms
though.

Thanks,
Andrew
--
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: [alsa-devel] [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch

[Mark Brown]

On Thu, Jul 16, 2015 at 04:45:25PM +0100, Nariman Poushin wrote:

 I will resend with a cover letter explaining the change from the previous
 patch set if that is the right thing to do.

No, that's fine.  If you want to fix something like that just reply to
the cover letter with the extra information.


signature.asc
Description: Digital signature

Re: [PATCH 05/12] ARM: OMAP2+: Add support for initializing dm814x clocks

[Stephen Boyd]

On 07/16/2015 02:37 AM, Tony Lindgren wrote:


Here's this patch updated with the above removed.



Ok. I fixed up Mike's email in case he wants to look at it. Looks fine 
to me though.




8 -
From: Tony Lindgren t...@atomide.com
Date: Thu, 16 Jul 2015 01:55:57 -0700
Subject: [PATCH] ARM: OMAP2+: Add support for initializing dm814x clocks

Let's add a minimal clocks for dm814x to get it booted. This is
mostly a placeholder and relies on the PLLs being on from the
bootloader.

Note that the divider clocks work the same way as on dm816x and
am335x.

Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com


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



--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -558,7 +558,7 @@ void __init ti814x_init_early(void)
ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
-   omap_clk_soc_init = ti81xx_dt_clk_init;
+   omap_clk_soc_init = dm814x_dt_clk_init;
  }
  
  void __init ti816x_init_early(void)

@@ -575,7 +575,7 @@ void __init ti816x_init_early(void)
ti81xx_hwmod_init();
omap_hwmod_init_postsetup();
if (of_have_populated_dt())
-   omap_clk_soc_init = ti81xx_dt_clk_init;
+   omap_clk_soc_init = dm816x_dt_clk_init;
  }
  #endif
  
--- a/drivers/clk/ti/Makefile

+++ b/drivers/clk/ti/Makefile
@@ -2,7 +2,7 @@ obj-y   += clk.o autoidle.o 
clockdomain.o
  clk-common= dpll.o composite.o divider.o gate.o \
  fixed-factor.o mux.o apll.o
  obj-$(CONFIG_SOC_AM33XX)  += $(clk-common) clk-33xx.o
-obj-$(CONFIG_SOC_TI81XX)   += $(clk-common) fapll.o clk-816x.o
+obj-$(CONFIG_SOC_TI81XX)   += $(clk-common) fapll.o clk-814x.o 
clk-816x.o
  obj-$(CONFIG_ARCH_OMAP2)  += $(clk-common) interface.o clk-2xxx.o
  obj-$(CONFIG_ARCH_OMAP3)  += $(clk-common) interface.o \
   clk-3xxx.o
--- /dev/null
+++ b/drivers/clk/ti/clk-814x.c
@@ -0,0 +1,31 @@
+/*
+ * 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 the Free Software Foundation version 2.
+ */
+
+#include linux/kernel.h
+#include linux/clk-provider.h
+#include linux/clk/ti.h
+
+static struct ti_dt_clk dm814_clks[] = {
+   DT_CLK(NULL, devosc_ck, devosc_ck),
+   DT_CLK(NULL, mpu_ck, mpu_ck),
+   DT_CLK(NULL, sysclk4_ck, sysclk4_ck),
+   DT_CLK(NULL, sysclk6_ck, sysclk6_ck),
+   DT_CLK(NULL, sysclk10_ck, sysclk10_ck),
+   DT_CLK(NULL, sysclk18_ck, sysclk18_ck),
+   DT_CLK(NULL, timer_sys_ck, devosc_ck),
+   DT_CLK(NULL, cpsw_125mhz_gclk, cpsw_125mhz_gclk),
+   DT_CLK(NULL, cpsw_cpts_rft_clk, cpsw_cpts_rft_clk),
+   { .node_name = NULL },
+};
+
+int __init dm814x_dt_clk_init(void)
+{
+   ti_dt_clocks_register(dm814_clks);
+   omap2_clk_disable_autoidle_all();
+   omap2_clk_enable_init_clocks(NULL, 0);
+
+   return 0;
+}
--- a/drivers/clk/ti/clk-816x.c
+++ b/drivers/clk/ti/clk-816x.c
@@ -42,7 +42,7 @@ static const char *enable_init_clks[] = {
ddr_pll_clk3,
  };
  
-int __init ti81xx_dt_clk_init(void)

+int __init dm816x_dt_clk_init(void)
  {
ti_dt_clocks_register(dm816x_clks);
omap2_clk_disable_autoidle_all();
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -329,7 +329,8 @@ int ti_clk_add_component(struct device_node *node, struct 
clk_hw *hw, int type);
  int omap3430_dt_clk_init(void);
  int omap3630_dt_clk_init(void);
  int am35xx_dt_clk_init(void);
-int ti81xx_dt_clk_init(void);
+int dm814x_dt_clk_init(void);
+int dm816x_dt_clk_init(void);
  int omap4xxx_dt_clk_init(void);
  int omap5xxx_dt_clk_init(void);
  int dra7xx_dt_clk_init(void);



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 V5] regmap: Apply optional delay in multi_reg_write/register_patch

[Mark Brown]

On Thu, Jul 16, 2015 at 04:36:22PM +0100, Nariman Poushin wrote:

 +
 + if (regs[i].delay_us)
 + udelay(regs[i].delay_us);

This is a bit funky.  While Takashi is correct that we could be running
in a spinlock equally this will mean that we could end up with some
really long busy waits.  It feels like we should at least make an effort
to complain about that, print a warning or something.


signature.asc
Description: Digital signature

[PATCH 14/18] ARM/omap2/timer: Migrate to new 'set-state' interface

[Viresh Kumar]

Migrate omap2 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap2/timer.c | 48 ++---
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index cac46d852da1..16b37e7196f5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -102,38 +102,38 @@ static int omap2_gp_timer_set_next_event(unsigned long 
cycles,
return 0;
 }
 
-static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
-   struct clock_event_device *evt)
+static int omap2_gp_timer_shutdown(struct clock_event_device *evt)
+{
+   __omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
+   return 0;
+}
+
+static int omap2_gp_timer_set_periodic(struct clock_event_device *evt)
 {
u32 period;
 
__omap_dm_timer_stop(clkev, OMAP_TIMER_POSTED, clkev.rate);
 
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   period = clkev.rate / HZ;
-   period -= 1;
-   /* Looks like we need to first set the load value separately */
-   __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG,
- 0x - period, OMAP_TIMER_POSTED);
-   __omap_dm_timer_load_start(clkev,
-   OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
-   0x - period, OMAP_TIMER_POSTED);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   break;
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+   period = clkev.rate / HZ;
+   period -= 1;
+   /* Looks like we need to first set the load value separately */
+   __omap_dm_timer_write(clkev, OMAP_TIMER_LOAD_REG, 0x - period,
+ OMAP_TIMER_POSTED);
+   __omap_dm_timer_load_start(clkev,
+  OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST,
+  0x - period, OMAP_TIMER_POSTED);
+   return 0;
 }
 
 static struct clock_event_device clockevent_gpt = {
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .rating = 300,
-   .set_next_event = omap2_gp_timer_set_next_event,
-   .set_mode   = omap2_gp_timer_set_mode,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .rating = 300,
+   .set_next_event = omap2_gp_timer_set_next_event,
+   .set_state_shutdown = omap2_gp_timer_shutdown,
+   .set_state_periodic = omap2_gp_timer_set_periodic,
+   .set_state_oneshot  = omap2_gp_timer_shutdown,
+   .tick_resume= omap2_gp_timer_shutdown,
 };
 
 static struct property device_disabled = {
-- 
2.4.0

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

Re: [PATCH v3 06/11] usb: gadget.h: Add OTG to gadget interface

[Peter Chen]

On Wed, Jul 08, 2015 at 01:19:32PM +0300, Roger Quadros wrote:
 The OTG core will use struct otg_gadget_ops to
 start/stop the gadget controller.
 
 The main purpose of this interface is to avoid directly
 calling usb_gadget_start/stop() from the OTG core as they
 wouldn't be defined in the built-in symbol table if
 CONFIG_USB_GADGET is m.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/linux/usb/gadget.h | 14 ++
  1 file changed, 14 insertions(+)
 
 diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
 index 4f3dfb7..0b4b341 100644
 --- a/include/linux/usb/gadget.h
 +++ b/include/linux/usb/gadget.h
 @@ -887,6 +887,20 @@ struct usb_gadget_driver {
  };
  
  
 +/*-*/
 +
 +/**
 + * struct otg_gadget_ops - Interface between OTG core and gadget
 + *
 + * Provided by the gadget core to allow the OTG core to start/stop the gadget
 + *
 + * @start: function to start the gadget
 + * @stop: function to stop the gadget
 + */
 +struct otg_gadget_ops {
 + int (*start)(struct usb_gadget *gadget);
 + int (*stop)(struct usb_gadget *gadget);
 +};
  
  /*-*/
  
 -- 
 2.1.4
 

Reviewed-by: Peter Chen peter.c...@freescale.com

-- 

Best Regards,
Peter Chen
--
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 05/11] usb: hcd.h: Add OTG to HCD interface

[Peter Chen]

On Wed, Jul 08, 2015 at 01:19:31PM +0300, Roger Quadros wrote:
 The OTG core will use struct otg_hcd_ops to
 add/remove the HCD controller.
 
 The main purpose of this interface is to avoid directly
 calling usb_add/remove_hcd() from the OTG core as they
 wouldn't be defined in the built-in symbol table if
 CONFIG_USB is m.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  include/linux/usb/hcd.h | 14 ++
  1 file changed, 14 insertions(+)
 
 diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
 index c9aa779..4108288 100644
 --- a/include/linux/usb/hcd.h
 +++ b/include/linux/usb/hcd.h
 @@ -386,6 +386,20 @@ struct hc_driver {
  
  };
  
 +/**
 + * struct otg_hcd_ops - Interface between OTG core and HCD
 + *
 + * Provided by the HCD core to allow the OTG core to start/stop the HCD
 + *
 + * @add: function to add the HCD
 + * @remove: function to remove the HCD
 + */
 +struct otg_hcd_ops {
 + int (*add)(struct usb_hcd *hcd,
 +unsigned int irqnum, unsigned long irqflags);
 + void (*remove)(struct usb_hcd *hcd);
 +};
 +
  static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)
  {
   return hcd-driver-flags  HCD_BH;
 -- 
 2.1.4
 

Reviewed-by: Peter Chen peter.c...@freescale.com

-- 

Best Regards,
Peter Chen
--
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 12/18] ARM/omap1/time: Migrate to new 'set-state' interface

[Viresh Kumar]

Migrate omap driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap1/time.c | 35 ---
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index a7588cfd0286..524977a31a49 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -124,29 +124,26 @@ static int omap_mpu_set_next_event(unsigned long cycles,
return 0;
 }
 
-static void omap_mpu_set_mode(enum clock_event_mode mode,
- struct clock_event_device *evt)
+static int omap_mpu_set_oneshot(struct clock_event_device *evt)
 {
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   omap_mpu_set_autoreset(0);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   omap_mpu_timer_stop(0);
-   omap_mpu_remove_autoreset(0);
-   break;
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+   omap_mpu_timer_stop(0);
+   omap_mpu_remove_autoreset(0);
+   return 0;
+}
+
+static int omap_mpu_set_periodic(struct clock_event_device *evt)
+{
+   omap_mpu_set_autoreset(0);
+   return 0;
 }
 
 static struct clock_event_device clockevent_mpu_timer1 = {
-   .name   = mpu_timer1,
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .set_next_event = omap_mpu_set_next_event,
-   .set_mode   = omap_mpu_set_mode,
+   .name   = mpu_timer1,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_next_event = omap_mpu_set_next_event,
+   .set_state_periodic = omap_mpu_set_periodic,
+   .set_state_oneshot  = omap_mpu_set_oneshot,
 };
 
 static irqreturn_t omap_mpu_timer1_interrupt(int irq, void *dev_id)
-- 
2.4.0

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

[PATCH 13/18] ARM/omap1/timer32: Migrate to new 'set-state' interface

[Viresh Kumar]

Migrate omap timer32 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

Acked-by: Santosh Shilimkar ssant...@kernel.org
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
 arch/arm/mach-omap1/timer32k.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 36bf174b3fac..0ae6c52a7d70 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -114,29 +114,28 @@ static int omap_32k_timer_set_next_event(unsigned long 
delta,
return 0;
 }
 
-static void omap_32k_timer_set_mode(enum clock_event_mode mode,
-   struct clock_event_device *evt)
+static int omap_32k_timer_shutdown(struct clock_event_device *evt)
 {
omap_32k_timer_stop();
+   return 0;
+}
 
-   switch (mode) {
-   case CLOCK_EVT_MODE_PERIODIC:
-   omap_32k_timer_start(OMAP_32K_TIMER_TICK_PERIOD);
-   break;
-   case CLOCK_EVT_MODE_ONESHOT:
-   case CLOCK_EVT_MODE_UNUSED:
-   case CLOCK_EVT_MODE_SHUTDOWN:
-   break;
-   case CLOCK_EVT_MODE_RESUME:
-   break;
-   }
+static int omap_32k_timer_set_periodic(struct clock_event_device *evt)
+{
+   omap_32k_timer_stop();
+   omap_32k_timer_start(OMAP_32K_TIMER_TICK_PERIOD);
+   return 0;
 }
 
 static struct clock_event_device clockevent_32k_timer = {
-   .name   = 32k-timer,
-   .features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
-   .set_next_event = omap_32k_timer_set_next_event,
-   .set_mode   = omap_32k_timer_set_mode,
+   .name   = 32k-timer,
+   .features   = CLOCK_EVT_FEAT_PERIODIC |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_next_event = omap_32k_timer_set_next_event,
+   .set_state_shutdown = omap_32k_timer_shutdown,
+   .set_state_periodic = omap_32k_timer_set_periodic,
+   .set_state_oneshot  = omap_32k_timer_shutdown,
+   .tick_resume= omap_32k_timer_shutdown,
 };
 
 static irqreturn_t omap_32k_timer_interrupt(int irq, void *dev_id)
-- 
2.4.0

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

Re: [PATCH v3 04/11] otg-fsm: move usb_bus_start_enum into otg-fsm-ops

[Peter Chen]

On Wed, Jul 08, 2015 at 01:19:30PM +0300, Roger Quadros wrote:
 This is to prevent missing symbol build error if OTG is
 enabled (built-in) and HCD core (CONFIG_USB) is module.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/usb/common/usb-otg-fsm.c | 6 --
  drivers/usb/phy/phy-fsl-usb.c| 2 ++
  include/linux/usb/otg-fsm.h  | 1 +
  3 files changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/common/usb-otg-fsm.c 
 b/drivers/usb/common/usb-otg-fsm.c
 index 1873eb3..156fd25 100644
 --- a/drivers/usb/common/usb-otg-fsm.c
 +++ b/drivers/usb/common/usb-otg-fsm.c
 @@ -166,8 +166,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
 usb_otg_state new_state)
   otg_loc_conn(fsm, 0);
   otg_loc_sof(fsm, 1);
   otg_set_protocol(fsm, PROTO_HOST);
 - usb_bus_start_enum(fsm-otg-host,
 - fsm-otg-host-otg_port);
 + if (fsm-ops-start_enum) {
 + fsm-ops-start_enum(fsm-otg-host,
 +  fsm-otg-host-otg_port);
 + }
   break;
   case OTG_STATE_A_IDLE:
   otg_drv_vbus(fsm, 0);
 diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
 index ee3f2c2..19541ed 100644
 --- a/drivers/usb/phy/phy-fsl-usb.c
 +++ b/drivers/usb/phy/phy-fsl-usb.c
 @@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
  
   .start_host = fsl_otg_start_host,
   .start_gadget = fsl_otg_start_gadget,
 +
 + .start_enum = usb_bus_start_enum,
  };
  
  /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
 diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
 index c631dde..22d8baa 100644
 --- a/include/linux/usb/otg-fsm.h
 +++ b/include/linux/usb/otg-fsm.h
 @@ -198,6 +198,7 @@ struct otg_fsm_ops {
   void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
   int (*start_host)(struct otg_fsm *fsm, int on);
   int (*start_gadget)(struct otg_fsm *fsm, int on);
 + int (*start_enum)(struct usb_bus *bus, unsigned port_num);
  };
  
  
 -- 
 2.1.4
 

Acked-by: Peter Chen peter.c...@freescale.com

-- 

Best Regards,
Peter Chen
--
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 05/12] ARM: OMAP2+: Add support for initializing dm814x clocks

[Tony Lindgren]

* Stephen Boyd sb...@codeaurora.org [150716 11:27]:
 On 07/16/2015 02:37 AM, Tony Lindgren wrote:
 
 Here's this patch updated with the above removed.
 
 
 Ok. I fixed up Mike's email in case he wants to look at it. Looks fine to me
 though.

OK thanks for updating Mike's email. 

Regards,

Tony

 8 -
 From: Tony Lindgren t...@atomide.com
 Date: Thu, 16 Jul 2015 01:55:57 -0700
 Subject: [PATCH] ARM: OMAP2+: Add support for initializing dm814x clocks
 
 Let's add a minimal clocks for dm814x to get it booted. This is
 mostly a placeholder and relies on the PLLs being on from the
 bootloader.
 
 Note that the divider clocks work the same way as on dm816x and
 am335x.
 
 Cc: Matthijs van Duin matthijsvand...@gmail.com
 Cc: Mike Turquette mturque...@linaro.org
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Stephen Boyd sb...@codeaurora.org
 Cc: Tero Kristo t-kri...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 
 Acked-by: Stephen Boyd sb...@codeaurora.org
 
 
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -558,7 +558,7 @@ void __init ti814x_init_early(void)
  ti81xx_hwmod_init();
  omap_hwmod_init_postsetup();
  if (of_have_populated_dt())
 -omap_clk_soc_init = ti81xx_dt_clk_init;
 +omap_clk_soc_init = dm814x_dt_clk_init;
   }
   void __init ti816x_init_early(void)
 @@ -575,7 +575,7 @@ void __init ti816x_init_early(void)
  ti81xx_hwmod_init();
  omap_hwmod_init_postsetup();
  if (of_have_populated_dt())
 -omap_clk_soc_init = ti81xx_dt_clk_init;
 +omap_clk_soc_init = dm816x_dt_clk_init;
   }
   #endif
 --- a/drivers/clk/ti/Makefile
 +++ b/drivers/clk/ti/Makefile
 @@ -2,7 +2,7 @@ obj-y+= clk.o 
 autoidle.o clockdomain.o
   clk-common = dpll.o composite.o divider.o gate.o \
fixed-factor.o mux.o apll.o
   obj-$(CONFIG_SOC_AM33XX)   += $(clk-common) clk-33xx.o
 -obj-$(CONFIG_SOC_TI81XX)+= $(clk-common) fapll.o clk-816x.o
 +obj-$(CONFIG_SOC_TI81XX)+= $(clk-common) fapll.o clk-814x.o 
 clk-816x.o
   obj-$(CONFIG_ARCH_OMAP2)   += $(clk-common) interface.o clk-2xxx.o
   obj-$(CONFIG_ARCH_OMAP3)   += $(clk-common) interface.o \
 clk-3xxx.o
 --- /dev/null
 +++ b/drivers/clk/ti/clk-814x.c
 @@ -0,0 +1,31 @@
 +/*
 + * 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 the Free Software Foundation version 2.
 + */
 +
 +#include linux/kernel.h
 +#include linux/clk-provider.h
 +#include linux/clk/ti.h
 +
 +static struct ti_dt_clk dm814_clks[] = {
 +DT_CLK(NULL, devosc_ck, devosc_ck),
 +DT_CLK(NULL, mpu_ck, mpu_ck),
 +DT_CLK(NULL, sysclk4_ck, sysclk4_ck),
 +DT_CLK(NULL, sysclk6_ck, sysclk6_ck),
 +DT_CLK(NULL, sysclk10_ck, sysclk10_ck),
 +DT_CLK(NULL, sysclk18_ck, sysclk18_ck),
 +DT_CLK(NULL, timer_sys_ck, devosc_ck),
 +DT_CLK(NULL, cpsw_125mhz_gclk, cpsw_125mhz_gclk),
 +DT_CLK(NULL, cpsw_cpts_rft_clk, cpsw_cpts_rft_clk),
 +{ .node_name = NULL },
 +};
 +
 +int __init dm814x_dt_clk_init(void)
 +{
 +ti_dt_clocks_register(dm814_clks);
 +omap2_clk_disable_autoidle_all();
 +omap2_clk_enable_init_clocks(NULL, 0);
 +
 +return 0;
 +}
 --- a/drivers/clk/ti/clk-816x.c
 +++ b/drivers/clk/ti/clk-816x.c
 @@ -42,7 +42,7 @@ static const char *enable_init_clks[] = {
  ddr_pll_clk3,
   };
 -int __init ti81xx_dt_clk_init(void)
 +int __init dm816x_dt_clk_init(void)
   {
  ti_dt_clocks_register(dm816x_clks);
  omap2_clk_disable_autoidle_all();
 --- a/include/linux/clk/ti.h
 +++ b/include/linux/clk/ti.h
 @@ -329,7 +329,8 @@ int ti_clk_add_component(struct device_node *node, 
 struct clk_hw *hw, int type);
   int omap3430_dt_clk_init(void);
   int omap3630_dt_clk_init(void);
   int am35xx_dt_clk_init(void);
 -int ti81xx_dt_clk_init(void);
 +int dm814x_dt_clk_init(void);
 +int dm816x_dt_clk_init(void);
   int omap4xxx_dt_clk_init(void);
   int omap5xxx_dt_clk_init(void);
   int dra7xx_dt_clk_init(void);
 
 
 -- 
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
 a Linux Foundation Collaborative Project
 
--
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/4] ARM: omap2: restore OMAP4 barrier behaviour

[Tony Lindgren]

* Russell King - ARM Linux li...@arm.linux.org.uk [150716 06:56]:
 On Wed, Jul 15, 2015 at 11:48:54PM -0700, Tony Lindgren wrote:
  Hi,
  
  * Russell King rmk+ker...@arm.linux.org.uk [150715 10:50]:
   Restore the OMAP4 barrier behaviour using the new implementation which
   allows multiplatform systems to hook into the mb() and wmb() ARM
   implementations to perform any necessary additional barrier maintanence.
  
  I'm getthing this with omap2plus_defconfig with the last patch
  applied:
  
  arch/arm/mach-omap2/omap4-common.c: In function ‘omap4_sram_init’:
  arch/arm/mach-omap2/omap4-common.c:138:14: error: implicit declaration of 
  function ‘of_get_named_gen_pool’ [-Werror=implicit-function-declaration]
sram_pool = of_get_named_gen_pool(np, sram, 0);
^
  arch/arm/mach-omap2/omap4-common.c:138:12: warning: assignment makes 
  pointer from integer without a cast [-Wint-conversion]
sram_pool = of_get_named_gen_pool(np, sram, 0);
  ^
 
 I'd forgotten to merge in the merge window fixes for this... which have now
 been lost.  This needs to become of_gen_pool_get() in 4.2-rc1 and later.

OK with that change looks good to me, so please feel free to
add for the whole series:

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

Re: [PATCH 2/2] ARM: OMAP2+: Remove legacy booting support for Pandora

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [150716 09:28]:
 * Grazvydas Ignotas nota...@gmail.com [150716 07:16]:
  Hi,
  
  On Thu, Jul 16, 2015 at 2:59 PM, Tony Lindgren t...@atomide.com wrote:
   We've been moving all omap2+ based systems to boot in device tree only
   mode for a few years now. Only omap3 has legacy booting support
   remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
   files for booting with device tree.
  
   This board has support for device tree based booting, and we've been
   printing warnings about the legacy booting being deprecated for a
   few merge cycles now. Let's attempt to remove the legacy booting
   for it.
  
   The reason for removing the legacy booting support now rather than
   later is we can simply revert this patch if necessary if we run
   into some unexpected issues that are not trivial to fix for the
   device tree based booting.
  
  It seems we lose wifi, backlight, audio and usb host mainline support
  with this as pandora's .dts currently lacks all that stuff.

More on that later on, but a question on the vendor kernel first..

  That said I'm not aware of any mainline users (everyone seems to be on
  our vendor kernel), so maybe we can add those later.

What all is keeping people from using mainline kernel on pandora?
Is it the sgx or are there other reasons too remaining?  

 Hmm wifi should be easy, isn't that just libertas_sdio?

Nope wl1251, we can initialize with pdata-quirks.c for now if it
does not yet support device tree except for the SPI version.
The same goes for the other devices too if needed, I'd assume
the the EHCI is similar to beagle though.

And of course we can still wait on removing the pandora board file
if you want to. Sounds like that may not be needed though because of
people using vendor kernel in this case even with the legacy
booting?

Regards,

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

[PATCH] Fix incomplete initialization of ADC[3:6]

[Adam YH Lee]

TPS65950(TWL4030) paired with OMAP3 is used in devices such as Beagleboard and
Gumstix Overo COMs. Its ADCs from 3 to 6 seem to be broken [1][2][3].

The ADC readings for these pins are stuck at near 0v for these two reasons:
- 3v1 bias regulator (vusb3v1) is off unless USB-otg is being used
- pins are not configured to attach as ADC

This patch attempts to fix these issues by making sure 3v1 regulator is enabled
and pins are correctly configured as ADC inputs.

[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/83698
[2] 
http://gumstix.8.x6.nabble.com/twl4030-madc-low-read-value-td4967139.html#none
[3] https://e2e.ti.com/support/power_management/pmu/f/43/t/732

Adam YH Lee (1):
  [TWL4030 MADC] Fix ADC[3:6] readings

 drivers/iio/adc/twl4030-madc.c | 14 ++
 drivers/phy/phy-twl4030-usb.c  |  7 +++
 2 files changed, 21 insertions(+)

-- 
2.1.4

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

[PATCH] [TWL4030 MADC] Fix ADC[3:6] readings

[Adam YH Lee]

MADC[3:6] reads incorrect values without these two following changes:

- enable the 3v1 bias regulator for ADC[3:6]
- configure ADC[3:6] lines as input, not as USB

Signed-off-by: Adam YH Lee adam.yh@gmail.com
---
 drivers/iio/adc/twl4030-madc.c | 14 ++
 drivers/phy/phy-twl4030-usb.c  |  7 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
index 94c5f05..b5020ab 100644
--- a/drivers/iio/adc/twl4030-madc.c
+++ b/drivers/iio/adc/twl4030-madc.c
@@ -45,6 +45,7 @@
 #include linux/types.h
 #include linux/gfp.h
 #include linux/err.h
+#include linux/regulator/consumer.h
 
 #include linux/iio/iio.h
 
@@ -52,6 +53,7 @@
  * struct twl4030_madc_data - a container for madc info
  * @dev:   Pointer to device structure for madc
  * @lock:  Mutex protecting this data structure
+ * @regulator: Pointer to bias regulator for madc
  * @requests:  Array of request struct corresponding to SW1, SW2 and RT
  * @use_second_irq:IRQ selection (main or co-processor)
  * @imr:   Interrupt mask register of MADC
@@ -60,6 +62,7 @@
 struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
+   struct regulator *usb3v1;
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
u8 imr;
@@ -848,6 +851,14 @@ static int twl4030_madc_probe(struct platform_device *pdev)
goto err_i2c;
}
 
+   madc-usb3v1 = devm_regulator_get(madc-dev, vusb3v1);
+   if (IS_ERR(madc-usb3v1))
+   return -ENODEV;
+
+   ret = regulator_enable(madc-usb3v1);
+   if (ret)
+   dev_err(madc-dev, could not be enable 3v1 bias regulator\n);
+
return 0;
 
 err_i2c:
@@ -867,6 +878,9 @@ static int twl4030_madc_remove(struct platform_device *pdev)
twl4030_madc_set_current_generator(madc, 0, 0);
twl4030_madc_set_power(madc, 0);
 
+   regulator_disable(madc-usb3v1);
+   regulator_put(madc-usb3v1);
+
return 0;
 }
 
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 7b04bef..88fc7d7 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -144,6 +144,9 @@
 #define PMBR1  0x0D
 #define GPIO_USB_4PIN_ULPI_2430C   (3  0)
 
+#define TWL4030_USB_SEL_MADC_MCPC  (13)
+#define TWL4030_USB_CARKIT_ANA_CTRL0xBB
+
 struct twl4030_usb {
struct usb_phy  phy;
struct device   *dev;
@@ -459,6 +462,10 @@ static int twl4030_phy_power_on(struct phy *phy)
twl4030_i2c_access(twl, 0);
schedule_delayed_work(twl-id_workaround_work, 0);
 
+   twl4030_usb_write(twl, TWL4030_USB_CARKIT_ANA_CTRL,
+   twl4030_usb_read(twl, TWL4030_USB_CARKIT_ANA_CTRL) |
+   TWL4030_USB_SEL_MADC_MCPC);
+
return 0;
 }
 
-- 
2.1.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