From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9BA70C27C53 for ; Sun, 9 Jun 2024 16:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dlKjtQiViYe9KvhmK3qOfr52fnxLXooq6Ke5QDHq62Y=; b=bbK89OZavOl6LS 8hgoqyd08xmem2PK1A2X53xaD4WGJQY8r1zxr2AwykB5317Hs1CvofZcoKF6ZU0qbnb99P8bFvPyl rM0zLrRkJe63ucQK8V/iEXXrqsDP37tIeE1uAJjksJMhCLNUZ5QYyXWGsBC0CXRhrlcF92ksLHoO0 XnxL6MR7Oht3/slIedNhw5TMiv9pTDpSQScGtLXtkVORp2vlhtJKiMPdj+5MP3q8kEuHCrLOkXQtu SBdyAC1Lakw5QCQWHp9qLg0qzyEiU2Gr7EQmEWXtMyB9vcnV/DZug+DFXV0HczFQg7D0MgX0pzjQo 1KTgDDzCk1EGuI+k6d9A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGL3j-00000002qpc-4BRi; Sun, 09 Jun 2024 16:06:20 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sGL3g-00000002qon-1o0k; Sun, 09 Jun 2024 16:06:18 +0000 Received: from i53875b65.versanet.de ([83.135.91.101] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sGL3G-0004V8-Ee; Sun, 09 Jun 2024 18:05:50 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: linux-rockchip@lists.infradead.org, Sebastian Reichel , Space Meyer , Sebastian Kropatsch Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Jonas Karlman , Dragan Simic , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board Date: Sun, 09 Jun 2024 18:05:49 +0200 Message-ID: <4035271.e99z0qppnp@diego> In-Reply-To: References: <20240602211901.237769-1-seb-dev@mail.de> <11747652.CDJkKcVGEf@phil> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240609_090616_515326_DCB3063B X-CRM114-Status: GOOD ( 30.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Samstag, 8. Juni 2024, 19:22:01 CEST schrieb Sebastian Kropatsch: > Hello, > > Am 08.06.2024 um 16:38 schrieb Heiko Stuebner: > > Am Donnerstag, 6. Juni 2024, 15:13:20 CEST schrieb Space Meyer: > >> On 02.06.2024 22:20, Sebastian Kropatsch wrote: > >>> Some RK3588 boards are still using this property, the following quote > >>> is from rk3588-tiger-haikou.dts for example: > >>> &sdmmc { > >>> /* while the same pin, sdmmc_det does not detect card changes */ > >>> cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>; > >>> > >>> I am unsure as to whether this comment from the quote might apply for > >>> the CM3588 as well. Please let me know if you are able to tell :-) > >> > >> I don't quite understand this. However GPIO0_A4 *is* routed to the micro > >> sd CD according to the NAS schematic, page 16 around A5. > > > > for the actual sdmmc_det functionality ... possibly some pinconfig thing? > > I.e. pull-whatever settings? > > I have no idea. I just removed the "cd-gpios" line in v2 due to a > suggestion by Jonas Karlman and then stumbled over this comment. > So I'm not sure whether to include or not include this property > for the CM3588 NAS since I don't know the consequences. > Probably in the end it doesn't even matter :) > > >>> + vcc_3v3_pcie30: regulator-vcc-3v3-pcie30 { > >>> + compatible = "regulator-fixed"; > >>> + regulator-name = "vcc_3v3_pcie30"; > >>> + regulator-always-on; > >>> + regulator-boot-on; > >>> + regulator-min-microvolt = <3300000>; > >>> + regulator-max-microvolt = <3300000>; > >>> + vin-supply = <&vcc_5v0_sys>; > >>> + }; > >> > >> These are 4 seperate regulators according to the schematic. However, as > >> they are all fixed, idk if they should be split or kept like this. > > > > personally, I really like the power-diagram to match schematics. > > I.e. $debugfs/regulator/regulator_summary will produce a really nice > > graph of all the system's regulators, so it's definitly nice if the > > hirarchy matches. Also prevents head-scratching later on ;-) > > These are indeed 4 different regulators according to the schematic.[1] > But they don't have any pin to control them separately. I can > duplicate them 4 times if that's the preferred practice. > > But matching the schematics won't be possible either way, since > e.g. there is only one single 5v regulator acc. to the schematic > (vcc_5v0_sys), but vcc_5v0_host_20, vcc_5v0_host_30, vbus_5v0_typec > and so on are needed since each device has a different control pin > to enable its power. Or is there a better way to solve this while > having only one 5v regulator node but still being able to set the > control pins separately for the different USB ports? The other option we often use is to define multiple phandles for a regulator. For exactly that case where one gpio controls a set of regulators. So you have one regulator vcc_5v0_host_20: vcc_5v0_host_30: vbus_5v0_typec: regulator-vcc-whatever { foo; } So in short there is not set rule, but more like a best-effort to get as close to the schematics as possible. I.e. someone going from dt to schematics should be able to just search for an identifier (of course same for the other direction). Heiko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel