Re: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer

2017-06-13 Thread Linus Walleij
On Mon, Jun 12, 2017 at 2:41 PM, Jonas Jensen wrote: > I stumbled upon boot time savings (going from next-20170518 to > next-20170609) which seem to shave off more than a second ([1] > compared to [2]) so I also booted without patches ([3]). > There seems to be improvement when these patches are

Re: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer

2017-06-12 Thread Andrew Jeffery
On Sun, 2017-06-11 at 23:26 +0200, Linus Walleij wrote: > This timer is often used on the ARM architecture, so as with so > many siblings, we can implement delay timers, removing the need > for the system to calibrate jiffys at boot, and potentially > handling CPU frequency scaling on targets. > >

Re: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer

2017-06-12 Thread Jonas Jensen
On 11 June 2017 at 23:26, Linus Walleij wrote: > Switching to timer-based delay loop, resolution 40n > Calibrating delay loop (skipped), value calculated using > timer frequency.. 50.00 BogoMIPS (lpj=25) Thanks for this, these work OK on UC-7112-LX. I stumbled upon boot time savings (going

Re: [PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer

2017-06-12 Thread Daniel Lezcano
On Sun, Jun 11, 2017 at 11:26:17PM +0200, Linus Walleij wrote: > This timer is often used on the ARM architecture, so as with so > many siblings, we can implement delay timers, removing the need > for the system to calibrate jiffys at boot, and potentially > handling CPU frequency scaling on target

[PATCH 2/2] drivers/clocksource/fttmr010: Implement delay timer

2017-06-11 Thread Linus Walleij
This timer is often used on the ARM architecture, so as with so many siblings, we can implement delay timers, removing the need for the system to calibrate jiffys at boot, and potentially handling CPU frequency scaling on targets. We cannot just protect the Kconfig with a "depends on ARM" because