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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux