From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753015AbdLEP0d (ORCPT ); Tue, 5 Dec 2017 10:26:33 -0500 Received: from mail-oi0-f68.google.com ([209.85.218.68]:35290 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751416AbdLEP0a (ORCPT ); Tue, 5 Dec 2017 10:26:30 -0500 X-Google-Smtp-Source: AGs4zMZgJIaiPNv4jVk5aTB8O5Au0eexSHSy/K1Keoe0HoVbinqyHvmoRErfiL694f6aM96t22L39Dx/JOHU2QcC6WM= MIME-Version: 1.0 In-Reply-To: References: From: "Rafael J. Wysocki" Date: Tue, 5 Dec 2017 16:26:29 +0100 X-Google-Sender-Auth: 1n8llhLz_BaHlX3XhDQHa-ogOq8 Message-ID: Subject: Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms To: Meelis Roos Cc: Viresh Kumar , Rafael Wysocki , Linux PM , Vincent Guittot , "4 . 14+" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 5, 2017 at 9:54 AM, Meelis Roos wrote: >> > The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay >> > value to 10 ms") caused a regression on EPIA-M min-ITX computer where >> > shutdown or reboot hangs occasionally with a print message like: >> > >> > longhaul: Warning: Timeout while waiting for idle PCI bus >> > cpufreq: __target_index: Failed to change cpu frequency: -16 >> > >> > This probably happens because the cpufreq governor tries to change the >> > frequency of the CPU faster than allowed by the hardware. >> > >> > With the above commit, the default transition delay comes to 10 ms for a >> > transition_latency of 200 us. Set the default transition delay to 20 ms >> > directly to fix this regression. >> > >> > Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms") >> > Cc: 4.14+ # 4.14+ >> > Reported-by: Meelis Roos >> > Suggested-by: Rafael J. Wysocki >> > Signed-off-by: Viresh Kumar >> > --- >> > drivers/cpufreq/longhaul.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c >> > index c46a12df40dd..56eafcb07859 100644 >> > --- a/drivers/cpufreq/longhaul.c >> > +++ b/drivers/cpufreq/longhaul.c >> > @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy) >> > if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0)) >> > longhaul_setup_voltagescaling(); >> > >> > - policy->cpuinfo.transition_latency = 200000; /* nsec */ >> > + policy->transition_delay_us = 20000; /* usec */ >> > >> > return cpufreq_table_validate_and_show(policy, longhaul_table); >> > } >> >> This patch also works on my EPIA-M board - tested 10+ times. > > An on the last try just after sending the mail, it hung again in the > same way as before - so maybe 20 is on the edge of being good. OK, so can you please try to modify the patch to set transition_delay_us to 30000, say, and see if that's reliable? Thanks, Rafael