Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2183349rdb; Thu, 21 Sep 2023 10:46:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG0Uz2JeAg2oJ/7far2Ml6U3oji54rwTLgyaHGlhrKeP7Xi+zx44EE5P7rzmbnttFzaXadl X-Received: by 2002:a17:903:2345:b0:1c3:a4f2:7c99 with SMTP id c5-20020a170903234500b001c3a4f27c99mr6139942plh.4.1695318393411; Thu, 21 Sep 2023 10:46:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695318393; cv=none; d=google.com; s=arc-20160816; b=bMqJksxmuWWOZ+EcJTyKha0Kj1QpZf3FHsS6PozRYitwpSCM+u5oe05WYN4aUz3wKC YCbAgOLfI49WLn2wXOhu67wvUzVfqnrPWaJU0gaWD61eZyoFou0R05HrQ/4jMplgXbW7 VaHNtm7Hq5UQiyHCLD+vxZQC7a3tANLU9iZVrC2gvd438Wl6sS91+cG47Un1CcJfeZry r/74PKglBq/JxpDaVcpnIGFm6vjk2Z3+k8+IZGuNLOkV+H9XrH6pIz9z1aUlQJ9HWMAw NtVwWbWfNFt0BcHq6MRwhZ5M2NbDBSUeKBGBLJTrBDtedGEu/rcF83FfZIUBpKio1Ieo JoKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1kcTQgFY9lHZu9mcnxsMSGECqqzK9NuYMRknkGxw7B4=; fh=35fp2/VibT3Etvo7HaQ70eNJ5gMwSrIPl//ktV6YXFY=; b=pekvRIXOKPX7MkK+ddbrqxovMd/hohgAYjMp87OROQMgKy/gOklFuKk1DWNKrN1Ly6 qRm5nNbh9kafT+S/q2VOU3HanFMdszuO1AJLGDbSG3LGyFCAZroTWtmpmHW/MvJ47sEl WLt39nxeB/6ZzdK19VNFoaybQD8tCeZcPIKqJQ441fPoxDggv7fkD/tc7FSk45GzaRSK sAVId850/fSpXRAKpXHi1UhOkmXXcVvugP8V46moGTC2b6ZPSg9ugjev2V6hBQrlpRpQ I5Luh2DtxSvGBv95dhwAh3eeXCe2Hlwt0aGmgyNI/0xr68qDzu7cM3+GYtBXeZWCPWzb TBww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id a1-20020a170902ecc100b001bc5f13c67esi1913884plh.589.2023.09.21.10.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 10:46:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 9BD78802572D; Thu, 21 Sep 2023 10:12:02 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230302AbjIURLz (ORCPT + 99 others); Thu, 21 Sep 2023 13:11:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59020 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231157AbjIURKI (ORCPT ); Thu, 21 Sep 2023 13:10:08 -0400 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [IPv6:2a0a:edc0:2:b01:1d::104]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18B1186BD for ; Thu, 21 Sep 2023 10:05:31 -0700 (PDT) Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qjKBp-0003Gb-Ij; Thu, 21 Sep 2023 15:57:57 +0200 Received: from [2a0a:edc0:2:b01:1d::c0] (helo=ptx.whiteo.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qjKBo-007wRQ-7M; Thu, 21 Sep 2023 15:57:56 +0200 Received: from sha by ptx.whiteo.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1qjKBo-00Ao2Z-3V; Thu, 21 Sep 2023 15:57:56 +0200 Date: Thu, 21 Sep 2023 15:57:56 +0200 From: Sascha Hauer To: Saravana Kannan Cc: Chen-Yu Tsai , Linus Walleij , linux-rockchip@lists.infradead.org, Heiko Stuebner , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio@vger.kernel.org, kernel@pengutronix.de, Quentin Schulz , Michael Riesch , Rob Herring , Krzysztof Kozlowski , Conor Dooley Subject: Re: [PATCH 1/3] pinctrl: rockchip: add support for io-domain dependency Message-ID: <20230921135756.GT637806@pengutronix.de> References: <20230904115816.1237684-1-s.hauer@pengutronix.de> <20230904115816.1237684-2-s.hauer@pengutronix.de> <20230913065843.GF637806@pengutronix.de> <20230915065120.GQ637806@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 21 Sep 2023 10:12:02 -0700 (PDT) On Wed, Sep 20, 2023 at 03:00:28PM -0700, Saravana Kannan wrote: > On Thu, Sep 14, 2023 at 11:51 PM Sascha Hauer wrote: > > > > On Wed, Sep 13, 2023 at 01:48:12PM -0700, Saravana Kannan wrote: > > > On Tue, Sep 12, 2023 at 11:58 PM Sascha Hauer wrote: > > > > > > > > On Wed, Sep 13, 2023 at 12:37:54PM +0800, Chen-Yu Tsai wrote: > > > > > On Tue, Sep 12, 2023 at 4:07 PM Linus Walleij wrote: > > > > > > > > > > > > Top posting to bring Saravana Kannan into this discussion. > > > > > > > > > > > > This looks like a big hack to me, Saravana has been working > > > > > > tirelessly to make the device tree probe order "sort itself out" > > > > > > and I am pretty sure this issue needs to be fixed at the DT > > > > > > core level and not in a driver. > > > > > > > > > > We could merge all the IO domain stuff into the pinctrl node/driver, > > > > > like is done for Allwinner? Maybe that would simplify things a bit? > > > > > > > > I thought about this as well. On Rockchip the pinctrl driver and the IO > > > > domain driver even work on the same register space, so putting these > > > > into a single node/driver would even feel more natural than what we have > > > > now. > > > > > > Then we should try to do this and fix any issues blocking us. > > > > > > > However, with that the pinctrl node would get the supplies that the IO > > > > domain node now has and we would never get into the probe of the pinctrl > > > > driver due to the circular dependencies. > > > > > > From a fw_devlink perspective, the circular dependency shouldn't be a > > > problem. It's smart enough to recognize all cycle possibilities (since > > > 6.3) and not enforce ordering between nodes in a cycle. > > > > > > So, this is really only a matter of pinctrl not trying to do > > > regulator_get() in its probe function. You need to do the > > > regulator_get() when the pins that depend on the io-domain are > > > requested. And if the regulator isn't ready yet, return -EPROBE_DEFER? > > > > That's basically what my series does already, I return -EPROBE_DEFER > > from the pinctrl driver when a pin is requested and the IO domain is not > > yet ready. > > > > > > > > Is there something that prevents us from doing that? > > > > No. We could do that, but it wouldn't buy us anthing. I am glad to hear > > that fw_devlink can break the circular dependencies. With this we could > > add the supplies to the pinctrl node and the pinctrl driver would still > > be probed. > > > > With the IO domain supplies added to the pinctrl node our binding would > > be cleaner, but still we would have to defer probe of many requested > > pins until finally the I2C driver providing access to the PMIC comes > > along. We also still need a "Do not defer probe for these pins" property > > in the pingrp needed for the I2C driver. > > Sorry about the slow reply. Been a bit busy. > > Oh, this is not true though. With the example binding I gave, > fw_devlink will automatically defer the probe of devices that depend > on pins that need an iodomain/regulator. > > pinctrl { > compatible = "rockchip,rk3568-pinctrl"; > i2c0 { > /omit-if-no-ref/ > i2c0_xfer: i2c0-xfer { > rockchip,pins = > /* i2c0_scl */ > <0 RK_PB1 1 &pcfg_pull_none_smt>, > /* i2c0_sda */ > <0 RK_PB2 1 &pcfg_pull_none_smt>; > }; > } > ... > ... > pinctrl-io { > compatible = "rockchip,rk3568-pinctrl-io"; > pmuio1-supply = <&vcc3v3_pmu>; > cam { > .... > } > .... > .... > } > > consumerA { > pinctrl-0 = <&cam>; > } > > With this model above, there are no cycles anymore. The cycles are gone because you skipped the problematic case in your example. Replace consumerA in your example with the I2C node providing access to the PMIC which provides &vcc3v3_pmu and then you have the cycles back. The I2C master device needs the IO domain which needs a regulator provided by a client on the very same I2C master. The cycles are actually there in hardware, you can't define them away ;) Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |