[PATCH 2/2] arm64: dts: imx8mm: Add i.MX8M Mini Toradex Verdin based Menlo board

[Marcel Ziswiler]

On Fri, 2022-04-08 at 09:16 -0700, Tim Harvey wrote:
> On Fri, Apr 8, 2022 at 8:54 AM Adam Ford <aford173 at gmail.com> wrote:
> > 
> > On Fri, Apr 8, 2022 at 10:29 AM Tim Harvey <tharvey at gateworks.com> wrote:
> > > 
> > > On Fri, Apr 8, 2022 at 2:05 AM Francesco Dolcini
> > > <francesco.dolcini at toradex.com> wrote:
> > > > 
> > > > On Fri, Apr 08, 2022 at 09:56:09AM +0200, Marcel Ziswiler wrote:
> > > > > On Fri, 2022-04-08 at 08:46 +0200, Francesco Dolcini wrote:
> > > > > > On Thu, Apr 07, 2022 at 10:24:56PM +0200, Marek Vasut wrote:
> > > > > > > +
> > > > > > > +&i2c1 {
> > > > > > > +       /* IMX8MM ERRATA e7805 -- I2C is limited to 384 kHz due to SoC bug */
> > > > > > > +       clock-frequency = <100000>;
> > > > > > should this and the related changes in the other i2c nodes done in the
> > > > > > verdin.dtsi? Marcel? (errata is here:
> > > > > > https://www.nxp.com/docs/en/errata/IMX8MDQLQ_1N14W.pdf)
> > > > > 
> > > > > Hehe, good catch. Yeah, we probably should move this one into imx8mm-verdin.dtsi instead. On the
> > > > > other hand, it
> > > > > won't hurt doing it twice resp. this one will always override it like that.
> > > > > 
> > > > > Anyway, looks like NXP has not fixed this and is re-using the exact same I2C IP with the same errata
> > > > > (;-p).
> > > > 
> > > > It looks like even i.MX7 is affected, and NXP has a quirk in the
> > > > i2c-imx driver [0]
> > > > 
> > > > [0]
> > > > https://source.codeaurora.org/external/imx/linux-imx/commit/drivers/i2c/busses/i2c-imx.c?h=lf-5.15.y&id=493b3892ee156af529796641889ca19b971735d2
> > > > 
> > > > Francesco
> > > 
> > > Francesco and Marek,
> > > 
> > > Interesting - I've never noticed this errata.
> > > 
> > > I don't see mention of it in the imx8mm-evk which sets the busses to
> > > 400khz, and all the other verdin I2C busses are set to 400khz as well.
> > > 
> > > Should we address this in the i2c driver in U-Boot (and Linux)
> > > instead? Otherwise, I think all of us board maintainers should be
> > > moving the i2c clock to 100kHz. Its not clear to me what I2C slaves
> > > may be affected by this issue.... perhaps maintainers are only
> > > concerned with things that go off-board?
> > 
> > My company has a downstream kernel and we've had no issues with 384KHz
> > instead of 400.  I am not sure that slowing all the way down to 100 is
> > necessary.  I can't imagine I2C devices care if the clocks go a bit
> > slower.  From my understanding of the errata is that it violates the
> > rise-time or something like that.  The peripherals I use don't appear
> > to care that it's slightly out of spec at 400KHz.
> > 
> 
> Adam,
> 
> Yes good point... 384Khz is the workaround in the errata. So instead
> of all of us moving our I2C clocks to 384000 (which we should
> according to the errata) should we do this in the i2c driver based off
> chip type?

How about doing something along the lines of that i.MX 7 quirk Francesco discovered in NXP's downstream?

Cheers

Marcel