On 2/8/21 4:30 PM, Florian Fainelli wrote:
> Update the documentation regarding "nohlt" and indicate that it is not
> only for bugs, but can be useful to disable the architecture specific
> sleep instructions. ARM, ARM64, SuperH and Microblaze all use
> CONFIG_GENERIC_IDLE_POLL_SETUP which takes care of honoring the
> "hlt"/"nohlt" parameters.
> 
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index a10b545c2070..83c37e23e1e2 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3266,9 +3266,14 @@
>                       parameter, xsave area per process might occupy more
>                       memory on xsaves enabled systems.
>  
> -     nohlt           [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
> -                     wfi(ARM) instruction doesn't work correctly and not to
> -                     use it. This is also useful when using JTAG debugger.
> +     nohlt           [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait
> +                     in do_idle() and not use the arch_cpu_idle()
> +                     implementation, requires CONFIG_GENERIC_IDLE_POLL_SETUP

Sounds good... but above, I would prefer s/,/;/

> +                     to be effective. This is useful on platforms where the
> +                     sleep(SH) or wfi(ARM,ARM64) instructions do not work
> +                     correctly or when doing power measurements to evalute
> +                     the impact of the sleep instructions. This is also
> +                     useful when using JTAG debugger.
>  
>       no_file_caps    Tells the kernel not to honor file capabilities.  The
>                       only way then for a file to be executed with privilege
> 

Acked-by: Randy Dunlap <[email protected]>

thanks.

-- 
~Randy

Reply via email to