Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread Tony Lindgren
* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:
 On 21/01/15 16:30, Tony Lindgren wrote:
 
  I gave this a quick boot test on am437x-gp-evm and the
  interrupts look OK with the fix also applied:
  
  # cat /proc/interrupts 
  CPU0   
   16:657 WUGEN  68  gp_timer
   18:  0 WUGEN   9  l3-dbg-irq
   19:  0 WUGEN  10  l3-app-irq
   20:  5 WUGEN  12  edma
   22:  0 WUGEN  14  edma_error
   23: 96 WUGEN  72  OMAP UART0
   33:  0  44e07000.gpio   6  mmc0
  158: 52 WUGEN  70  44e0b000.i2c
  159:  0 WUGEN  71  4802a000.i2c
  160: 35 WUGEN  64  mmc0
  161:  0 WUGEN  40  4a10.ethernet
  162:   7739 WUGEN  41  4a10.ethernet
  163:   7608 WUGEN  42  4a10.ethernet
  164:  0 WUGEN  43  4a10.ethernet
  170:  0 WUGEN 100  gpmc
  180:  0 WUGEN   7  tps65218
  IPI0:  0  CPU wakeup interrupts
  IPI1:  0  Timer broadcast interrupts
  IPI2:  0  Rescheduling interrupts
  IPI3:  0  Function call interrupts
  IPI4:  0  Single function call interrupts
  IPI5:  0  CPU stop interrupts
  IPI6:  0  IRQ work interrupts
  IPI7:  0  completion interrupts
  Err:  0
 
 Interesting. No TWD timer on this one?

Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:

# cat /proc/interrupts 
CPU0   
 16:  0 WUGEN  67  gp_timer
 17:529   GIC  29  twd
 18:  0 WUGEN   9  l3-dbg-irq
 19:  0 WUGEN  10  l3-app-irq
 20:  5 WUGEN  12  edma
 22:  0 WUGEN  14  edma_error
 23:130 WUGEN  72  OMAP UART0
 34:  0  44e07000.gpio   6  mmc0
159: 52 WUGEN  70  44e0b000.i2c
160:  0 WUGEN  71  4802a000.i2c
161: 35 WUGEN  64  mmc0
162:  0 WUGEN  40  4a10.ethernet
163:   8033 WUGEN  41  4a10.ethernet
164:   7769 WUGEN  42  4a10.ethernet
165:  0 WUGEN  43  4a10.ethernet
171:  0 WUGEN 100  gpmc
181:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0

Hmm I wonder why we have the !is_smp() check in the TWD timer?

Regards,

Tony

8 ---
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
interrupt-parent = gic;
};
 
