[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d48d2e85-42f1-570a-bd8f-e3834147c8b8@marcan.st>
Date: Tue, 23 Nov 2021 23:41:12 +0900
From: Hector Martin <marcan@...can.st>
To: Janne Grunau <j@...nau.net>, Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Rob Herring <robh+dt@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/4] arm64: dts: apple: t8103: Add i2c nodes
On 23/11/2021 14.41, Hector Martin wrote:
> On 23/11/2021 07.58, Janne Grunau wrote:
>> Apple M1 has at least 5 i2c controllers. i2c0, i2c1 and i2c3 are used
>> on all M1 Mac devices. The 2020 Mac Mini uses i2c2 and the 13-inch
>> MacBook Pro uses i2c2 and i2c4.
>
> On further testing: i2c3 is not used on the 1GbE variant of j274. iBoot
> actually kills the node entirely. The interesting thing is it doesn't
> work; it times out probe transactions. I suspect iBoot does not enable
> its clock or something like that.
>
> I'll poke around this on IRC, but a priori we probably need m1n1 code to
> kill this node when the ADT doesn't have it. Maybe I should generalize
> the dwc3 killing code...
Did that as of m1n1 be7ff3a, so we're good now :)
For those following along in the list: the reason why i2c3 was getting
stuck is because it seems the unused bus is weakly pulled low on these
machines, which jams it. Setting the GPIO pull mode to pull-up makes it
work as an empty bus, but let's just not instantiate at all in this
case. m1n1 now checks the Apple DT and sets any FDT i2c devices that are
not present in it to disabled.
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists