Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Peter Ujfalusi]

On 12/04/2015 02:54 AM, Tony Lindgren wrote:
> Hi Peter,
> 
> * Peter Ujfalusi  [151016 00:23]:
> 
> I noticed something while changing dm81xx to use the edma_xbar..
> 
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> +
>> +edma_xbar: dma-router@44e10f90 {
>> +compatible = "ti,am335x-edma-crossbar";
>> +reg = <0x44e10f90 0x40>;
>> +
>> +#dma-cells = <3>;
>> +dma-requests = <32>;
>> +
>> +dma-masters = <>;
>>  };
> 
> The edma_xbar should now be just a child at offset 0xf90 under the
> scm: scm@21. Can you please check the other patches too?

Thanks Tony,

I'll make sure they are in the correct place when resending them.

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

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 04/12/15 11:18, Grygorii Strashko wrote:

On 12/04/2015 12:54 PM, Sudeep Holla wrote:

Hi Grygorii,

On 04/12/15 10:44, Grygorii Strashko wrote:

On 12/03/2015 11:37 PM, Tony Lindgren wrote:


[...]


And these both need to be applied together when we have a fix for the
above
as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.



Most probably below diff will fix above issue:

diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 3fc2cbe..69cde67 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
  ct->chip.irq_ack = irq_gc_ack_set_bit;
  ct->chip.irq_mask = irq_gc_mask_clr_bit;
  ct->chip.irq_unmask = irq_gc_mask_set_bit;
+   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;


Thanks for testing.


Sry, I've not tested it yet - it's just fast assumption :(



OK, no worries.


In that case without this hunk, we should get error
from pcs_irq_set_wake in the suspend path. No ? May be driver is not
checking the error value and entering suspend.



Yep. Noone is checking return result from enable_irq_wake() in suspend path
(see dev_pm_arm_wake_irq()).



True, but one possible reason for the warning Tony posted.


Actually, return result of  enable_irq_wake()  is checked only in ~30% of
cases in kernel now :)



That's bad, but I admit that even I failed to add check in some of the
patches I posted earlier.

--
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 2/7] ARM: dts: Update edma bindings on dm814x to use edma_xbar

[Peter Ujfalusi]

On 12/04/2015 03:25 AM, Tony Lindgren wrote:
> The edma is the same as on am33xx, except it has four tptc
> instances. And we need the edma_xbar for at least mmc3, so
> let's use the edma_xbar and the new binding as suggested by
> Peter Ujfalusi .
> 
> Cc: Peter Ujfalusi 
> Signed-off-by: Tony Lindgren 

Reviewed-by: Peter Ujfalusi 

> ---
>  arch/arm/boot/dts/dm814x.dtsi | 68 
> ---
>  1 file changed, 58 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
> index ca92346..9d81980e 100644
> --- a/arch/arm/boot/dts/dm814x.dtsi
> +++ b/arch/arm/boot/dts/dm814x.dtsi
> @@ -126,8 +126,8 @@
>   interrupts = <65>;
>   ti,spi-num-cs = <4>;
>   ti,hwmods = "mcspi1";
> - dmas = < 16  17
> -  18  19>;
> + dmas = < 16 0  17 0
> +  18 0  19 0>;
>   dma-names = "tx0", "rx0", "tx1", "rx1";
>   };
>  
> @@ -145,7 +145,7 @@
>   reg = <0x2 0x2000>;
>   clock-frequency = <4800>;
>   interrupts = <72>;
> - dmas = < 26  27>;
> + dmas = < 26 0  27 0>;
>   dma-names = "tx", "rx";
>   };
>  
> @@ -155,7 +155,7 @@
>   reg = <0x22000 0x2000>;
>   clock-frequency = <4800>;
>   interrupts = <73>;
> - dmas = < 28  29>;
> + dmas = < 28 0  29 0>;
>   dma-names = "tx", "rx";
>   };
>  
> @@ -165,7 +165,7 @@
>   reg = <0x24000 0x2000>;
>   clock-frequency = <4800>;
>   interrupts = <74>;
> - dmas = < 30  31>;
> + dmas = < 30 0  31 0>;
>   dma-names = "tx", "rx";
>   };
>  
> @@ -205,6 +205,14 @@
>   };
>   };
>  
> + edma_xbar: dma-router@f90 {
> + compatible = "ti,am335x-edma-crossbar";
> + reg = <0xf90 0x40>;
> + #dma-cells = <3>;
> + dma-requests = <32>;
> + dma-masters = <>;
> + };
> +
>   /*
>* Note that silicon revision 2.1 and older
>* require input enabled (bit 18 set) for all
> @@ -272,12 +280,52 @@
>   };
>  
>   edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg =   <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg =   <0x4900 0x1>;
> + reg-names = "edma3_cc";
>   interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> +   "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> +<_tptc2 3>, <_tptc3 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> + };
> +
> + edma_tptc0: tptc@4980 {
> + compatible = "ti,edma3-tptc";
> + ti,hwmods = "tptc0";
> + reg =   <0x4980 0x10>;
> + interrupts = <112>;
> + interrupt-names = "edma3_tcerrint";
> + };
> +
> + edma_tptc1: tptc@4990 {
> + compatible = "ti,edma3-tptc";
> + ti,hwmods = "tptc1";
> + reg =   <0x4990 0x10>;
> + interrupts = <113>;
> + interrupt-names = "edma3_tcerrint";
> + };
> +
> + edma_tptc2: tptc@49a0 {
> + compatible = "ti,edma3-tptc";
> + ti,hwmods = "tptc2";
> + reg =   <0x49a0 0x10>;
> +   

[PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Peter Ujfalusi]

Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/am335x-evm.dts|  9 +---
 arch/arm/boot/dts/am335x-pepper.dts | 11 +
 arch/arm/boot/dts/am33xx.dtsi   | 94 ++---
 3 files changed, 71 insertions(+), 43 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 4caf074063fe..a55072fb6646 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -743,8 +743,8 @@
  {
/* these are on the crossbar and are outlined in the
   xbar-event-map element */
-   dmas = < 12
-13>;
+   dmas = <_xbar 12 0 1
+   _xbar 13 0 2>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <_en_reg>;
@@ -766,11 +766,6 @@
};
 };
 
- {
-   ti,edma-xbar-event-map = /bits/ 16 <1 12
-   2 13>;
-};
-
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/am335x-pepper.dts 
b/arch/arm/boot/dts/am335x-pepper.dts
index 9cb77a120319..4dd4f71498e5 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -339,13 +339,6 @@
ti,non-removable;
 };
 
- {
-   /* Map eDMA MMC2 Events from Crossbar */
-   ti,edma-xbar-event-map = /bits/ 16 <1 12
-2 13>;
-};
-
-
  {
/* Wifi & Bluetooth on MMC #3 */
status = "okay";
@@ -354,8 +347,8 @@
vmmmc-supply = <_reg>;
bus-width = <4>;
ti,non-removable;
-   dmas = < 12
-13>;
+   dmas = <_xbar 12 0 1
+   _xbar 13 0 2>;
dma-names = "tx", "rx";
 };
 
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9b8861891bf0..9d414ed31e99 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -161,6 +161,14 @@
mboxes = < _wkupm3>;
};
 
+   edma_xbar: dma-router@f90 {
+   compatible = "ti,am335x-edma-crossbar";
+   reg = <0xf90 0x40>;
+   #dma-cells = <3>;
+   dma-requests = <32>;
+   dma-masters = <>;
+   };
+
scm_clockdomains: clockdomains {
};
};
@@ -174,12 +182,44 @@
};
 
edma: edma@4900 {
-   compatible = "ti,edma3";
-   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
-   reg =   <0x4900 0x1>,
-   <0x44e10f90 0x40>;
+   compatible = "ti,edma3-tpcc";
+   ti,hwmods = "tpcc";
+   reg =   <0x4900 0x1>;
+   reg-names = "edma3_cc";
interrupts = <12 13 14>;
-   #dma-cells = <1>;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+  <_tptc2 0>;
+
+   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
+   };
+
+   edma_tptc0: tptc@4980 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc0";
+   reg =   <0x4980 0x10>;
+   interrupts = <112>;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc1: tptc@4990 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc1";
+   reg =   <0x4990 0x10>;
+   interrupts = <113>;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc2: tptc@49a0 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc2";
+   reg =   <0x49a0 0x10>;
+   interrupts = <114>;
+   interrupt-names = "edma3_tcerrint";
};
 
gpio0: 

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/03/2015 11:37 PM, Tony Lindgren wrote:

* Grygorii Strashko  [151203 10:36]:


I think, this patch should not break our wake-up functionality.
It will just change the moment when pcs_irq_handler() will be called:

before this change:
- suspend_enter()
   
   - arch_suspend_enable_irqs();
 - ^ right here

after this change:
- suspend_enter()
   
   dpm_resume_noirq()
   - resume_device_irqs()
 ^ here

Correct? And as for me this is more safe.


I think there's more to it though. With both applied, it produces this on
coming back up from suspend:

PM: noirq resume of devices complete after 18.127 msecs
[ cut here ]
WARNING: CPU: 0 PID: 123 at kernel/irq/manage.c:605 irq_set_irq_wake+0xbc/0xfc()
Unbalanced IRQ 375 wake disable
Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
CPU: 0 PID: 123 Comm: bash Tainted: GW   4.4.0-rc3-dirty #2682
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
] (show_stack) from [] (dump_stack+0x84/0x9c)
[] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
[] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (irq_set_irq_wake+0xbc/0xfc)
[] (irq_set_irq_wake) from [] 
(device_wakeup_disarm_wake_irqs+0x70/0x12c)
[] (device_wakeup_disarm_wake_irqs) from [] 
(dpm_resume_noirq+0x20c/0x2e4)
[] (dpm_resume_noirq) from [] 
(suspend_devices_and_enter+0x1e4/0x6bc)
[] (suspend_devices_and_enter) from [] 
(pm_suspend+0x358/0x4b8)
[] (pm_suspend) from [] (state_store+0x64/0xb8)
[] (state_store) from [] (kobj_attr_store+0x14/0x20)
[] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50)
[] (sysfs_kf_write) from [] (kernfs_fop_write+0xbc/0x1cc)
[] (kernfs_fop_write) from [] (__vfs_write+0x24/0xd8)
[] (__vfs_write) from [] (vfs_write+0x94/0x154)
[] (vfs_write) from [] (SyS_write+0x40/0x94)
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
---[ end trace 321b51565e161bee ]---

And these both need to be applied together when we have a fix for the above
as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.



Most probably below diff will fix above issue:

diff --git a/arch/arm/mach-omap2/prm_common.c 
b/arch/arm/mach-omap2/prm_common.c

index 3fc2cbe..69cde67 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct 
omap_prcm_irq_setup *irq_setup)

ct->chip.irq_ack = irq_gc_ack_set_bit;
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
+   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;

ct->regs.ack = irq_setup->ack + i * 4;
ct->regs.mask = irq_setup->mask + i * 4;


--
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: DTS: am437x: Use the new DT bindings for the eDMA3

[Peter Ujfalusi]

Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
enable the DMA even crossbar with ti,am335x-edma-crossbar.
With the new bindings boards can customize and tweak the DMA channel
priority to match their needs. With the new binding the memcpy is safe
to be used since with the old binding it was not possible for a driver
to know which channel is allowed to be used as non HW triggered channel.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/am4372.dtsi   | 80 +++--
 arch/arm/boot/dts/am437x-gp-evm.dts |  9 +
 2 files changed, 62 insertions(+), 27 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index fda655c252f5..2714fa0f8bc8 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -172,6 +172,14 @@
mboxes = < _wkupm3>;
};
 
+   edma_xbar: dma-router@f90 {
+   compatible = "ti,am335x-edma-crossbar";
+   reg = <0xf90 0x40>;
+   #dma-cells = <3>;
+   dma-requests = <64>;
+   dma-masters = <>;
+   };
+
scm_clockdomains: clockdomains {
};
};
@@ -184,14 +192,46 @@
};
 
edma: edma@4900 {
-   compatible = "ti,edma3";
-   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
-   reg =   <0x4900 0x1>,
-   <0x44e10f90 0x10>;
+   compatible = "ti,edma3-tpcc";
+   ti,hwmods = "tpcc";
+   reg =   <0x4900 0x1>;
+   reg-names = "edma3_cc";
interrupts = ,
-   ,
-   ;
-   #dma-cells = <1>;
+,
+;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
+  <_tptc2 0>;
+
+   ti,edma-memcpy-channels = /bits/ 16 <32 33>;
+   };
+
+   edma_tptc0: tptc@4980 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc0";
+   reg =   <0x4980 0x10>;
+   interrupts = ;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc1: tptc@4990 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc1";
+   reg =   <0x4990 0x10>;
+   interrupts = ;
+   interrupt-names = "edma3_tcerrint";
+   };
+
+   edma_tptc2: tptc@49a0 {
+   compatible = "ti,edma3-tptc";
+   ti,hwmods = "tptc2";
+   reg =   <0x49a0 0x10>;
+   interrupts = ;
+   interrupt-names = "edma3_tcerrint";
};
 
uart0: serial@44e09000 {
@@ -496,8 +536,8 @@
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
-   dmas = < 24
-25>;
+   dmas = < 24 0>,
+   < 25 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -508,8 +548,8 @@
reg = <0x481d8000 0x1000>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
-   dmas = < 2
-3>;
+   dmas = < 2 0>,
+   < 3 0>;
dma-names = "tx", "rx";
interrupts = ;
status = "disabled";
@@ -777,7 +817,7 @@
compatible = "ti,omap5-sham";
ti,hwmods = "sham";
reg = <0x5310 0x300>;
-   dmas = < 36>;
+   dmas = < 36 0>;
dma-names = "rx";
interrupts = ;
};
@@ -787,8 +827,8 @@
ti,hwmods = "aes";
reg = 

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

Hi Grygorii,

On 04/12/15 10:44, Grygorii Strashko wrote:

On 12/03/2015 11:37 PM, Tony Lindgren wrote:


[...]


And these both need to be applied together when we have a fix for the
above
as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.



Most probably below diff will fix above issue:

diff --git a/arch/arm/mach-omap2/prm_common.c
b/arch/arm/mach-omap2/prm_common.c
index 3fc2cbe..69cde67 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
omap_prcm_irq_setup *irq_setup)
 ct->chip.irq_ack = irq_gc_ack_set_bit;
 ct->chip.irq_mask = irq_gc_mask_clr_bit;
 ct->chip.irq_unmask = irq_gc_mask_set_bit;
+   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;


Thanks for testing. In that case without this hunk, we should get error
from pcs_irq_set_wake in the suspend path. No ? May be driver is not
checking the error value and entering suspend.

--
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 7/7] ARM: dts: Enable emmc on hp t410

[Peter Ujfalusi]

On 12/04/2015 03:25 AM, Tony Lindgren wrote:
> There's a 2GB emmc on hp t410 that's wired to the sd_2 interface.
> Note that we also need to configure the evtmux using edma_xbar for
> edma channels.
> 
> Signed-off-by: Tony Lindgren 

One question inlined for the mmc3, other than that:
Reviewed-by: Peter Ujfalusi 

> ---
>  arch/arm/boot/dts/dm8148-t410.dts | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dm8148-t410.dts 
> b/arch/arm/boot/dts/dm8148-t410.dts
> index 79838dd..d1927a7 100644
> --- a/arch/arm/boot/dts/dm8148-t410.dts
> +++ b/arch/arm/boot/dts/dm8148-t410.dts
> @@ -15,6 +15,13 @@
>   device_type = "memory";
>   reg = <0x8000 0x4000>;  /* 1 GB */
>   };
> +
> + vmmcsd_fixed: fixedregulator@0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vmmcsd_fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
>  };
>  
>  _emac0 {
> @@ -26,3 +33,31 @@
>   phy_id = <_mdio>, <1>;
>   phy-mode = "rgmii";
>  };
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_fixed>;
> + bus-width = <8>;
> + dmas = <_xbar 8 0 1/* use SDTXEVT1 instead of MCASP0TX */
> + _xbar 9 0 2>;  /* use SDRXEVT1 instead of MCASP0RX */
> + dma-names = "tx", "rx";

Do you happened to know how the audio is connected on the board?
The DM814x-EVM seams to be using McASP2 with aic3106 so it is possible that HP
copied the design from there...

> +};
> +
> + {
> + sd2_pins: pinmux_sd2_pins {
> + pinctrl-single,pins = <
> + DM814X_IOPAD(0x09c0, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[7] */
> + DM814X_IOPAD(0x09c4, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[6] */
> + DM814X_IOPAD(0x09c8, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[5] */
> + DM814X_IOPAD(0x09cc, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[4] */
> + DM814X_IOPAD(0x09d0, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[3] */
> + DM814X_IOPAD(0x09d4, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[2] */
> + DM814X_IOPAD(0x09d8, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[1] */
> + DM814X_IOPAD(0x09dc, PIN_INPUT_PULLUP | 0x1)/* 
> SD2_DAT[0] */
> + DM814X_IOPAD(0x09e0, PIN_INPUT | 0x1)   /* 
> SD2_CLK */
> + DM814X_IOPAD(0x09f4, PIN_INPUT_PULLUP | 0x2)/* 
> SD2_CMD */
> + DM814X_IOPAD(0x0920, PIN_INPUT | 40)/* SD2_SDCD */
> + >;
> + };
> +};
> 


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

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/04/2015 12:54 PM, Sudeep Holla wrote:
> Hi Grygorii,
> 
> On 04/12/15 10:44, Grygorii Strashko wrote:
>> On 12/03/2015 11:37 PM, Tony Lindgren wrote:
> 
> [...]
> 
>>> And these both need to be applied together when we have a fix for the
>>> above
>>> as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.
>>>
>>
>> Most probably below diff will fix above issue:
>>
>> diff --git a/arch/arm/mach-omap2/prm_common.c
>> b/arch/arm/mach-omap2/prm_common.c
>> index 3fc2cbe..69cde67 100644
>> --- a/arch/arm/mach-omap2/prm_common.c
>> +++ b/arch/arm/mach-omap2/prm_common.c
>> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
>> omap_prcm_irq_setup *irq_setup)
>>  ct->chip.irq_ack = irq_gc_ack_set_bit;
>>  ct->chip.irq_mask = irq_gc_mask_clr_bit;
>>  ct->chip.irq_unmask = irq_gc_mask_set_bit;
>> +   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
> 
> Thanks for testing. 

Sry, I've not tested it yet - it's just fast assumption :(

In that case without this hunk, we should get error
> from pcs_irq_set_wake in the suspend path. No ? May be driver is not
> checking the error value and entering suspend.
> 

Yep. Noone is checking return result from enable_irq_wake() in suspend path
(see dev_pm_arm_wake_irq()).

Actually, return result of  enable_irq_wake()  is checked only in ~30% of
cases in kernel now :)


-- 
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 1/3] ARM: OMAP2+: Fix SoC detection for dra62x j5-eco

[Tony Lindgren]

* Matthijs van Duin  [151203 18:44]:
> On 4 December 2015 at 00:11, Tony Lindgren  wrote:
> > We can boot dra62x j5-eco using the dm814x code as the clocks and
> > devices are mapped in the device tree. The dra62x is also known
> > as jacinto 5.
> 
> I'm pretty sure the "eco" in the name isn't optional. As far as I know:
> jacinto 5 = dra65x ~ dm814x
> jacinto 5 eco = dra62x ~ dm811x
> jacinto 5 entry = dra61x/60x ~ am335x
> 
> Here ~ means equivalence modulo efuse bits.
> 
> My knowledge of TI's automotive processors is limited however, as is
> public documentation, so perhaps someone from TI can ack or nak this.

OK I'll update to to use "jacinto 5 eco" specifically to avoid more
confusion.

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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Grygorii Strashko  [151204 02:45]:
> On 12/03/2015 11:37 PM, Tony Lindgren wrote:
> >* Grygorii Strashko  [151203 10:36]:
> >>
> >>I think, this patch should not break our wake-up functionality.
> >>It will just change the moment when pcs_irq_handler() will be called:
> >>
> >>before this change:
> >>- suspend_enter()
> >>   
> >>   - arch_suspend_enable_irqs();
> >> - ^ right here
> >>
> >>after this change:
> >>- suspend_enter()
> >>   
> >>   dpm_resume_noirq()
> >>   - resume_device_irqs()
> >> ^ here
> >>
> >>Correct? And as for me this is more safe.
> >
> >I think there's more to it though. With both applied, it produces this on
> >coming back up from suspend:
> >
> >PM: noirq resume of devices complete after 18.127 msecs
> >[ cut here ]
> >WARNING: CPU: 0 PID: 123 at kernel/irq/manage.c:605 
> >irq_set_irq_wake+0xbc/0xfc()
> >Unbalanced IRQ 375 wake disable
> >Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
> >CPU: 0 PID: 123 Comm: bash Tainted: GW   4.4.0-rc3-dirty #2682
> >Hardware name: Generic OMAP36xx (Flattened Device Tree)
> >[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> >] (show_stack) from [] (dump_stack+0x84/0x9c)
> >[] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
> >[] (warn_slowpath_common) from [] 
> >(warn_slowpath_fmt+0x30/0x40)
> >[] (warn_slowpath_fmt) from [] 
> >(irq_set_irq_wake+0xbc/0xfc)
> >[] (irq_set_irq_wake) from [] 
> >(device_wakeup_disarm_wake_irqs+0x70/0x12c)
> >[] (device_wakeup_disarm_wake_irqs) from [] 
> >(dpm_resume_noirq+0x20c/0x2e4)
> >[] (dpm_resume_noirq) from [] 
> >(suspend_devices_and_enter+0x1e4/0x6bc)
> >[] (suspend_devices_and_enter) from [] 
> >(pm_suspend+0x358/0x4b8)
> >[] (pm_suspend) from [] (state_store+0x64/0xb8)
> >[] (state_store) from [] (kobj_attr_store+0x14/0x20)
> >[] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50)
> >[] (sysfs_kf_write) from [] (kernfs_fop_write+0xbc/0x1cc)
> >[] (kernfs_fop_write) from [] (__vfs_write+0x24/0xd8)
> >[] (__vfs_write) from [] (vfs_write+0x94/0x154)
> >[] (vfs_write) from [] (SyS_write+0x40/0x94)
> >[] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
> >---[ end trace 321b51565e161bee ]---
> >
> >And these both need to be applied together when we have a fix for the above
> >as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.
> >
> 
> Most probably below diff will fix above issue:
> 
> diff --git a/arch/arm/mach-omap2/prm_common.c
> b/arch/arm/mach-omap2/prm_common.c
> index 3fc2cbe..69cde67 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
> omap_prcm_irq_setup *irq_setup)
> ct->chip.irq_ack = irq_gc_ack_set_bit;
> ct->chip.irq_mask = irq_gc_mask_clr_bit;
> ct->chip.irq_unmask = irq_gc_mask_set_bit;
> +   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
> 
> ct->regs.ack = irq_setup->ack + i * 4;
> ct->regs.mask = irq_setup->mask + i * 4;
> 
> 

That fixes the warning on resume, but adds a new one during init:

[ cut here ]
WARNING: CPU: 0 PID: 1 at kernel/irq/pm.c:51 irq_pm_install_action+0x9c/0xec()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc3-1-g6a5e5ec #2694
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x9c)
[] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
[] (warn_slowpath_common) from [] 
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from [] 
(irq_pm_install_action+0x9c/0xec)
[] (irq_pm_install_action) from [] (__setup_irq+0x434/0x5e0)
[] (__setup_irq) from [] (request_threaded_irq+0xc4/0x15c)
[] (request_threaded_irq) from [] 
(omap3_pm_init+0x10c/0x400)
[] (omap3_pm_init) from [] (omap3_init_late+0xc/0x14)
[] (omap3_init_late) from [] (init_machine_late+0x1c/0x90)
[] (init_machine_late) from [] (do_one_initcall+0x80/0x1e0)
[] (do_one_initcall) from [] 
(kernel_init_freeable+0x218/0x2e8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
---[ end trace 81093452bf564522 ]---

And then there's still at least one problem remaining with the original patch
where togging the parent irq in pin specific irq pcs_irq_set_wake does not
make sense. Will comment on that separately.

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 7/7] ARM: dts: Enable emmc on hp t410

[Tony Lindgren]

* Peter Ujfalusi  [151204 01:21]:
> On 12/04/2015 03:25 AM, Tony Lindgren wrote:
> > There's a 2GB emmc on hp t410 that's wired to the sd_2 interface.
> > Note that we also need to configure the evtmux using edma_xbar for
> > edma channels.
> > 
> > Signed-off-by: Tony Lindgren 
> 
> One question inlined for the mmc3, other than that:
> Reviewed-by: Peter Ujfalusi 
> 
> > ---
> >  arch/arm/boot/dts/dm8148-t410.dts | 35 +++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/dm8148-t410.dts 
> > b/arch/arm/boot/dts/dm8148-t410.dts
> > index 79838dd..d1927a7 100644
> > --- a/arch/arm/boot/dts/dm8148-t410.dts
> > +++ b/arch/arm/boot/dts/dm8148-t410.dts
> > @@ -15,6 +15,13 @@
> > device_type = "memory";
> > reg = <0x8000 0x4000>;  /* 1 GB */
> > };
> > +
> > +   vmmcsd_fixed: fixedregulator@0 {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "vmmcsd_fixed";
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +   };
> >  };
> >  
> >  _emac0 {
> > @@ -26,3 +33,31 @@
> > phy_id = <_mdio>, <1>;
> > phy-mode = "rgmii";
> >  };
> > +
> > + {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_pins>;
> > +   vmmc-supply = <_fixed>;
> > +   bus-width = <8>;
> > +   dmas = <_xbar 8 0 1/* use SDTXEVT1 instead of MCASP0TX */
> > +   _xbar 9 0 2>;  /* use SDRXEVT1 instead of MCASP0RX */
> > +   dma-names = "tx", "rx";
> 
> Do you happened to know how the audio is connected on the board?
> The DM814x-EVM seams to be using McASP2 with aic3106 so it is possible that HP
> copied the design from there...

I grepped the sources for it and these are the evtmux channels the original
code is using. So maybe they have some different audio setup, the hacks in the
original board file mention "hdmi-dai".

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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Tony Lindgren  [151203 13:41]:
> * Sudeep Holla  [151203 11:00]:
> > 
> > I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
> > which ensures it's marked for wakeup.
> 
> Hmm well see the error I pasted in this thread, maybe that provides
> more clues.

The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
separately, not for the whole controller.

I think all that can be left out with the snipped from Grygorii, and maybe
also the lock_class_key changes.

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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 04/12/15 15:40, Tony Lindgren wrote:

* Tony Lindgren  [151203 13:41]:

* Sudeep Holla  [151203 11:00]:


I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
which ensures it's marked for wakeup.


Hmm well see the error I pasted in this thread, maybe that provides
more clues.


The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
separately, not for the whole controller.



OK, my understanding was that this driver supports multiple single
pinmux with one main irq `pcs_soc->irq`. Hence I added the wakeup on
that irq. I now think that understand is wrong.


I think all that can be left out with the snipped from Grygorii, and maybe
also the lock_class_key changes.


OK

--
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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/04/2015 05:35 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [151204 02:45]:
>> On 12/03/2015 11:37 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko  [151203 10:36]:

 I think, this patch should not break our wake-up functionality.
 It will just change the moment when pcs_irq_handler() will be called:

 before this change:
 - suspend_enter()

- arch_suspend_enable_irqs();
  - ^ right here

 after this change:
 - suspend_enter()

dpm_resume_noirq()
- resume_device_irqs()
  ^ here

 Correct? And as for me this is more safe.
>>>
>>> I think there's more to it though. With both applied, it produces this on
>>> coming back up from suspend:
>>>
>>> PM: noirq resume of devices complete after 18.127 msecs
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 123 at kernel/irq/manage.c:605 
>>> irq_set_irq_wake+0xbc/0xfc()
>>> Unbalanced IRQ 375 wake disable
>>> Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl 
>>> twl4030_wdt
>>> CPU: 0 PID: 123 Comm: bash Tainted: GW   4.4.0-rc3-dirty #2682
>>> Hardware name: Generic OMAP36xx (Flattened Device Tree)
>>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>>> ] (show_stack) from [] (dump_stack+0x84/0x9c)
>>> [] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
>>> [] (warn_slowpath_common) from [] 
>>> (warn_slowpath_fmt+0x30/0x40)
>>> [] (warn_slowpath_fmt) from [] 
>>> (irq_set_irq_wake+0xbc/0xfc)
>>> [] (irq_set_irq_wake) from [] 
>>> (device_wakeup_disarm_wake_irqs+0x70/0x12c)
>>> [] (device_wakeup_disarm_wake_irqs) from [] 
>>> (dpm_resume_noirq+0x20c/0x2e4)
>>> [] (dpm_resume_noirq) from [] 
>>> (suspend_devices_and_enter+0x1e4/0x6bc)
>>> [] (suspend_devices_and_enter) from [] 
>>> (pm_suspend+0x358/0x4b8)
>>> [] (pm_suspend) from [] (state_store+0x64/0xb8)
>>> [] (state_store) from [] (kobj_attr_store+0x14/0x20)
>>> [] (kobj_attr_store) from [] (sysfs_kf_write+0x4c/0x50)
>>> [] (sysfs_kf_write) from [] 
>>> (kernfs_fop_write+0xbc/0x1cc)
>>> [] (kernfs_fop_write) from [] (__vfs_write+0x24/0xd8)
>>> [] (__vfs_write) from [] (vfs_write+0x94/0x154)
>>> [] (vfs_write) from [] (SyS_write+0x40/0x94)
>>> [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
>>> ---[ end trace 321b51565e161bee ]---
>>>
>>> And these both need to be applied together when we have a fix for the above
>>> as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.
>>>
>>
>> Most probably below diff will fix above issue:
>>
>> diff --git a/arch/arm/mach-omap2/prm_common.c
>> b/arch/arm/mach-omap2/prm_common.c
>> index 3fc2cbe..69cde67 100644
>> --- a/arch/arm/mach-omap2/prm_common.c
>> +++ b/arch/arm/mach-omap2/prm_common.c
>> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
>> omap_prcm_irq_setup *irq_setup)
>>  ct->chip.irq_ack = irq_gc_ack_set_bit;
>>  ct->chip.irq_mask = irq_gc_mask_clr_bit;
>>  ct->chip.irq_unmask = irq_gc_mask_set_bit;
>> +   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
>>
>>  ct->regs.ack = irq_setup->ack + i * 4;
>>  ct->regs.mask = irq_setup->mask + i * 4;
>>
>>
> 
> That fixes the warning on resume, but adds a new one during init:
> 
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at kernel/irq/pm.c:51 irq_pm_install_action+0x9c/0xec()
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc3-1-g6a5e5ec #2694
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x84/0x9c)
> [] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
> [] (warn_slowpath_common) from [] 
> (warn_slowpath_null+0x1c/0x24)
> [] (warn_slowpath_null) from [] 
> (irq_pm_install_action+0x9c/0xec)
> [] (irq_pm_install_action) from [] 
> (__setup_irq+0x434/0x5e0)
> [] (__setup_irq) from [] (request_threaded_irq+0xc4/0x15c)
> [] (request_threaded_irq) from [] 
> (omap3_pm_init+0x10c/0x400)
> [] (omap3_pm_init) from [] (omap3_init_late+0xc/0x14)
> [] (omap3_init_late) from [] (init_machine_late+0x1c/0x90)
> [] (init_machine_late) from [] 
> (do_one_initcall+0x80/0x1e0)
> [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x218/0x2e8)
> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
> ---[ end trace 81093452bf564522 ]---
> 

Sorry, I can't test it right now :(
Potential fix below:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2dbd378..4e56fd9 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -481,7 +481,7 @@ int __init omap3_pm_init(void)
 
