diff mbox series

[v6,2/3] media: i2c: imx274: Remove stop stream i2c writes during remove

Message ID 1600724379-7324-3-git-send-email-skomatineni@nvidia.com
State Accepted
Commit f4fcf0108b42a997aace451fa1a0801e1c7de0d3
Headers show
Series None | expand

Commit Message

Sowjanya Komatineni Sept. 21, 2020, 9:39 p.m. UTC
Sensor should already be in standby during remove and there is no
need to configure sensor registers for stream stop.

Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
 drivers/media/i2c/imx274.c | 3 ---
 1 file changed, 3 deletions(-)

Comments

Thierry Reding Sept. 22, 2020, 7:55 a.m. UTC | #1
On Mon, Sep 21, 2020 at 02:39:38PM -0700, Sowjanya Komatineni wrote:
> Sensor should already be in standby during remove and there is no
> need to configure sensor registers for stream stop.
> 
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
>  drivers/media/i2c/imx274.c | 3 ---
>  1 file changed, 3 deletions(-)

Reviewed-by: Thierry Reding <treding@nvidia.com>
Luca Ceresoli Sept. 22, 2020, 8:09 a.m. UTC | #2
Hi,

On 21/09/20 23:39, Sowjanya Komatineni wrote:
> Sensor should already be in standby during remove and there is no
> need to configure sensor registers for stream stop.

I beg your pardon for the newbie question: does the V4L2 framework
guarantee that the stream is stopped (.s_stream(..., 0)) before removing
the driver?

Thanks,
Luca Ceresoli Sept. 24, 2020, 10:09 a.m. UTC | #3
On 22/09/20 10:47, Sakari Ailus wrote:
> Hi Luca,
> 
> On Tue, Sep 22, 2020 at 10:09:33AM +0200, Luca Ceresoli wrote:
>> Hi,
>>
>> On 21/09/20 23:39, Sowjanya Komatineni wrote:
>>> Sensor should already be in standby during remove and there is no
>>> need to configure sensor registers for stream stop.
>>
>> I beg your pardon for the newbie question: does the V4L2 framework
>> guarantee that the stream is stopped (.s_stream(..., 0)) before removing
>> the driver?
> 
> It doesn't. That's however one of the lesser concerns, and I don't think
> it'd help if drivers tried to prepare for that.

Thanks for the clarification.

I've been working with hardware where the sensor is always powered. In
this case, and with this patch applied, the sensor would keep producing
frames after driver removal. This looks wrong, unless I'm overlooking
something.

BTW at first sight it looks like the framework should take care of
stopping the stream before removal, not the individual drivers, but
maybe there are good reasons this is not done?
Sakari Ailus Sept. 24, 2020, 5:24 p.m. UTC | #4
On Thu, Sep 24, 2020 at 12:09:22PM +0200, Luca Ceresoli wrote:
> On 22/09/20 10:47, Sakari Ailus wrote:
> > Hi Luca,
> > 
> > On Tue, Sep 22, 2020 at 10:09:33AM +0200, Luca Ceresoli wrote:
> >> Hi,
> >>
> >> On 21/09/20 23:39, Sowjanya Komatineni wrote:
> >>> Sensor should already be in standby during remove and there is no
> >>> need to configure sensor registers for stream stop.
> >>
> >> I beg your pardon for the newbie question: does the V4L2 framework
> >> guarantee that the stream is stopped (.s_stream(..., 0)) before removing
> >> the driver?
> > 
> > It doesn't. That's however one of the lesser concerns, and I don't think
> > it'd help if drivers tried to prepare for that.
> 
> Thanks for the clarification.
> 
> I've been working with hardware where the sensor is always powered. In
> this case, and with this patch applied, the sensor would keep producing
> frames after driver removal. This looks wrong, unless I'm overlooking
> something.
> 
> BTW at first sight it looks like the framework should take care of
> stopping the stream before removal, not the individual drivers, but
> maybe there are good reasons this is not done?

Yes, it should.

This is a complex problem area to address. The framework (V4L2) wasn't
originally built with object refcounting when support was added for complex
cameras that comprise multiple devices because it wasn't thought it would
be really needed. And it's hard to add that later on.

Either way, there's little individual drivers can do to address that; the
framework support needs to be there first.

The same goes with Media controller; it's not just V4L2.
diff mbox series

Patch

diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index a4b9dfd..5e515f0 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -1968,9 +1968,6 @@  static int imx274_remove(struct i2c_client *client)
 	struct v4l2_subdev *sd = i2c_get_clientdata(client);
 	struct stimx274 *imx274 = to_imx274(sd);
 
-	/* stop stream */
-	imx274_write_table(imx274, imx274_stop);
-
 	v4l2_async_unregister_subdev(sd);
 	v4l2_ctrl_handler_free(&imx274->ctrls.handler);
 	media_entity_cleanup(&sd->entity);