Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

2015-08-13 Thread Keerthy



On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:

* Keerthy a0393...@ti.com [150811 10:57]:



On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:

* Keerthy j-keer...@ti.com [150810 02:31]:

@@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
  #ifdefCONFIG_SOC_AM43XX
  # undef soc_is_am43xx
  # undef soc_is_am437x
-# define soc_is_am43xx()   is_am43xx()
-# define soc_is_am437x()   is_am437x()
+# undef soc_is_am438x
+# define soc_is_am43xx()   of_machine_is_compatible(ti,am43)
+# define soc_is_am437x()   of_machine_is_compatible(ti,am4372)
+# define soc_is_am438x()   of_machine_is_compatible(ti,am438x)
  #endif


Hmm didn't I already comment on this change? I don't want to do it
for one SoC. Please add the SoC detection the old way for am43xx,
then do another series that changes all the DT only SoCs to use
of_machine_is_compatible() after it's been properly tested so now
regressions are caused for the early init code.


Okay. I misinterpreted your earlier comment. Thanks for clarifying.
I will re-do.


Actually, can you please do the following patches first while at it:

1.  Change dra7 SoC detection to intialize soc_name and soc_rev
 registers based on the of_machine_is_compatible so we don't
 do pointless string comparisons with the current code

2. Add am437x detection the same way

3. Change all the existing DT only SoCs to do the same (this
can be done in a separate series)

That should allow us to drop most of the SoC detection code.


Alright. I will post only the clock dts patch and the driver patches for 
now.


I will work on 1,2 and 3 in order.

Thanks Tony for your feedback.

-Keerthy


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 0/2] ARM: AM437X: Add rtc clock handling

2015-08-13 Thread Keerthy
The series is applicable for all am437x series of processors.
It adds clock handling support. Boot tested on am437x-gp-evm.

Keerthy (2):
  ARM: dts: AM437x: Add the internal and external clock nodes for rtc
  rtc: omap: Add external clock enabling support

 arch/arm/boot/dts/am4372.dtsi|  2 ++
 arch/arm/boot/dts/am437x-gp-evm.dts  | 13 +++
 arch/arm/boot/dts/am437x-idk-evm.dts |  9 
 arch/arm/boot/dts/am437x-sk-evm.dts  |  9 
 drivers/rtc/rtc-omap.c   | 44 
 5 files changed, 77 insertions(+)

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


[GIT PULL] omap gpmc null pointer fix against v4.2-rc6

2015-08-13 Thread Tony Lindgren
The following changes since commit cd4556733b30cc363adc7b1cea3bffa7e2dd0c7c:

  ARM: dts: dra7: Fix broken pbias device creation (2015-08-05 03:04:07 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.2/fixes-rc6

for you to fetch changes up to e984a1791ac6a7c944911207e8a9c344763f0003:

  memory: omap-gpmc: Don't try to save uninitialized GPMC context (2015-08-12 
01:43:49 -0700)


Fix a NULL pointer exception for omap GPMC bus code if probe fails.


Tomeu Vizoso (1):
  memory: omap-gpmc: Don't try to save uninitialized GPMC context

 drivers/memory/omap-gpmc.c | 6 ++
 1 file changed, 6 insertions(+)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 00/22] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

2015-08-13 Thread Tony Lindgren
* Roger Quadros rog...@ti.com [150813 00:17]:
 On 11/08/15 15:48, Tony Lindgren wrote:
  
  OK. Yeah let's make sure no regressions are caused by this.. We also
  still have the omap3 legacy booting around, have you checked that it
  keeps on working?
 
 I don't have any omap3 board with legacy support with me. I have omap3-beagle
 but looks like legacy boot is dropped for it already.
 
 I'll try to revert the patch that drops beagle support and test it on that 
 one.

OK yeah that should work just fine.

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


Re: [PATCH v2 00/22] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

2015-08-13 Thread Roger Quadros

On 11/08/15 15:48, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [150807 02:15]:
 Hi,

 We do a couple of things in this series which result in
 cleaner device tree implementation, faster perfomance and
 multi-platform support. As an added bonus we get new GPI/Interrupt pins
 for use in the system.

 - Establish a custom interface between NAND and GPMC driver. This is
 needed because all of the NAND registers sit in the GPMC register space.
 Some bits like NAND IRQ are even shared with GPMC.

 - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
 with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
 This causes performance increase when using prefetch-irq mode.
 30% increase in read, 17% increase in write in prefetch-irq mode.

 - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
 driver can be used on non-OMAP platforms. e.g. Keystone.

 - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
 2 to 4 of these and most of them would be unused otherwise. It also
 allows a cleaner implementation of NAND Ready pin status for the NAND driver.

 - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
 
 Nice job :) Using GPIOCHIP + IRQCHIP allows us to make the GPMC
 using drivers pretty much generic eventually.

Thanks :)
  
 NOTE: I've only adapted dra7.dtsi and dra7x-evms for this series.
 I will adapt all other boards when the series is in a shape to be accepted.
 
 OK. Yeah let's make sure no regressions are caused by this.. We also
 still have the omap3 legacy booting around, have you checked that it
 keeps on working?

I don't have any omap3 board with legacy support with me. I have omap3-beagle
but looks like legacy boot is dropped for it already.

I'll try to revert the patch that drops beagle support and test it on that one.

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 2/2] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

2015-08-13 Thread Heiko Stübner
Am Mittwoch, 12. August 2015, 16:12:41 schrieb Stephen Boyd:
 Use the provider based method to get a clock's name so that we
 can get rid of the clk member in struct clk_hw one day. Mostly
 converted with the following coccinelle script.
 
 @@
 struct clk_hw *E;
 @@
 
 -__clk_get_name(E-clk)
 +clk_hw_get_name(E)
 

For the Rockchip part
Reviewed-by: Heiko Stuebner he...@sntech.de


Heiko

 diff --git a/drivers/clk/rockchip/clk-inverter.c
 b/drivers/clk/rockchip/clk-inverter.c index 8054fdb5effb..7cbf43beb3c6
 100644
 --- a/drivers/clk/rockchip/clk-inverter.c
 +++ b/drivers/clk/rockchip/clk-inverter.c
 @@ -50,7 +50,7 @@ static int rockchip_inv_set_phase(struct clk_hw *hw, int
 degrees) val = !!degrees;
   } else {
   pr_err(%s: unsupported phase %d for %s\n,
 -__func__, degrees, __clk_get_name(hw-clk));
 +__func__, degrees, clk_hw_get_name(hw));
   return -EINVAL;
   }
 
 diff --git a/drivers/clk/rockchip/clk-mmc-phase.c
 b/drivers/clk/rockchip/clk-mmc-phase.c index 77e19097bdc7..9b613426e968
 100644
 --- a/drivers/clk/rockchip/clk-mmc-phase.c
 +++ b/drivers/clk/rockchip/clk-mmc-phase.c
 @@ -108,7 +108,7 @@ static int rockchip_mmc_set_phase(struct clk_hw *hw, int
 degrees) writel(HIWORD_UPDATE(raw_value, 0x07ff, mmc_clock-shift),
 mmc_clock-reg);
 
   pr_debug(%s-set_phase(%d) delay_nums=%u reg[0x%p]=0x%03x
 actual_degrees=%d\n, -   __clk_get_name(hw-clk), degrees, 
 delay_num,
 + clk_hw_get_name(hw), degrees, delay_num,
   mmc_clock-reg, raw_value(mmc_clock-shift),
   rockchip_mmc_get_phase(hw)
   );

--
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 3/6] genirq: introduce irq_chip_set_type_parent() helper

2015-08-13 Thread Sudeep Holla



On 12/08/15 18:45, Grygorii Strashko wrote:

It's expected to use this helper when the current
domain doesn't implement .irq_set_type(),  but expect
the parent to do so.

Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
  include/linux/irq.h |  1 +
  kernel/irq/chip.c   | 20 
  2 files changed, 21 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 92188b0..51744bc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -484,6 +484,7 @@ extern int irq_chip_set_affinity_parent(struct irq_data 
*data,
  extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on);
  extern int irq_chip_set_vcpu_affinity_parent(struct irq_data *data,
 void *vcpu_info);
+extern int irq_chip_set_type_parent(struct irq_data *data, unsigned int type);
  #endif

  /* Handling of unhandled and spurious interrupts: */
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index bdb1b9d..b48938b 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -985,6 +985,26 @@ int irq_chip_set_affinity_parent(struct irq_data *data,
  }

  /**
+ * irq_chip_set_type_parent - Set IRQ type on the parent interrupt
+ * @data:  Pointer to interrupt specific data
+ * @type:  IRQ_TYPE_{LEVEL,EDGE}_* value - see include/linux/irq.h
+ *
+ * Conditional, as the underlying parent chip might not implement it.
+ */
+int irq_chip_set_type_parent(struct irq_data *data, unsigned int type)
+{
+   data = data-parent_data;
+
+   if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+   return 0;
+


I think this is unrelated here(perhaps copy-paste error ?). I fail to
see how wakeup and trigger type are related.

Regards,
Sudeep
--
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 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Sudeep Holla



On 12/08/15 18:45, Grygorii Strashko wrote:

The irqchip_set_wake_parent should not fail if IRQ chip
specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
configuration can't be propagated properly through IRQ
domains hierarchy.

In case of TI OMAP DRA7 the issue reproduced with following
configuration:
ARM GIC-OMAP wakeupgen-TI CBAR-GPIO-GPIO pcf857x-gpio_key

gpio_key is wakeup source

Failure is reproduced during suspend/resume to RAM:
suspend:
  - gpio_keys_suspend
enable_irq_wake
  + pcf857x_irq_set_wake
+ omap_gpio_wake_enable
  + TI CBAR irq_chip_set_wake_parent
+ OMAP wakeupgen has no .irq_set_wake()
and -ENOSYS will be returned

resume:
  - gpio_keys_resume
+ disable_irq_wake
  + irq_set_irq_wake
+ WARN(1, Unbalanced IRQ %d wake disable\n, irq);

Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
  kernel/irq/chip.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct irq_data 
*data, void *vcpu_info)
  int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
  {
data = data-parent_data;
+
+   if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+   return 0;
+


[Nit] I think the irq core can access data-chip directly. Either way,
it's better to be consistent, the statement following doesn't use helper
function.

Otherwise looks good to me.

Regards,
Sudeep


if (data-chip-irq_set_wake)
return data-chip-irq_set_wake(data, on);



--
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] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

2015-08-13 Thread Thierry Reding
On Wed, Aug 12, 2015 at 04:12:41PM -0700, Stephen Boyd wrote:
 Use the provider based method to get a clock's name so that we
 can get rid of the clk member in struct clk_hw one day. Mostly
 converted with the following coccinelle script.
 
 @@
 struct clk_hw *E;
 @@
 
 -__clk_get_name(E-clk)
 +clk_hw_get_name(E)
 
[...]
  drivers/clk/tegra/clk-pll.c  |  8 

Acked-by: Thierry Reding tred...@nvidia.com


signature.asc
Description: PGP signature


Re: [PATCH-next 2/4] arm: boot: dts: am4372: add ARM timers and SCU nodes

2015-08-13 Thread Tony Lindgren
* Felipe Balbi ba...@ti.com [150812 13:00]:
 AM437x devices sport SCU, TWD and Global timers,
 let's add them to DTS so they have a chance to
 probe and be used by Linux.

Applying this one into omap-for-v4.3/dt-v2. Not sure
if it will get merged as we're getting close to the
merge window. The rest we can patch once Russell has
reverted the bogus SMP dependency.

Regards,

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


Re: [PATCH 2/2] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

2015-08-13 Thread Geert Uytterhoeven
On Thu, Aug 13, 2015 at 1:12 AM, Stephen Boyd sb...@codeaurora.org wrote:
 Use the provider based method to get a clock's name so that we
 can get rid of the clk member in struct clk_hw one day. Mostly
 converted with the following coccinelle script.

 @@
 struct clk_hw *E;
 @@

 -__clk_get_name(E-clk)
 +clk_hw_get_name(E)

 Cc: Heiko Stuebner he...@sntech.de
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Peter De Schrijver pdeschrij...@nvidia.com
 Cc: Prashant Gaikwad pgaik...@nvidia.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Thierry Reding thierry.red...@gmail.com
 Cc: Alexandre Courbot gnu...@gmail.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Cc: Andrew Bresticker abres...@chromium.org
 Cc: Ezequiel Garcia ezequiel.gar...@imgtec.com
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: Kevin Cernekee cerne...@chromium.org
 Cc: Geert Uytterhoeven geert+rene...@glider.be
 Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-rockc...@lists.infradead.org
 Cc: linux-samsung-...@vger.kernel.org
 Cc: linux-te...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

  drivers/clk/shmobile/clk-div6.c  |  2 +-

For the shmobile part:

Acked-by: Geert Uytterhoeven geert+rene...@glider.be

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

2015-08-13 Thread Sebastian Hesselbarth

On 08/13/2015 01:12 AM, Stephen Boyd wrote:

Use the provider based method to get a clock's name so that we
can get rid of the clk member in struct clk_hw one day. Mostly
converted with the following coccinelle script.

@@
struct clk_hw *E;
@@

-__clk_get_name(E-clk)
+clk_hw_get_name(E)

[...]

Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
  drivers/clk/berlin/berlin2-pll.c |  4 ++--


For Berlin,

Acked-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

Thanks!

[...]

diff --git a/drivers/clk/berlin/berlin2-pll.c b/drivers/clk/berlin/berlin2-pll.c
index f4b8d324b083..1c2294d3ba85 100644
--- a/drivers/clk/berlin/berlin2-pll.c
+++ b/drivers/clk/berlin/berlin2-pll.c
@@ -61,7 +61,7 @@ berlin2_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
fbdiv = (val  map-fbdiv_shift)  FBDIV_MASK;
rfdiv = (val  map-rfdiv_shift)  RFDIV_MASK;
if (rfdiv == 0) {
-   pr_warn(%s has zero rfdiv\n, __clk_get_name(hw-clk));
+   pr_warn(%s has zero rfdiv\n, clk_hw_get_name(hw));
rfdiv = 1;
}

@@ -70,7 +70,7 @@ berlin2_pll_recalc_rate(struct clk_hw *hw, unsigned long 
parent_rate)
vcodiv = map-vcodiv[vcodivsel];
if (vcodiv == 0) {
pr_warn(%s has zero vcodiv (index %d)\n,
-   __clk_get_name(hw-clk), vcodivsel);
+   clk_hw_get_name(hw), vcodivsel);
vcodiv = 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 v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

2015-08-13 Thread Keerthy



On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:

* Keerthy a0393...@ti.com [150811 10:57]:



On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:

* Keerthy j-keer...@ti.com [150810 02:31]:

@@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
  #ifdefCONFIG_SOC_AM43XX
  # undef soc_is_am43xx
  # undef soc_is_am437x
-# define soc_is_am43xx()   is_am43xx()
-# define soc_is_am437x()   is_am437x()
+# undef soc_is_am438x
+# define soc_is_am43xx()   of_machine_is_compatible(ti,am43)
+# define soc_is_am437x()   of_machine_is_compatible(ti,am4372)
+# define soc_is_am438x()   of_machine_is_compatible(ti,am438x)
  #endif


Hmm didn't I already comment on this change? I don't want to do it
for one SoC. Please add the SoC detection the old way for am43xx,
then do another series that changes all the DT only SoCs to use
of_machine_is_compatible() after it's been properly tested so now
regressions are caused for the early init code.


Okay. I misinterpreted your earlier comment. Thanks for clarifying.
I will re-do.


Actually, can you please do the following patches first while at it:

1.  Change dra7 SoC detection to intialize soc_name and soc_rev
 registers based on the of_machine_is_compatible so we don't
 do pointless string comparisons with the current code


Tony,

just another confirmation. So the intent here is to directly do
of_machine_is_compatible checks instead if soc_is_dra* and try to remove 
soc_is calls from mach-omap2 code right?


-Keerthy


2. Add am437x detection the same way

3. Change all the existing DT only SoCs to do the same (this
can be done in a separate series)

That should allow us to drop most of the SoC detection code.

Regards,

Tony


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


Re: [PATCH v2 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod

2015-08-13 Thread Tero Kristo

On 08/12/2015 05:39 PM, Paul Walmsley wrote:

On Mon, 10 Aug 2015, Keerthy wrote:


The patch adds rtc hwmod. This is present on gp and sk evm and not on
epos evm. Hence adding it selectively using a seprate list.

Signed-off-by: Keerthy j-keer...@ti.com


So just to confirm, the RTC IP block has been physically removed or
permanently disabled on these new AM438x chips?  So the registers are no
longer accessible by the MPU?

Is there a TRM available for these chips?


No public TRM available, as the SoC mostly contains secure environment 
support on them.


The RTC module is physically present on the SoC, but it is permanently 
disabled. A secure RTC is used instead on these devices, where needed.


-Tero




- 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



--
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: AM437x: Add the internal and external clock nodes for rtc

2015-08-13 Thread Keerthy
rtc can either be supplied from internal 32k clock or external crystal
generated 32k clock. Internal clock is SOC specific and the external
clock is board dependent. Adding the corresponding nodes.

Signed-off-by: Keerthy j-keer...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi|  2 ++
 arch/arm/boot/dts/am437x-gp-evm.dts  | 13 +
 arch/arm/boot/dts/am437x-idk-evm.dts |  9 +
 arch/arm/boot/dts/am437x-sk-evm.dts  |  9 +
 4 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d99b2ee..484f092 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -336,6 +336,8 @@
interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
  GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = rtc;
+   clocks = clk_32768_ck;
+   clock-names = int-clk;
status = disabled;
};
 
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 215775d..22038f2 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -112,6 +112,13 @@
clock-frequency = 1200;
};
 
+   /* fixed 32k external oscillator clock */
+   clk_32k_rtc: clk_32k_rtc {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 32768;
+   };
+
sound0: sound@0 {
compatible = simple-audio-card;
simple-audio-card,name = AM437x-GP-EVM;
@@ -941,3 +948,9 @@
tx-num-evt = 32;
rx-num-evt = 32;
 };
+
+rtc {
+   clocks = clk_32k_rtc, clk_32768_ck;
+   clock-names = ext-clk, int-clk;
+   status = okay;
+};
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts 
b/arch/arm/boot/dts/am437x-idk-evm.dts
index 37834427..af25801 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -110,6 +110,13 @@
gpios = gpio4 2 GPIO_ACTIVE_LOW;
};
};
+
+   /* fixed 32k external oscillator clock */
+   clk_32k_rtc: clk_32k_rtc {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 32768;
+   };
 };
 
 am43xx_pinmux {
@@ -394,6 +401,8 @@
 };
 
 rtc {
+   clocks = clk_32k_rtc, clk_32768_ck;
+   clock-names = ext-clk, int-clk;
status = okay;
 };
 
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 22af448..7da7c2d 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -24,6 +24,13 @@
display0 = lcd0;
};
 
+   /* fixed 32k external oscillator clock */
+   clk_32k_rtc: clk_32k_rtc {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 32768;
+   };
+
backlight {
compatible = pwm-backlight;
pwms = ecap0 0 5 PWM_POLARITY_INVERTED;
@@ -697,6 +704,8 @@
 };
 
 rtc {
+   clocks = clk_32k_rtc, clk_32768_ck;
+   clock-names = ext-clk, int-clk;
status = okay;
 };
 
-- 
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 2/2] rtc: omap: Add external clock enabling support

2015-08-13 Thread Keerthy
Configure the clock source to either internal clock
or external clock based on the availability of the clocks.
External clock is preferred as it can be ticking during suspend.

Signed-off-by: Keerthy j-keer...@ti.com
---
 drivers/rtc/rtc-omap.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8b6355f..479f730 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -25,6 +25,7 @@
 #include linux/of_device.h
 #include linux/pm_runtime.h
 #include linux/io.h
+#include linux/clk.h
 
 /*
  * The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
@@ -107,6 +108,7 @@
 
 /* OMAP_RTC_OSC_REG bit fields: */
 #define OMAP_RTC_OSC_32KCLK_EN BIT(6)
+#define OMAP_RTC_OSC_SEL_32KCLK_SRCBIT(3)
 
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1)
@@ -136,6 +138,7 @@ struct omap_rtc {
int irq_timer;
u8 interrupts_reg;
bool is_pmic_controller;
+   bool has_ext_clk;
const struct omap_rtc_device_type *type;
 };
 
@@ -525,6 +528,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
 {
struct omap_rtc *rtc;
struct resource *res;
+   struct clk *ext_clk, *int_clk;
u8 reg, mask, new_ctrl;
const struct platform_device_id *id_entry;
const struct of_device_id *of_id;
@@ -553,6 +557,17 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (rtc-irq_alarm = 0)
return -ENOENT;
 
+   ext_clk = devm_clk_get(pdev-dev, ext-clk);
+   if (!IS_ERR(ext_clk)) {
+   rtc-has_ext_clk = true;
+   clk_prepare(ext_clk);
+   } else {
+   int_clk = devm_clk_get(pdev-dev, int-clk);
+
+   if (!IS_ERR(int_clk))
+   clk_prepare(int_clk);
+   }
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rtc-base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(rtc-base))
@@ -627,6 +642,17 @@ static int omap_rtc_probe(struct platform_device *pdev)
if (reg != new_ctrl)
rtc_write(rtc, OMAP_RTC_CTRL_REG, new_ctrl);
 
