[PATCH v3 11/11] i2c: npcm: Support NPCM845

[Tomer Maimon]

Hi Andy,

On Mon, 7 Mar 2022 at 11:44, Andy Shevchenko <
andriy.shevchenko at linux.intel.com> wrote:

> On Sun, Mar 06, 2022 at 03:33:20PM +0200, Tomer Maimon wrote:
> > On Thu, 3 Mar 2022 at 16:11, Andy Shevchenko <
> > andriy.shevchenko at linux.intel.com> wrote:
> > > On Thu, Mar 03, 2022 at 02:35:58PM +0200, Tali Perry wrote:
> > > > > On Thu, Mar 3, 2022 at 12:45 PM Andy Shevchenko <
> > > andriy.shevchenko at linux.intel.com> wrote:
>
> ...
>
> > > But hold on and read set of questions below.
> > >
> > > Previously it was a fixed field with the NPCM_I2CTXF_STS_TX_BYTES mask
> > > applied,
> > > right? From above I have got that FIFO is growing twice. Is it correct?
> >
> > What do you mean by growing twice? TX and RX?
>
> I meant from 16 bytes to 32 bytes.
>
Yes, the FIFO grow to 32 byte

>
> > > Does the LSB stay at the same offset? What is the meaning of the MSB
> in 32
> > > byte
> > > case? If it's reserved then why not to always use 32 byte approach?
> >
> > Yes, the LSB stays in the same place, and bit 5 is reserved in the
> NPCM7XX
> > SoC.
> > Unfortunately, the I2C test failed when we tried to use the 32 bytes
> > approach at NPCM7XX Soc, this is why we added NPCM_I2CTXF_STS_TX_BYTES
> and
> > NPCM_I2C_STSRXF_RX_BYTES to the data structure.
> >
> > The device tree data structure pass data for each specific device, so I
> > don't understand why not use device tree data for supporting the I2C
> > specific device? this is not the case here?
>
> Basically we use compatible strings for that, but in any case if something
> can be autodetected from hardware, it's better to use autodetection.

Thanks for the clarification, in our case we don't autodetect from the
hardware...

>


>
> --
> With Best Regards,
> Andy Shevchenko
>
>
> We will send a new version soon, highly appreciate your help!

Best regards,

Tomer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220307/a7a907d6/attachment-0001.htm>