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

Adam Ford aford173 at gmail.com
Fri Apr 8 08:54:05 PDT 2022


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

>
> Best Regards,
>
> Tim



More information about the linux-arm-kernel mailing list