Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6628455imu; Mon, 21 Jan 2019 12:27:00 -0800 (PST) X-Google-Smtp-Source: ALg8bN4wFMUnuJO29Rf9B12CBiLP1HAvTVdGSHl9KDZgS7CjfZQbg+lhx98ZkZ6OsEXE2Tp1cY4y X-Received: by 2002:a17:902:b60a:: with SMTP id b10mr29821868pls.303.1548102420529; Mon, 21 Jan 2019 12:27:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548102420; cv=none; d=google.com; s=arc-20160816; b=hcEkjBEGg2moIZshxSZYUiIh3V+ApDafxmYI5eFbvXhbF1VQVS7Uny4nX6SuwO0amG Y49znevB5QapzfJbx20yNdsbNS5OvHB9g63Ax43oyHm4wbxsUSnbdghkxqTezJZigYeB 2xj9hEGUfw9JPa7VSgsZFwOqWVbDOLaPpg+tEBYu1AjJSJ5YXsEbWzaFg+y7AD1JqzQO mTA6ejsJyZcP63FXsUPJTti4qfTImn4F28qThsSCMFbZRDMxq7iOHroBThij1cvuhhbX l1th2HmxnET5tu+q0ZLKO2bZUZJG2bpUx8b+feZaI7I5PsMy0V42o08RT/R0IF1T1ux1 JUZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+kNxBWcx9FlQtYo+QTClvu5wwFACfZ6lH7rIFaQJ/dA=; b=zI0Bxz5vuVXlkHwZ/V37eBzOg2o3ZSrHlJdLfRS3EU0arcmKIjFyndpvR47iBJobAM 2mrTL+OrdoSHJ7yGMF9JBxou8UGcYGUPzXARoR9VAH8f4Qn2mwNapyr0M2MGbS/ArH2m fBfodMPP2rTREmf5BoMuF2Uo0dJDCSlNpwr5alz4i+CoNGLff5gEaGeBcaJtJANoA9c8 OrmQ/d8yV6pfMvf5xJg5c7dRLbZanfc9MzYmNGkBLJcuhnbuDCcPS/1yrb9SEBZGMncm /ln3jynGtiYtH0HZc+jjyh6SRUCnwAV1djQhePmWCeY6HhfB86L4d3cYzFV0QYc4GZl6 +ljw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=EPRfLJWB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3si13566782pfn.285.2019.01.21.12.26.44; Mon, 21 Jan 2019 12:27:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=EPRfLJWB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728268AbfAUUYz (ORCPT + 99 others); Mon, 21 Jan 2019 15:24:55 -0500 Received: from mail-wr1-f52.google.com ([209.85.221.52]:33734 "EHLO mail-wr1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727997AbfAUUYy (ORCPT ); Mon, 21 Jan 2019 15:24:54 -0500 Received: by mail-wr1-f52.google.com with SMTP id c14so24929522wrr.0 for ; Mon, 21 Jan 2019 12:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kNxBWcx9FlQtYo+QTClvu5wwFACfZ6lH7rIFaQJ/dA=; b=EPRfLJWBNnQ6sKNrd5Rg3vtNCWbJNFvXNvXET2uu5r2GX/7y0p3p0PSzXgm8W58VAr lAfhnL+sVx58kjvIsGE/vKfrZbvmzVb7CgS1A4CKEe/vl6TRl9ocSNB3mo+hSF+hymCB 9KbZF3eV+ihm03Js53l80nHJxMDTIw6zDCcPQC08ukFsPtfYE86w4gcj0CRzZrV5zrz6 2NJYBq7btGdZH3V3selQo4ZFHp+PiiY/4VqkA6IQngviFJLOP8tzp8hZSib9R8WmvGrF Dj76MCayhMpwHg9QcHhDExgYOXgmba78ItOyjlZOZJx2h1nG2LO8OcW/Tg6VcfsJRBlJ PjMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+kNxBWcx9FlQtYo+QTClvu5wwFACfZ6lH7rIFaQJ/dA=; b=dzjiN9Exxr/puZuc0R9O8kcSLwXAJHoWP5Qmzts2Cd9wCdgKpnM2dbdFELF2KJAAfJ BgKxbVScH1pHlJVqoi1OR/sWtf22JzmR82wfD/rAmai/E4YKGcMNB73WkAeIV97y4MpF EefJGGQ4mvYTuA76CtV0pJYdsicx31TEtasFWONuqPSR5usWdOLodPBBKTF1g4HWP9/T gv7MauC2H98QTMy8iv2af7aEc6TJi8Z4hk0S5NE/L6Sd1eXfJZKLn44NbQ3M9Nkq1+n8 fULXBOhr45haiPseMQLNEu88PwfUXqujvGUPUjp0YWBeymmVikf+gkvGNCFeHrveNP4/ Rhxg== X-Gm-Message-State: AJcUukcH7C5QE2ggWwohvB2TbzS+YKYybL06Qdp0VLtCSdRuFsd3ej1y Ggi6P3hZq2vFA2pX3/FWtSb/Sgq8z+hYSBEXV5edGW7rEig= X-Received: by 2002:adf:9b11:: with SMTP id b17mr30007249wrc.168.1548102291697; Mon, 21 Jan 2019 12:24:51 -0800 (PST) MIME-Version: 1.0 References: <20190109183014.20466-1-slongerbeam@gmail.com> <20190109183014.20466-12-slongerbeam@gmail.com> <6b4c3fb1-929b-8894-e2f9-aca2f392f0e5@gmail.com> In-Reply-To: <6b4c3fb1-929b-8894-e2f9-aca2f392f0e5@gmail.com> From: Tim Harvey Date: Mon, 21 Jan 2019 12:24:40 -0800 Message-ID: Subject: Re: [PATCH v8 11/11] media: imx.rst: Update doc to reflect fixes to interlaced capture To: Steve Longerbeam Cc: linux-media , Philipp Zabel , Mauro Carvalho Chehab , open list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2019 at 3:54 PM Steve Longerbeam wrote: > > Hi Tim, > > On 1/15/19 1:58 PM, Tim Harvey wrote: > > On Wed, Jan 9, 2019 at 10:30 AM Steve Longerbeam wrote: > >> Also add an example pipeline for unconverted capture with interweave > >> on SabreAuto. > >> > >> Cleanup some language in various places in the process. > >> > >> Signed-off-by: Steve Longerbeam > >> Reviewed-by: Philipp Zabel > >> --- > >> Changes since v4: > >> - Make clear that it is IDMAC channel that does pixel reordering and > >> interweave, not the CSI. Caught by Philipp Zabel. > >> Changes since v3: > >> - none. > >> Changes since v2: > >> - expand on idmac interweave behavior in CSI subdev. > >> - switch second SabreAuto pipeline example to PAL to give > >> both NTSC and PAL examples. > >> - Cleanup some language in various places. > >> --- > >> Documentation/media/v4l-drivers/imx.rst | 103 +++++++++++++++--------- > >> 1 file changed, 66 insertions(+), 37 deletions(-) > >> > > > >> Capture Pipelines > >> ----------------- > >> @@ -516,10 +522,33 @@ On the SabreAuto, an on-board ADV7180 SD decoder is connected to the > >> parallel bus input on the internal video mux to IPU1 CSI0. > >> > >> The following example configures a pipeline to capture from the ADV7180 > >> -video decoder, assuming NTSC 720x480 input signals, with Motion > >> -Compensated de-interlacing. Pad field types assume the adv7180 outputs > >> -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf > >> -entity at its output pad: > >> +video decoder, assuming NTSC 720x480 input signals, using simple > >> +interweave (unconverted and without motion compensation). The adv7180 > >> +must output sequential or alternating fields (field type 'seq-bt' for > >> +NTSC, or 'alternate'): > >> + > >> +.. code-block:: none > >> + > >> + # Setup links > >> + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > >> + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > >> + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > >> + # Configure pads > >> + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > >> + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > >> + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > >> + # Configure "ipu1_csi0 capture" interface (assumed at /dev/video4) > >> + v4l2-ctl -d4 --set-fmt-video=field=interlaced_bt > >> + > >> +Streaming can then begin on /dev/video4. The v4l2-ctl tool can also be > >> +used to select any supported YUV pixelformat on /dev/video4. > >> + > > Hi Steve, > > > > I'm testing 4.20 with this patchset on top. > > > > I'm on a GW5104 which has an IMX6Q with the adv7180 on ipu1_csi0 like > > the SabeAuto example above I can't get the simple interveave example > > to work: > > > > media-ctl -r # reset all links > > # Setup links (ADV7180 IPU1_CSI0) > > media-ctl -l '"adv7180 2-0020":0 -> "ipu1_csi0_mux":1[1]' > > media-ctl -l '"ipu1_csi0_mux":2 -> "ipu1_csi0":0[1]' > > media-ctl -l '"ipu1_csi0":2 -> "ipu1_csi0 capture":0[1]' # /dev/video4 > > # Configure pads > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > > media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x480]" > > This is the reason. The adv7180 is only allowing to configure alternate > field mode, and thus it reports the field height on the mbus, not the > full frame height. Imx deals with alternate field mode by capturing a > full frame, so the CSI entity sets the output pad height to double the > height. > > So the CSI input pad needs to be configured with the field height: > > media-ctl -V "'ipu1_csi0':0 [fmt:AYUV32/720x240]" > > It should work for you after doing that. And better yet, don't bother > configuring the input pad, because media-ctl will propagate formats from > source to sink pads for you, so it's better to rely on the propagation, > and set the CSI output pad format instead (full frame height at output pad): > > media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480]" > Steve, Thanks - that makes sense. I also noticed that if I setup one of the vdic pipelines first then went back after a 'media-ctl -r' and setup the example that failed it no longer failed. I'm thinking that this is because 'media-ctl -r' make reset all the links but does not reset all the V4L2 formats on pads? > > Final note: the imx.rst doc is technically correct even though it is > showing full frame heights being configured at the pads, because it is > expecting the adv7180 has accepted 'seq-bt'. But even the example given > in that doc works for alternate field mode, because the pad heights are > forced to the correct field height for alternate mode. > hmmm... I don't quite follow this statement. It sounds like the example would only be correct if you were setting 'field:alternate' but the example sets 'field:seq-bt' instead. I wonder if you should add some verbiage explaining the difference in format (resolution specifically) between the input and output pads and/or change the example to set the output pad format so people don't run into what I did trying to follow the example. Tim