Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4264894ybz; Tue, 28 Apr 2020 08:24:40 -0700 (PDT) X-Google-Smtp-Source: APiQypLtv49JwYdh1pvtrU34rc+ABK9jUfIpp0cE2fWsFL34lHWyC6hL9mYHs24I6yl3t2hpMiUo X-Received: by 2002:a05:6402:48a:: with SMTP id k10mr21939954edv.98.1588087480121; Tue, 28 Apr 2020 08:24:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588087480; cv=none; d=google.com; s=arc-20160816; b=XFmnl9f/b0t1P6911QdN73rODqR6xj+8oYZxmY01LCPko+1G1hEYLzZmYhRHl3tL3/ cnYXlmmCbduqp4y6L3Zlio7BFhP3Mb3KY4vk6Di8CEZO5b7BWkMVQluqBqf1GIduOY4I WrTIExamLK8ZjxXiYwVnsC7a/EC87CAAvnkIIcDnBVJew21dUuRMZStsSn7LJibq5RIW jURz9dhYHfKYPmGshQf9MA/5ocM1CvHAArBAG3BVCmtDv3IRaNYDZqdUC9Bnh0tJjQcV I9dE51Jxlzm7t6hTXcpWs/yECT9yxcTtCpbJDmMLA3oLjSjhKvmnKDNezzcc7AkFoDNA g8sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=nkwrb47Ony0w7N4RuRJxFo+qWTDzftw/4WxjJIvWe1M=; b=ewLEz2kzufKvBYJi0vkFm/EYqJaDnnTgyOD2Fd2SqzmQ2QHB50cZ95iL3wJHDUmuAY I43Rsku/6XZXk4zG+i2QNATgkFqymdVW3/K5IDdVvPW3GDPCCHJ1pBDE0ovrkObFe0fG UaRzT7lXIJCFTaz/0dgMkVTd6Hye8J2Xaav+T74j4GqSKMoikutX4BHc4zRcnJeeImce /pNSsxUD7PIZKJFysNh181PUs3CiDalBzOu0V8DuF//dBqRA1VyCMvAFgxwtTYFnTVaG 4pUQ8KN1zuLeEQDMYCkNxEh32QGPOKftUxHPjoCgw/1JKJJDXmjgBuhyzF2Oq5JttsEa tJfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw24si1973976edb.248.2020.04.28.08.24.16; Tue, 28 Apr 2020 08:24:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728365AbgD1PVi (ORCPT + 99 others); Tue, 28 Apr 2020 11:21:38 -0400 Received: from foss.arm.com ([217.140.110.172]:54022 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728788AbgD1PVd (ORCPT ); Tue, 28 Apr 2020 11:21:33 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8B23530E; Tue, 28 Apr 2020 08:21:32 -0700 (PDT) Received: from [10.57.33.170] (unknown [10.57.33.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E72243F305; Tue, 28 Apr 2020 08:21:30 -0700 (PDT) Subject: Re: [PATCH v2] arm64: dts: allwinner: h6: Use dummy regulator for Tanix TX6 To: =?UTF-8?B?Q2zDqW1lbnQgUMOpcm9u?= , Maxime Ripard , Chen-Yu Tsai , Rob Herring Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sunxi , Piotr Oniszczuk , linux-arm-kernel@lists.infradead.org References: <20200428142629.8950-1-peron.clem@gmail.com> From: Robin Murphy Message-ID: <98246e5d-ebef-bcb5-f0b8-d74b3834b835@arm.com> Date: Tue, 28 Apr 2020 16:21:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428142629.8950-1-peron.clem@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-04-28 3:26 pm, Clément Péron wrote: > Tanix TX6 has a fixed regulator. As DVFS is instructed to change > voltage to meet OPP table, the DVFS is not working as expected. Hmm, isn't that really a bug in the DVFS code? I guess it's just blindly propagating -EINVAL from the fixed regulators not implementing set_voltage, but AFAICS it has no real excuse not to be cleverer and still allow switching frequency as long as the voltage *is* high enough for the given OPP. I wonder how well it works if the regulator is programmable but shared with other consumers... that case probably can't be hacked around in DT. Robin. > Avoid to introduce a new dedicated OPP Table where voltage are > equals to the fixed regulator as it will only duplicate all the OPPs. > Instead remove the fixed regulator so the DVFS framework will create > dummy regulator and will have the same behavior. > > Add some comments to explain this in the device-tree. > > Reported-by: Piotr Oniszczuk > Fixes: add1e27fb703 ("arm64: dts: allwinner: h6: Enable CPU opp tables for Tanix TX6") > Signed-off-by: Clément Péron > --- > .../boot/dts/allwinner/sun50i-h6-tanix-tx6.dts | 18 ++++++++++++++++-- > 1 file changed, 16 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts > index be81330db14f..3e96fcb317ea 100644 > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix-tx6.dts > @@ -48,7 +48,15 @@ > }; > > &cpu0 { > - cpu-supply = <®_vdd_cpu_gpu>; > + /* > + * Don't specify the CPU regulator, as it's a fixed > + * regulator DVFS will not work as it is intructed > + * to reach a voltage which can't be reached. > + * Not specifying a regulator will create a dummy > + * regulator allowing all OPPs. > + * > + * cpu-supply = <®_vdd_cpu_gpu>; > + */ > }; > > &de { > @@ -68,7 +76,13 @@ > }; > > &gpu { > - mali-supply = <®_vdd_cpu_gpu>; > + /* > + * Don't specify the GPU regulator, see comment > + * above for the CPU supply. > + * > + * mali-supply = <®_vdd_cpu_gpu>; > + */ > + > status = "okay"; > }; > >