| Message ID | 20150121183615.GS7718@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 1/21/2015 10:36 AM, Tony Lindgren wrote: > * Marc Zyngier <marc.zyngier@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 4a100000.ethernet >>> 162: 7739 WUGEN 41 4a100000.ethernet >>> 163: 7608 WUGEN 42 4a100000.ethernet >>> 164: 0 WUGEN 43 4a100000.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-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* santosh shilimkar <santosh.shilimkar@oracle.com> [150121 12:16]: > On 1/21/2015 10:36 AM, Tony Lindgren wrote: > >* Marc Zyngier <marc.zyngier@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 4a100000.ethernet > >>>162: 7739 WUGEN 41 4a100000.ethernet > >>>163: 7608 WUGEN 42 4a100000.ethernet > >>>164: 0 WUGEN 43 4a100000.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-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 1/21/2015 12:43 PM, Tony Lindgren wrote: > * santosh shilimkar <santosh.shilimkar@oracle.com> [150121 12:16]: >> On 1/21/2015 10:36 AM, Tony Lindgren wrote: >>> * Marc Zyngier <marc.zyngier@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 4a100000.ethernet >>>>> 162: 7739 WUGEN 41 4a100000.ethernet >>>>> 163: 7608 WUGEN 42 4a100000.ethernet >>>>> 164: 0 WUGEN 43 4a100000.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-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* santosh shilimkar <santosh.shilimkar@oracle.com> [150121 13:31]: > On 1/21/2015 12:43 PM, Tony Lindgren wrote: > >* santosh shilimkar <santosh.shilimkar@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-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- 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