Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp2550593rdb; Mon, 25 Dec 2023 17:17:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IGcAAZI88gCZVBQltOwSFjIrldpTq2saI6YyDaBswMf0UeaXEMMoBKdl92Jgni69MbhjYNo X-Received: by 2002:a05:6808:2115:b0:3bb:821b:4b47 with SMTP id r21-20020a056808211500b003bb821b4b47mr5124645oiw.27.1703553440822; Mon, 25 Dec 2023 17:17:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703553440; cv=none; d=google.com; s=arc-20160816; b=SHweXU97kBuLH9wOQPp18kIl4UwwvcePjV3Go38g6lx4uUU98AclYokF/GAlPA5glM ZZEr8SO+Z6vc0q0p4lHazvIkMsI5Jxq+/4pgHaiJUipGkewDFt7781y3i8PzNOGqpXL0 5FEBGKwal2VIqsCbND0MolrXn9N4s/Aua4zswlO+JH8ZsjZg/AnDR+DiO8t5UDBEP5Ou 4e/lGCLxBbAJu7nvvx/Nhu97jcoUGTVzjoN98R/FAftb1Bel26ar64en08/eBYta96Az RDLAySvakdmVyz/k7QVDWL3Ve+Vgvwh4Q7uyumIh7BeFvM+FpGn4gAQPHhcYOXwWrRZo e0dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=ZFtKWmpHbT0n5o6P8CX+AC1OCJA0dhfpwcTmcKe4FwM=; fh=zMQrkbt80wW/pllHaGySXtDx4dUJbL2QSlSQlt7sNp8=; b=QLQsuU7h1Pvn/0cb+Q61ohFdGUwv7lJqvH6U6uRVZy1aino7saXjp9cut8Lse/C6S2 KmjUIcgHK7KY7zlaI469PAbkj62wYvfkWbw8AizOKvn6P3hEpeFAEjVaH9mUP0WfiPS5 PykiZg3+tdhgehr/ej72Df5x1DY3csMH/9Yl34zAGPJpfCH/ZQ7vFRx+vaRxFf+52Ojq 9IAvGEf2Cm8FoYljYnz+KllHw8QPVwU9UTOxgI2L4RhJ6TQIEhfKPgFCUykSQ4UHgrYV va/KGIJyzZAqDN6SNlyiA/eE7OMzdTLqFw80TYWQv9IbSH21Sxo/2l7ffuzgBW7oHeHq ugcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-11311-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11311-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id g14-20020a056a0023ce00b006d96d3a4a75si8396370pfc.39.2023.12.25.17.17.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Dec 2023 17:17:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-11311-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-11311-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-11311-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id BC83EB2141B for ; Tue, 26 Dec 2023 01:17:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 94FA6A47; Tue, 26 Dec 2023 01:17:09 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BAD98A2A; Tue, 26 Dec 2023 01:17:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 7513A1FB; Mon, 25 Dec 2023 17:17:45 -0800 (PST) Received: from minigeek.lan (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3B7A03F641; Mon, 25 Dec 2023 17:16:58 -0800 (PST) Date: Tue, 26 Dec 2023 01:16:34 +0000 From: Andre Przywara To: fuyao Cc: fuyao , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Alexandre TORGUE , Enric Balletbo i Serra , Baruch Siach , Paul Barker , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] ARM: dts: sun8i: r40: open the regulator aldo1 Message-ID: <20231226011634.32e2342d@minigeek.lan> In-Reply-To: References: <20231220150400.0f32e2a5@donnerap.manchester.arm.com> <20231221103906.1830ef94@donnerap.manchester.arm.com> Organization: Arm Ltd. X-Mailer: Claws Mail 4.2.0 (GTK 3.24.31; x86_64-slackware-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 25 Dec 2023 18:11:24 +0800 fuyao wrote: Hi, thanks for the reply, with insightful information! > On Thu, Dec 21, 2023 at 10:39:06AM +0000, Andre Przywara wrote: > > On Thu, 21 Dec 2023 10:20:49 +0800 > > fuyao wrote: > > > > Hi, > > > > thanks for the reply! > > > > > On Wed, Dec 20, 2023 at 03:04:00PM +0000, Andre Przywara wrote: > > > > On Wed, 20 Dec 2023 16:18:43 +0800 > > > > fuyao wrote: > > > > > > > > Hi, > > > > > > > > > the aldo1 is connect regulator pin which power the TV. > > > > > > > > What do you mean with that? That ALDO1 is connected to VCC-TVOUT and/or > > > > VCC-TVIN on the R40 SoC? > > > > > > The ALDO1 is connected to VCC-TVOUT on the R40 Soc. > > > > Ah, thanks for the confirmation. > > > > > > > The USB core use TV ref as reference Voltage. > > > > > > > > The USB core in the SoC? So pin VCC-USB, which requires 3.3V, the same > > > > voltage as the TV pins? > > > > Which means this doesn't really have much to do with TV, it's just that > > > > USB and also "TV" are supplied by ALDO1? > > > > > > The internal USB PHY requires a reference voltage. It seems that in > > > order to save costs, the reference voltage of the TVOUT module is used. > > > > Do you mean a USB *reference* voltage that is separate from the USB PHY > > power supply voltage, so pin VCC-USB on the SoC? And that it is internally > > connected to some TV-OUT related circuits? So that would apply to all > > devices using the R40 SoC then? > yes, The usb need a power from TV module insides. Ah, alright. I dimly remember hearing reports about unstable USB operation on some (custom?) R40 boards, that might as well explain it. On the BananaPis (the only other officially supported R40 boards), TVOUT and TVOUT are connected to DCDC1, so are effectively always powered by 3.3V already, which would explain why we didn't observe USB issues there. > > Or is it simply that the SoC pins VCC-TVOUT and VCC-USB are connected > > together, on this SoM? > no Thanks for the confirmation! > > Do you have access to some schematic? I couldn't find one online easily, > > so cannot check this myself. > > > It has up to https://file.io/VSUL4FDrapDY Ah, many thanks, that's really useful! That indeed confirms that both TVIN and TVOUT are exclusively powered by ALDO1. So if you resend the patch as v2, with the regulator-name changed, and possibly with the following commit message, I'd support it: ============= The USB PHY in the Allwinner R40 SoC seems to rely on voltage on the VCC-TVIN/OUT supply pins for proper operation, on top of its own supply voltage on VCC-USB. Without a 3.3V voltage supplied to VCC-TV*, USB operation becomes unstable and can result in disconnects. The Forlinx FETA40i-C SoM connects both the VCC-TVOUT and VCC-TVIN pins to the ALDO1 rail of the PMIC, so we need to enable that rail for USB operation. Since there is no supply property in the DT bindings for the USB core, we need to always enable the regulator. This fixes unstable USB operation on boards using the Forlinx FETA40i-C module. ================ Cheers, Andre > > Thanks, > > Andre > > > > > > > Signed-off-by: fuyao > > > > > --- > > > > > arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi | 7 +++++++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi > > > > > index 9f39b5a2bb35..8906170461df 100644 > > > > > --- a/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi > > > > > +++ b/arch/arm/boot/dts/allwinner/sun8i-r40-feta40i.dtsi > > > > > @@ -42,6 +42,13 @@ &pio { > > > > > vcc-pg-supply = <®_dldo1>; > > > > > }; > > > > > > > > > > +®_aldo1 { > > > > > + regulator-always-on; > > > > > > > > So did USB never work before, with the DT as in mainline? > > > > > > > > > > The USB can work, but is unstable. Occasionally disconnected because of > > > the D+/D- electrical characteristics. > > > > > > > For always-on regulators it would be good to see some rationale why this > > > > cannot be referenced by its consumer. If it is really supplying the USB > > > > core, that would be a reason, because we don't have a good way of > > > > describing this. > > > > > > > > > + regulator-min-microvolt = <3300000>; > > > > > + regulator-max-microvolt = <3300000>; > > > > > + regulator-name = "vcc-aldo1"; > > > > > > > > Regulators should be named after their users, so use something like: > > > > regulator-name = "vcc-3v3-tv-usb"; > > > > > > > > > > thanks. > > > > > > > That then also serves as documentation of why this is always on. > > > > > > > > Cheers, > > > > Andre > > > > > > > > > +}; > > > > > + > > > > > ®_aldo2 { > > > > > regulator-always-on; > > > > > regulator-min-microvolt = <1800000>; > > > > > > > >