+   /*
+* If we have the external clock then
+* Switch to external clock so we can keep ticking
+* acorss suspend
+*/
+   if (rtc-has_ext_clk) {
+   reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+   rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
+ OMAP_RTC_OSC_SEL_32KCLK_SRC);
+   }
+
rtc-type-lock(rtc);
 
device_init_wakeup(pdev-dev, true);
@@ -672,6 +698,8 @@ err:
 static int __exit omap_rtc_remove(struct platform_device *pdev)
 {
struct omap_rtc *rtc = platform_get_drvdata(pdev);
+   struct clk *ext_clk, *int_clk;
+   u8 reg;
 
if (pm_power_off == omap_rtc_power_off 
omap_rtc_power_off_rtc == rtc) {
@@ -681,10 +709,26 @@ static int __exit omap_rtc_remove(struct platform_device 
*pdev)
 
device_init_wakeup(pdev-dev, 0);
 
+   ext_clk = devm_clk_get(pdev-dev, ext-clk);
+   if (!IS_ERR(ext_clk)) {
+   clk_unprepare(ext_clk);
+   } else {
+   int_clk = devm_clk_get(pdev-dev, int-clk);
+
+   if (!IS_ERR(int_clk))
+   clk_unprepare(int_clk);
+   }
+
rtc-type-unlock(rtc);
/* leave rtc running, but disable irqs */
rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
 
+   if (rtc-has_ext_clk) {
+   reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+   reg = ~OMAP_RTC_OSC_SEL_32KCLK_SRC;
+   rtc_write(rtc, OMAP_RTC_OSC_REG, reg);
+   }
+
rtc-type-lock(rtc);
 
/* Disable the clock/module */
-- 
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 v2 06/22] mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty check

2015-08-13 Thread Roger Quadros


On 07/08/15 12:12, Roger Quadros wrote:
 Instead of accessing the gpmc_status register directly start
 using the gpmc_nand_ops-nand_writebuffer_empty() helper
 to check write buffer empty status.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mtd/nand/omap2.c | 12 ++--
  1 file changed, 2 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
 index f214fe2..5c2f6df 100644
 --- a/drivers/mtd/nand/omap2.c
 +++ b/drivers/mtd/nand/omap2.c
 @@ -289,15 +289,11 @@ static void omap_write_buf8(struct mtd_info *mtd, const 
 u_char *buf, int len)
   struct omap_nand_info *info = container_of(mtd,
   struct omap_nand_info, mtd);
   u_char *p = (u_char *)buf;
 - u32 status = 0;
  
   while (len--) {
   iowrite8(*p++, info-nand.IO_ADDR_W);
   /* wait until buffer is available for write */
 - do {
 - status = readl(info-reg.gpmc_status) 
 - STATUS_BUFF_EMPTY;
 - } while (!status);
 + while (info-ops-nand_writebuffer_empty());

This should be
while (!info-ops-nand_writebuffer_empty());

   }
  }
  
 @@ -325,17 +321,13 @@ static void omap_write_buf16(struct mtd_info *mtd, 
 const u_char * buf, int len)
   struct omap_nand_info *info = container_of(mtd,
   struct omap_nand_info, mtd);
   u16 *p = (u16 *) buf;
 - u32 status = 0;
   /* FIXME try bursts of writesw() or DMA ... */
   len = 1;
  
   while (len--) {
   iowrite16(*p++, info-nand.IO_ADDR_W);
   /* wait until buffer is available for write */
 - do {
 - status = readl(info-reg.gpmc_status) 
 - STATUS_BUFF_EMPTY;
 - } while (!status);
 + while (info-ops-nand_writebuffer_empty());

here as well.

   }
  }
  
 

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 v2 07/13] memory: kill off set_irq_flags usage

2015-08-13 Thread Tony Lindgren
* Rob Herring r...@kernel.org [150712 07:29]:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:
 
 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN
 
 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

Applying this one into omap-for-v4.3/soc thanks.

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


Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

2015-08-13 Thread Tony Lindgren
* Keerthy a0393...@ti.com [150813 02:08]:
 
 
 On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:
 * Keerthy a0393...@ti.com [150811 10:57]:
 
 
 On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
 * Keerthy j-keer...@ti.com [150810 02:31]:
 @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
   #ifdef  CONFIG_SOC_AM43XX
   # undef soc_is_am43xx
   # undef soc_is_am437x
 -# define soc_is_am43xx() is_am43xx()
 -# define soc_is_am437x() is_am437x()
 +# undef soc_is_am438x
 +# define soc_is_am43xx() of_machine_is_compatible(ti,am43)
 +# define soc_is_am437x() of_machine_is_compatible(ti,am4372)
 +# define soc_is_am438x() of_machine_is_compatible(ti,am438x)
   #endif
 
 Hmm didn't I already comment on this change? I don't want to do it
 for one SoC. Please add the SoC detection the old way for am43xx,
 then do another series that changes all the DT only SoCs to use
 of_machine_is_compatible() after it's been properly tested so now
 regressions are caused for the early init code.
 
 Okay. I misinterpreted your earlier comment. Thanks for clarifying.
 I will re-do.
 
 Actually, can you please do the following patches first while at it:
 
 1.  Change dra7 SoC detection to intialize soc_name and soc_rev
  registers based on the of_machine_is_compatible so we don't
  do pointless string comparisons with the current code
 
 just another confirmation. So the intent here is to directly do
 of_machine_is_compatible checks instead if soc_is_dra* and try to remove
 soc_is calls from mach-omap2 code right?

Only do of_machine_is_compatible check once to initialize
the necessary variables for soc_is_* to use. 

Rgarads,

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] usb: phy: phy-generic: Fix reset behaviour on legacy boot

2015-08-13 Thread Roger Quadros
The gpio-desc migration done in v4.0 caused a regression
with legacy boots due to reversed reset logic.
e.g. omap3-beagle USB host breaks on legacy boot.

Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that
it matches the driver logic and pin behaviour.

