RE: [RFC PATCH 1/1] i2c: rcar: handle RXDMA HW bug on Gen3

[Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>]

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