/* IO interrupt is shared with mux code */
ret = request_irq(omap_prcm_event_to_irq("io"),
-   _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, 

Re: [PATCH 2/2] ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi

[Enric Balletbo Serra]

2015-12-03 19:02 GMT+01:00 Javier Martinez Canillas :
> When the WiFi support was added to the IGEP0030 board, the MMC subsystem
> did not provide a mechanism to define power sequence providers. So a DT
> hack was used to toggle the WiFi chip reset and power down pins by using
> fake fixed regulators whose enable GPIO was the GPIOs connected to these
> pins.
>
> But now the simple MMC power sequence provider can be used for this and
> the workaround removed.
>
> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
>  arch/arm/boot/dts/omap3-igep0030.dts | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
> b/arch/arm/boot/dts/omap3-igep0030.dts
> index 468608dab30a..55b0cc4f5ee5 100644
> --- a/arch/arm/boot/dts/omap3-igep0030.dts
> +++ b/arch/arm/boot/dts/omap3-igep0030.dts
> @@ -15,25 +15,17 @@
> model = "IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)";
> compatible = "isee,omap3-igep0030", "ti,omap36xx", "ti,omap3";
>
> -   /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
> -   lbee1usjyc_pdn: lbee1usjyc_pdn {
> +   vmmcsdio_fixed: fixedregulator-mmcsdio {
> compatible = "regulator-fixed";
> -   regulator-name = "regulator-lbee1usjyc-pdn";
> +   regulator-name = "vmmcsdio_fixed";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> -   gpio = < 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - 
> WIFI_PDN */
> -   startup-delay-us = <1>;
> -   enable-active-high;
> };
>
> -   /* Regulator to trigger the RESET_N_W signal of the Wifi module */
> -   lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
> -   compatible = "regulator-fixed";
> -   regulator-name = "regulator-lbee1usjyc-reset-n-w";
> -   regulator-min-microvolt = <330>;
> -   regulator-max-microvolt = <330>;
> -   gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - 
> RESET_N_W */
> -   enable-active-high;
> +   mmc2_pwrseq: mmc2_pwrseq {
> +   compatible = "mmc-pwrseq-simple";
> +   reset-gpios = < 11 GPIO_ACTIVE_LOW>,  /* gpio_139 - 
> RESET_N_W */
> + < 10 GPIO_ACTIVE_LOW>;  /* gpio_138 - 
> WIFI_PDN */
> };
>  };
>
> @@ -62,8 +54,8 @@
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins _pins>;
> -   vmmc-supply = <_pdn>;
> -   vmmc_aux-supply = <_reset_n_w>;
> +   vmmc-supply = <_fixed>;
> +   mmc-pwrseq = <_pwrseq>;
> bus-width = <4>;
> non-removable;
>  };
> --
> 2.4.3
>

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

Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init

[Enric Balletbo Serra]

2015-12-03 20:27 GMT+01:00 Tony Lindgren :
> * Javier Martinez Canillas  [151203 10:29]:
>> Hello Tony,
>>
>> On 12/03/2015 03:16 PM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas  [151203 10:03]:
>> >> Hello,
>> >>
>> >> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
>> >> Device Tree to use the MMC power sequence provider to initialize the SDIO
>> >> WiFi chip instead of using fake fixed regulators to just toggle the Reset
>> >> and Power pins in the chip.
>> >>
>> >> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
>> >> is the same with regard to the SDIO WiFi so it should be safe to land too.
>> >>
>> >> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
>> >> using a different WiFi chip (wlcore instead of libertas) than the one in
>> >> the board I've access to test so I preferred to leave those untouched.
>> >
>> > Do you have some solution for the start-up latency issue?
>> >
>>
>> No, I don't and that's one of the reasons why I didn't want to touch the
>> DTS that have the wlcore chip.
>>
>> The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a
>> startup-delay-us property in the regulator for the WLAN_EN pin as is
>> the case for the IGEPv5 DTS but I don't know if those DTS are just wrong.
>
> OK
>
>> The DTS for the igep0020 and igep0030 that have the libertas chip,
>> did have a startup-delay-us for the WIFI_PDN but using the GPIOs
>> for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is
>> enough to make the SDIO chip reset, be enumerated and WiFi to work
>> correctly so I don't know if that is really needed or is just a bad
>> description in the DTS.
>
> Hmm OK.
>
>> Since is working for the boards with the libertas chip, I preferred
>> to remove the DTS hack but left the boards with wlcore chip since
>> you said the startup-delay-us is needed there (but probably we should
>> add to the regulators in the boards that don't have it then).
>
> OK
>
> Thanks,
>
> Tony

I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.

Thanks,
Enric
--
To unsubscribe from this list: send the line "unsubscribe 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] OMAPDSS: DSS: fix a warning message

[Dan Carpenter]

The WARN() macro has to take a condition.  The current code will just
print the stack trace and the function name instead of the intended
warning message.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/video/fbdev/omap2/dss/dss.h 
b/drivers/video/fbdev/omap2/dss/dss.h
index 2406bcd..da3a85a 100644
--- a/drivers/video/fbdev/omap2/dss/dss.h
+++ b/drivers/video/fbdev/omap2/dss/dss.h
@@ -343,7 +343,8 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
 #else
 static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
 {
-   WARN("%s: DSI not compiled in, returning pixel_size as 0\n", __func__);
+   WARN(1, "%s: DSI not compiled in, returning pixel_size as 0\n",
+__func__);
return 0;
 }
 #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi

[Enric Balletbo Serra]

2015-12-03 19:02 GMT+01:00 Javier Martinez Canillas :
> When the WiFi support was added to the IGEP0020 board, the MMC subsystem
> did not provide a mechanism to define power sequence providers. So a DT
> hack was used to toggle the WiFi chip reset and power down pins by using
> fake fixed regulators whose enable GPIO was the GPIOs connected to these
> pins.
>
> But now the simple MMC power sequence provider can be used for this and
> the workaround removed.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
>  arch/arm/boot/dts/omap3-igep0020.dts | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index 3835e1569c29..33d6b4ead092 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -15,25 +15,17 @@
> model = "IGEPv2 Rev. C (TI OMAP AM/DM37x)";
> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>
> -   /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
> -   lbee1usjyc_pdn: lbee1usjyc_pdn {
> +   vmmcsdio_fixed: fixedregulator-mmcsdio {
> compatible = "regulator-fixed";
> -   regulator-name = "regulator-lbee1usjyc-pdn";
> +   regulator-name = "vmmcsdio_fixed";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> -   gpio = < 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - 
> WIFI_PDN */
> -   startup-delay-us = <1>;
> -   enable-active-high;
> };
>
> -   /* Regulator to trigger the RESET_N_W signal of the Wifi module */
> -   lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
> -   compatible = "regulator-fixed";
> -   regulator-name = "regulator-lbee1usjyc-reset-n-w";
> -   regulator-min-microvolt = <330>;
> -   regulator-max-microvolt = <330>;
> -   gpio = < 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - 
> RESET_N_W */
> -   enable-active-high;
> +   mmc2_pwrseq: mmc2_pwrseq {
> +   compatible = "mmc-pwrseq-simple";
> +   reset-gpios = < 11 GPIO_ACTIVE_LOW>,  /* gpio_139 - 
> RESET_N_W */
> + < 10 GPIO_ACTIVE_LOW>;  /* gpio_138 - 
> WIFI_PDN */
> };
>  };
>
> @@ -51,8 +43,8 @@
>   {
> pinctrl-names = "default";
> pinctrl-0 = <_pins _pins>;
> -   vmmc-supply = <_pdn>;
> -   vmmc_aux-supply = <_reset_n_w>;
> +   vmmc-supply = <_fixed>;
> +   mmc-pwrseq = <_pwrseq>;
> bus-width = <4>;
> non-removable;
>  };
> --
> 2.4.3
>

I also tested these patches

Acked-by: Enric Balletbo Serra 
--
To unsubscribe from this list: send the line "unsubscribe 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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Grygorii Strashko  [151204 08:00]:
> On 12/04/2015 05:35 PM, Tony Lindgren wrote:
> > * Grygorii Strashko  [151204 02:45]:
> >> On 12/03/2015 11:37 PM, Tony Lindgren wrote:
> >>> * Grygorii Strashko  [151203 10:36]:
> 
>  I think, this patch should not break our wake-up functionality.
>  It will just change the moment when pcs_irq_handler() will be called:
> 
>  before this change:
>  - suspend_enter()
> 
> - arch_suspend_enable_irqs();
>   - ^ right here
> 
>  after this change:
>  - suspend_enter()
> 
> dpm_resume_noirq()
> - resume_device_irqs()
>   ^ here
> 
>  Correct? And as for me this is more safe.
> >>>
> >>> I think there's more to it though. With both applied, it produces this on
> >>> coming back up from suspend:
> >>>
> >>> PM: noirq resume of devices complete after 18.127 msecs
> >>> [ cut here ]
> >>> WARNING: CPU: 0 PID: 123 at kernel/irq/manage.c:605 
> >>> irq_set_irq_wake+0xbc/0xfc()
> >>> Unbalanced IRQ 375 wake disable
> >>> Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl 
> >>> twl4030_wdt
> >>> CPU: 0 PID: 123 Comm: bash Tainted: GW   4.4.0-rc3-dirty #2682
> >>> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> >>> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> >>> ] (show_stack) from [] (dump_stack+0x84/0x9c)
> >>> [] (dump_stack) from [] 
> >>> (warn_slowpath_common+0x7c/0xb8)
> >>> [] (warn_slowpath_common) from [] 
> >>> (warn_slowpath_fmt+0x30/0x40)
> >>> [] (warn_slowpath_fmt) from [] 
> >>> (irq_set_irq_wake+0xbc/0xfc)
> >>> [] (irq_set_irq_wake) from [] 
> >>> (device_wakeup_disarm_wake_irqs+0x70/0x12c)
> >>> [] (device_wakeup_disarm_wake_irqs) from [] 
> >>> (dpm_resume_noirq+0x20c/0x2e4)
> >>> [] (dpm_resume_noirq) from [] 
> >>> (suspend_devices_and_enter+0x1e4/0x6bc)
> >>> [] (suspend_devices_and_enter) from [] 
> >>> (pm_suspend+0x358/0x4b8)
> >>> [] (pm_suspend) from [] (state_store+0x64/0xb8)
> >>> [] (state_store) from [] (kobj_attr_store+0x14/0x20)
> >>> [] (kobj_attr_store) from [] 
> >>> (sysfs_kf_write+0x4c/0x50)
> >>> [] (sysfs_kf_write) from [] 
> >>> (kernfs_fop_write+0xbc/0x1cc)
> >>> [] (kernfs_fop_write) from [] (__vfs_write+0x24/0xd8)
> >>> [] (__vfs_write) from [] (vfs_write+0x94/0x154)
> >>> [] (vfs_write) from [] (SyS_write+0x40/0x94)
> >>> [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)
> >>> ---[ end trace 321b51565e161bee ]---
> >>>
> >>> And these both need to be applied together when we have a fix for the 
> >>> above
> >>> as otherwise we'll get the lock recursion Sudeep mentioned in patch 2/2.
> >>>
> >>
> >> Most probably below diff will fix above issue:
> >>
> >> diff --git a/arch/arm/mach-omap2/prm_common.c
> >> b/arch/arm/mach-omap2/prm_common.c
> >> index 3fc2cbe..69cde67 100644
> >> --- a/arch/arm/mach-omap2/prm_common.c
> >> +++ b/arch/arm/mach-omap2/prm_common.c
> >> @@ -338,6 +338,7 @@ int omap_prcm_register_chain_handler(struct
> >> omap_prcm_irq_setup *irq_setup)
> >>  ct->chip.irq_ack = irq_gc_ack_set_bit;
> >>  ct->chip.irq_mask = irq_gc_mask_clr_bit;
> >>  ct->chip.irq_unmask = irq_gc_mask_set_bit;
> >> +   ct->chip.flags = IRQCHIP_SKIP_SET_WAKE;
> >>
> >>  ct->regs.ack = irq_setup->ack + i * 4;
> >>  ct->regs.mask = irq_setup->mask + i * 4;
> >>
> >>
> > 
> > That fixes the warning on resume, but adds a new one during init:
> > 
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at kernel/irq/pm.c:51 
> > irq_pm_install_action+0x9c/0xec()
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc3-1-g6a5e5ec #2694
> > Hardware name: Generic OMAP36xx (Flattened Device Tree)
> > [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> > [] (show_stack) from [] (dump_stack+0x84/0x9c)
> > [] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
> > [] (warn_slowpath_common) from [] 
> > (warn_slowpath_null+0x1c/0x24)
> > [] (warn_slowpath_null) from [] 
> > (irq_pm_install_action+0x9c/0xec)
> > [] (irq_pm_install_action) from [] 
> > (__setup_irq+0x434/0x5e0)
> > [] (__setup_irq) from [] 
> > (request_threaded_irq+0xc4/0x15c)
> > [] (request_threaded_irq) from [] 
> > (omap3_pm_init+0x10c/0x400)
> > [] (omap3_pm_init) from [] (omap3_init_late+0xc/0x14)
> > [] (omap3_init_late) from [] 
> > (init_machine_late+0x1c/0x90)
> > [] (init_machine_late) from [] 
> > (do_one_initcall+0x80/0x1e0)
> > [] (do_one_initcall) from [] 
> > (kernel_init_freeable+0x218/0x2e8)
> > [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec)
> > [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
> > ---[ end trace 81093452bf564522 ]---
> > 
> 
> Sorry, I can't test it right now :(
> Potential fix below:
> diff --git a/arch/arm/mach-omap2/pm34xx.c 

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Felipe Balbi]

Hi,

Peter Ujfalusi  writes:
> @@ -174,12 +182,44 @@
>   };
>  
>   edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg =   <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg =   <0x4900 0x1>;
> + reg-names = "edma3_cc";
>   interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> +   "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> +<_tptc2 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;

