Re: [PATCH 4/4] rcar-csi2: Do not try to recover after transfer error

["Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>]

Hi Jacopo,

Thanks for your feedback.

On 2020-11-16 18:09:32 +0100, Jacopo Mondi wrote:
> Hi Niklas,
> 
> On Thu, Nov 12, 2020 at 11:51:47PM +0100, Niklas Söderlund wrote:
> > Instead of restarting the R-Car CSI-2 receiver if a transmission error
> > is detected inform the R-Car VIN driver of the error so it can stop the
> > whole pipeline and inform user-space. This is done to reflect a updated
> > usage recommendation in later versions of the datasheet.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > ---
> >  drivers/media/platform/rcar-vin/rcar-csi2.c | 14 ++++++--------
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > index 945d2eb8723367f0..a7212ecc46572a3b 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -773,21 +773,19 @@ static irqreturn_t rcsi2_irq(int irq, void *data)
> >
> >  	rcsi2_write(priv, INTERRSTATE_REG, err_status);
> >
> > -	dev_info(priv->dev, "Transfer error, restarting CSI-2 receiver\n");
> > -
> >  	return IRQ_WAKE_THREAD;
> >  }
> >
> >  static irqreturn_t rcsi2_irq_thread(int irq, void *data)
> >  {
> >  	struct rcar_csi2 *priv = data;
> > +	struct v4l2_event event = {
> > +		.type = V4L2_EVENT_EOS,
> > +	};
> >
> > -	mutex_lock(&priv->lock);
> > -	rcsi2_stop(priv);
> > -	usleep_range(1000, 2000);
> > -	if (rcsi2_start(priv))
> > -		dev_warn(priv->dev, "Failed to restart CSI-2 receiver\n");
> > -	mutex_unlock(&priv->lock);
> > +	dev_err(priv->dev, "Transfer error detected.\n");
> > +
> > +	v4l2_subdev_notify_event(&priv->subdev, &event);
> 
> Is event handling synchronous with the notification ? I mean, now that
> the sleep has gone, is this worth a threaded irq ?

I had the same line of thought, as far as I can tell the "remote side" 
event handling is done in the callers context. So I definitely think a 
threaded irq model is needed here as we have no idea what the "remote 
side" in a different driver will do :-)

> 
> Thanks
>   j
> 
> >
> >  	return IRQ_HANDLED;
> >  }
> > --
> > 2.29.2
> >

-- 
Regards,
Niklas Söderlund