From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06CCBC4363D for ; Thu, 24 Sep 2020 10:09:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B2A202396E for ; Thu, 24 Sep 2020 10:09:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727369AbgIXKJ3 (ORCPT ); Thu, 24 Sep 2020 06:09:29 -0400 Received: from hostingweb31-40.netsons.net ([89.40.174.40]:39229 "EHLO hostingweb31-40.netsons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726597AbgIXKJ3 (ORCPT ); Thu, 24 Sep 2020 06:09:29 -0400 Received: from [77.244.183.192] (port=62008 helo=[192.168.178.24]) by hostingweb31.netsons.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kLOBp-000GrA-Jp; Thu, 24 Sep 2020 12:09:25 +0200 Subject: Re: [PATCH v6 2/3] media: i2c: imx274: Remove stop stream i2c writes during remove To: Sakari Ailus Cc: Sowjanya Komatineni , thierry.reding@gmail.com, jonathanh@nvidia.com, hverkuil@xs4all.nl, jacopo+renesas@jmondi.org, leonl@leopardimaging.com, robh+dt@kernel.org, lgirdwood@gmail.com, broonie@kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <1600724379-7324-1-git-send-email-skomatineni@nvidia.com> <1600724379-7324-3-git-send-email-skomatineni@nvidia.com> <20200922084746.GA8644@valkosipuli.retiisi.org.uk> From: Luca Ceresoli Message-ID: Date: Thu, 24 Sep 2020 12:09:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200922084746.GA8644@valkosipuli.retiisi.org.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostingweb31.netsons.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: hostingweb31.netsons.net: authenticated_id: luca@lucaceresoli.net X-Authenticated-Sender: hostingweb31.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? -- Luca