ARM: shmobile: Use shmobile_init_delay() on r8a7791
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/03] ARM: shmobile: Use shmobile_init_delay() on r8a7791
Quoted 21 lines · Simon Horman
Quoted 12 lines · Laurent Pinchart
Hi Magnus,
Quoted 8 lines · On Monday 12 May 2014 08:25:08 Magnus Damm wrote:
ARM: shmobile: Use
shmobile_init_delay()on r8a7791[PATCH 01/03] ARM: shmobile: Use r8a7791 DT CPU Frequency in common case [PATCH 02/03] ARM: shmobile: Use r8a7791 DT CPU Frequency for Koelsch [PATCH 03/03] ARM: shmobile: Remove unused
r8a7791_init_early()Convert r8a7791 to rely on
shmobile_init_delay()instead of using a per-SoC delay setup function.Quoted 7 lines
I'm afraid this patch set causes a boot time and CPU load regression on Koelsch. With Simon's latest devel branch which has the patches applied, the kernel boot time (using
koelsch_defconfig) up to the point where the kernel tries to connect to the DHCP server is 17.898437s. The CPU load (as reported by top) on an idle system is then around 33%, spent in [kworker/0:1]. If I revert the patches the same time goes down to 1.921875s and the CPU load on an idle system is close to 0.
Quoted 5 lines
Thanks for checking this Laurent.
I have this and the (related to my eyes) r8a7740 changes in their own branch. For now I will leave it in next but refrain from sending a pull-request. I will drop it from next if the problem hasn't been resolved in time for rc6 (which seems likely).
Hi Laurent, Hi Magnus,
I have done some further investigation and I believe that the problem is that "clock-frequency" node values are in Hz while shmobile_setup_delay expects an argument in MHz.
I propose the following:
From: Simon Horman <[email protected]>
[PATCH] ARM: shmobile: Set clock frequency in HZ from OF nodes
shmobile_init_delay() looks for OF "clock-frequency" to determine the delay which is set by calling shmobile_setup_delay().
Unfortunately this seems to be incorrect in detail as "clock-frequency" node values are in HZ whereas the frequency argument to shmobile_setup_delay() is in MHz.
Provide a variant of shmobile_setup_delay() that accepts HZ to correct this problem.
arch/arm/mach-shmobile/timer.c +13 -10
@@ -23,21 +23,24 @@#include <linux/delay.h> #include <linux/of_address.h> -void __init shmobile_setup_delay (unsigned int max_cpu_core_mhz, -unsigned int mult,unsigned int div) +void __init shmobile_setup_delay_hz (unsigned int max_cpu_core_hz, +unsigned int mult,unsigned int div) {/* calculate a worst-case loops-per-jiffy value -* based on maximum cpu core mhz setting and the +* based on maximum cpu core hz setting and the * __delay() implementation in arch/arm/lib/delay.S * * this will result in a longer delay than expected * when the cpu core runs on lower frequencies. */ - -unsigned int value = (1000000 * mult) / (HZ * div); -if (!preset_lpj) - preset_lpj = max_cpu_core_mhz * value; + preset_lpj = max_cpu_core_hz * mult / (HZ * div); +} + +void __init shmobile_setup_delay (unsigned int max_cpu_core_mhz, +unsigned int mult,unsigned int div) +{ +shmobile_setup_delay_hz (max_cpu_core_mhz, mult *100000 , div); }void __init shmobile_init_delay (void )
@@ -58,12 +61,12 @@ void __init shmobile_init_delay(void)if (max_freq) {if (of_find_compatible_node (NULL ,NULL ,"arm,cortex-a8" )) -shmobile_setup_delay (max_freq,1 ,3 ); +shmobile_setup_delay_hz (max_freq,1 ,3 );else if (of_find_compatible_node (NULL ,NULL ,"arm,cortex-a9" )) -shmobile_setup_delay (max_freq,1 ,3 ); +shmobile_setup_delay_hz (max_freq,1 ,3 );else if (of_find_compatible_node (NULL ,NULL ,"arm,cortex-a15" ))if (!IS_ENABLED (CONFIG_ARM_ARCH_TIMER )) -shmobile_setup_delay (max_freq,2 ,4 ); +shmobile_setup_delay_hz (max_freq,2 ,4 ); } }