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

[Tim Harvey]

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?

Best Regards,

Tim