Fixes: e9f2cefb0cdc (usb: phy: generic: migrate to gpio_desc)
Cc: sta...@vger.kernel.org # 4.0+
Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/phy/phy-generic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index deee68e..0cd85f2 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -230,7 +230,8 @@ int usb_phy_gen_create_phy(struct device *dev, struct 
usb_phy_generic *nop,
clk_rate = pdata-clk_rate;
needs_vcc = pdata-needs_vcc;
if (gpio_is_valid(pdata-gpio_reset)) {
-   err = devm_gpio_request_one(dev, pdata-gpio_reset, 0,
+   err = devm_gpio_request_one(dev, pdata-gpio_reset,
+   GPIOF_ACTIVE_LOW,
dev_name(dev));
if (!err)
nop-gpiod_reset =
-- 
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 v2 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Grygorii Strashko

On 08/13/2015 11:54 AM, Sudeep Holla wrote:



On 12/08/15 18:45, Grygorii Strashko wrote:

The irqchip_set_wake_parent should not fail if IRQ chip
specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
configuration can't be propagated properly through IRQ
domains hierarchy.

In case of TI OMAP DRA7 the issue reproduced with following
configuration:
ARM GIC-OMAP wakeupgen-TI CBAR-GPIO-GPIO pcf857x-gpio_key

gpio_key is wakeup source

Failure is reproduced during suspend/resume to RAM:
suspend:
  - gpio_keys_suspend
enable_irq_wake
  + pcf857x_irq_set_wake
+ omap_gpio_wake_enable
  + TI CBAR irq_chip_set_wake_parent
+ OMAP wakeupgen has no .irq_set_wake()
and -ENOSYS will be returned

resume:
  - gpio_keys_resume
+ disable_irq_wake
  + irq_set_irq_wake
+ WARN(1, Unbalanced IRQ %d wake disable\n, irq);

Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
  kernel/irq/chip.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct
irq_data *data, void *vcpu_info)
  int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
  {
  data = data-parent_data;
+
+if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+return 0;
+


[Nit] I think the irq core can access data-chip directly. Either way,
it's better to be consistent, the statement following doesn't use helper
function.


thanks. I'll change it to:
if (data-chip-flags  IRQCHIP_SKIP_SET_WAKE)
return 0;



Otherwise looks good to me.


Does it means that I can add your Reviewed-by: with above change?





  if (data-chip-irq_set_wake)
  return data-chip-irq_set_wake(data, on);





--
regards,
-grygorii
--
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 3/6] genirq: introduce irq_chip_set_type_parent() helper

2015-08-13 Thread Grygorii Strashko

On 08/13/2015 11:58 AM, Sudeep Holla wrote:



On 12/08/15 18:45, Grygorii Strashko wrote:

It's expected to use this helper when the current
domain doesn't implement .irq_set_type(),  but expect
the parent to do so.

Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
  include/linux/irq.h |  1 +
  kernel/irq/chip.c   | 20 
  2 files changed, 21 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 92188b0..51744bc 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -484,6 +484,7 @@ extern int irq_chip_set_affinity_parent(struct
irq_data *data,
  extern int irq_chip_set_wake_parent(struct irq_data *data, unsigned
int on);
  extern int irq_chip_set_vcpu_affinity_parent(struct irq_data *data,
   void *vcpu_info);
+extern int irq_chip_set_type_parent(struct irq_data *data, unsigned
int type);
  #endif

  /* Handling of unhandled and spurious interrupts: */
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index bdb1b9d..b48938b 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -985,6 +985,26 @@ int irq_chip_set_affinity_parent(struct irq_data
*data,
  }

  /**
+ * irq_chip_set_type_parent - Set IRQ type on the parent interrupt
+ * @data:Pointer to interrupt specific data
+ * @type:IRQ_TYPE_{LEVEL,EDGE}_* value - see include/linux/irq.h
+ *
+ * Conditional, as the underlying parent chip might not implement it.
+ */
+int irq_chip_set_type_parent(struct irq_data *data, unsigned int type)
+{
+data = data-parent_data;
+
+if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+return 0;
+


I think this is unrelated here(perhaps copy-paste error ?). I fail to
see how wakeup and trigger type are related.


Oh. Yes, it's copy-paste error. thanks, will fix.

--
regards,
-grygorii
--
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: [net-next PATCH 3/3] ARM: dts: am33xx: update cpsw compatible

2015-08-13 Thread Tony Lindgren
* Mugunthan V N mugunthan...@ti.com [150812 02:56]:
 CPSW driver has been updated with compatibles for enabling errata
 workarounds. So updating cpsw compatibles.
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

This too:

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/boot/dts/am33xx.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index 21fcc44..8b59c86 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -700,7 +700,7 @@
   };
  
   mac: ethernet@4a10 {
 - compatible = ti,cpsw;
 + compatible = ti,am335x-cpsw,ti,cpsw;
   ti,hwmods = cpgmac0;
   clocks = cpsw_125mhz_gclk, cpsw_cpts_rft_clk;
   clock-names = fck, cpts;
 -- 
 2.5.0.234.gefc8a62
 
--
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: [net-next PATCH 2/3] ARM: dts: dra7: update cpsw compatible

2015-08-13 Thread Tony Lindgren
* Mugunthan V N mugunthan...@ti.com [150812 02:56]:
 CPSW driver has been updated with compatibles for enabling errata
 workarounds. So updating cpsw compatibles.
 
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

Please feel free to merge this one via net tree once the changes
are reviewed:

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/boot/dts/dra7.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
 index 8f1e25b..b4fdd10 100644
 --- a/arch/arm/boot/dts/dra7.dtsi
 +++ b/arch/arm/boot/dts/dra7.dtsi
 @@ -1398,7 +1398,7 @@
   };
  
   mac: ethernet@4a10 {
 - compatible = ti,cpsw;
 + compatible = ti,dra7-cpsw,ti,cpsw;
   ti,hwmods = gmac;
   clocks = dpll_gmac_ck, gmac_gmii_ref_clk_div;
   clock-names = fck, cpts;
 -- 
 2.5.0.234.gefc8a62
 
--
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 6/6] irqchip: crossbar: fix irq masking at suspend

2015-08-13 Thread Sudeep Holla



On 12/08/15 18:46, Grygorii Strashko wrote:

All ARM GIC IRQs have to masked during suspend if they are not
wakeup source. Now this is not happen, since switching to
use IRQ domain hierarchy, because suspend_device_irq() only checks flags
in the last IRQ chip in hierarchy for IRQCHIP_MASK_ON_SUSPEND
bit set. And in the case of TI OMAP DRA7 the last IRQ chip is TI Crossbar
which do not have this flag set.

In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
   ARM GIC - OMAP wakeupgen - TI CBAR
ARM GIC - IRQCHIP_MASK_ON_SUSPEND=n


May be this won't affect your platform or this patch but even GIC marks
IRQCHIP_MASK_ON_SUSPEND=y now since GIC doesn't provide any facility to
configure the wakeup source and keeps all the interrupt source enabled.

We have this flag enabled now as it's always safer to mask all the non
wakeup interrupts are masked at the chip level when suspending.

Also the beginning of the commit message contradicts when you also say
in the following statement IRQCHIP_MASK_ON_SUSPEND=n. So you may need to
update the log.

Regards,
Sudeep
--
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 5/6] ARM: OMAP: wakeupgen: fix arm gic irq type configuration

2015-08-13 Thread Tony Lindgren
* Grygorii Strashko grygorii.stras...@ti.com [150812 10:49]:
 It's observed that ARM GIC IRQ triggering type is not configured
 properly when IRQ is routed through IRQ domain hierarchy and
 system started using DT. As result, system will start using default
 ARM GIC configuration, ignore DT IRQ triggering configuration,
 and value of desc-irq_data.state_use_accessors = 0.
 
 In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
 ARM GIC - OMAP wakeupgen - TI CBAR
 
 Failed call chain:
  irq_create_of_mapping
  irq_set_irq_type
  __irq_set_trigger
  if (!chip || !chip-irq_set_type) {
 return 0; - return here
  }
 OMAP wakeupgen has no .irq_set_type() defined and, so, IRQ triggering
 configuration will not be propagated to parent IRQ domain.
 
 Hence, fix it by using irq_chip_set_type_parent() for
 propagation IRQ triggering type to parent IRQ domains.
 
 Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com

Makse sense to merge this along with the irqchip changes once those
are ready, so feel free to add to this one:

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/mach-omap2/omap-wakeupgen.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c 
 b/arch/arm/mach-omap2/omap-wakeupgen.c
 index 8e52621..e1d2e99 100644
 --- a/arch/arm/mach-omap2/omap-wakeupgen.c
 +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
 @@ -392,6 +392,7 @@ static struct irq_chip wakeupgen_chip = {
   .irq_mask   = wakeupgen_mask,
   .irq_unmask = wakeupgen_unmask,
   .irq_retrigger  = irq_chip_retrigger_hierarchy,
 + .irq_set_type   = irq_chip_set_type_parent,
   .flags  = IRQCHIP_SKIP_SET_WAKE | 
 IRQCHIP_MASK_ON_SUSPEND,
  #ifdef CONFIG_SMP
   .irq_set_affinity   = irq_chip_set_affinity_parent,
 -- 
 2.5.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 v2 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Grygorii Strashko

On 08/13/2015 01:01 PM, Marc Zyngier wrote:

On 12/08/15 18:45, Grygorii Strashko wrote:

The irqchip_set_wake_parent should not fail if IRQ chip
specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
configuration can't be propagated properly through IRQ
domains hierarchy.

In case of TI OMAP DRA7 the issue reproduced with following
configuration:
ARM GIC-OMAP wakeupgen-TI CBAR-GPIO-GPIO pcf857x-gpio_key

gpio_key is wakeup source

Failure is reproduced during suspend/resume to RAM:
suspend:
  - gpio_keys_suspend
enable_irq_wake
  + pcf857x_irq_set_wake
+ omap_gpio_wake_enable
  + TI CBAR irq_chip_set_wake_parent
+ OMAP wakeupgen has no .irq_set_wake()


Most importantly, wakeupgen has IRQCHIP_SKIP_SET_WAKE set.


and -ENOSYS will be returned

resume:
  - gpio_keys_resume
+ disable_irq_wake
  + irq_set_irq_wake
+ WARN(1, Unbalanced IRQ %d wake disable\n, irq);

Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
  kernel/irq/chip.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct irq_data 
*data, void *vcpu_info)
  int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
  {
data = data-parent_data;
+
+   if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+   return 0;
+
if (data-chip-irq_set_wake)
return data-chip-irq_set_wake(data, on);




We have a more general issue with chip flags, and how they combine
within a stack of irqchips.


Indeed. Problem looks similar to IRQCHIP_MASK_ON_SUSPEND flag usage.



What if you remove the irq_chip_set_wake_parent from the crossbar
driver, and instead set IRQCHIP_SKIP_SET_WAKE?


I've thought about this and it should work for me.
One question - what if crossbar will be not the last one in
IRQ domains hierarchy?


--
regards,
-grygorii
--
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/6] genirq: fix irq_chip_retrigger_hierarchy

2015-08-13 Thread Marc Zyngier
[adding Jiang to the cc list]

On 12/08/15 18:45, Grygorii Strashko wrote:
 Now irq_chip_retrigger_hierarchy() returns -ENOSYS if it
 was not able to find at least one .irq_retrigger() callback
 implemented in IRQ domain hierarchy. As result, IRQ
 re-triggering is not working now on ARM (TI OMAP) where
 ARM GIC is not implemented this callback.
 The .irq_retrigger() is optional (see check_irq_resend())
 and there are no reasons to fail if it was not found, hence
 lets return 0 in this case.
 
 In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
 ARM GIC - OMAP wakeupgen - TI CBAR
 
 Failure is reproduced during resume from suspend to RAM:
 - wakeup by IRQx
 - suspend_enter
   + arch_suspend_enable_irqs
 + handle_fasteoi_irq
   + irq_may_run
 + irq_pm_check_wakeup
   + irq_disable(IRQx)
   + dpm_resume_noirq()
 + resume_device_irqs
   + resume_irqs
 + resume_irq
   + __enable_irq == IRQx is not re-triggered
 
 Fixes: 85f08c17de26 ('genirq: Introduce helper functions...')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
 ---
  kernel/irq/chip.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
 index 27f4332..6de638b 100644
 --- a/kernel/irq/chip.c
 +++ b/kernel/irq/chip.c
 @@ -997,7 +997,7 @@ int irq_chip_retrigger_hierarchy(struct irq_data *data)
   if (data-chip  data-chip-irq_retrigger)
   return data-chip-irq_retrigger(data);
  
 - return -ENOSYS;
 + return 0;
  }
  
  /**
 

I think this makes sense. Not having an irq_retrigger or having an
irq_retrigger that returns zero are the same thing.

Actually, we don't even distinguish between a retrigger that
successfully poked the HW, and a retrigger that returned an error. Both
are considered to not to require a SW retrigger... maybe we should fix
that too. Jiang, Thomas?

Anyway, for this patch:

Reviewed-by: Marc Zyngier marc.zyng...@arm.com

M.
-- 
Jazz is not dead. It just smells funny...
--
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 6/6] irqchip: crossbar: fix irq masking at suspend

2015-08-13 Thread Grygorii Strashko
On 08/13/2015 12:30 PM, Sudeep Holla wrote:
 
 
 On 12/08/15 18:46, Grygorii Strashko wrote:
 All ARM GIC IRQs have to masked during suspend if they are not
 wakeup source. Now this is not happen, since switching to
 use IRQ domain hierarchy, because suspend_device_irq() only checks flags
 in the last IRQ chip in hierarchy for IRQCHIP_MASK_ON_SUSPEND
 bit set. And in the case of TI OMAP DRA7 the last IRQ chip is TI Crossbar
 which do not have this flag set.

 In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
 ARM GIC - IRQCHIP_MASK_ON_SUSPEND=n
 
 May be this won't affect your platform or this patch but even GIC marks
 IRQCHIP_MASK_ON_SUSPEND=y now since GIC doesn't provide any facility to
 configure the wakeup source and keeps all the interrupt source enabled.

That's true for next, bur not true for 4.2-rc6 or 4.1 :(

 
 We have this flag enabled now as it's always safer to mask all the non
 wakeup interrupts are masked at the chip level when suspending.

Indeed, but that's do not work in case of IRQ domain hierarchy and
it's do not clear how should it work?
I've tried to describe this problem in cover letter actually.

 
 Also the beginning of the commit message contradicts when you also say
 in the following statement IRQCHIP_MASK_ON_SUSPEND=n. So you may need to
 update the log.

I'll try to reword. What I've tried to mention that IRQs masking on
suspend is default expected behavior and that how it was before
switching to IRQ domain hierarchy.

All ARM GIC IRQs have to masked during suspend if they are not
 wakeup source - this is expected behavior and that's how it was before
 switching to IRQ domain hierarchy. ...
ok?

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


[GIT PULL 1/2] omap soc fix for v4.3 merge window

2015-08-13 Thread Tony Lindgren
The following changes since commit 24da741c678f865de3182194604dbddcc7fc7f3c:

  Merge branch 'dm814x-soc' into omap-for-v4.3/soc (2015-07-23 21:59:18 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.3/soc-pt2

for you to fetch changes up to ed293d1ad2b0c28b6abc3bd728b07754bc00f1cd:

  memory: kill off set_irq_flags usage (2015-08-13 00:48:52 -0700)


Fix omap PM regression in Linux next and kill set_irq_flags usage
for GPMC.


Rob Herring (1):
  memory: kill off set_irq_flags usage

Tony Lindgren (1):
  ARM: OMAP2+: Fix power domain operations regression caused by 81xx

 arch/arm/mach-omap2/powerdomains3xxx_data.c | 6 +-
 drivers/memory/omap-gpmc.c  | 5 ++---
 2 files changed, 7 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL 2/2] omap device tree changes for v4.3, part 4

2015-08-13 Thread Tony Lindgren
The following changes since commit ed05637c30e6d13e5793aab64d6a6e57e30228af:

  ARM: dts: omap3-devkit8000: Add ADS7846 Touchscreen support (2015-08-06 
02:43:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v4.3/dt-pt4-v2

for you to fetch changes up to 8cbd4c2f6a996f6cf5dfdf8775d331606cff95bd:

  arm: boot: dts: am4372: add ARM timers and SCU nodes (2015-08-13 01:25:11 
-0700)


Fix up bogus RTC compatible change for am4372 and add missing
DPLL for am4372 cpsw Ethernet driver. Also add ARM global and
local timers for am4372.


Felipe Balbi (1):
  arm: boot: dts: am4372: add ARM timers and SCU nodes

Keerthy (3):
  ARM: dts: AM437X: add dpll_clksel_mac_clk node
  ARM: dts: am4372: Set the default clock rate for dpll_clksel_mac_clk clock
  ARM: dts: AM4372: Add the am4372-rtc compatible string

Tony Lindgren (1):
  Merge branch 'for-4.3/ti-clk-dt' of https://github.com/t-kristo/linux-pm 
into omap-for-v4.3/dt-v2

 Documentation/devicetree/bindings/rtc/rtc-omap.txt |  1 +
 arch/arm/boot/dts/am4372.dtsi  | 31 +++---
 arch/arm/boot/dts/am43xx-clocks.dtsi   |  9 +++
 drivers/clk/ti/clk-43xx.c  |  1 +
 4 files changed, 39 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Sudeep Holla



On 13/08/15 10:51, Grygorii Strashko wrote:

On 08/13/2015 11:54 AM, Sudeep Holla wrote:



On 12/08/15 18:45, Grygorii Strashko wrote:


[...]


diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6de638b..bdb1b9d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct
irq_data *data, void *vcpu_info)
   int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
   {
   data = data-parent_data;
+
+if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
+return 0;
+


[Nit] I think the irq core can access data-chip directly. Either way,
it's better to be consistent, the statement following doesn't use helper
function.


thanks. I'll change it to:
if (data-chip-flags  IRQCHIP_SKIP_SET_WAKE)
return 0;



Otherwise looks good to me.


Does it means that I can add your Reviewed-by: with above change?



Yes you can.

Regards,
Sudeep
--
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 6/6] irqchip: crossbar: fix irq masking at suspend

2015-08-13 Thread Sudeep Holla



On 13/08/15 11:17, Grygorii Strashko wrote:

On 08/13/2015 12:30 PM, Sudeep Holla wrote:



On 12/08/15 18:46, Grygorii Strashko wrote:

All ARM GIC IRQs have to masked during suspend if they are not
wakeup source. Now this is not happen, since switching to
use IRQ domain hierarchy, because suspend_device_irq() only checks flags
in the last IRQ chip in hierarchy for IRQCHIP_MASK_ON_SUSPEND
bit set. And in the case of TI OMAP DRA7 the last IRQ chip is TI Crossbar
which do not have this flag set.

In case of TI OMAP DRA7 the following IRQ hierarchy is defined:
ARM GIC - OMAP wakeupgen - TI CBAR
ARM GIC - IRQCHIP_MASK_ON_SUSPEND=n


May be this won't affect your platform or this patch but even GIC marks
IRQCHIP_MASK_ON_SUSPEND=y now since GIC doesn't provide any facility to
configure the wakeup source and keeps all the interrupt source enabled.


That's true for next, bur not true for 4.2-rc6 or 4.1 :(



True, I just wanted to ensure there is no assumption.

[...]


Also the beginning of the commit message contradicts when you also say
in the following statement IRQCHIP_MASK_ON_SUSPEND=n. So you may need to
update the log.


I'll try to reword. What I've tried to mention that IRQs masking on
suspend is default expected behavior and that how it was before
switching to IRQ domain hierarchy.

All ARM GIC IRQs have to masked during suspend if they are not
  wakeup source - this is expected behavior and that's how it was before
  switching to IRQ domain hierarchy. ...
ok?



My mistake I referred the code after it was converted to use stack
domains. So I missed to understand that you were using gic_arch_extn
flags before to override GIC flags as gic_set_irqchip_flags was not
used when I removed it. Sorry for the noise, you can retain the commit
log as is.

Regards,
Sudeep
--
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 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Marc Zyngier
On 12/08/15 18:45, Grygorii Strashko wrote:
 The irqchip_set_wake_parent should not fail if IRQ chip
 specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
 configuration can't be propagated properly through IRQ
 domains hierarchy.
 
 In case of TI OMAP DRA7 the issue reproduced with following
 configuration:
 ARM GIC-OMAP wakeupgen-TI CBAR-GPIO-GPIO pcf857x-gpio_key
 
 gpio_key is wakeup source
 
 Failure is reproduced during suspend/resume to RAM:
 suspend:
  - gpio_keys_suspend
enable_irq_wake
  + pcf857x_irq_set_wake
+ omap_gpio_wake_enable
  + TI CBAR irq_chip_set_wake_parent
+ OMAP wakeupgen has no .irq_set_wake()

Most importantly, wakeupgen has IRQCHIP_SKIP_SET_WAKE set.

and -ENOSYS will be returned
 
 resume:
  - gpio_keys_resume
+ disable_irq_wake
  + irq_set_irq_wake
+ WARN(1, Unbalanced IRQ %d wake disable\n, irq);
 
 Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
 ---
  kernel/irq/chip.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
 index 6de638b..bdb1b9d 100644
 --- a/kernel/irq/chip.c
 +++ b/kernel/irq/chip.c
 @@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct irq_data 
 *data, void *vcpu_info)
  int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
  {
   data = data-parent_data;
 +
 + if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
 + return 0;
 +
   if (data-chip-irq_set_wake)
   return data-chip-irq_set_wake(data, on);
  
 

We have a more general issue with chip flags, and how they combine
within a stack of irqchips.

What if you remove the irq_chip_set_wake_parent from the crossbar
driver, and instead set IRQCHIP_SKIP_SET_WAKE?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] omap gpmc null pointer fix against v4.2-rc6

2015-08-13 Thread Olof Johansson
On Thu, Aug 13, 2015 at 01:20:22AM -0700, Tony Lindgren wrote:
 The following changes since commit cd4556733b30cc363adc7b1cea3bffa7e2dd0c7c:
 
   ARM: dts: dra7: Fix broken pbias device creation (2015-08-05 03:04:07 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
 tags/omap-for-v4.2/fixes-rc6
 
 for you to fetch changes up to e984a1791ac6a7c944911207e8a9c344763f0003:
 
   memory: omap-gpmc: Don't try to save uninitialized GPMC context (2015-08-12 
 01:43:49 -0700)

Thanks, merged.


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


Re: [PATCH] gpio: omap: Fix missing raw locks conversion

2015-08-13 Thread Linus Walleij
On Wed, Aug 5, 2015 at 4:37 PM, Axel Lin axel@ingics.com wrote:

 Fix below build warning:
   CC  drivers/gpio/gpio-omap.o
 drivers/gpio/gpio-omap.c: In function 'omap_gpio_irq_type':
 drivers/gpio/gpio-omap.c:504:3: warning: passing argument 1 of 
 'spin_unlock_irqrestore' from incompatible pointer type [enabled by default]
 include/linux/spinlock.h:360:29: note: expected 'struct spinlock_t *' but 
 argument is of type 'struct raw_spinlock_t *'

 Fixes: commit 4dbada2be460 (gpio: omap: use raw locks for locking)
 Signed-off-by: Axel Lin axel@ingics.com

Fixed by merging in -rc4 and applying this patch for next.

Thanks!

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: [4.2-rc1][PATCH] gpio: omap: add missed spin_unlock_irqrestore in omap_gpio_irq_type

2015-08-13 Thread Linus Walleij
On Fri, Aug 7, 2015 at 9:34 AM, Grygorii Strashko
grygorii.stras...@ti.com wrote:
 Hi Tony,
 On 08/07/2015 06:36 AM, Tony Lindgren wrote:

 * Linus Walleij linus.wall...@linaro.org [150716 01:38]:

 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.


 Linus, looks like we now have a new build warning in Linux next
 with the fixes and raw_spinlock_t change, so a merge or a commit
 is needed. If you prefer a patch, here's one below.


 Yes. It seems merge/rebase issue between fixes  next:
 - this patch went through fixes and RAW spinlock conversation
 patch through -next, and without merge conflicts.

 and patch has been posted already by Axel Lin:
 http://www.spinics.net/lists/linux-omap/msg121031.html

I merged v4.2-rc4 into my devel branch and applied Axel's
patch to fix this mess. Check that it looks OK now...

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 v2 00/22] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

2015-08-13 Thread Roger Quadros
On 13/08/15 11:36, Tony Lindgren wrote:
 * Roger Quadros rog...@ti.com [150813 00:17]:
 On 11/08/15 15:48, Tony Lindgren wrote:

 OK. Yeah let's make sure no regressions are caused by this.. We also
 still have the omap3 legacy booting around, have you checked that it
 keeps on working?

 I don't have any omap3 board with legacy support with me. I have omap3-beagle
 but looks like legacy boot is dropped for it already.

 I'll try to revert the patch that drops beagle support and test it on that 
 one.
 
 OK yeah that should work just fine.
 

Just verified that with the change in patch 6 it works on omap3-beagle legacy 
boot.
I have fixed some checkpatch issues in this series as well. Will post a v3
after you have gone one pass over this series.

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 v2 16/22] memory: omap-gpmc: Support general purpose input for WAITPINs

2015-08-13 Thread Roger Quadros


On 07/08/15 12:12, Roger Quadros wrote:
 OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
 input if not used for memory wait state insertion.
 
 The first user will be the OMAP NAND chip to get the NAND
 read/busy status using gpiolib.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/memory/omap-gpmc.c | 122 
 +++--
  1 file changed, 117 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
 index 30d9c21..264009d 100644
 --- a/drivers/memory/omap-gpmc.c
 +++ b/drivers/memory/omap-gpmc.c
 @@ -21,6 +21,7 @@
  #include linux/spinlock.h
  #include linux/io.h
  #include linux/module.h
 +#include linux/gpio/driver.h
  #include linux/interrupt.h
  #include linux/platform_device.h
  #include linux/of.h
 @@ -223,6 +224,11 @@ struct omap3_gpmc_regs {
   struct gpmc_cs_config cs_context[GPMC_CS_NUM];
  };
  
 +struct gpmc_device {
 + struct device *dev;
 + struct gpio_chip gpio_chip;
 +};
 +
  static struct resource   gpmc_mem_root;
  static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
  static DEFINE_SPINLOCK(gpmc_mem_lock);
 @@ -1919,10 +1925,69 @@ err:
   return ret;
  }
  
 +static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
 +{
 + return 1;   /* we're input only */
 +}
 +
 +static int gpmc_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
 +{
 + return 0;   /* we're input only */
 +}
 +
 +static int gpmc_gpio_direction_output(struct gpio_chip *chip, unsigned 
 offset,
 +   int value)
 +{
 + return -EINVAL; /* we're input only */
 +}
 +
 +static void gpmc_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
 +{
 +}
 +
 +static int gpmc_gpio_get(struct gpio_chip *chip, unsigned offset)
 +{
 + u32 reg;
 +
 + offset += 8;
 +
 + reg = gpmc_read_reg(GPMC_STATUS)  BIT(offset);
 +
 + return !!reg;
 +}
 +
 +static int gpmc_gpio_init(struct gpmc_device *gpmc)
 +{
 + int ret;
 +
 + gpmc-gpio_chip.dev = gpmc-dev;
 + gpmc-gpio_chip.owner = THIS_MODULE;
 + gpmc-gpio_chip.label = DEVICE_NAME;
 + gpmc-gpio_chip.ngpio = gpmc_nr_waitpins;
 + gpmc-gpio_chip.get_direction = gpmc_gpio_get_direction;
 + gpmc-gpio_chip.direction_input = gpmc_gpio_direction_input;
 + gpmc-gpio_chip.direction_output = gpmc_gpio_direction_output;
 + gpmc-gpio_chip.set = gpmc_gpio_set;
 + gpmc-gpio_chip.get = gpmc_gpio_get;
 + gpmc-gpio_chip.base = -1;
 +
 + ret = gpiochip_add(gpmc-gpio_chip);
 + if (ret  0) {
 + dev_err(gpmc-dev, could not register gpio chip: %d\n, ret);
 + return ret;
 + }
 +
 + return 0;
 +}
 +
 +static void gpmc_gpio_exit(struct gpmc_device *gpmc)
 +{
 + gpiochip_remove(gpmc-gpio_chip);
 +}
 +
  static int gpmc_probe_dt(struct platform_device *pdev)
  {
   int ret;
 - struct device_node *child;
   const struct of_device_id *of_id =
   of_match_device(gpmc_dt_ids, pdev-dev);
  
 @@ -1950,6 +2015,17 @@ static int gpmc_probe_dt(struct platform_device *pdev)
   return ret;
   }
  
 + dev_info(pdev-dev, num-cs %d, num-wait %d\n,
 +  gpmc_cs_num, gpmc_nr_waitpins);
 +
 + return 0;
 +}
 +
 +static int gpmc_probe_dt_children(struct platform_device *pdev)
 +{
 + int ret;
 + struct device_node *child;
 +
   for_each_available_child_of_node(pdev-dev.of_node, child) {
  
   if (!child-name)
 @@ -1959,6 +2035,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
   ret = gpmc_probe_onenand_child(pdev, child);
   else
   ret = gpmc_probe_generic_child(pdev, child);
 +
 + if (ret)
 + return ret;
   }
  
   return 0;
 @@ -1968,6 +2047,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
  {
   return 0;
  }
 +
 +static int gpmc_probe_dt_children(struct platform_device *pdev)
 +{
 + return 0;
 +}
  #endif
  
  static int gpmc_probe(struct platform_device *pdev)
 @@ -1975,6 +2059,7 @@ static int gpmc_probe(struct platform_device *pdev)
   int rc;
   u32 l;
   struct resource *res;
 + struct gpmc_device *gpmc;
  
   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   if (res == NULL)
 @@ -2005,6 +2090,17 @@ static int gpmc_probe(struct platform_device *pdev)
   return -EINVAL;
   }
  
 + rc = gpmc_probe_dt(pdev);
 + if (rc)
 + return rc;
 +
 + gpmc = devm_kzalloc(pdev-dev, sizeof(*gpmc), GFP_KERNEL);
 + if (!gpmc)
 + return -ENOMEM;
 +
 + gpmc-dev = pdev-dev;
 + platform_set_drvdata(pdev, gpmc);
 +
   pm_runtime_enable(pdev-dev);
   pm_runtime_get_sync(pdev-dev);
  
 @@ -2032,24 +2128,40 @@ static int gpmc_probe(struct platform_device *pdev)
GPMC_REVISION_MINOR(l));
  
   gpmc_mem_init();
 + rc = 

PowerVR SGX540 drivers for PandaBoard(OMAP4460) on vanilla kernel

2015-08-13 Thread Sedat Marangoz
Hi all,

Is there a way to install PVR SGX540 driver to my PandaBoard
ES(OMAP4460) which runs on vanilla kernel and small filesystem.
The latest Graphics SDK does not have support for OMAP4.
I searched and found pvr_omap is available for Ubuntu 12.04 via
installing omap4-extras package.
Also, there is similar issue here:
https://e2e.ti.com/support/omap/f/849/t/287992 which advices to use
GLSDK.

But in our project we are not using Ubuntu, instead there is small
ROOTFS and the kernel version is 3.10.80 (because of some specific
project reasons).
I found some packages here:
https://launchpad.net/~tiomap-dev/+archive/ubuntu/release/+packages .
And tried to build source package of
pvr-omap4-dkms_1.9.0.7.1.1-1_armhf.deb according to below
instructions, but I got lots of errors.

export ARCH=arm
export CROSS_COMPILE=cros compiler prefix
export DISCIMAGE=path to filesystem
export KERNELDIR=path to kernel (I tried both 3.8 and 3.10.80 kernel
versions source code)
cd eurasiacon/build/linux2/omap4430_linux/
make

I do not think pvr_omap4 source code has proper header and source
files for my kernel, am I wrong?

Is there a way to install SGX540 driver to my Pandaboard ES (OMAP4460)
which has custom kernel such as version 3.10.80?

Regards
Sedat
--
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 2/6] genirq: fix irqchip_set_wake_parent if IRQCHIP_SKIP_SET_WAKE

2015-08-13 Thread Grygorii Strashko
On 08/13/2015 01:31 PM, Grygorii Strashko wrote:
 On 08/13/2015 01:01 PM, Marc Zyngier wrote:
 On 12/08/15 18:45, Grygorii Strashko wrote:
 The irqchip_set_wake_parent should not fail if IRQ chip
 specifies IRQCHIP_SKIP_SET_WAKE. Otherwise, IRQ wakeup
 configuration can't be propagated properly through IRQ
 domains hierarchy.

 In case of TI OMAP DRA7 the issue reproduced with following
 configuration:
 ARM GIC-OMAP wakeupgen-TI CBAR-GPIO-GPIO pcf857x-gpio_key

 gpio_key is wakeup source

 Failure is reproduced during suspend/resume to RAM:
 suspend:
   - gpio_keys_suspend
 enable_irq_wake
   + pcf857x_irq_set_wake
 + omap_gpio_wake_enable
   + TI CBAR irq_chip_set_wake_parent
 + OMAP wakeupgen has no .irq_set_wake()

 Most importantly, wakeupgen has IRQCHIP_SKIP_SET_WAKE set.

 and -ENOSYS will be returned

 resume:
   - gpio_keys_resume
 + disable_irq_wake
   + irq_set_irq_wake
 + WARN(1, Unbalanced IRQ %d wake disable\n, irq);

 Fixes: 08b55e2a9208 ('genirq: Add irqchip_set_wake_parent')
 Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
 ---
   kernel/irq/chip.c | 4 
   1 file changed, 4 insertions(+)

 diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
 index 6de638b..bdb1b9d 100644
 --- a/kernel/irq/chip.c
 +++ b/kernel/irq/chip.c
 @@ -1024,6 +1024,10 @@ int irq_chip_set_vcpu_affinity_parent(struct 
 irq_data *data, void *vcpu_info)
   int irq_chip_set_wake_parent(struct irq_data *data, unsigned int on)
   {
   data = data-parent_data;
 +
 +if (irq_data_get_irq_chip(data)-flags  IRQCHIP_SKIP_SET_WAKE)
 +return 0;
 +
   if (data-chip-irq_set_wake)
   return data-chip-irq_set_wake(data, on);



 We have a more general issue with chip flags, and how they combine
 within a stack of irqchips.
 
 Indeed. Problem looks similar to IRQCHIP_MASK_ON_SUSPEND flag usage.
 

 What if you remove the irq_chip_set_wake_parent from the crossbar
 driver, and instead set IRQCHIP_SKIP_SET_WAKE?
 
 I've thought about this and it should work for me.
 One question - what if crossbar will be not the last one in
 IRQ domains hierarchy?
 

I can confirm, if I revert this patch, add IRQCHIP_SKIP_SET_WAKE to
the crossbar and remove irq_chip_set_wake_parent wakeups still works.
What do you prefer me to do: add additional patch for the crossbar,
drop/keep this patch?

-- 
regards,
-grygorii
--
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: DRA752: Add ID detect for ES2.0

2015-08-13 Thread Nishanth Menon
From: Vishal Mahaveer vish...@ti.com

ES2.0 is a minor variant of ES1.1. ES2.0 is an incremental revision
with various fixes including the following:
- reset logic fixes
- few assymetric aging logic fixes
- MMC clock rate fixes
- Ethernet speed fixes
- edma fixes for mcasp

NOTE: even though we use a compatible of dra742 and dra752, the usage in
the Linux kernel is more or less interchangable - we use dra752 more
often in the linux kernel compared to dra742 and 4.2-rc6

Signed-off-by: Vishal Mahaveer vish...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
based on linux-next next-20150812, applies to v4.2-rc6 as well.
Definetly not a 4.2 material, for 4.3, this probably missed the first merge
window for 4.3, will be great if it could be considered for the second merge
window.

 arch/arm/mach-omap2/id.c  | 8 ++--
 arch/arm/mach-omap2/soc.h | 2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713ffb06b..54a5ba54d2ff 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -653,8 +653,12 @@ void __init dra7xxx_check_revision(void)
omap_revision = DRA752_REV_ES1_0;
break;
case 1:
-   default:
omap_revision = DRA752_REV_ES1_1;
+   break;
+   case 2:
+   default:
+   omap_revision = DRA752_REV_ES2_0;
+   break;
}
break;
 
@@ -674,7 +678,7 @@ void __init dra7xxx_check_revision(void)
/* Unknown default to latest silicon rev as default*/
pr_warn(%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%x)\n,
__func__, idcode, hawkeye, rev);
-   omap_revision = DRA752_REV_ES1_1;
+   omap_revision = DRA752_REV_ES2_0;
}
 
sprintf(soc_name, DRA%03x, omap_rev()  16);
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d11ea5..2d1d3845253c 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -469,6 +469,8 @@ IS_OMAP_TYPE(3430, 0x3430)
 #define DRA7XX_CLASS   0x0700
 #define DRA752_REV_ES1_0   (DRA7XX_CLASS | (0x52  16) | (0x10  8))
 #define DRA752_REV_ES1_1   (DRA7XX_CLASS | (0x52  16) | (0x11  8))
+#define DRA752_REV_ES2_0   (DRA7XX_CLASS | (0x52  16) | (0x20  8))
+#define DRA722_REV_ES1_0   (DRA7XX_CLASS | (0x22  16) | (0x10  8))
 #define DRA722_REV_ES1_0   (DRA7XX_CLASS | (0x22  16) | (0x10  8))
 
 void omap2xxx_check_revision(void);
-- 
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 v3] i2c: omap: improve duty cycle on SCL

2015-08-13 Thread Felipe Balbi
On Fri, Jul 10, 2015 at 12:27:15PM -0500, Felipe Balbi wrote:
 On Thu, Jul 09, 2015 at 09:42:41PM +0200, Wolfram Sang wrote:
  On Thu, Jun 18, 2015 at 12:25:58PM -0500, Felipe Balbi wrote:
   On Thu, Jun 18, 2015 at 10:09:59AM +0200, Alexander Sverdlin wrote:
Hello Felipe,

On 17/06/15 21:31, ext Felipe Balbi wrote:
 With this patch we try to be as close to 50%
 duty cycle as possible. The reason for this
 is that some devices present an erratic behavior
 with certain duty cycles.
 
 One such example is TPS65218 PMIC which fails
 to change voltages when running @ 400kHz and
 duty cycle is lower than 34%.
 
 The idea of the patch is simple:
 
 calculate desired scl_period from requested scl
 and use 50% for tLow and 50% for tHigh.
 
 tLow is calculated with a DIV_ROUND_UP() to make
 sure it's slightly higher than tHigh and to make
 sure that we end up within I2C specifications.

if you refuse to change the calculations to achieve maximum possible
bus rate (as I've shown you with SCLL=9 and SCLH=9), maybe you want to
change the description? Because you are doing something else than is
written here. You are only in spec because you are not doing 50% duty
cycle. And you didn't mention here that you lower the bus speed below
400kHz to achieve this.
   
   and there's a comment where the calculation goes which states as close
   to 50% as possible but we make sure tLow is higher than tHigh so we're
   still within spec.
  
  So, is that ready to go in for-next?
 
 should be.

ping ?

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 0/3] ARM: multi_v7_defconfig: Enable more OMAP family platforms

2015-08-13 Thread Nishanth Menon
On Tue, Aug 11, 2015 at 5:37 AM, Tony Lindgren t...@atomide.com wrote:

 * Kevin Hilman khil...@kernel.org [150807 16:10]:
  Tony Lindgren t...@atomide.com writes:
 
   Ping, looks like these are still pending. Probably should be
   applied directly by the arm-soc maintainers.
 
  If these should go through arm-soc, please resend to:a...@kernel.org so
  they make it into our queue of stuff to be reviewed/applied.

 OK thanks, up to Nihshant to resend.


Sorry about the slow response - i will have to do this at a later
point(probably based off 4.3-rc1). tied up with a few other internal
stuff atm :(

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


[PATCH] gpiolib: irqchip: use different lockdep class for each gpio irqchip

2015-08-13 Thread Grygorii Strashko
Since IRQ chip helpers were introduced drivers lose ability to
register separate lockdep classes for each registered GPIO IRQ
chip and the gpiolib now is using shared lockdep class for
all GPIO IRQ chips (gpiochip_irq_lock_class).
As result, lockdep will produce warning when there are min two
stacked GPIO chips and all of them are interrupt controllers.

HW configuration which generates lockdep warning (TI dra7-evm):

[SOC GPIO bankA.gpioX]
  - irq - [pcf875x.gpioY]
- irq - DevZ.enable_irq_wake(pcf_gpioY_irq);
The issue was reported in [1] and discussed [2].

=
[ INFO: possible recursive locking detected ]
4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted
-
sh/63 is trying to acquire lock:
 (class){..}, at: [c009b91c] __irq_get_desc_lock+0x50/0x94

but task is already holding lock:
 (class){..}, at: [c009b91c] __irq_get_desc_lock+0x50/0x94

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

   CPU0
   
  lock(class);
  lock(class);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

7 locks held by sh/63:
 #0:  (sb_writers#4){.+.+.+}, at: [c016bbb8] vfs_write+0x13c/0x164
 #1:  (of-mutex){+.+.+.}, at: [c01debf4] kernfs_fop_write+0x4c/0x1a0
 #2:  (s_active#36){.+.+.+}, at: [c01debfc] kernfs_fop_write+0x54/0x1a0
 #3:  (pm_mutex){+.+.+.}, at: [c009758c] pm_suspend+0xec/0x4c4
 #4:  (dev-mutex){..}, at: [c03f77f8] __device_suspend+0xd4/0x398
 #5:  (gpio-lock){+.+.+.}, at: [c009b940] __irq_get_desc_lock+0x74/0x94
 #6:  (class){..}, at: [c009b91c] __irq_get_desc_lock+0x50/0x94

stack backtrace:
CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55
Hardware name: Generic DRA74X (Flattened Device Tree)
[c0016e24] (unwind_backtrace) from [c0013338] (show_stack+0x10/0x14)
[c0013338] (show_stack) from [c05f6b24] (dump_stack+0x84/0x9c)
[c05f6b24] (dump_stack) from [c00903f4] (__lock_acquire+0x19c0/0x1e20)
[c00903f4] (__lock_acquire) from [c0091098] (lock_acquire+0xa8/0x128)
[c0091098] (lock_acquire) from [c05fd61c] (_raw_spin_lock_irqsave+0x38/0x4c)
[c05fd61c] (_raw_spin_lock_irqsave) from [c009b91c] 
(__irq_get_desc_lock+0x50/0x94)
[c009b91c] (__irq_get_desc_lock) from [c009c4f4] 
(irq_set_irq_wake+0x20/0xfc)
[c009c4f4] (irq_set_irq_wake) from [c0393ac4] 
(pcf857x_irq_set_wake+0x24/0x54)
[c0393ac4] (pcf857x_irq_set_wake) from [c009c560] 
(irq_set_irq_wake+0x8c/0xfc)
[c009c560] (irq_set_irq_wake) from [c04a02ac] (gpio_keys_suspend+0x70/0xd4)
[c04a02ac] (gpio_keys_suspend) from [c03f6a00] (dpm_run_callback+0x50/0x124)
[c03f6a00] (dpm_run_callback) from [c03f7830] (__device_suspend+0x10c/0x398)
[c03f7830] (__device_suspend) from [c03f90f0] (dpm_suspend+0x134/0x2f4)
[c03f90f0] (dpm_suspend) from [c0096e20] 
(suspend_devices_and_enter+0xa8/0x728)
[c0096e20] (suspend_devices_and_enter) from [c00977cc] 
(pm_suspend+0x32c/0x4c4)
[c00977cc] (pm_suspend) from [c0096060] (state_store+0x64/0xb8)
[c0096060] (state_store) from [c01dec64] (kernfs_fop_write+0xbc/0x1a0)
[c01dec64] (kernfs_fop_write) from [c016b280] (__vfs_write+0x20/0xd8)
[c016b280] (__vfs_write) from [c016bb0c] (vfs_write+0x90/0x164)
[c016bb0c] (vfs_write) from [c016c330] (SyS_write+0x44/0x9c)
[c016c330] (SyS_write) from [c000f500] (ret_fast_syscall+0x0/0x54)

Lets fix it by using separate lockdep class for each registered GPIO
IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros.

The implementation of this patch inspired by solution done by Nicolas
Boichat for regmap [3]

[1] http://www.spinics.net/lists/linux-gpio/msg05844.html
[2] http://www.spinics.net/lists/linux-gpio/msg06021.html
[3] http://www.spinics.net/lists/arm-kernel/msg429834.html

Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: Roger Quadros rog...@ti.com
Reported-by: Roger Quadros rog...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
 drivers/gpio/gpiolib.c  | 27 ++-
 include/linux/gpio/driver.h | 27 ++-
 2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bf4bd1d..75dddc1 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -456,12 +456,6 @@ void gpiochip_set_chained_irqchip(struct gpio_chip 
*gpiochip,
 }
 EXPORT_SYMBOL_GPL(gpiochip_set_chained_irqchip);
 
-/*
- * This lock class tells lockdep that GPIO irqs are in a different
- * category than their parents, so it won't report false recursion.
- */
-static struct lock_class_key gpiochip_irq_lock_class;
-
 /**
  * gpiochip_irq_map() - maps an IRQ into a GPIO irqchip
  * @d: the irqdomain used by this irqchip
@@ -478,7 +472,11 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned 
int irq,
struct gpio_chip *chip = d-host_data;
 
irq_set_chip_data(irq, chip);
-   irq_set_lockdep_class(irq, gpiochip_irq_lock_class);
+   /*
+* This lock class tells lockdep that 

Re: [PATCH-next 2/4] arm: boot: dts: am4372: add ARM timers and SCU nodes

2015-08-13 Thread Felipe Balbi
On Thu, Aug 13, 2015 at 01:32:15AM -0700, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [150812 13:00]:
  AM437x devices sport SCU, TWD and Global timers,
  let's add them to DTS so they have a chance to
  probe and be used by Linux.
 
 Applying this one into omap-for-v4.3/dt-v2. Not sure
 if it will get merged as we're getting close to the
 merge window. The rest we can patch once Russell has
 reverted the bogus SMP dependency.

I'm just waiting for Russell's it's okay to post on patch system.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH 2/2] clk: Convert __clk_get_name(hw-clk) to clk_hw_get_name(hw)

2015-08-13 Thread Andrew Bresticker
On Wed, Aug 12, 2015 at 4:12 PM, Stephen Boyd sb...@codeaurora.org wrote:
 Use the provider based method to get a clock's name so that we
 can get rid of the clk member in struct clk_hw one day. Mostly
 converted with the following coccinelle script.

 @@
 struct clk_hw *E;
 @@

 -__clk_get_name(E-clk)
 +clk_hw_get_name(E)

 Cc: Heiko Stuebner he...@sntech.de
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Peter De Schrijver pdeschrij...@nvidia.com
 Cc: Prashant Gaikwad pgaik...@nvidia.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Thierry Reding thierry.red...@gmail.com
 Cc: Alexandre Courbot gnu...@gmail.com
 Cc: Tero Kristo t-kri...@ti.com
 Cc: Ulf Hansson ulf.hans...@linaro.org
 Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
 Cc: Andrew Bresticker abres...@chromium.org
 Cc: Ezequiel Garcia ezequiel.gar...@imgtec.com
 Cc: Ralf Baechle r...@linux-mips.org
 Cc: Kevin Cernekee cerne...@chromium.org
 Cc: Geert Uytterhoeven geert+rene...@glider.be
 Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-rockc...@lists.infradead.org
 Cc: linux-samsung-...@vger.kernel.org
 Cc: linux-te...@vger.kernel.org
 Cc: linux-omap@vger.kernel.org
 Signed-off-by: Stephen Boyd sb...@codeaurora.org

  drivers/clk/pistachio/clk-pll.c  |  4 ++--

For Pistachio,

Acked-by: Andrew Bresticker abres...@chromium.org
--
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: [net-next PATCH 0/3] Add AM335x PG1.0 CPSW errata workaround

2015-08-13 Thread David Miller
From: Mugunthan V N mugunthan...@ti.com
Date: Wed, 12 Aug 2015 15:22:52 +0530

 With commit 870915feabdc (drivers: net: cpsw: remove
 disable_irq/enable_irq as irq can be masked from cpsw itself),
 CPSW on AM335x beagle bone white is broken as there is a errata
 for AM335x PG1.0. This patch series implements the workaround by
 disabling the interrupts from ARM IRQ controller for AM335x SoC
 in addition to the masking of interrupts in CPSW.

Series applied, thanks.
--
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] Remove board support for VoiceBlue board.

2015-08-13 Thread Ladislav Michl
Remove board support files for 10 years discontinued VoiceBlue board.

Signed-off-by: Ladislav Michl la...@linux-mips.org

---
 arch/arm/mach-omap1/Kconfig|   7 -
 arch/arm/mach-omap1/Makefile   |   1 -
 arch/arm/mach-omap1/board-voiceblue.c  | 296 -
 arch/arm/mach-omap1/include/mach/board-voiceblue.h |  19 --
 4 files changed, 323 deletions(-)
 delete mode 100644 arch/arm/mach-omap1/board-voiceblue.c
 delete mode 100644 arch/arm/mach-omap1/include/mach/board-voiceblue.h

diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index cdd05f2..afb80950 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -90,13 +90,6 @@ config MACH_OMAP_FSAMPLE
  Support for TI OMAP 850 F-Sample board. Say Y here if you have such
  a board.
 
-config MACH_VOICEBLUE
-   bool Voiceblue
-   depends on ARCH_OMAP1  ARCH_OMAP15XX
-   help
- Support for Voiceblue GSM/VoIP gateway. Say Y here if you have
- such a board.
-
 config MACH_OMAP_PALMTE
bool Palm Tungsten E
depends on ARCH_OMAP1  ARCH_OMAP15XX
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 3889b6c..0e8ea95 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -37,7 +37,6 @@ obj-$(CONFIG_MACH_OMAP_FSAMPLE)   += 
board-fsample.o board-nand.o
 obj-$(CONFIG_MACH_OMAP_OSK)+= board-osk.o
 obj-$(CONFIG_MACH_OMAP_H3) += board-h3.o board-h3-mmc.o \
   board-nand.o
-obj-$(CONFIG_MACH_VOICEBLUE)   += board-voiceblue.o
 obj-$(CONFIG_MACH_OMAP_PALMTE) += board-palmte.o
 obj-$(CONFIG_MACH_OMAP_PALMZ71)+= board-palmz71.o
 obj-$(CONFIG_MACH_OMAP_PALMTT) += board-palmtt.o
diff --git a/arch/arm/mach-omap1/board-voiceblue.c 
b/arch/arm/mach-omap1/board-voiceblue.c
deleted file mode 100644
index e960687..000
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ /dev/null
@@ -1,296 +0,0 @@
-/*
- * linux/arch/arm/mach-omap1/board-voiceblue.c
- *
- * Modified from board-generic.c
- *
- * Copyright (C) 2004 2N Telekomunikace, Ladislav Michl mi...@2n.cz
- *
- * Code for OMAP5910 based VoiceBlue board (VoIP to GSM gateway).
- *
- * 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/delay.h
-#include linux/gpio.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/irq.h
-#include linux/init.h
-#include linux/kernel.h
-#include linux/mtd/physmap.h
-#include linux/notifier.h
-#include linux/reboot.h
-#include linux/serial_8250.h
-#include linux/serial_reg.h
-#include linux/smc91x.h
-#include linux/export.h
-#include linux/reboot.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-#include asm/mach/map.h
-
-#include mach/board-voiceblue.h
-#include mach/flash.h
-#include mach/mux.h
-#include mach/tc.h
-
-#include mach/hardware.h
-#include mach/usb.h
-
-#include common.h
-
-static struct plat_serial8250_port voiceblue_ports[] = {
-   {
-   .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x4),
-   .flags  = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
-   .iotype = UPIO_MEM,
-   .regshift   = 1,
-   .uartclk= 3686400,
-   },
-   {
-   .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x5),
-   .flags  = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
-   .iotype = UPIO_MEM,
-   .regshift   = 1,
-   .uartclk= 3686400,
-   },
-   {
-   .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x6),
-   .flags  = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
-   .iotype = UPIO_MEM,
-   .regshift   = 1,
-   .uartclk= 3686400,
-   },
-   {
-   .mapbase= (unsigned long)(OMAP_CS1_PHYS + 0x7),
-   .flags  = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
-   .iotype = UPIO_MEM,
-   .regshift   = 1,
-   .uartclk= 3686400,
-   },
-   { },
-};
-
-static struct platform_device serial_device = {
-   .name   = serial8250,
-   .id = PLAT8250_DEV_PLATFORM1,
-};
-
-static int __init ext_uart_init(void)
-{
-   if (!machine_is_voiceblue())
-   return -ENODEV;
-
-   voiceblue_ports[0].irq = gpio_to_irq(12);
-   voiceblue_ports[1].irq = gpio_to_irq(13);
-   voiceblue_ports[2].irq = gpio_to_irq(14);
-   voiceblue_ports[3].irq = gpio_to_irq(15);
-   serial_device.dev.platform_data = voiceblue_ports;
-   return platform_device_register(serial_device);
-}

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

2015-08-13 Thread Paul Walmsley
Hi guys

On Wed, 12 Aug 2015, Alexandre Belloni wrote:

 On 13/08/2015 at 00:38:50 +0530, Keerthy wrote :
  The intent here is to switch to a higher precision clock which is the
  internal clock when available.
  
  Alexandre,
  
  Is dynamic switching preferred over sticking  to external clock always if
  present?
 
 I'd say that I don't really care. I'd say the best would be to make a
 decision based on clock-accuracy but maybe that is an information you
 don't have yet. Anyway, this could be added at a later date.

Either the clock mux logic is glitchless, in which case the RTC is likely 
to lose at least 31 microseconds per switch; or it's not glitchless, in 
which case it's unsafe to switch the RTC clock source while the clock 
isn't gated.  Keerthy, before submitting this patch for merging, I'd 
suggest consulting your hardware folks to figure out which case it is.


- 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 v2 2/6] rtc: omap: Add external clock enabling support

2015-08-13 Thread Keerthy



On Friday 14 August 2015 01:47 AM, Paul Walmsley wrote:

Hi guys

On Wed, 12 Aug 2015, Alexandre Belloni wrote:


On 13/08/2015 at 00:38:50 +0530, Keerthy wrote :

The intent here is to switch to a higher precision clock which is the
internal clock when available.

Alexandre,

Is dynamic switching preferred over sticking  to external clock always if
present?


I'd say that I don't really care. I'd say the best would be to make a
decision based on clock-accuracy but maybe that is an information you
don't have yet. Anyway, this could be added at a later date.


Either the clock mux logic is glitchless, in which case the RTC is likely
to lose at least 31 microseconds per switch; or it's not glitchless, in
which case it's unsafe to switch the RTC clock source while the clock
isn't gated.  Keerthy, before submitting this patch for merging, I'd
suggest consulting your hardware folks to figure out which case it is.


Paul,

Thanks. Yes so i am doing the static way first. Keeping external clock 
always if available. Switching dynamically can be done later with more 
clarifications.


Thanks,
Keerthy




- 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] usb: phy: phy-generic: Fix reset behaviour on legacy boot

2015-08-13 Thread Fabio Estevam
On Thu, Aug 13, 2015 at 7:28 AM, Roger Quadros rog...@ti.com wrote:
 The gpio-desc migration done in v4.0 caused a regression
 with legacy boots due to reversed reset logic.
 e.g. omap3-beagle USB host breaks on legacy boot.

 Request the reset GPIO with GPIOF_ACTIVE_LOW flag so that
 it matches the driver logic and pin behaviour.

 Fixes: e9f2cefb0cdc (usb: phy: generic: migrate to gpio_desc)
 Cc: sta...@vger.kernel.org # 4.0+
 Signed-off-by: Roger Quadros rog...@ti.com

The USB on my mx51-babbage board still works fine with this change:

Tested-by: Fabio Estevam fabio.este...@freescale.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-next 1/4] Revert ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp

2015-08-13 Thread Russell King - ARM Linux
On Wed, Aug 12, 2015 at 02:56:53PM -0500, Felipe Balbi wrote:
 This reverts commit 904464b91eca8c665acea033489225af02eeb75a.
 
 The problem pointed out by commit 904464b91eca (ARM: 7655/1:
 smp_twd: make twd_local_timer_of_register() no-op for nosmp)
 doesn't exist anymore.
 
 We can safely boot with nosmp and the warning won't show up.
 
 The other side benefit of this patch is that TWD has a chance
 to probe on single-core A9 systems such as AM437x which sport
 TWD.

I don't remember all the details from Feb 2013 on why we made that
change.  If this is proven safe, then I guess it's okay.

-- 
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-next 1/4] Revert ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp

2015-08-13 Thread Felipe Balbi
On Thu, Aug 13, 2015 at 04:37:07PM +0100, Russell King - ARM Linux wrote:
 On Wed, Aug 12, 2015 at 02:56:53PM -0500, Felipe Balbi wrote:
  This reverts commit 904464b91eca8c665acea033489225af02eeb75a.
  
  The problem pointed out by commit 904464b91eca (ARM: 7655/1:
  smp_twd: make twd_local_timer_of_register() no-op for nosmp)
  doesn't exist anymore.
  
  We can safely boot with nosmp and the warning won't show up.
  
  The other side benefit of this patch is that TWD has a chance
  to probe on single-core A9 systems such as AM437x which sport
  TWD.
 
 I don't remember all the details from Feb 2013 on why we made that
 change.  If this is proven safe, then I guess it's okay.

Do you want me to upload to your patch system and, perhaps, keep in
linux-next for v4.4 merge window ? (too late for v4.3 I guess).

-- 
balbi


signature.asc
Description: Digital signature