From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933427AbdCKS67 (ORCPT ); Sat, 11 Mar 2017 13:58:59 -0500 Received: from mail-pf0-f195.google.com ([209.85.192.195]:35668 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755314AbdCKS6v (ORCPT ); Sat, 11 Mar 2017 13:58:51 -0500 Subject: Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event To: Russell King - ARM Linux References: <1489121599-23206-1-git-send-email-steve_longerbeam@mentor.com> <1489121599-23206-16-git-send-email-steve_longerbeam@mentor.com> <5b0a0e76-2524-4140-5ccc-380a8f949cfa@xs4all.nl> <6b574476-77df-0e25-a4d1-32d4fe0aec12@xs4all.nl> <5d5cf4a4-a4d3-586e-cd16-54f543dfcce9@gmail.com> <20170311185137.GE21222@n2100.armlinux.org.uk> Cc: Hans Verkuil , robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org, kernel@pengutronix.de, fabio.estevam@nxp.com, mchehab@kernel.org, nick@shmanahar.org, markus.heiser@darmarIT.de, p.zabel@pengutronix.de, laurent.pinchart+renesas@ideasonboard.com, bparrot@ti.com, geert@linux-m68k.org, arnd@arndb.de, sudipm.mukherjee@gmail.com, minghsiu.tsai@mediatek.com, tiffany.lin@mediatek.com, jean-christophe.trotin@st.com, horms+renesas@verge.net.au, niklas.soderlund+renesas@ragnatech.se, robert.jarzmik@free.fr, songjun.wu@microchip.com, andrew-ct.chen@mediatek.com, gregkh@linuxfoundation.org, shuah@kernel.org, sakari.ailus@linux.intel.com, pavel@ucw.cz, devel@driverdev.osuosl.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org From: Steve Longerbeam Message-ID: Date: Sat, 11 Mar 2017 10:58:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170311185137.GE21222@n2100.armlinux.org.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote: > On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote: >> On 03/11/2017 03:39 AM, Hans Verkuil wrote: >>> It's fine to use an internal event as long as the end-user doesn't >>> see it. But if you lose vsyncs, then you never capture another frame, >>> right? >> >> No, that's not correct. By loss of vertical sync, I mean the IPU >> captures portions of two different frames, resulting in a permanent >> "split image", with one frame containing portions of two consecutive >> images. Or, the video rolls continuously, if you remember the old CRT >> television sets of yore, it's the same rolling effect. > > I have seen that rolling effect, but the iMX6 regains correct sync > within one complete "roll" just fine here with IMX219. However, it > has always recovered. I've seen permanent split images, and rolling that continues for minutes. > > So, I don't think there's a problem with the iMX6 part of the > processing, and so I don't think we should cripple the iMX6 capture > drivers for this problem. > > It seems to me that the problem is with the source. The the problem is almost surely in the CSI. It's handling of the bt.656 sync codes is broken in some way. Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Longerbeam Subject: Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Date: Sat, 11 Mar 2017 10:58:46 -0800 Message-ID: References: <1489121599-23206-1-git-send-email-steve_longerbeam@mentor.com> <1489121599-23206-16-git-send-email-steve_longerbeam@mentor.com> <5b0a0e76-2524-4140-5ccc-380a8f949cfa@xs4all.nl> <6b574476-77df-0e25-a4d1-32d4fe0aec12@xs4all.nl> <5d5cf4a4-a4d3-586e-cd16-54f543dfcce9@gmail.com> <20170311185137.GE21222@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170311185137.GE21222@n2100.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Russell King - ARM Linux Cc: mark.rutland@arm.com, andrew-ct.chen@mediatek.com, minghsiu.tsai@mediatek.com, sakari.ailus@linux.intel.com, nick@shmanahar.org, songjun.wu@microchip.com, Hans Verkuil , pavel@ucw.cz, robert.jarzmik@free.fr, devel@driverdev.osuosl.org, markus.heiser@darmarIT.de, laurent.pinchart+renesas@ideasonboard.com, shuah@kernel.org, geert@linux-m68k.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, kernel@pengutronix.de, arnd@arndb.de, mchehab@kernel.org, bparrot@ti.com, robh+dt@kernel.org, horms+renesas@verge.net.au, tiffany.lin@mediatek.com, linux-arm-kernel@lists.infradead.org, niklas.soderlund+renesas@ragnatech.se, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, jean-christophe.trotin@st.com, p.zabel@pengutronix.de, fabio.estevam@nxp.com, shawnguo@kernel.org, sudipm.mukherjee@gmail.com List-Id: devicetree@vger.kernel.org On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote: > On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote: >> On 03/11/2017 03:39 AM, Hans Verkuil wrote: >>> It's fine to use an internal event as long as the end-user doesn't >>> see it. But if you lose vsyncs, then you never capture another frame, >>> right? >> >> No, that's not correct. By loss of vertical sync, I mean the IPU >> captures portions of two different frames, resulting in a permanent >> "split image", with one frame containing portions of two consecutive >> images. Or, the video rolls continuously, if you remember the old CRT >> television sets of yore, it's the same rolling effect. > > I have seen that rolling effect, but the iMX6 regains correct sync > within one complete "roll" just fine here with IMX219. However, it > has always recovered. I've seen permanent split images, and rolling that continues for minutes. > > So, I don't think there's a problem with the iMX6 part of the > processing, and so I don't think we should cripple the iMX6 capture > drivers for this problem. > > It seems to me that the problem is with the source. The the problem is almost surely in the CSI. It's handling of the bt.656 sync codes is broken in some way. Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: slongerbeam@gmail.com (Steve Longerbeam) Date: Sat, 11 Mar 2017 10:58:46 -0800 Subject: [PATCH v5 15/39] [media] v4l2: add a frame interval error event In-Reply-To: <20170311185137.GE21222@n2100.armlinux.org.uk> References: <1489121599-23206-1-git-send-email-steve_longerbeam@mentor.com> <1489121599-23206-16-git-send-email-steve_longerbeam@mentor.com> <5b0a0e76-2524-4140-5ccc-380a8f949cfa@xs4all.nl> <6b574476-77df-0e25-a4d1-32d4fe0aec12@xs4all.nl> <5d5cf4a4-a4d3-586e-cd16-54f543dfcce9@gmail.com> <20170311185137.GE21222@n2100.armlinux.org.uk> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/11/2017 10:51 AM, Russell King - ARM Linux wrote: > On Sat, Mar 11, 2017 at 10:14:49AM -0800, Steve Longerbeam wrote: >> On 03/11/2017 03:39 AM, Hans Verkuil wrote: >>> It's fine to use an internal event as long as the end-user doesn't >>> see it. But if you lose vsyncs, then you never capture another frame, >>> right? >> >> No, that's not correct. By loss of vertical sync, I mean the IPU >> captures portions of two different frames, resulting in a permanent >> "split image", with one frame containing portions of two consecutive >> images. Or, the video rolls continuously, if you remember the old CRT >> television sets of yore, it's the same rolling effect. > > I have seen that rolling effect, but the iMX6 regains correct sync > within one complete "roll" just fine here with IMX219. However, it > has always recovered. I've seen permanent split images, and rolling that continues for minutes. > > So, I don't think there's a problem with the iMX6 part of the > processing, and so I don't think we should cripple the iMX6 capture > drivers for this problem. > > It seems to me that the problem is with the source. The the problem is almost surely in the CSI. It's handling of the bt.656 sync codes is broken in some way. Steve