From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752169AbdCMN2d (ORCPT ); Mon, 13 Mar 2017 09:28:33 -0400 Received: from pandora.armlinux.org.uk ([78.32.30.218]:58704 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753045AbdCMN2J (ORCPT ); Mon, 13 Mar 2017 09:28:09 -0400 Date: Mon, 13 Mar 2017 13:27:02 +0000 From: Russell King - ARM Linux To: Sakari Ailus Cc: Philipp Zabel , Steve Longerbeam , robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org, kernel@pengutronix.de, fabio.estevam@nxp.com, mchehab@kernel.org, hverkuil@xs4all.nl, nick@shmanahar.org, markus.heiser@darmarIT.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, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, devel@driverdev.osuosl.org, Steve Longerbeam Subject: Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Message-ID: <20170313132701.GJ21222@n2100.armlinux.org.uk> References: <1487211578-11360-1-git-send-email-steve_longerbeam@mentor.com> <1487211578-11360-30-git-send-email-steve_longerbeam@mentor.com> <20170220220409.GX16975@valkosipuli.retiisi.org.uk> <20170221001332.GS21222@n2100.armlinux.org.uk> <25596b21-70de-5e46-f149-f9ce3a86ecb7@gmail.com> <1487667023.2331.8.camel@pengutronix.de> <20170313131647.GB10701@valkosipuli.retiisi.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170313131647.GB10701@valkosipuli.retiisi.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > The vast majority of existing drivers do not implement them nor the user > space expects having to set them. Making that mandatory would break existing > user space. > > In addition, that does not belong to link validation either: link validation > should only include static properties of the link that are required for > correct hardware operation. Frame rate is not such property: hardware that > supports the MC interface generally does not recognise such concept (with > the exception of some sensors). Additionally, it is dynamic: the frame rate > can change during streaming, making its validation at streamon time useless. So how do we configure the CSI, which can do frame skipping? With what you're proposing, it means it's possible to configure the camera sensor source pad to do 50fps. Configure the CSI sink pad to an arbitary value, such as 30fps, and configure the CSI source pad to 15fps. What you actually get out of the CSI is 25fps, which bears very little with the actual values used on the CSI source pad. You could say "CSI should ask the camera sensor" - well, that's fine if it's immediately downstream, but otherwise we'd need to go walking down the graph to find something that resembles its source - there may be mux and CSI2 interface subdev blocks in that path. Or we just accept that frame rates are completely arbitary and bear no useful meaning what so ever. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Date: Mon, 13 Mar 2017 13:27:02 +0000 Message-ID: <20170313132701.GJ21222@n2100.armlinux.org.uk> References: <1487211578-11360-1-git-send-email-steve_longerbeam@mentor.com> <1487211578-11360-30-git-send-email-steve_longerbeam@mentor.com> <20170220220409.GX16975@valkosipuli.retiisi.org.uk> <20170221001332.GS21222@n2100.armlinux.org.uk> <25596b21-70de-5e46-f149-f9ce3a86ecb7@gmail.com> <1487667023.2331.8.camel@pengutronix.de> <20170313131647.GB10701@valkosipuli.retiisi.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170313131647.GB10701@valkosipuli.retiisi.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Sakari Ailus 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, hverkuil@xs4all.nl, Steve Longerbeam , 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, Steve Longerbeam , 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, Philipp Zabel , fabio.estevam@nxp.com, shawnguo List-Id: devicetree@vger.kernel.org On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > The vast majority of existing drivers do not implement them nor the user > space expects having to set them. Making that mandatory would break existing > user space. > > In addition, that does not belong to link validation either: link validation > should only include static properties of the link that are required for > correct hardware operation. Frame rate is not such property: hardware that > supports the MC interface generally does not recognise such concept (with > the exception of some sensors). Additionally, it is dynamic: the frame rate > can change during streaming, making its validation at streamon time useless. So how do we configure the CSI, which can do frame skipping? With what you're proposing, it means it's possible to configure the camera sensor source pad to do 50fps. Configure the CSI sink pad to an arbitary value, such as 30fps, and configure the CSI source pad to 15fps. What you actually get out of the CSI is 25fps, which bears very little with the actual values used on the CSI source pad. You could say "CSI should ask the camera sensor" - well, that's fine if it's immediately downstream, but otherwise we'd need to go walking down the graph to find something that resembles its source - there may be mux and CSI2 interface subdev blocks in that path. Or we just accept that frame rates are completely arbitary and bear no useful meaning what so ever. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Mon, 13 Mar 2017 13:27:02 +0000 Subject: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates In-Reply-To: <20170313131647.GB10701@valkosipuli.retiisi.org.uk> References: <1487211578-11360-1-git-send-email-steve_longerbeam@mentor.com> <1487211578-11360-30-git-send-email-steve_longerbeam@mentor.com> <20170220220409.GX16975@valkosipuli.retiisi.org.uk> <20170221001332.GS21222@n2100.armlinux.org.uk> <25596b21-70de-5e46-f149-f9ce3a86ecb7@gmail.com> <1487667023.2331.8.camel@pengutronix.de> <20170313131647.GB10701@valkosipuli.retiisi.org.uk> Message-ID: <20170313132701.GJ21222@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote: > The vast majority of existing drivers do not implement them nor the user > space expects having to set them. Making that mandatory would break existing > user space. > > In addition, that does not belong to link validation either: link validation > should only include static properties of the link that are required for > correct hardware operation. Frame rate is not such property: hardware that > supports the MC interface generally does not recognise such concept (with > the exception of some sensors). Additionally, it is dynamic: the frame rate > can change during streaming, making its validation at streamon time useless. So how do we configure the CSI, which can do frame skipping? With what you're proposing, it means it's possible to configure the camera sensor source pad to do 50fps. Configure the CSI sink pad to an arbitary value, such as 30fps, and configure the CSI source pad to 15fps. What you actually get out of the CSI is 25fps, which bears very little with the actual values used on the CSI source pad. You could say "CSI should ask the camera sensor" - well, that's fine if it's immediately downstream, but otherwise we'd need to go walking down the graph to find something that resembles its source - there may be mux and CSI2 interface subdev blocks in that path. Or we just accept that frame rates are completely arbitary and bear no useful meaning what so ever. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.