Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp172064iob; Mon, 2 May 2022 16:13:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkQXf9nltKAwVByBMIXcEW4zaX13mNW2rqRNxbB81H6pgWLYeMbEhYX7TqeIm0jtGqK4tF X-Received: by 2002:a17:902:ce8e:b0:15e:a99c:3731 with SMTP id f14-20020a170902ce8e00b0015ea99c3731mr5852057plg.50.1651533237083; Mon, 02 May 2022 16:13:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651533237; cv=none; d=google.com; s=arc-20160816; b=AYLQr4u7kD7f/SuYK/gZA1RUCwcxIUSA6wWwc3tnZ7MiUsTPG0SRtttFsKenJa3AYi k+ImEID+R49EFOCg0h1LHzDBnwUJ22fBVhDDCIXv5r/AL92P+cGcPEguN7+XwW7UQfbf xCo6n0iOpY6K8+wzW/Qg8IsdjlM7KzQ3AFfJNH05F9aQNhbl40v7bzl3XYih4BVpEGSY hb275s2WYxNNvYuqEHTZcxd78P7dbeR+1SHDPG8vedeDfEH0pVBVApcmYZ2bvrkW4Qok IglJLuJ+Ho0HxzrTViqm8+NhgdMTzZWhWGSAuA4omB+azLTb1vnkludaF1aUO+7u/Mfi gE3Q== 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=PBd3uGzUu2SkE2bP0N1X1PxHzelnm/DSNY1bgfiL9HA=; b=AGGzBjh0cx83yzbl9DofDGNbGiLdxAl9jVhglHTSDoxIw6u2SLTYYJXaUYwJLzXufS gW14nLJzeU0mKM3+81vKIKAR5Li0tR1YG+tQikH+B8HLWhy1uVVQmdJU1lZn2mLyQAqx Xapognrrozm2q0eJqHdPPa45xt3T7wzOLuYwfkztAIep7xacWy2BbLnszXvyiNL6lxoI uutbk3i1QP8v5lGMZ3/vUDecCFUeMiBCzAlP8/ZRr78CJAOvUkzSCFykGW7koGTbGu7B 6LaTQSoY4S6Z05MHEX4Kz/qX3wSGq2b+8eKYQVXSools5FNU5w0EidBu7pVFuw8b11lw MN3A== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id p10-20020a65490a000000b003a97e8f54c2si15931889pgs.244.2022.05.02.16.13.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 16:13:57 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xs4all.nl Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6FB292FE7F; Mon, 2 May 2022 16:13:48 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357240AbiD2KRJ (ORCPT + 99 others); Fri, 29 Apr 2022 06:17:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234485AbiD2KRI (ORCPT ); Fri, 29 Apr 2022 06:17:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B14718E3B; Fri, 29 Apr 2022 03:13:51 -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 89D7262310; Fri, 29 Apr 2022 10:13:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4B50C385A4; Fri, 29 Apr 2022 10:13:47 +0000 (UTC) Message-ID: Date: Fri, 29 Apr 2022 12:13:46 +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: Laurent Pinchart , Jacopo Mondi 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: <20220310095202.2701399-1-eugen.hristev@microchip.com> <20220310095202.2701399-9-eugen.hristev@microchip.com> <39f541ec-313f-fe15-b93f-dd78469b2366@xs4all.nl> <20220429095848.ec4xnul6tin6n7sf@uno.localdomain> From: Hans Verkuil In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 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. Regards, Hans