Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp154715iob; Mon, 2 May 2022 15:45:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhFULQ4h24QMGUlzf4uefDaUrC22DJ7O6p3PI8yw5ebHGhBNHDnYkjommGERA+sGW39YP9 X-Received: by 2002:a2e:bf04:0:b0:246:7ace:e157 with SMTP id c4-20020a2ebf04000000b002467acee157mr8777999ljr.241.1651531510989; Mon, 02 May 2022 15:45:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651531510; cv=none; d=google.com; s=arc-20160816; b=eoZICqfj6GwX33YDQwXhTizUEzECVvh9mIMKCX9z9oqvAlRI9QVvJ87mcB8hi3g2PI Wls0L2H8up/+sbN4xfj91RrMCd9ko/CwnY5pq0msJeEMb5J/1gEeow0nkwE5BaCYJ8Ss TtqnOrevpNq3feUUtEhsIdQFDLTgQ2JIUZg5GUpJ+WGX4TdEsyXAjcgb9D6Uwq7e+Ejv AYuHYQXUdKWbeDHiqbTVu1gL4XG6kQYA2UJGiD1NLzfGmJKYr9h6AXfwF8HBdGDjiqhL H24BzsXH64lfpUqnNg60svRW3sKZQjBWjF7IuQ1oHPZ3vA92nn5HkFsCLbNZL/lTEKSH YW1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=kQgxyh2bdYJWM9c1jY+zgnOo4VkXauUrSGmGMNZvvNA=; b=tdajvUQl5PvFhviWqVySxgOcvtd0Vb5E8Bj4lCAlz2NnioQzktlxjXhDBFH5LN4ql7 2r7w8eFac9vdM2lTRU3NaQhxaD9uwkI7pKbGBaU3YECWJAGxVYP1SwyG4yPzwe3kTz3I Ir/ACtpFieM3IjbQwUT6jaspHOj679nahB2sDtXt6WfcjiWQ8S0bVaQEB5w9SeTpVdz3 kwRjRn7Hbk5/xk5+ZiDB3BPJJZdd8YYrzVPDffWM7XHpTV5iv4NIlBjaW0NP2wrtLF4X hdvyC00OMRod3h/gg9KYsK7oNA5e0p9kTOUb2ua6THek/cpn7ZI6U9oEYVKXca+g8jWO Lhzg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e23-20020a2e9e17000000b0024952f7bac1si15094796ljk.28.2022.05.02.15.44.43; Mon, 02 May 2022 15:45:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359534AbiD2MyC (ORCPT + 99 others); Fri, 29 Apr 2022 08:54:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359506AbiD2Mxt (ORCPT ); Fri, 29 Apr 2022 08:53:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8801C13E02; Fri, 29 Apr 2022 05:50:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3CDB262219; Fri, 29 Apr 2022 12:50:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96C79C385A7; Fri, 29 Apr 2022 12:50:26 +0000 (UTC) Message-ID: Date: Fri, 29 Apr 2022 14:50:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v9 08/13] media: atmel: atmel-isc: change format propagation to subdev into only verification Content-Language: en-US To: Jacopo Mondi , Laurent Pinchart Cc: Eugen.Hristev@microchip.com, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Claudiu.Beznea@microchip.com, robh+dt@kernel.org, Nicolas.Ferre@microchip.com References: <20220429095848.ec4xnul6tin6n7sf@uno.localdomain> <50b07246-39ed-2e5d-05ff-b8b482cb2bcb@xs4all.nl> <540a488a-5e3e-6031-b358-a02448b4d52a@xs4all.nl> <20220429123859.bu7anjhtk4i2ukns@uno.localdomain> From: Hans Verkuil In-Reply-To: <20220429123859.bu7anjhtk4i2ukns@uno.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/04/2022 14:38, Jacopo Mondi wrote: > Hi > > On Fri, Apr 29, 2022 at 03:28:11PM +0300, Laurent Pinchart wrote: >> On Fri, Apr 29, 2022 at 02:23:45PM +0200, Hans Verkuil wrote: >>> On 29/04/2022 14:02, Laurent Pinchart wrote: >>>> On Fri, Apr 29, 2022 at 01:17:27PM +0200, Hans Verkuil wrote: >>>>> On 29/04/2022 12:20, Laurent Pinchart wrote: >>>>>> On Fri, Apr 29, 2022 at 12:13:46PM +0200, Hans Verkuil wrote: >>>>>>> On 29/04/2022 12:07, Laurent Pinchart wrote: >>>>>>>> On Fri, Apr 29, 2022 at 11:58:48AM +0200, Jacopo Mondi wrote: >>>>>>>>> On Fri, Apr 29, 2022 at 10:43:09AM +0200, Hans Verkuil wrote: >>>>>>>>>> On 29/04/2022 10:28, Eugen.Hristev@microchip.com wrote: >>>>>>>>>>> On 4/29/22 11:17 AM, Hans Verkuil wrote: >>>>>>>>>>>> On 10/03/2022 10:51, Eugen Hristev wrote: >>>>>>>>>>>>> As a top MC video driver, the atmel-isc should not propagate the format to the >>>>>>>>>>>>> subdevice, it should rather check at start_streaming() time if the subdev is properly >>>>>>>>>>>>> configured with a compatible format. >>>>>>>>>>>>> Removed the whole format finding logic, and reworked the format verification >>>>>>>>>>>>> at start_streaming time, such that the ISC will return an error if the subdevice >>>>>>>>>>>>> is not properly configured. To achieve this, media_pipeline_start >>>>>>>>>>>>> is called and a link_validate callback is created to check the formats. >>>>>>>>>>>>> With this being done, the module parameter 'sensor_preferred' makes no sense >>>>>>>>>>>>> anymore. The ISC should not decide which format the sensor is using. The >>>>>>>>>>>>> ISC should only cope with the situation and inform userspace if the streaming >>>>>>>>>>>>> is possible in the current configuration. >>>>>>>>>>>>> The redesign of the format propagation has also risen the question of the >>>>>>>>>>>>> enumfmt callback. If enumfmt is called with an mbus_code, the enumfmt handler >>>>>>>>>>>>> should only return the formats that are supported for this mbus_code. >>>>>>>>>>>>> Otherwise, the enumfmt will report all the formats that the ISC could output. >>>>>>>>>>>>> With this rework, the dynamic list of user formats is removed. It makes no >>>>>>>>>>>>> more sense to identify at complete time which formats the sensor could emit, >>>>>>>>>>>>> and add those into a separate dynamic list. >>>>>>>>>>>>> The ISC will start with a simple preconfigured default format, and at >>>>>>>>>>>>> link validate time, decide whether it can use the format that is configured >>>>>>>>>>>>> on the sink or not. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Eugen Hristev >>>>>>>>>>>>> Reviewed-by: Jacopo Mondi >>>>>>>>>>>>> --- >>>>>>>>>>>>> Changes in v9: >>>>>>>>>>>>> - isc_link_validate now static >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v7: >>>>>>>>>>>>> - minor typos as suggested by Jacopo >>>>>>>>>>>>> - small changes, reduce some indentation, modified an index, as suggested by >>>>>>>>>>>>> Jacopo >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v6: >>>>>>>>>>>>> - reworked a bit enum_fmt as suggested by Jacopo >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v5: >>>>>>>>>>>>> - removed user_formats dynamic list as it is now pointless >>>>>>>>>>>>> - greatly simplified the enum_fmt function >>>>>>>>>>>>> - removed some init code that was useless now >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v4: >>>>>>>>>>>>> - moved validation code into link_validate and used media_pipeline_start >>>>>>>>>>>>> - merged this patch with the enum_fmt patch which was previously in v3 of >>>>>>>>>>>>> the series >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in v3: >>>>>>>>>>>>> - clamp to maximum resolution once the frame size from the subdev is found >>>>>>>>>>>>> drivers/media/platform/atmel/atmel-isc-base.c | 412 ++++++++---------- >>>>>>>>>>>>> .../media/platform/atmel/atmel-isc-scaler.c | 5 + >>>>>>>>>>>>> drivers/media/platform/atmel/atmel-isc.h | 13 +- >>>>>>>>>>>>> .../media/platform/atmel/atmel-sama5d2-isc.c | 20 + >>>>>>>>>>>>> .../media/platform/atmel/atmel-sama7g5-isc.c | 20 + >>>>>>>>>>>>> 5 files changed, 236 insertions(+), 234 deletions(-) >>>>>>>>>>>>> >>>>>>>>>>>>> diff --git a/drivers/media/platform/atmel/atmel-isc-base.c b/drivers/media/platform/atmel/atmel-isc-base.c >>>>>>>>>>>>> index ee1dda6707a0..fe2c0af58060 100644 >>>>>>>>>>>>> --- a/drivers/media/platform/atmel/atmel-isc-base.c >>>>>>>>>>>>> +++ b/drivers/media/platform/atmel/atmel-isc-base.c >>>>>>>>>>>>> @@ -36,11 +36,6 @@ static unsigned int debug; >>>>>>>>>>>>> module_param(debug, int, 0644); >>>>>>>>>>>>> MODULE_PARM_DESC(debug, "debug level (0-2)"); >>>>>>>>>>>>> >>>>>>>>>>>>> -static unsigned int sensor_preferred = 1; >>>>>>>>>>>>> -module_param(sensor_preferred, uint, 0644); >>>>>>>>>>>>> -MODULE_PARM_DESC(sensor_preferred, >>>>>>>>>>>>> - "Sensor is preferred to output the specified format (1-on 0-off), default 1"); >>>>>>>>>>>>> - >>>>>>>>>>>>> #define ISC_IS_FORMAT_RAW(mbus_code) \ >>>>>>>>>>>>> (((mbus_code) & 0xf000) == 0x3000) >>>>>>>>>>>>> >>>>>>>>>>>>> @@ -337,6 +332,10 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count) >>>>>>>>>>>>> unsigned long flags; >>>>>>>>>>>>> int ret; >>>>>>>>>>>>> >>>>>>>>>>>>> + ret = media_pipeline_start(&isc->video_dev.entity, &isc->mpipe); >>>>>>>>>>>> >>>>>>>>>>>> The pipeline validation is done in start_streaming, but I don't think that >>>>>>>>>>>> is the best place: if STREAMON is called before buffers are queued, then >>>>>>>>>>>> an invalid pipeline isn't discovered until enough buffers are queued to >>>>>>>>>>>> kick off start_streaming. >>>>>>>>>>>> >>>>>>>>>>>> Drivers like vsp1, omap3isp and the samsung drivers all do this in streamon(). >>>>>>>>>>>> >>>>>>>>>>>> I think that is the correct time to do this. >>>>>>>>>>> >>>>>>>>>>> Hello Hans, >>>>>>>>>>> >>>>>>>>>>> Initially (v2, v3) I had this in streamon(). The problem that I faced at >>>>>>>>>>> that time was that streamoff was never called, so I could not call >>>>>>>>>>> media_pipeline_stop(). Then Jacopo told me to move it to start_streaming >>>>>>>>>>> (see change log for v4) , and I did not face any more problems. >>>>>>>>> >>>>>>>>> Yes indeed, seems I suggested to use media_pipeline_handler in a >>>>>>>>> comment on your v3 >>>>>>>>> >>>>>>>>> "at s_stream time your top driver calls media_pipeline_start()" >>>>>>>>> >>>>>>>>> sorry about that, I should have looked around a bit more carefully and >>>>>>>>> notice most drivers do so at vb2 streamon >>>>>>>>> >>>>>>>>> However I don't see media_pipeline_start being called at all in v3 of >>>>>>>>> the patch >>>>>>>>> >>>>>>>>>> It's a mess. Looking at some drivers I see that omap3isp calls media_pipeline_stop >>>>>>>>>> in streamoff (so will have the same problem as you described if VIDIOC_STREAMOFF >>>>>>>>>> isn't called), exynos4-is does the same, but it also checks the streaming state in >>>>>>>>>> the release() fop callback, so that would fix this problem. And vimc does this >>>>>>>>>> in stop_streaming. >>>>>>>>>> >>>>>>>>>> I'm in favor of fixing this in vb2, that framework knows exactly when this needs >>>>>>>>>> to be called. >>>>>>>>> >>>>>>>>> Are you suggesting to have vb2 to call media_pipeline_start() or is it >>>>>>>>> more complex than this ? >>>>>>>> >>>>>>>> I think Hans meant adding a .validate() operation to vb2. >>>>>>>> >>>>>>>> vb2 is already quite complex, I don't think adding more features is a >>>>>>>> good idea. I'd rather have vb2 focus on buffer management only >>>>>>>> (.start_streaming() and .stop_streaming() shouldn't have been in there >>>>>>>> in my opinion), and handle validation in the .streamon() handler. I'd >>>>>>>> expect most drivers that deal with media pipelines to do more work in >>>>>>>> .streamon() anyway. >>>>>>> >>>>>>> I disagree with that :-) >>>>>>> >>>>>>> It's vb2 that keeps track of the streaming state and when what actions >>>>>>> need to be taken. Drivers really shouldn't need to care about the ioctls >>>>>>> themselves, and just implement the relevant vb2 callbacks. Relying on >>>>>>> drivers to handle any of the streaming ioctls is asking for problems, >>>>>>> as this shows: most drivers implement this wrong today. >>>>>>> >>>>>>> The vb2 framework knows when e.g. the pipeline needs to be started or >>>>>>> stopped, and can do this at the best time, without drivers needing to >>>>>>> keep track of when streamon/off/release is called. Keep that logic in >>>>>>> vb2. >>>>>> >>>>>> Pipeline management and buffer management are two different issues. >>>>>> Don't forget about devices that have multiple video nodes, part of the >>>>>> same pipeline (possibly a combination of output and capture nodes, or >>>>>> all of the same type). Forcing drivers to go through vb2 operations to >>>>>> handle the pipeline will be messy, will result in more bloat in vb2, and >>>>>> make the result more bug-prone and harder to maintain. >>>>>> >>>>>> If pipeline management is too complex, let's simplify it, new helpers >>>>>> can make sense, but not through vb2. >>>>> >>>>> But it is vb2 that knows when streaming starts and stops. >>>> >>>> That's right, but pipeline start (which includes validation and resource >>>> reservation) needs to be performed synchronously with VIDIOC_STREAMON. >>>> The streaming state managed by vb2 is not relevant, >>>> media_pipeline_start() must not be delayed the same way >>>> .start_streaming() is. >>> >>> It will be the first thing that vb2_streamon calls. This has nothing to do >>> with start_streaming: that's called when sufficient number of buffers are >>> queued up to be able to start the DMA. This proposed prepare_streaming op >>> will be called when VIDIOC_STREAMON is called. >> >> Then it doesn't need vb2's knowledge of the stream state :-) >> >>>>> The driver just >>>>> needs to be informed (e.g. prepare_streaming and unprepare_streaming ops). >>>>> >>>>> vb2 deals with buffer management and it keeps track of the streaming state >>>>> and makes the streaming state transitions. That *is* an integral part of >>>>> vb2. What is missing at the moment are callbacks done at streamon time and >>>>> when the streaming stops (streamoff, or close() when is_streaming is true). >>>>> >>>>> If you want to implement stream validation in a driver, then there are a >>>>> lot of things you need to do: >>>>> >>>>> - override streamon, make sure you call vb2_queue_is_busy(), validate the >>>>> pipeline, then call vb2_streamon, if that fails, remember to stop the >>>>> pipeline. >>>>> >>>>> - override streamoff, make sure you call vb2_queue_is_busy(), stop the >>>>> pipeline and call vb2_streamoff. >>>>> >>>>> - in the release() function when the fh is closed, you have to check >>>>> vb2_is_streaming(), check that you are the owner of the queue, and if true, >>>>> stop the pipeline. >>>> >>>> I'm not opposed to helper functions to implement that, they can bundle >>>> vb2 calls and pipeline management. >>>> >>>>> By moving this to vb2 ops all you need to implement are the prepare and >>>>> unprepare ops. >>>>> >>>>> Esp. the release() implementation is tricky. I'm pretty sure that >>>>> drivers/media/platform/samsung/exynos4-is/fimc-lite.c is wrong, since it >>>>> should only call media_pipeline_stop() for the owner of the queue. Instead >>>>> it calls it for the last user of the queue. >>>>> >>>>> I see that fimc_lite_streamoff() is wrong too: you can safely call >>>>> VIDIOC_STREAMOFF twice: the second streamoff just returns 0 without >>>>> doing anything. Instead media_pipeline_stop is called without testing if >>>>> the queue is streaming. >>>>> >>>>> And yes, this is in part because V4L2 has quite some history and certainly >>>>> API choice were made in the past that we wouldn't make today. But vb2 >>>>> shields you from that, and behaves much more like a proper state machine. >>>>> >>>>> I know you prefer to give a lot more control to driver developers, but >>>>> in my experience very few developers can do things like this right. And >>>>> it is really hard as a reviewer to check if all the corner cases are handled >>>>> correctly in a driver. If vb2 is used, then I know things are called at the >>>>> right time, and that makes my life as reviewer so much easier. >>>> >>>> It's not just about giving more control to drivers, it's about >>>> organizing the software layers in a way that keeps them maintainable, >>>> with layered abstractions and not midlayers. >>>> >>>> We are extensively reworking the media pipeline management as part of >>>> the stream series, and there will be more work on top of that that will >>>> make even more fundamental changes. I would like to at least postpone >>>> any work on vb2 until then, to be able to evaluate the impact. >>> >>> I'll make an RFC patch for vb2 so you have a better idea of what it does. >> >> As long as we don't merge it before I get the chance to send the media >> pipeline management rework, I'm all for RFCs :-) >> > > To unblock Eugen is it fine if he moves media_pipeline_start() at > streamon() time for now ? It will require overriding > v4l2_ioctl.vidioc_streamon which might be a bit of additional work > (but probably easier to replace once a proper solution lands) > > Otherwise, should the series go in as it is now ? I had a comment about patch 6, so I want a new series anyway. All the patches with just fixes (everything but 4 and 8) can go in once I have them. I think - all things considered - it is currently best to start and stop the pipeline in start/stop_streaming: that at least avoids all the complications with streamon/off/close() that is really hard to get right without (IMHO) my proposed vb2 changes. With that I will accept the series. Regards, Hans > > Thanks > j > >>>>> There may still be a few drivers that really need to do this manually, and >>>>> that's OK, but a driver like the atmel-isc doesn't need that at all. >> >> -- >> Regards, >> >> Laurent Pinchart