can you explain this property here ? Are you setting bits 20 and 21 on a
16-bit field ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Sudeep Holla  [151204 08:27]:
> 
> 
> On 04/12/15 16:19, Grygorii Strashko wrote:
> >On 12/04/2015 05:44 PM, Sudeep Holla wrote:
> >>
> >>
> >>On 04/12/15 15:40, Tony Lindgren wrote:
> >>>* Tony Lindgren  [151203 13:41]:
> * Sudeep Holla  [151203 11:00]:
> >
> >I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
> >which ensures it's marked for wakeup.
> 
> Hmm well see the error I pasted in this thread, maybe that provides
> more clues.
> >>>
> >>>The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
> >>>look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
> >>>separately, not for the whole controller.
> >>>
> >>
> >>OK, my understanding was that this driver supports multiple single
> >>pinmux with one main irq `pcs_soc->irq`. Hence I added the wakeup on
> >>that irq. I now think that understand is wrong.
> >>
> >
> >With this change, PCS parent IRQ will be marked as wake up source as many
> >times as many pins were requested as wake up IRQs (protected by counter).
> >Most of all GPIO IRQ chips work this way.
> >Of course, if we will look on pinctrl-single.c from only OMAP point of view
> >then Prent IRQ can be marked as wake up source from probe only once.
> >But, since this driver expected to be generic - this patch is more correct,
> >because other HW may require to perform some real HW re-configuration to
> >enable/disable wake up capabilities for Parent IRQ in Parent IRQ controller.
> >
> 
> Thanks for the detailed explanation. I was bit confused if my
> understanding is correct or not.
> 
> >Any way, in my opinion, it's right and more safe to manage all wakeup IRQs
> >through IRQ PM core and Device wakeirq framework. And this patch should just
> >go together with platform changes and not alone.

OK yeah if it's a counter then it makes sense to me.

> Agreed, since I don't have platform to test, I will leave it you guys to
> pick up these patches when ready and with any changes if required.

Yeah probably best that Grygorii tries to sort it out :)

Regards,

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

Re: [PATCH 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Grygorii Strashko  [151204 08:31]:
> On 12/04/2015 06:11 PM, Sudeep Holla wrote:
> > 
> > 
> > On 04/12/15 15:59, Grygorii Strashko wrote:
> >>
> >> Sorry, I can't test it right now :(
> >> Potential fix below:
> > 
> > I had posted similar patch a while ago which Tony rejected.
> > I might have made a mistake of not putting them together, though they
> > were part of the same series[1], patch 12 and 16
> 
> True. I've remembered that I saw smth. like this, but I was not able to find 
> it :(

Just tried it and applying that makes the wake-up interrupts not work at all.

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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Tony Lindgren]

* Sudeep Holla  [151204 08:16]:
> Hi Tony,
> 
> On 04/12/15 15:40, Tony Lindgren wrote:
> >* Tony Lindgren  [151203 13:41]:
> >>* Sudeep Holla  [151203 11:00]:
> >>>
> >>>I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
> >>>which ensures it's marked for wakeup.
> >>
> >>Hmm well see the error I pasted in this thread, maybe that provides
> >>more clues.
> >
> >The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
> >look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
> >separately, not for the whole controller.
> >
> 
> After thinking more about it we need some way to tell IRQ core that
> pcs_soc->irq is wakeup capable. Is that going to happen automatically
> via dev_pm_set_dedicated_wake_irq as you mentioned earlier ?
> 
> >I think all that can be left out with the snipped from Grygorii, and maybe
> >also the lock_class_key changes.
> >
> 
> If we not calling irq_set_irq_wake(pcs_soc->irq) in pcs_irq_set_wake, do
> you see possibility of lockdep recursion in any other paths.
> 
> Otherwise we don't need this if we remove irq_set_irq_wake(pcs_soc->irq)
> from pcs_irq_set_wake

I think Grygorii is right here and this is correct as it's a counter
once the other issues are sorted out and we have figured out what all
needs to be patched together.

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] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 04/12/15 16:19, Grygorii Strashko wrote:

On 12/04/2015 05:44 PM, Sudeep Holla wrote:



On 04/12/15 15:40, Tony Lindgren wrote:

* Tony Lindgren  [151203 13:41]:

* Sudeep Holla  [151203 11:00]:


I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
which ensures it's marked for wakeup.


Hmm well see the error I pasted in this thread, maybe that provides
more clues.


The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
separately, not for the whole controller.



OK, my understanding was that this driver supports multiple single
pinmux with one main irq `pcs_soc->irq`. Hence I added the wakeup on
that irq. I now think that understand is wrong.



With this change, PCS parent IRQ will be marked as wake up source as many
times as many pins were requested as wake up IRQs (protected by counter).
Most of all GPIO IRQ chips work this way.
Of course, if we will look on pinctrl-single.c from only OMAP point of view
then Prent IRQ can be marked as wake up source from probe only once.
But, since this driver expected to be generic - this patch is more correct,
because other HW may require to perform some real HW re-configuration to
enable/disable wake up capabilities for Parent IRQ in Parent IRQ controller.



Thanks for the detailed explanation. I was bit confused if my
understanding is correct or not.


Any way, in my opinion, it's right and more safe to manage all wakeup IRQs
through IRQ PM core and Device wakeirq framework. And this patch should just
go together with platform changes and not alone.



Agreed, since I don't have platform to test, I will leave it you guys to
pick up these patches when ready and with any changes if required.

--
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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

Hi Tony,

On 04/12/15 15:40, Tony Lindgren wrote:

* Tony Lindgren  [151203 13:41]:

* Sudeep Holla  [151203 11:00]:


I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
which ensures it's marked for wakeup.


Hmm well see the error I pasted in this thread, maybe that provides
more clues.


The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
separately, not for the whole controller.



After thinking more about it we need some way to tell IRQ core that
pcs_soc->irq is wakeup capable. Is that going to happen automatically
via dev_pm_set_dedicated_wake_irq as you mentioned earlier ?


I think all that can be left out with the snipped from Grygorii, and maybe
also the lock_class_key changes.



If we not calling irq_set_irq_wake(pcs_soc->irq) in pcs_irq_set_wake, do
you see possibility of lockdep recursion in any other paths.

Otherwise we don't need this if we remove irq_set_irq_wake(pcs_soc->irq)
from pcs_irq_set_wake

--
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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 04/12/15 15:59, Grygorii Strashko wrote:


Sorry, I can't test it right now :(
Potential fix below:


I had posted similar patch a while ago which Tony rejected.
I might have made a mistake of not putting them together, though they
were part of the same series[1], patch 12 and 16


diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2dbd378..4e56fd9 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -481,7 +481,7 @@ int __init omap3_pm_init(void)

 /* IO interrupt is shared with mux code */
 ret = request_irq(omap_prcm_event_to_irq("io"),
-   _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, "pm_io",
+   _prcm_int_handle_io, IRQF_SHARED, "pm_io",
 omap3_pm_init);
 enable_irq(omap_prcm_event_to_irq("io"));

@@ -489,6 +489,7 @@ int __init omap3_pm_init(void)
 pr_err("pm: Failed to request pm_io irq\n");
 goto err2;
 }
+   enable_irq_wake(omap_prcm_event_to_irq("io"));

 ret = pwrdm_for_each(pwrdms_setup, NULL);
 if (ret) {





[1] http://lkml.iu.edu/hypermail/linux/kernel/1509.2/03937.html
--
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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/04/2015 05:44 PM, Sudeep Holla wrote:
> 
> 
> On 04/12/15 15:40, Tony Lindgren wrote:
>> * Tony Lindgren  [151203 13:41]:
>>> * Sudeep Holla  [151203 11:00]:

 I have added irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake
 which ensures it's marked for wakeup.
>>>
>>> Hmm well see the error I pasted in this thread, maybe that provides
>>> more clues.
>>
>> The irq_set_irq_wake(pcs_soc->irq, state) in pcs_irq_set_wake does not
>> look right to me as pcs_irq_set_wake toggles the irq_wake for each pin
>> separately, not for the whole controller.
>>
> 
> OK, my understanding was that this driver supports multiple single
> pinmux with one main irq `pcs_soc->irq`. Hence I added the wakeup on
> that irq. I now think that understand is wrong.
> 

With this change, PCS parent IRQ will be marked as wake up source as many
times as many pins were requested as wake up IRQs (protected by counter).
Most of all GPIO IRQ chips work this way.
Of course, if we will look on pinctrl-single.c from only OMAP point of view
then Prent IRQ can be marked as wake up source from probe only once.
But, since this driver expected to be generic - this patch is more correct,
because other HW may require to perform some real HW re-configuration to
enable/disable wake up capabilities for Parent IRQ in Parent IRQ controller.

Any way, in my opinion, it's right and more safe to manage all wakeup IRQs
through IRQ PM core and Device wakeirq framework. And this patch should just
go together with platform changes and not alone.

-- 
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 2/2] pinctrl: single: remove misuse of IRQF_NO_SUSPEND flag

[Grygorii Strashko]

On 12/04/2015 06:11 PM, Sudeep Holla wrote:
> 
> 
> On 04/12/15 15:59, Grygorii Strashko wrote:
>>
>> Sorry, I can't test it right now :(
>> Potential fix below:
> 
> I had posted similar patch a while ago which Tony rejected.
> I might have made a mistake of not putting them together, though they
> were part of the same series[1], patch 12 and 16

True. I've remembered that I saw smth. like this, but I was not able to find it 
:(


-- 
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] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Arnd Bergmann]

On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
> > Peter Ujfalusi  writes:
> > > @@ -174,12 +182,44 @@
> > > };
> > >  
> > > edma: edma@4900 {
> > > -   compatible = "ti,edma3";
> > > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > > -   reg =   <0x4900 0x1>,
> > > -   <0x44e10f90 0x40>;
> > > +   compatible = "ti,edma3-tpcc";
> > > +   ti,hwmods = "tpcc";
> > > +   reg =   <0x4900 0x1>;
> > > +   reg-names = "edma3_cc";
> > > interrupts = <12 13 14>;
> > > -   #dma-cells = <1>;
> > > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > > + "edma3_ccerrint";
> > > +   dma-requests = <64>;
> > > +   #dma-cells = <2>;
> > > +
> > > +   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> > > +  <_tptc2 0>;
> > > +
> > > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > 
> > can you explain this property here ? Are you setting bits 20 and 21 on a
> > 16-bit field ?
> 
> I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
> instead of /bits/ 16?
> 

Please just drop the /bits/ 16 and use normal cells.

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

Re: [PATCH v2] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Grygorii Strashko]

On 12/04/2015 08:46 PM, Bjorn Helgaas wrote:
> Hi Grygorii,
> 
> On Fri, Nov 20, 2015 at 03:59:26PM +0200, Grygorii Strashko wrote:
>> On -RT, TI DRA7 PCIe driver always produces below backtrace when the
>> first PCI interrupt is triggered:
>>
>> [ cut here ]
>> WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 
>> handle_irq_event_percpu+0x14c/0x174()
>> irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
[...]
>> [] (handle_simple_irq) from [] 
>> (generic_handle_irq+0x30/0x44)
>>   r5:ee4a9020 r4:01cc
>> [] (generic_handle_irq) from [] 
>> (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
>>   r5:ee4a9020 r4:0001
>> [] (dra7xx_pcie_msi_irq_handler) from [] 
>> (irq_forced_thread_fn+0x28/0x5c)
>>   r5:ee1d0900 r4:ee4b59c0
>> [] (irq_forced_thread_fn) from [] 
>> (irq_thread+0x128/0x204)
>>   r7:0001 r6: r5:ee4d2000 r4:ee4b59e4
>> [] (irq_thread) from [] (kthread+0xd4/0xec)
>>   r10: r9: r8: r7:c00870b4 r6:ee4b59c0 r5:ee4b5a00
>>   r4:
>> [] (kthread) from [] (ret_from_fork+0x14/0x2c)
>>   r7: r6: r5:c005e228 r4:ee4b5a00
>> ---[ end trace 0002 ]---
> 
> The backtrace might be OK (maybe slightly overkill), but all the
> stack addresses are certainly irrelevant and distracting.  We only
> need enough to recognize the problem.  I don't think the modules list
> is relevant either.

I'll take this into account. Is this blocker for this patch now?

> 
>> This backtrace is triggered because dra7xx_pcie_msi_irq_handler()
>> forced to be threaded by default on -RT but, in the same time, it's
>> IRQ dispatcher and calls generic_handle_irq(), which leads to
>> handle_simple_irq() call. The handle_simple_irq() expected to be
>> called with IRQ disabled.
>>
>> The same issue will also happen if kernel will boot with "threadirqs"
>> cmdline parameter (CONFIG_IRQ_FORCED_THREADING).
>>
>> As discussed in [1], the current DRA7 PCIe hw configuration supports
>> 32 interrupts, which cannot change because it's hardwired in silicon,
>> this is a single status read and assuming that only a few (most of the
>> time it will be exactly ONE) of those interrupts are pending at the
>> same time is pretty much a sane assumption. And recommended fix for
>> this issue is to request dra7xx_pcie_msi IRQ with IRQF_NO_THREAD flag.
>>
>> [1] https://lkml.org/lkml/2015/11/3/660
>>
>> Cc: Thomas Gleixner 
>> Cc: Sebastian Andrzej Siewior 
>> Signed-off-by: Grygorii Strashko 
>> ---
>> Changes in v2:
>> - comment in code truncated
>> Link on v1:
>>   https://lkml.org/lkml/2015/11/5/593
>>   drivers/pci/host/pci-dra7xx.c | 13 -
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
>> index 8c36880..0415192 100644
>> --- a/drivers/pci/host/pci-dra7xx.c
>> +++ b/drivers/pci/host/pci-dra7xx.c
>> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
>> dra7xx_pcie *dra7xx,
>>  return -EINVAL;
>>  }
>>   
>> +/*
>> + * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
>> + * On -RT and if kernel is booting with "threadirqs" cmd line parameter
>> + * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
>> + * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
>> + * which, in turn, will be resolved to handle_simple_irq() call.
>> + * The handle_simple_irq() expected to be called with IRQ disabled, as
>> + * result kernle will display warning:
>> + * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
>> + */
>>  ret = devm_request_irq(>dev, pp->irq,
>> -   dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
>> +   dra7xx_pcie_msi_irq_handler,
>> +   IRQF_SHARED | IRQF_NO_THREAD,
>> "dra7-pcie-msi", pp);
> 
> There's similar code in exynos_add_pcie_port(), imx6_add_pcie_port(),
> and spear13xx_add_pcie_port().  Do they need similar changes?  If not,
> why not?
> 
> I see your discussion about DRA7 hardware design, but my impression is
> that this problem affects anybody who calls dw_handle_msi_irq() from a
> handler registered with IRQF_SHARED.

Issue fixed by this patch is not related to IRQF_SHARED. 
It will happen on -RT or if kernel will boot with "threadirqs" cmd line 
parameter
- in both cases these PCI IRQ handlers will be forced to be threaded and,
as result, generic_handle_irq() will produce above backtrace.

Personally, I don't have strong opinion about "should similar change be applied
to other PCI drivers or not?" And I think, that owners of those driver should
make such decision.

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

[PATCH 3/6] ARM: dts: Add usb support for dm814x and dra62x

[Tony Lindgren]

The usb is very much like on am33xx, we just put the some of the
componends under scm where they belong.

Cc: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm814x.dtsi | 125 ++
 1 file changed, 125 insertions(+)

diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 18a8f0d..c254ace 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -21,6 +21,10 @@
serial2 = 
ethernet0 = _emac0;
ethernet1 = _emac1;
+   usb0 = 
+   usb1 = 
+   phy0 = _phy;
+   phy1 = _phy;
};
 
cpus {
@@ -57,6 +61,113 @@
ranges;
ti,hwmods = "l3_main";
 
+   usb: usb@4740 {
+   compatible = "ti,am33xx-usb";
+   reg = <0x4740 0x1000>;
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ti,hwmods = "usb_otg_hs";
+
+   usb0_phy: usb-phy@47401300 {
+   compatible = "ti,am335x-usb-phy";
+   reg = <0x47401300 0x100>;
+   reg-names = "phy";
+   ti,ctrl_mod = <_ctrl_mod>;
+   };
+
+   usb0: usb@47401000 {
+   compatible = "ti,musb-am33xx";
+   reg = <0x47401400 0x400
+  0x47401000 0x200>;
+   reg-names = "mc", "control";
+
+   interrupts = <18>;
+   interrupt-names = "mc";
+   dr_mode = "otg";
+   mentor,multipoint = <1>;
+   mentor,num-eps = <16>;
+   mentor,ram-bits = <12>;
+   mentor,power = <500>;
+   phys = <_phy>;
+
+   dmas = <  0 0   1 0
+ 2 0   3 0
+ 4 0   5 0
+ 6 0   7 0
+ 8 0   9 0
+10 0  11 0
+12 0  13 0
+14 0   0 1
+ 1 1   2 1
+ 3 1   4 1
+ 5 1   6 1
+ 7 1   8 1
+ 9 1  10 1
+11 1  12 1
+13 1  14 1>;
+   dma-names =
+   "rx1", "rx2", "rx3", "rx4", "rx5", 
"rx6", "rx7",
+   "rx8", "rx9", "rx10", "rx11", "rx12", 
"rx13",
+   "rx14", "rx15",
+   "tx1", "tx2", "tx3", "tx4", "tx5", 
"tx6", "tx7",
+   "tx8", "tx9", "tx10", "tx11", "tx12", 
"tx13",
+   "tx14", "tx15";
+   };
+
+   usb1: usb@47401800 {
+   compatible = "ti,musb-am33xx";
+   reg = <0x47401c00 0x400
+   0x47401800 0x200>;
+   reg-names = "mc", "control";
+   interrupts = <19>;
+   interrupt-names = "mc";
+   dr_mode = "otg";
+   mentor,multipoint = <1>;
+   mentor,num-eps = <16>;
+   mentor,ram-bits = <12>;
+   mentor,power = <500>;
+   phys = <_phy>;
+
+   dmas = < 15 0  16 0
+17 0  18 0
+19 0  20 0
+21 0  22 0
+23 0  24 0
+25 0  26 0
+27 0  28 0
+29 0  15 1
+16 1  17 1
+18 1  19 1
+20 1  21 1
+22 1  23 1
+24 1  25 1
+26 1  27 1
+28 1  29 1>;
+  

[PATCH 1/6] ARM: OMAP2+: Update 81xx clock and power domains for default, active and sgx

[Tony Lindgren]

These offsets seem to be common, so let's rename the defines. And let's
set up the default_l3_slow_81xx_clkdm with active and default powerdomains
for dm814x. These are needed for usb to work.

Cc: Paul Walmsley 
Cc: Tero Kristo 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/clockdomains81xx_data.c | 29 +++--
 arch/arm/mach-omap2/cm81xx.h|  6 +++---
 arch/arm/mach-omap2/powerdomains3xxx_data.c | 10 ++
 3 files changed, 24 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomains81xx_data.c 
b/arch/arm/mach-omap2/clockdomains81xx_data.c
index 53442c8..3b5fb05 100644
--- a/arch/arm/mach-omap2/clockdomains81xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains81xx_data.c
@@ -83,6 +83,14 @@ static struct clockdomain mmu_cfg_81xx_clkdm = {
.flags  = CLKDM_CAN_SWSUP,
 };
 
+static struct clockdomain default_l3_slow_81xx_clkdm = {
+   .name   = "default_l3_slow_clkdm",
+   .pwrdm  = { .name = "default_pwrdm" },
+   .cm_inst= TI81XX_CM_DEFAULT_MOD,
+   .clkdm_offs = TI816X_CM_DEFAULT_L3_SLOW_CLKDM,
+   .flags  = CLKDM_CAN_SWSUP,
+};
+
 /* 816x only */
 
 static struct clockdomain alwon_mpu_816x_clkdm = {
@@ -96,7 +104,7 @@ static struct clockdomain alwon_mpu_816x_clkdm = {
 static struct clockdomain active_gem_816x_clkdm = {
.name   = "active_gem_clkdm",
.pwrdm  = { .name = "active_pwrdm" },
-   .cm_inst= TI816X_CM_ACTIVE_MOD,
+   .cm_inst= TI81XX_CM_ACTIVE_MOD,
.clkdm_offs = TI816X_CM_ACTIVE_GEM_CLKDM,
.flags  = CLKDM_CAN_SWSUP,
 };
@@ -128,7 +136,7 @@ static struct clockdomain ivahd2_816x_clkdm = {
 static struct clockdomain sgx_816x_clkdm = {
.name   = "sgx_clkdm",
.pwrdm  = { .name = "sgx_pwrdm" },
-   .cm_inst= TI816X_CM_SGX_MOD,
+   .cm_inst= TI81XX_CM_SGX_MOD,
.clkdm_offs = TI816X_CM_SGX_CLKDM,
.flags  = CLKDM_CAN_SWSUP,
 };
@@ -136,7 +144,7 @@ static struct clockdomain sgx_816x_clkdm = {
 static struct clockdomain default_l3_med_816x_clkdm = {
.name   = "default_l3_med_clkdm",
.pwrdm  = { .name = "default_pwrdm" },
-   .cm_inst= TI816X_CM_DEFAULT_MOD,
+   .cm_inst= TI81XX_CM_DEFAULT_MOD,
.clkdm_offs = TI816X_CM_DEFAULT_L3_MED_CLKDM,
.flags  = CLKDM_CAN_SWSUP,
 };
@@ -144,7 +152,7 @@ static struct clockdomain default_l3_med_816x_clkdm = {
 static struct clockdomain default_ducati_816x_clkdm = {
.name   = "default_ducati_clkdm",
.pwrdm  = { .name = "default_pwrdm" },
-   .cm_inst= TI816X_CM_DEFAULT_MOD,
+   .cm_inst= TI81XX_CM_DEFAULT_MOD,
.clkdm_offs = TI816X_CM_DEFAULT_DUCATI_CLKDM,
.flags  = CLKDM_CAN_SWSUP,
 };
@@ -152,19 +160,11 @@ static struct clockdomain default_ducati_816x_clkdm = {
 static struct clockdomain default_pci_816x_clkdm = {
.name   = "default_pci_clkdm",
.pwrdm  = { .name = "default_pwrdm" },
-   .cm_inst= TI816X_CM_DEFAULT_MOD,
+   .cm_inst= TI81XX_CM_DEFAULT_MOD,
.clkdm_offs = TI816X_CM_DEFAULT_PCI_CLKDM,
.flags  = CLKDM_CAN_SWSUP,
 };
 
-static struct clockdomain default_l3_slow_816x_clkdm = {
-   .name   = "default_l3_slow_clkdm",
-   .pwrdm  = { .name = "default_pwrdm" },
-   .cm_inst= TI816X_CM_DEFAULT_MOD,
-   .clkdm_offs = TI816X_CM_DEFAULT_L3_SLOW_CLKDM,
-   .flags  = CLKDM_CAN_SWSUP,
-};
-
 static struct clockdomain *clockdomains_ti814x[] __initdata = {
_l3_slow_81xx_clkdm,
_l3_med_81xx_clkdm,
@@ -172,6 +172,7 @@ static struct clockdomain *clockdomains_ti814x[] __initdata 
= {
_ethernet_81xx_clkdm,
_81xx_clkdm,
_cfg_81xx_clkdm,
+   _l3_slow_81xx_clkdm,
NULL,
 };
 
@@ -198,7 +199,7 @@ static struct clockdomain *clockdomains_ti816x[] __initdata 
= {
_l3_med_816x_clkdm,
_ducati_816x_clkdm,
_pci_816x_clkdm,
-   _l3_slow_816x_clkdm,
+   _l3_slow_81xx_clkdm,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/cm81xx.h b/arch/arm/mach-omap2/cm81xx.h
index 45cb407..3a0ccf0 100644
--- a/arch/arm/mach-omap2/cm81xx.h
+++ b/arch/arm/mach-omap2/cm81xx.h
@@ -18,15 +18,15 @@
 #define __ARCH_ARM_MACH_OMAP2_CM_TI81XX_H
 
 /* TI81XX common CM module offsets */
+#define TI81XX_CM_ACTIVE_MOD   0x0400  /* 256B */
+#define TI81XX_CM_DEFAULT_MOD  0x0500  /* 256B */
 #define TI81XX_CM_ALWON_MOD0x1400  /* 1KB */
+#define TI81XX_CM_SGX_MOD  0x0900  /* 256B */
 
 /* TI816X CM module offsets */
-#define TI816X_CM_ACTIVE_MOD   0x0400  /* 256B */
-#define TI816X_CM_DEFAULT_MOD   

[PATCH 0/6] Add usb support for dm814x and dra62x

[Tony Lindgren]

Hi,

These patches add usb support for dm814x and dra62x. These patches depend
on what's listed at the mmc patches at:

http://marc.info/?l=linux-omap=144919234321418=2

Regards,

Tony


Tony Lindgren (6):
  ARM: OMAP2+: Update 81xx clock and power domains for default, active
and sgx
  ARM: OMAP2+: Add support for dm814x and dra62x usb
  ARM: dts: Add usb support for dm814x and dra62x
  ARM: dts: Add usb support for dm814x-evm
  ARM: dts: Add usb support for hp t410
  ARM: dts: Add usb support for j5-eco evm

 arch/arm/boot/dts/dm8148-evm.dts|  24 ++
 arch/arm/boot/dts/dm8148-t410.dts   |  35 
 arch/arm/boot/dts/dm814x.dtsi   | 125 
 arch/arm/boot/dts/dra62x-j5eco-evm.dts  |  21 +
 arch/arm/mach-omap2/clockdomains81xx_data.c |  29 +++
 arch/arm/mach-omap2/cm81xx.h|   6 +-
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  38 +++--
 arch/arm/mach-omap2/powerdomains3xxx_data.c |  10 ++-
 8 files changed, 258 insertions(+), 30 deletions(-)

-- 
2.6.2

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

[PATCH 2/6] ARM: OMAP2+: Add support for dm814x and dra62x usb

[Tony Lindgren]

The usb phys are different on dm814x compared to dm816x so we need to
use the clkdcoldo output for usb.

Cc: Paul Walmsley 
Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 38 +++---
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 6ee5ba5..7118755 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -104,8 +104,8 @@
  * The default .clkctrl_offs field is offset from CM_DEFAULT, that's
  * TRM 18.7.6 CM_DEFAULT device register values minus 0x500
  */
-#define DM816X_CM_DEFAULT_OFFSET   0x500
-#define DM816X_CM_DEFAULT_USB_CLKCTRL  (0x558 - DM816X_CM_DEFAULT_OFFSET)
+#define DM81XX_CM_DEFAULT_OFFSET   0x500
+#define DM81XX_CM_DEFAULT_USB_CLKCTRL  (0x558 - DM81XX_CM_DEFAULT_OFFSET)
 
 /* L3 Interconnect entries clocked at 125, 250 and 500MHz */
 static struct omap_hwmod dm81xx_alwon_l3_slow_hwmod = {
@@ -557,22 +557,42 @@ static struct omap_hwmod_class dm81xx_usbotg_class = {
.sysc = _usbhsotg_sysc,
 };
 
-static struct omap_hwmod dm81xx_usbss_hwmod = {
+static struct omap_hwmod dm814x_usbss_hwmod = {
+   .name   = "usb_otg_hs",
+   .clkdm_name = "default_l3_slow_clkdm",
+   .main_clk   = "481c5260.adpll.clkdcoldo",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM81XX_CM_DEFAULT_USB_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+   .class  = _usbotg_class,
+};
+
+static struct omap_hwmod_ocp_if dm814x_default_l3_slow__usbss = {
+   .master = _default_l3_slow_hwmod,
+   .slave  = _usbss_hwmod,
+   .clk= "sysclk6_ck",
+   .user   = OCP_USER_MPU,
+};
+
+static struct omap_hwmod dm816x_usbss_hwmod = {
.name   = "usb_otg_hs",
.clkdm_name = "default_l3_slow_clkdm",
.main_clk   = "sysclk6_ck",
.prcm   = {
.omap4 = {
-   .clkctrl_offs = DM816X_CM_DEFAULT_USB_CLKCTRL,
+   .clkctrl_offs = DM81XX_CM_DEFAULT_USB_CLKCTRL,
.modulemode = MODULEMODE_SWCTRL,
},
},
.class  = _usbotg_class,
 };
 
-static struct omap_hwmod_ocp_if dm81xx_default_l3_slow__usbss = {
+static struct omap_hwmod_ocp_if dm816x_default_l3_slow__usbss = {
.master = _default_l3_slow_hwmod,
-   .slave  = _usbss_hwmod,
+   .slave  = _usbss_hwmod,
.clk= "sysclk6_ck",
.user   = OCP_USER_MPU,
 };
@@ -1301,8 +1321,6 @@ static struct omap_hwmod_ocp_if 
dm81xx_tptc3__alwon_l3_fast = {
 /*
  * REVISIT: Test and enable the following once clocks work:
  * dm81xx_l4_ls__mailbox
- * dm81xx_alwon_l3_slow__gpmc
- * dm81xx_default_l3_slow__usbss
  *
  * Also note that some devices share a single clkctrl_offs..
  * For example, i2c1 and 3 share one, and i2c2 and 4 share one.
@@ -1337,6 +1355,8 @@ static struct omap_hwmod_ocp_if *dm814x_hwmod_ocp_ifs[] 
__initdata = {
_l4_ls__timer2,
_l4_hs__cpgmac0,
_cpgmac0__mdio,
+   _alwon_l3_slow__gpmc,
+   _default_l3_slow__usbss,
_alwon_l3_med__mmc3,
NULL,
 };
@@ -1384,7 +1404,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] 
__initdata = {
_tptc2__alwon_l3_fast,
_tptc3__alwon_l3_fast,
_alwon_l3_slow__gpmc,
-   _default_l3_slow__usbss,
+   _default_l3_slow__usbss,
NULL,
 };
 
-- 
2.6.2

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

[PATCH 4/6] ARM: dts: Add usb support for dm814x-evm

[Tony Lindgren]

Add usb support for dm814x-evm

Cc: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm8148-evm.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dm8148-evm.dts b/arch/arm/boot/dts/dm8148-evm.dts
index 08d01c3..e070862 100644
--- a/arch/arm/boot/dts/dm8148-evm.dts
+++ b/arch/arm/boot/dts/dm8148-evm.dts
@@ -56,4 +56,28 @@
DM814X_IOPAD(0x093C, PIN_INPUT_PULLUP |  0x80)  /* 
GP1[6] */
>;
};
+
+   usb0_pins: pinmux_usb0_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0c34, PIN_OUTPUT | 0x1)  /* USB0_DRVVBUS 
*/
+   >;
+   };
+
+   usb1_pins: pinmux_usb1_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0834, PIN_OUTPUT | 0x80) /* USB1_DRVVBUS 
*/
+   >;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dr_mode = "host";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dr_mode = "host";
 };
-- 
2.6.2

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

[PATCH 5/6] ARM: dts: Add usb support for hp t410

[Tony Lindgren]

Add usb support for hp t410 and a fixed regulator for the hub power.

Cc: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dm8148-t410.dts | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/dm8148-t410.dts 
b/arch/arm/boot/dts/dm8148-t410.dts
index d1927a7..5d4313f 100644
--- a/arch/arm/boot/dts/dm8148-t410.dts
+++ b/arch/arm/boot/dts/dm8148-t410.dts
@@ -16,6 +16,17 @@
reg = <0x8000 0x4000>;  /* 1 GB */
};
 
+   /* gpio9 seems to control USB VBUS regulator and/or hub power */
+   usb_power: regulator@9 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_power";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-always-on;
+   };
+
vmmcsd_fixed: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "vmmcsd_fixed";
@@ -60,4 +71,28 @@
DM814X_IOPAD(0x0920, PIN_INPUT | 40)/* SD2_SDCD */
>;
};
+
+   usb0_pins: pinmux_usb0_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0c34, PIN_OUTPUT | 0x1)  /* USB0_DRVVBUS 
*/
+   >;
+   };
+
+   usb1_pins: pinmux_usb1_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0834, PIN_OUTPUT | 0x80) /* USB1_DRVVBUS 
*/
+   >;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dr_mode = "host";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dr_mode = "host";
 };
-- 
2.6.2

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

[PATCH 6/6] ARM: dts: Add usb support for j5-eco evm

[Tony Lindgren]

Add usb support for j5-eco evm.

Cc: Felipe Balbi 
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra62x-j5eco-evm.dts | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/dra62x-j5eco-evm.dts 
b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
index 97ac839..7900806 100644
--- a/arch/arm/boot/dts/dra62x-j5eco-evm.dts
+++ b/arch/arm/boot/dts/dra62x-j5eco-evm.dts
@@ -56,4 +56,25 @@
DM814X_IOPAD(0x093C, PIN_INPUT_PULLUP |  0x80)  /* 
GP1[6] */
>;
};
+
+   usb0_pins: pinmux_usb0_pins {
+   pinctrl-single,pins = <
+   DM814X_IOPAD(0x0c34, PIN_OUTPUT | 0x1)  /* USB0_DRVVBUS 
*/
+   >;
+   };
+};
+
+/* USB0_ID pin state: SW10[1] = 0 cable detection, SW10[1] = 1 ID grounded */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   dr_mode = "otg";
+};
+
+_phy {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
 };
