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?
> > + /* 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?
Kind regards,
Wolfram
Attachment:
signature.asc
Description: PGP signature
