Message ID | 1538059567-8381-4-git-send-email-hugues.fruchet@st.com (mailing list archive) |
---|---|
State | New |
Delegated to: | Sakari Ailus |
Headers |
Received: from vger.kernel.org ([209.132.180.67]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <linux-media-owner@vger.kernel.org>) id 1g5XYm-0003Ll-Vo; Thu, 27 Sep 2018 14:46:33 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727621AbeI0VFE (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Thu, 27 Sep 2018 17:05:04 -0400 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:48166 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727541AbeI0VFD (ORCPT <rfc822;linux-media@vger.kernel.org>); Thu, 27 Sep 2018 17:05:03 -0400 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w8REd0KU009398; Thu, 27 Sep 2018 16:46:17 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2mnb6xugs0-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Sep 2018 16:46:17 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 24EF134; Thu, 27 Sep 2018 14:46:16 +0000 (GMT) Received: from Webmail-eu.st.com (Safex1hubcas22.st.com [10.75.90.92]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id F0C2E4E0A; Thu, 27 Sep 2018 14:46:15 +0000 (GMT) Received: from SAFEX1HUBCAS23.st.com (10.75.90.46) by Safex1hubcas22.st.com (10.75.90.92) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 27 Sep 2018 16:46:15 +0200 Received: from localhost (10.201.23.73) by webmail-ga.st.com (10.75.90.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 27 Sep 2018 16:46:15 +0200 From: Hugues Fruchet <hugues.fruchet@st.com> To: Steve Longerbeam <slongerbeam@gmail.com>, Sakari Ailus <sakari.ailus@iki.fi>, Hans Verkuil <hverkuil@xs4all.nl>, "Mauro Carvalho Chehab" <mchehab@kernel.org>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Maxime Ripard <maxime.ripard@bootlin.com> CC: <devicetree@vger.kernel.org>, <linux-media@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, Hugues Fruchet <hugues.fruchet@st.com>, Benjamin Gaignard <benjamin.gaignard@linaro.org>, Jacopo Mondi <jacopo@jmondi.org> Subject: [PATCH 3/4] media: dt-bindings: media: Document pclk-max-frequency property Date: Thu, 27 Sep 2018 16:46:06 +0200 Message-ID: <1538059567-8381-4-git-send-email-hugues.fruchet@st.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1538059567-8381-1-git-send-email-hugues.fruchet@st.com> References: <1538059567-8381-1-git-send-email-hugues.fruchet@st.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.201.23.73] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-09-27_07:, , signatures=0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org |
Commit Message
Hugues FRUCHET
Sept. 27, 2018, 2:46 p.m. UTC
This optional property aims to inform parallel video devices
of the maximum pixel clock frequency admissible by host video
interface. If bandwidth of data to be transferred requires a
pixel clock which is higher than this value, parallel video
device could then typically adapt framerate to reach
this constraint.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++
1 file changed, 2 insertions(+)
Comments
Hi! On Thu, Sep 27, 2018 at 04:46:06PM +0200, Hugues Fruchet wrote: > This optional property aims to inform parallel video devices > of the maximum pixel clock frequency admissible by host video > interface. If bandwidth of data to be transferred requires a > pixel clock which is higher than this value, parallel video > device could then typically adapt framerate to reach > this constraint. > > Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> > --- > Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt > index baf9d97..fa4c112 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -147,6 +147,8 @@ Optional endpoint properties > as 0 (normal). This property is valid for serial busses only. > - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used > with CCP2, for instance. > +- pclk-max-frequency: maximum pixel clock frequency admissible by video > + host interface. That seems to be a property of the capture device, not the camera itself. Can't that be negotiated through the media API? Maxime
Hi Hugues, On Thu, Sep 27, 2018 at 04:46:06PM +0200, Hugues Fruchet wrote: > This optional property aims to inform parallel video devices > of the maximum pixel clock frequency admissible by host video > interface. If bandwidth of data to be transferred requires a > pixel clock which is higher than this value, parallel video > device could then typically adapt framerate to reach > this constraint. > > Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> > --- > Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt > index baf9d97..fa4c112 100644 > --- a/Documentation/devicetree/bindings/media/video-interfaces.txt > +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt > @@ -147,6 +147,8 @@ Optional endpoint properties > as 0 (normal). This property is valid for serial busses only. > - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used > with CCP2, for instance. > +- pclk-max-frequency: maximum pixel clock frequency admissible by video > + host interface. Is there a limit on the pixel clock or the link frequency? We do have a property for the link frequency and a control for the pixel lock as well as for the link frequency. Could these be used for the purpose? The link frequency in general should be specified for the board, and that limits the pixel clock as well in the case the bus transfers a given number of pixels per clock. The OMAP3ISP driver also address this by reading back the pixel clock from the sensor before starting streaming.
Hi Sakari, On 09/28/2018 09:03 AM, Sakari Ailus wrote: > Hi Hugues, > > On Thu, Sep 27, 2018 at 04:46:06PM +0200, Hugues Fruchet wrote: >> This optional property aims to inform parallel video devices >> of the maximum pixel clock frequency admissible by host video >> interface. If bandwidth of data to be transferred requires a >> pixel clock which is higher than this value, parallel video >> device could then typically adapt framerate to reach >> this constraint. >> >> Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> >> --- >> Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt >> index baf9d97..fa4c112 100644 >> --- a/Documentation/devicetree/bindings/media/video-interfaces.txt >> +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt >> @@ -147,6 +147,8 @@ Optional endpoint properties >> as 0 (normal). This property is valid for serial busses only. >> - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used >> with CCP2, for instance. >> +- pclk-max-frequency: maximum pixel clock frequency admissible by video >> + host interface. > > Is there a limit on the pixel clock or the link frequency? The constraint is the frequency of the clock in input of the SoC (pixel clock line). > > We do have a property for the link frequency and a control for the pixel > lock as well as for the link frequency. Could these be used for the > purpose? As this was documented mainly for MIPI-CSI2 I was not clear if this could be used or not, but video-interface.txt binding let open the door to parallel port usage... I had also some hesitations to use this property because what I was searching for here was a maximum limit to not exceed while "link-frequencies" is described as frequencies to use: "Allowed data bus frequencies". The fact that there was several entries for this property was also quite confusing. What I can do is to use this property and add a comment explaining that this can also be used for parallel port as the frequency to not exceed on pixel clock signal, what do you think about it ? Checking drivers which are implementing "link-frequencies", I've found OV2659 sensor which is doing almost what I want to, ie compute the clock rate depending on link-frequency, see ov2659_pll_calc_params(). > > The link frequency in general should be specified for the board, and that > limits the pixel clock as well in the case the bus transfers a given number > of pixels per clock. > > The OMAP3ISP driver also address this by reading back the pixel clock from > the sensor before starting streaming. > BR, Hugues.
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index baf9d97..fa4c112 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -147,6 +147,8 @@ Optional endpoint properties as 0 (normal). This property is valid for serial busses only. - strobe: Whether the clock signal is used as clock (0) or strobe (1). Used with CCP2, for instance. +- pclk-max-frequency: maximum pixel clock frequency admissible by video + host interface. Example -------