Hello Wolfram-san,
> From: Wolfram Sang, Sent: Thursday, May 31, 2018 5:31 PM
>
> Hello Shimoda-san,
>
> > > Subject: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3
> >
> > If possible, I'd like to replace "bug" with "specification" or other words
> > :)
>
> "behaviour" maybe is a better word?
It sounds good to me.
> > > + /* Gen3 has a HW bug which needs a reset before allowing RX DMA once */
> > > + if (priv->devtype == I2C_RCAR_GEN3) {
> > > + priv->flags |= ID_P_NO_RXDMA;
> > > + if (!IS_ERR(priv->rstc)) {
> > > + ret = reset_control_reset(priv->rstc);
> >
> > According to the datasheet Rev.1.00 page 57-69, we should do:
> > reset_control_assert();
> > udelay(1);
> > reset_control_deassert();
> > while (reset_control_status())
> > ;
> > instead of reset_control_reset(), I think.
>
> I was following Geert's suggestion here from the mail thread '[periperi] About
> BSP patch "i2c: rcar: Fix I2C DMA reception by adding reset':
>
> ===
>
> >> reset_control_assert() + reset_control_deassert() can be replaced by
> >> reset_control_assert().
> >
> > Do you mean 'reset_control_reset' maybe? I am not sure, I don't know
> > this API very well... but two time *_assert looks suspicious.
>
> Of course. Silly c&p.
>
> >> In addition, that will make sure the delay of one cycle of the RCLK clock
> >> is taken into account, which is not the case with the current code.
> >
> > I guess this is why there is now this patch in the BSP which Shimoda-san
> > mentioned in a later mail:
> >
> > f0cd22525f73 ("i2c: rcar: Fix module reset function for hardware
> > specification")
>
> Exactly.
>
> ===
>
> As far as I understood it takes care of the proper reset mechanism with the
> delay?
I missed this email... As I replied to Geert-san on other email thread,
I'll ask HW team about this topic.
Best regards,
Yoshihiro Shimoda
> Kind regards,
>
> Wolfram
