Hi Geert-san, Wolfram-san,
> From: Geert Uytterhoeven, Sent: Thursday, May 31, 2018 5:45 PM
>
> Hi Shimoda-san,
>
> On Wed, May 30, 2018 at 10:35 AM, Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
> >> From: Wolfram Sang, Sent: Tuesday, May 29, 2018 7:59 PM
> >> 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 :)
> >
> > <snip>
> >> @@ -743,6 +753,16 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap,
> >>
> >> pm_runtime_get_sync(dev);
> >>
> >> + /* 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.
>
> The i2c-specific procedure documented at page 57-69 thus differs from
> the generic one at page 8A-58, which is what cpg_mssr_reset() implements.
>
> The latter waits 35µs instead of 1µs, so that should be safe.
> But it doesn't check the status bit. Is the longer delay sufficient, or should
> a check polling the status bit be added to cpg_mssr_reset()?
Thank you for the pointed out.
I agree we should wait 35us for safe.
But, anyway I'll ask HW team about this contradiction and really need polling the status.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
