diff mbox series

[3/4] media: dt-bindings: media: Document pclk-max-frequency property

Message ID 1538059567-8381-4-git-send-email-hugues.fruchet@st.com (mailing list archive)
State New, archived
Headers show
Series OV5640: reduce rate according to maximum pixel clock | expand

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

Maxime Ripard Sept. 27, 2018, 5:26 p.m. UTC | #1
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
Sakari Ailus Sept. 28, 2018, 7:03 a.m. UTC | #2
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.
Hugues FRUCHET Oct. 1, 2018, 2:53 p.m. UTC | #3
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 mbox series

Patch

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
 -------