-- 
2.6.2

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

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

* Arnd Bergmann  [151204 13:38]:
> On Friday 04 December 2015 10:47:07 Tony Lindgren wrote:
> > > Peter Ujfalusi  writes:
> > > > @@ -174,12 +182,44 @@
> > > > };
> > > >  
> > > > edma: edma@4900 {
> > > > -   compatible = "ti,edma3";
> > > > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > > > -   reg =   <0x4900 0x1>,
> > > > -   <0x44e10f90 0x40>;
> > > > +   compatible = "ti,edma3-tpcc";
> > > > +   ti,hwmods = "tpcc";
> > > > +   reg =   <0x4900 0x1>;
> > > > +   reg-names = "edma3_cc";
> > > > interrupts = <12 13 14>;
> > > > -   #dma-cells = <1>;
> > > > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > > > + "edma3_ccerrint";
> > > > +   dma-requests = <64>;
> > > > +   #dma-cells = <2>;
> > > > +
> > > > +   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> > > > +  <_tptc2 0>;
> > > > +
> > > > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> > > 
> > > can you explain this property here ? Are you setting bits 20 and 21 on a
> > > 16-bit field ?
> > 
> > I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
> > instead of /bits/ 16?
> > 
> 
> Please just drop the /bits/ 16 and use normal cells.

Yeah agreed, makes things less confusing for sure :)

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] PCI: dra7xx: mark dra7xx_pcie_msi irq as IRQF_NO_THREAD

[Bjorn Helgaas]

Hi Grygorii,

On Fri, Nov 20, 2015 at 03:59:26PM +0200, Grygorii Strashko wrote:
> On -RT, TI DRA7 PCIe driver always produces below backtrace when the
> first PCI interrupt is triggered:
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 
> handle_irq_event_percpu+0x14c/0x174()
> irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
> Modules linked in: ahci_platform(+) ti_vip(+) libahci_platform xhci_pci(+) 
> c_can_platform(+)
> libahci xhci_hcd ti_vpe c_can libata v4l2_mem2mem can_dev gpio_keys leds_gpio
> snd_soc_simple_card usbcore spi_ti_qspi videobuf2_core extcon_usb_gpio 
> omap_wdt
> ti_vpdma videobuf2_dma_contig ti_soc_thermal videobuf2_memops dwc3_omap extcon
> rtc_omap ov1063x v4l2_common videodev media snd_soc_tlv320aic3x omap_rng 
> rng_core omap_remoteproc
> CPU: 1 PID: 82 Comm: irq/26-dra7-pci Not tainted 
> 4.1.10-rt10-02638-g6486d7e-dirty #1
> Hardware name: Generic DRA74X (Flattened Device Tree)
> Backtrace:
> [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
>  r7:c07acca0 r6: r5:c09034e4 r4:
> [] (show_stack) from [] (dump_stack+0x90/0xac)
> [] (dump_stack) from [] (warn_slowpath_common+0x7c/0xb8)
>  r7:c07acca0 r6:0096 r5:0009 r4:ee4d3e38
> [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x38/0x40)
>  r8:ee3fcc00 r7:01cc r6: r5:0002 r4:c07acc78
> [] (warn_slowpath_fmt) from [] 
> (handle_irq_event_percpu+0x14c/0x174)
>  r3:01cc r2:c07acc78
>  r4:ecfcdd80
> [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x84/0xb8)
>  r10:0001 r9:ee4b59c0 r8:ee1d0900 r7:0001 r6: r5:ecfcdd80
>  r4:ee3fcc00
> [] (handle_irq_event) from [] 
> (handle_simple_irq+0x90/0x118)
>  r5:ee4a9020 r4:ee3fcc00
> [] (handle_simple_irq) from [] 
> (generic_handle_irq+0x30/0x44)
>  r5:ee4a9020 r4:01cc
> [] (generic_handle_irq) from [] 
> (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
>  r5:ee4a9020 r4:0001
> [] (dra7xx_pcie_msi_irq_handler) from [] 
> (irq_forced_thread_fn+0x28/0x5c)
>  r5:ee1d0900 r4:ee4b59c0
> [] (irq_forced_thread_fn) from [] (irq_thread+0x128/0x204)
>  r7:0001 r6: r5:ee4d2000 r4:ee4b59e4
> [] (irq_thread) from [] (kthread+0xd4/0xec)
>  r10: r9: r8: r7:c00870b4 r6:ee4b59c0 r5:ee4b5a00
>  r4:
> [] (kthread) from [] (ret_from_fork+0x14/0x2c)
>  r7: r6: r5:c005e228 r4:ee4b5a00
> ---[ end trace 0002 ]---

The backtrace might be OK (maybe slightly overkill), but all the
stack addresses are certainly irrelevant and distracting.  We only
need enough to recognize the problem.  I don't think the modules list
is relevant either.

> This backtrace is triggered because dra7xx_pcie_msi_irq_handler()
> forced to be threaded by default on -RT but, in the same time, it's
> IRQ dispatcher and calls generic_handle_irq(), which leads to
> handle_simple_irq() call. The handle_simple_irq() expected to be
> called with IRQ disabled.
> 
> The same issue will also happen if kernel will boot with "threadirqs"
> cmdline parameter (CONFIG_IRQ_FORCED_THREADING).
> 
> As discussed in [1], the current DRA7 PCIe hw configuration supports
> 32 interrupts, which cannot change because it's hardwired in silicon,
> this is a single status read and assuming that only a few (most of the
> time it will be exactly ONE) of those interrupts are pending at the
> same time is pretty much a sane assumption. And recommended fix for
> this issue is to request dra7xx_pcie_msi IRQ with IRQF_NO_THREAD flag.
> 
> [1] https://lkml.org/lkml/2015/11/3/660
> 
> Cc: Thomas Gleixner 
> Cc: Sebastian Andrzej Siewior 
> Signed-off-by: Grygorii Strashko 
> ---
> Changes in v2:
> - comment in code truncated
> Link on v1:
>  https://lkml.org/lkml/2015/11/5/593
>  drivers/pci/host/pci-dra7xx.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 8c36880..0415192 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct 
> dra7xx_pcie *dra7xx,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
> +  * On -RT and if kernel is booting with "threadirqs" cmd line parameter
> +  * the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
> +  * in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
> +  * which, in turn, will be resolved to handle_simple_irq() call.
> +  * The handle_simple_irq() expected to be called with IRQ disabled, as
> +  * result kernle will display warning:
> +  * "irq XXX handler YYY+0x0/0x14 enabled interrupts".
> +  */
>   ret = devm_request_irq(>dev, pp->irq,
> -dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
> +  

Re: [PATCH] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3

[Tony Lindgren]

* Felipe Balbi  [151204 09:23]:
> 
> Hi,
> 
> Peter Ujfalusi  writes:
> > @@ -174,12 +182,44 @@
> > };
> >  
> > edma: edma@4900 {
> > -   compatible = "ti,edma3";
> > -   ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> > -   reg =   <0x4900 0x1>,
> > -   <0x44e10f90 0x40>;
> > +   compatible = "ti,edma3-tpcc";
> > +   ti,hwmods = "tpcc";
> > +   reg =   <0x4900 0x1>;
> > +   reg-names = "edma3_cc";
> > interrupts = <12 13 14>;
> > -   #dma-cells = <1>;
> > +   interrupt-names = "edma3_ccint", "emda3_mperr",
> > + "edma3_ccerrint";
> > +   dma-requests = <64>;
> > +   #dma-cells = <2>;
> > +
> > +   ti,tptcs = <_tptc0 7>, <_tptc1 5>,
> > +  <_tptc2 0>;
> > +
> > +   ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> 
> can you explain this property here ? Are you setting bits 20 and 21 on a
> 16-bit field ?

I think it's an arry of u16 dma channels.. But could it be just /bits/ 8
instead of /bits/ 16?

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