On Mon, Jul 23, 2018 at 07:55:22PM +0200, Wolfram Sang wrote:
> On Thu, Jun 28, 2018 at 10:45:38PM +0200, Wolfram Sang wrote:
> > On Gen3, we can only do RXDMA once per transfer reliably. For that, we
> > must reset the device, then we can have RXDMA once. This patch
> > implements this. When
On Thu, Jun 28, 2018 at 10:45:38PM +0200, Wolfram Sang wrote:
> On Gen3, we can only do RXDMA once per transfer reliably. For that, we
> must reset the device, then we can have RXDMA once. This patch
> implements this. When there is no reset controller or the reset fails,
> RXDMA will be blocked
On Fri, Jun 29, 2018 at 09:54:04AM +0200, Wolfram Sang wrote:
>
> > > + /* Gen3 needs a reset before allowing RXDMA once */
> > > + if (priv->devtype == I2C_RCAR_GEN3) {
> >
> > So on R-Car Gen3 the device is always reset, even if no reads will be done?
> > Or is that something you
> > + /* Gen3 needs a reset before allowing RXDMA once */
> > + if (priv->devtype == I2C_RCAR_GEN3) {
>
> So on R-Car Gen3 the device is always reset, even if no reads will be done?
> Or is that something you cannot check for at this point?
You got a point. I copied the behaviour
Hi Wolfram,
On Thu, Jun 28, 2018 at 10:45 PM Wolfram Sang
wrote:
> On Gen3, we can only do RXDMA once per transfer reliably. For that, we
> must reset the device, then we can have RXDMA once. This patch
> implements this. When there is no reset controller or the reset fails,
> RXDMA will be
On Gen3, we can only do RXDMA once per transfer reliably. For that, we
must reset the device, then we can have RXDMA once. This patch
implements this. When there is no reset controller or the reset fails,
RXDMA will be blocked completely. Otherwise, it will be disabled after
the first RXDMA
