[PATCH 1/2] media: omap4iss: Make module stop timeout print a warning message

[PATCH 1/2] media: omap4iss: Make module stop timeout print a warning message

[Laurent Pinchart]

Module stop timeouts are serious enough that they deserve a proper
warning message, not a debug message that will go unnoticed.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/staging/media/omap4iss/iss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss.c b/drivers/staging/media/omap4iss/iss.c
index 0b03cb7c59d5..b7e82eed8aad 100644
--- a/drivers/staging/media/omap4iss/iss.c
+++ b/drivers/staging/media/omap4iss/iss.c
@@ -601,8 +601,8 @@ static int iss_pipeline_disable(struct iss_pipeline *pipe,
 		subdev = media_entity_to_v4l2_subdev(entity);
 		ret = v4l2_subdev_call(subdev, video, s_stream, 0);
 		if (ret < 0) {
-			dev_dbg(iss->dev, "%s: module stop timeout.\n",
-				subdev->name);
+			dev_warn(iss->dev, "%s: module stop timeout.\n",
+				 subdev->name);
 			/* If the entity failed to stopped, assume it has
 			 * crashed. Mark it as such, the ISS will be reset when
 			 * applications will release it.
-- 
Regards,

Laurent Pinchart

[PATCH 2/2] media: omap4iss: csi2: Fix IRQ handling when stopping module

[Laurent Pinchart]

When stopping the CSI2 receiver the s_stream handler will wait for the
IRQ handler to notice the stop request. The receiver, automatically
disabled by the hardware after each frame, is then not reenabled by the
IRQ handler as it returns immediately.

As the IRQ handler check is performed before handling the context IRQ,
the context IRQ source isn't cleared, and the CSI2 IRQ is then fired
again immediately. The IRQ handler then fails to notice that the module
is being stopped, processes the IRQ normally and reenables the CSI2
hardware.

The problem goes unnoticed at stream stop time, but depending on the IRQ
and s_stream scheduling timings, the CSI2 receiver can end up being
hanged and will not produce any interrupt the next time it gets enabled,
despite being soft-reset then.

Fix this by checking for module stop after clearing the context IRQ
source.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/staging/media/omap4iss/iss_csi2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/omap4iss/iss_csi2.c b/drivers/staging/media/omap4iss/iss_csi2.c
index bc83f8246101..b6b5c12b9c9d 100644
--- a/drivers/staging/media/omap4iss/iss_csi2.c
+++ b/drivers/staging/media/omap4iss/iss_csi2.c
@@ -674,6 +674,9 @@ static void csi2_isr_ctx(struct iss_csi2_device *csi2,
 	status = iss_reg_read(csi2->iss, csi2->regs1, CSI2_CTX_IRQSTATUS(n));
 	iss_reg_write(csi2->iss, csi2->regs1, CSI2_CTX_IRQSTATUS(n), status);
 
+	if (omap4iss_module_sync_is_stopping(&csi2->wait, &csi2->stopping))
+		return;
+
 	/* Propagate frame number */
 	if (status & CSI2_CTX_IRQ_FS) {
 		struct iss_pipeline *pipe =
@@ -776,9 +779,6 @@ void omap4iss_csi2_isr(struct iss_csi2_device *csi2)
 		pipe->error = true;
 	}
 
-	if (omap4iss_module_sync_is_stopping(&csi2->wait, &csi2->stopping))
-		return;
-
 	/* Successful cases */
 	if (csi2_irqstatus & CSI2_IRQ_CONTEXT0)
 		csi2_isr_ctx(csi2, &csi2->contexts[0]);
-- 
Regards,

Laurent Pinchart