+   local-timer@48240600 {
+   compatible = arm,cortex-a9-twd-timer;
+   clocks = dpll_mpu_m2_ck;
+   reg = 0x48240600 0x20;
+   interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) | 
IRQ_TYPE_LEVEL_HIGH);
+   interrupt-parent = gic;
+   };
+
wakeupgen: interrupt-controller@48281000 {
compatible = ti,omap4-wugen-mpu;
interrupt-controller;
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -388,7 +388,7 @@ static void __init twd_local_timer_of_register(struct 
device_node *np)
 {
int err;
 
-   if (!is_smp() || !setup_max_cpus)
+   if (!setup_max_cpus)
return;
 
twd_ppi = irq_of_parse_and_map(np, 0);
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -237,7 +237,7 @@ DT_MACHINE_START(AM43_DT, Generic AM43 (Flattened Device 
Tree))
.init_late  = am43xx_init_late,
.init_irq   = omap_gic_of_init,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_gptimer_timer_init,
+   .init_time  = omap4_local_timer_init,
.dt_compat  = am43_boards_compat,
.restart= omap44xx_restart,
 MACHINE_END
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread Marc Zyngier
On 21/01/15 16:30, Tony Lindgren wrote:
 * Marc Zyngier marc.zyng...@arm.com [150119 01:48]:
 OMAP4/5 has been (ab)using the gic_arch_extn to provide
 wakeup from suspend, and it makes a lot of sense to convert
 this code to use stacked domains instead.

 This patch does just this, updating the DT files to actually
 reflect what the HW provides.

 BIG FAT WARNING: because the DTs were so far lying by not
 exposing the WUGEN HW block, kernels with this patch applied
 won't have any suspend-resume facility when booted with old DTs,
 and old kernels with updated DTs won't even boot.

 On a platform with this patch applied, the system looks like
 this:

 root@bacon-fat:~# cat /proc/interrupts
 CPU0   CPU1
  16:  0  0 WUGEN  37  gp_timer
  19: 233799 155916   GIC  27  arch_timer
  23:  0  0 WUGEN   9  l3-dbg-irq
  24:  1  0 WUGEN  10  l3-app-irq
  27:282  0 WUGEN  13  omap-dma-engine
  44:  0  0  4ae1.gpio  13  DMA
 
 You may want to update this part for the fix :)

Ah, yes. Thanks for noticing this.

 I gave this a quick boot test on am437x-gp-evm and the
 interrupts look OK with the fix also applied:
 
 # cat /proc/interrupts 
 CPU0   
  16:657 WUGEN  68  gp_timer
  18:  0 WUGEN   9  l3-dbg-irq
  19:  0 WUGEN  10  l3-app-irq
  20:  5 WUGEN  12  edma
  22:  0 WUGEN  14  edma_error
  23: 96 WUGEN  72  OMAP UART0
  33:  0  44e07000.gpio   6  mmc0
 158: 52 WUGEN  70  44e0b000.i2c
 159:  0 WUGEN  71  4802a000.i2c
 160: 35 WUGEN  64  mmc0
 161:  0 WUGEN  40  4a10.ethernet
 162:   7739 WUGEN  41  4a10.ethernet
 163:   7608 WUGEN  42  4a10.ethernet
 164:  0 WUGEN  43  4a10.ethernet
 170:  0 WUGEN 100  gpmc
 180:  0 WUGEN   7  tps65218
 IPI0:  0  CPU wakeup interrupts
 IPI1:  0  Timer broadcast interrupts
 IPI2:  0  Rescheduling interrupts
 IPI3:  0  Function call interrupts
 IPI4:  0  Single function call interrupts
 IPI5:  0  CPU stop interrupts
 IPI6:  0  IRQ work interrupts
 IPI7:  0  completion interrupts
 Err:  0

Interesting. No TWD timer on this one?

 Also verified that suspend and resume to a serial console event
 works on omap4430-sdp. So please feel free to add:
 
 Acked-by: Tony Lindgren t...@atomide.com

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: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread santosh shilimkar

On 1/21/2015 10:36 AM, Tony Lindgren wrote:

* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:

On 21/01/15 16:30, Tony Lindgren wrote:


I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:

# cat /proc/interrupts
 CPU0
  16:657 WUGEN  68  gp_timer
  18:  0 WUGEN   9  l3-dbg-irq
  19:  0 WUGEN  10  l3-app-irq
  20:  5 WUGEN  12  edma
  22:  0 WUGEN  14  edma_error
  23: 96 WUGEN  72  OMAP UART0
  33:  0  44e07000.gpio   6  mmc0
158: 52 WUGEN  70  44e0b000.i2c
159:  0 WUGEN  71  4802a000.i2c
160: 35 WUGEN  64  mmc0
161:  0 WUGEN  40  4a10.ethernet
162:   7739 WUGEN  41  4a10.ethernet
163:   7608 WUGEN  42  4a10.ethernet
164:  0 WUGEN  43  4a10.ethernet
170:  0 WUGEN 100  gpmc
180:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0


Interesting. No TWD timer on this one?


Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:


TWD is useless on this machine since single core and TWD
as know die in low power states. All the broadcast stuff
is for SMP machines.

Above is expected and correct and no patching is needed.

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


Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread Tony Lindgren
* santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:
 On 1/21/2015 10:36 AM, Tony Lindgren wrote:
 * Marc Zyngier marc.zyng...@arm.com [150121 09:25]:
 On 21/01/15 16:30, Tony Lindgren wrote:
 
 I gave this a quick boot test on am437x-gp-evm and the
 interrupts look OK with the fix also applied:
 
 # cat /proc/interrupts
  CPU0
   16:657 WUGEN  68  gp_timer
   18:  0 WUGEN   9  l3-dbg-irq
   19:  0 WUGEN  10  l3-app-irq
   20:  5 WUGEN  12  edma
   22:  0 WUGEN  14  edma_error
   23: 96 WUGEN  72  OMAP UART0
   33:  0  44e07000.gpio   6  mmc0
 158: 52 WUGEN  70  44e0b000.i2c
 159:  0 WUGEN  71  4802a000.i2c
 160: 35 WUGEN  64  mmc0
 161:  0 WUGEN  40  4a10.ethernet
 162:   7739 WUGEN  41  4a10.ethernet
 163:   7608 WUGEN  42  4a10.ethernet
 164:  0 WUGEN  43  4a10.ethernet
 170:  0 WUGEN 100  gpmc
 180:  0 WUGEN   7  tps65218
 IPI0:  0  CPU wakeup interrupts
 IPI1:  0  Timer broadcast interrupts
 IPI2:  0  Rescheduling interrupts
 IPI3:  0  Function call interrupts
 IPI4:  0  Single function call interrupts
 IPI5:  0  CPU stop interrupts
 IPI6:  0  IRQ work interrupts
 IPI7:  0  completion interrupts
 Err:  0
 
 Interesting. No TWD timer on this one?
 
 Good question, adding Felipe to cc. It eems to be there in
 the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
 MPU_PRV_TIMERS. Also seems to actually work with the
 attached patch:
 
 TWD is useless on this machine since single core and TWD
 as know die in low power states. All the broadcast stuff
 is for SMP machines.

Hmm it seems we should still use TWD during runtime and
swich over to the gptimer for idle states for wake-up
events.

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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread santosh shilimkar

On 1/21/2015 12:43 PM, Tony Lindgren wrote:

* santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:

On 1/21/2015 10:36 AM, Tony Lindgren wrote:

* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:

On 21/01/15 16:30, Tony Lindgren wrote:


I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:

# cat /proc/interrupts
 CPU0
  16:657 WUGEN  68  gp_timer
  18:  0 WUGEN   9  l3-dbg-irq
  19:  0 WUGEN  10  l3-app-irq
  20:  5 WUGEN  12  edma
  22:  0 WUGEN  14  edma_error
  23: 96 WUGEN  72  OMAP UART0
  33:  0  44e07000.gpio   6  mmc0
158: 52 WUGEN  70  44e0b000.i2c
159:  0 WUGEN  71  4802a000.i2c
160: 35 WUGEN  64  mmc0
161:  0 WUGEN  40  4a10.ethernet
162:   7739 WUGEN  41  4a10.ethernet
163:   7608 WUGEN  42  4a10.ethernet
164:  0 WUGEN  43  4a10.ethernet
170:  0 WUGEN 100  gpmc
180:  0 WUGEN   7  tps65218
IPI0:  0  CPU wakeup interrupts
IPI1:  0  Timer broadcast interrupts
IPI2:  0  Rescheduling interrupts
IPI3:  0  Function call interrupts
IPI4:  0  Single function call interrupts
IPI5:  0  CPU stop interrupts
IPI6:  0  IRQ work interrupts
IPI7:  0  completion interrupts
Err:  0


Interesting. No TWD timer on this one?


Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3.  L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:


TWD is useless on this machine since single core and TWD
as know die in low power states. All the broadcast stuff
is for SMP machines.


Hmm it seems we should still use TWD during runtime and
swich over to the gptimer for idle states for wake-up
events.


Well timer wheel code don't support it so if you are serious,
some one needs to do that. For me, it is not worth at all.
You will have more to loose than gain with these time switching
schemes since you have to keep 2 times alive, do switching, loose
the idle time.

All of that is to save few CPU cycles since TWD is closer
compared to other SOC timer.

Anyways I will let you fight it out but IIRC, I had a
discussion a while back with tglx in one of the conference
and the conclusion was it not worth doing.
Rather TWD hardware on SOC should be made wakeup capable
and then everything is good.

Till you have support, using TWD on AM43XX will break CPUIDLE.
Not sure if it is supported or some one cares about it. Just
keep that aspect in mind.

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


Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains

2015-01-21 Thread Tony Lindgren
* santosh shilimkar santosh.shilim...@oracle.com [150121 13:31]:
 On 1/21/2015 12:43 PM, Tony Lindgren wrote:
 * santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]:
 
 TWD is useless on this machine since single core and TWD
 as know die in low power states. All the broadcast stuff
 is for SMP machines.
 
 Hmm it seems we should still use TWD during runtime and
 swich over to the gptimer for idle states for wake-up
 events.
 
 Well timer wheel code don't support it so if you are serious,
 some one needs to do that. For me, it is not worth at all.
 You will have more to loose than gain with these time switching
 schemes since you have to keep 2 times alive, do switching, loose
 the idle time.
 
 All of that is to save few CPU cycles since TWD is closer
 compared to other SOC timer.
 
 Anyways I will let you fight it out but IIRC, I had a
 discussion a while back with tglx in one of the conference
 and the conclusion was it not worth doing.
 Rather TWD hardware on SOC should be made wakeup capable
 and then everything is good.
 
 Till you have support, using TWD on AM43XX will break CPUIDLE.
 Not sure if it is supported or some one cares about it. Just
 keep that aspect in mind.

Yes sure I'm aware of this. It should be easy to profile the
speed gain to see if it would make much of a difference
before starting to tinker with that.

The way I think it's possible to do would be to copy the TWD
timer value to a wake-up capable gptimer before hitting any
deeper idle state. Of course some aux timer support might be
still needed :)

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