Hi Shimoda-san,
On Wed, May 30, 2018 at 10:35 AM, Yoshihiro Shimoda
<[email protected]> 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()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
