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 E942EC433F5 for ; Thu, 16 Dec 2021 21:31:20 +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-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XZnnpDkFLrwliUuAbsnjLEa9CNNysy1fKa4Vc04tIKE=; b=dHCFFbyWTfErGa10fNQULLltO2 mAohS9jDo64OC9m57NAVWVSYNpWIaHeQ9LDWrNuhDTqPNelxzpvfQN++XNxANBBqcUJOWF+1wbC6m NqE0jFIE6067juYd2z4iK0o259F+/5eFYOa/Qc9JwgPTD2KQ4I5YW9E2OTFNW4ucvAEoA22WUjWav /iDuyWPJtmFGE7lJ416IDAis64WgWlxS+TNJvebgsvPzzdBTpVNHhrTipQki5HSYNiEpyXxfNcHzk Uk49RZl+g+i3vaDNPhRiCDza3mOay0McWM9clGdXJH9y2luuae5MHEeyEF0ZGy36ljg/PfqgPvmif xvp5sWLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxyKC-007g8t-Ir; Thu, 16 Dec 2021 21:30:04 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mxyK7-007g6A-OV for linux-arm-kernel@lists.infradead.org; Thu, 16 Dec 2021 21:30:01 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxyK1-0001hc-SR; Thu, 16 Dec 2021 22:29:53 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.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 1mxyJy-004uja-60; Thu, 16 Dec 2021 22:29:49 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.92) (envelope-from ) id 1mxyJw-0006Vq-Qn; Thu, 16 Dec 2021 22:29:48 +0100 Date: Thu, 16 Dec 2021 22:29:48 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Maxime Ripard Cc: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Nicolas Saenz Julienne , bcm-kernel-feedback-list@broadcom.com, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Stefan Wahren , Cyril Brulebois , Dave Stevenson , Rob Herring Subject: Re: [PATCH v2] ARM: dts: bcm2711-rpi-cm4-io: Add rtc on a pinctrl-muxed i2c bus Message-ID: <20211216212948.nrfmm4jpbhoknfr5@pengutronix.de> References: <20211209181813.1312509-1-u.kleine-koenig@pengutronix.de> <22b563b0-8d9e-52a1-ebdc-e1f75a855d86@kleine-koenig.org> <20211213164947.dzuarzi4gqo6gxzo@houat> <20211215095637.dlrixu4iy3awpmek@houat> MIME-Version: 1.0 In-Reply-To: <20211215095637.dlrixu4iy3awpmek@houat> X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211216_132959_977699_C4E15990 X-CRM114-Status: GOOD ( 53.01 ) 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: multipart/mixed; boundary="===============6767611692772801254==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============6767611692772801254== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="l4d4isoz6wutnwel" Content-Disposition: inline --l4d4isoz6wutnwel Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Maxime, (added Rob to Cc for the dt question) On Wed, Dec 15, 2021 at 10:56:37AM +0100, Maxime Ripard wrote: > On Mon, Dec 13, 2021 at 09:25:16PM +0100, Uwe Kleine-K=F6nig wrote: > > On 12/13/21 17:49, Maxime Ripard wrote: > > > On Thu, Dec 09, 2021 at 10:21:39PM +0100, Uwe Kleine-K=F6nig wrote: > > > > I used the wrong git wrapper so this patch appeared with the wrong = sender > > > > address. If need be I can resend from the address used in the S-o-b. > > >=20 > > > Your SoB seems to match the From header, so unless you'd like to > > > contribute with your pengutronix it should be fine? > >=20 > > The problem is that the sender of the patch (i.e. my pengutronix self) > > didn't add a S-o-b. >=20 > I don't think that's a problem, but I might be wrong >=20 > > > > On 12/9/21 19:18, Uwe Kleine-K=F6nig wrote: > > > > > From: Uwe Kleine-K=F6nig > > > > >=20 > > > > > The cm4-io board comes with an PCF85063. Add it to the device tre= e to make > > > > > it usable. The i2c0 bus can use two different pinmux settings to = use > > > > > different pins. To keep the bus appearing on the usual pin pair (= gpio0 + > > > > > gpio1) use a pinctrl-muxed setting as the upstream dts does. > > > > >=20 > > > > > Signed-off-by: Uwe Kleine-K=F6nig > > > > > --- > > > > > arch/arm/boot/dts/bcm2711-rpi-cm4-io.dts | 35 ++++++++++++++++= ++++++++ > > > > > 1 file changed, 35 insertions(+) > > > > >=20 > > > > > diff --git a/arch/arm/boot/dts/bcm2711-rpi-cm4-io.dts b/arch/arm/= boot/dts/bcm2711-rpi-cm4-io.dts > > > > > index 19600b629be5..5ddad146b541 100644 > > > > > --- a/arch/arm/boot/dts/bcm2711-rpi-cm4-io.dts > > > > > +++ b/arch/arm/boot/dts/bcm2711-rpi-cm4-io.dts > > > > > @@ -18,6 +18,41 @@ led-pwr { > > > > > linux,default-trigger =3D "default-on"; > > > > > }; > > > > > }; > > > > > + > > > > > + i2c0mux { > > > > > + compatible =3D "i2c-mux-pinctrl"; > > > > > + #address-cells =3D <1>; > > > > > + #size-cells =3D <0>; > > > > > + > > > > > + i2c-parent =3D <&i2c0>; > > > > > + > > > > > + pinctrl-names =3D "i2c0", "i2c0-vc"; > > > > > + pinctrl-0 =3D <&i2c0_gpio0>; > > > > > + pinctrl-1 =3D <&i2c0_gpio44>; > > > > > + > > > > > + i2c@0 { > > > > > + reg =3D <0>; > > > > > + #address-cells =3D <1>; > > > > > + #size-cells =3D <0>; > > > > > + }; > > > > > + > > > > > + i2c@1 { > > > > > + reg =3D <1>; > > > > > + #address-cells =3D <1>; > > > > > + #size-cells =3D <0>; > > > > > + > > > > > + rtc@51 { > > > > > + /* Attention: An alarm resets the machine */ > > > > > + compatible =3D "nxp,pcf85063"; > > > > > + reg =3D <0x51>; > > > > > + }; > > > > > + }; > > > > > + }; > > > > > +}; > > > > > + > > > > > +&i2c0 { > > > > > + /delete-property/ pinctrl-names; > > > > > + /delete-property/ pinctrl-0; > > > > > }; > > > > > &ddc0 { > > > >=20 > > > > Just some further information: > > > >=20 > > > > Cyril (who I talked to on irc) and I found that not only i2c0 can b= e used to > > > > access the gpio bus on pins 44/45 (as I did in v1) but that also &i= 2c1 can > > > > drive these pins. However similar to &i2c0, &i2c1 is used on pins 2= /3 per > > > > default and so is also available on the default gpio header. > > > >=20 > > > > Also note that this is a breaking change, because overlays that add= ed > > > > devices to &i2c0 before (expecting them to be accessed via gpio0/1)= need to > > > > modify /i2c0mux/i2c@0 now instead of /soc/i2c@7e205000 (aka &i2c0). > > >=20 > > > We can mitigate that by setting the i2c0 label to the /i2c0mux/i2c@0 > > > node, since the overlay will not resolve what i2c0 is connected to un= til > > > it's applied. > >=20 > > It depends on the overlay if that works or not. If the node to patch is > > specified by label, this is fine. If however the node is referenced by = path > > (which is the usual thing for mainline, as the dtbs are compiled without > > -@), this change is a problem. >=20 > I'm not sure that using path is as ubiquitous with mainline as you imply > (I've never used or saw that myself), but yeah, any overlay that would > use the path directly would be broken. >=20 > > I'm not aware how bcm2711-rpi-cm4-io.dts could make the i2c0 label poin= t to > > the i2c@0 node that is introduced here. After all the i2c label is defi= ned > > in another file. Is there some syntax to do that? I still have no idea how to move the i2c0 label. @Rob: An idea was to declare the i2c@0 node that the patch above introduces should become the new &i2c0 as e.g. an overlay that adds an i2c device should add it there now instead of the original bus. Is this possible? And a good idea? Apart from not knowing if this is possible at all, in the meantime I doubt this to be a good idea. I think this adds to much confusion because it complicates (human and machine) parsing of the device tree. If i2c0 is referenced before the move it should certainly continue to point to /soc/i2c@7e205000, so usage of i2c0 depends on ordering. > > > Also, I think it's worth noting that this change will mimic what the = RPi > > > kernel is doing. > >=20 > > The commit log has "Use [...] as the upstream dts does.". Isn't that go= od > > enough? >=20 > Isn't upstream usually kernel.org kernels? Ah, indeed. Will change to "as the vendor dts does". Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --l4d4isoz6wutnwel Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAmG7r8kACgkQwfwUeK3K 7AlmgQf+KdyY6sv4AmMmGv/KaGxAkxvC9qz7dsRMuZ+o6gdzYcaTLFBEODHSOtHF yMz+F1Xg6HNIuRBHzdop8dB4DhO9Kq4Db3An4SFE8Pr/M53cZkWQdYuo/fCEYtKW VDBi4SsfAui1ncawMMi3z82UXnpx5i4uMsBlm7gqoPA18yqpAKnPbhdlL2Y261WU eWJb22IQxaQzzD2DhPlKaNgsNeWqjnJxEr63uBQrV4I6qvWc5b5LCAXL/LNy5sli jAO5h20VldmO5TMLRKx3sgKlFAW3/3m/QKbStxZY8R7AaOuJU4SlMjK7FY4Xsw0U 1r0eFQcEdiz+svoH+Ya3N+dRsSMcbg== =ZmaT -----END PGP SIGNATURE----- --l4d4isoz6wutnwel-- --===============6767611692772801254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============6767611692772801254==--