From patchwork Thu Jun 13 16:09:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Kemnade X-Patchwork-Id: 10992981 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D77EE924 for ; Thu, 13 Jun 2019 16:46:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C702522BF1 for ; Thu, 13 Jun 2019 16:46:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B020626242; Thu, 13 Jun 2019 16:46:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 084FE22BF1 for ; Thu, 13 Jun 2019 16:46:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731950AbfFMQqv (ORCPT ); Thu, 13 Jun 2019 12:46:51 -0400 Received: from mail.andi.de1.cc ([85.214.239.24]:49434 "EHLO mail.andi.de1.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404168AbfFMQqt (ORCPT ); Thu, 13 Jun 2019 12:46:49 -0400 X-Greylist: delayed 1124 seconds by postgrey-1.27 at vger.kernel.org; Thu, 13 Jun 2019 12:46:47 EDT DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kemnade.info; s=20180802; h=Content-Type:MIME-Version:Message-ID:Subject:To :From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1I3y8nqcJVpxthG73yLJqt3fM1GjciDgS30mgpzyGos=; b=i+5hfE2B0oerl7ASbQfCQ9Ckpu NAD8hrilFOX0+AkKTEAiXKhYzkYZ+HYcfEJiwgdIIqSHP9KAY63nD2ajs05yT6mCfecjlZNDWg3vo VFiK/OsEtD8diKZTdcFaaRatrvKu3Gfzd1Q+S+jciRacE0tKZIWwSEWQYfcezjTCsOSY=; Received: from p5dcc3dfb.dip0.t-ipconnect.de ([93.204.61.251] helo=eeepc) by mail.andi.de1.cc with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hbSa2-0005j7-2T; Thu, 13 Jun 2019 18:28:02 +0200 Received: from [::1] (helo=localhost) by localhost with esmtp (Exim 4.89) (envelope-from ) id 1hbSIz-0002wp-Cw; Thu, 13 Jun 2019 18:10:25 +0200 Date: Thu, 13 Jun 2019 18:09:58 +0200 From: Andreas Kemnade To: Discussions about the Letux Kernel , linux-pm@vger.kernel.org, linux-omap@vger.kernel.org Subject: BUG: no cpufreq on gta04 (omap dm3730) in 5.2-rc4 Message-ID: <20190613180958.48e04530@kemnade.info> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; i686-pc-linux-gnu) MIME-Version: 1.0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On the gta04 (dm3730 cpu), cpufreq does not work properly with above-mentioned kernel. cpufreq-info just shows analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. dmesg log shows these interesting lines. [ 3.140655] core: _opp_supported_by_regulators: OPP minuV: 1012500 maxuV: 1012500, not supported by regulator [ 3.152709] cpu cpu0: _opp_add: OPP not supported by regulators (300000000) [ 3.160278] core: _opp_supported_by_regulators: OPP minuV: 1200000 maxuV: 1200000, not supported by regulator [ 3.171142] cpu cpu0: _opp_add: OPP not supported by regulators (600000000) [ 3.178710] core: _opp_supported_by_regulators: OPP minuV: 1325000 maxuV: 1325000, not supported by regulator [ 3.189483] cpu cpu0: _opp_add: OPP not supported by regulators (800000000) looking through logs shows that these lines first appeared in next-20190506. They were not present in next-20190503. If I understand that correcly it is about vdd1. Analysis reveals: in int regulator_is_supported_voltage(struct regulator *regulator, int min_uV, int max_uV) the following if fails: /* Any voltage within constrains range is fine? */ if (rdev->desc->continuous_voltage_range) { The following hack did the trick not sure whether it is correct, whether these things are continuous enough. If that all is ok, I will of course submit a formal patch. Regards Andreas diff --git a/drivers/regulator/twl-regulator.c b/drivers/regulator/twl-regulator.c index 6fa15b2d6fb3..f7bfdf53701d 100644 --- a/drivers/regulator/twl-regulator.c +++ b/drivers/regulator/twl-regulator.c @@ -478,6 +478,7 @@ static const struct twlreg_info TWL4030_INFO_##label = { \ .type = REGULATOR_VOLTAGE, \ .owner = THIS_MODULE, \ .enable_time = turnon_delay, \ + .continuous_voltage_range = true, \ .of_map_mode = twl4030reg_map_mode, \ }, \ }