Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-29 Thread Jose Abreu 
Hi Hans,


On 28-03-2017 11:07, Hans Verkuil wrote:
> On 27/03/17 13:58, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 24-03-2017 12:28, Hans Verkuil wrote:
>>> On 03/24/17 13:21, Jose Abreu wrote:
 Hi Hans,


 On 24-03-2017 12:12, Hans Verkuil wrote:
> On 03/24/17 12:52, Jose Abreu wrote:
>> Hi Hans,
>>
>>
 Can you please review this series, when possible? And if you
 could test it on cobalt it would be great :)
>>> Hopefully next week. 
>> Thanks :)
>>
>>> Did you have some real-world numbers w.r.t. measured
>>> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
>> I did make some measurements but I'm afraid I didn't yet test
>> with many sources (I mostly tested with signal generators which
>> should have a higher precision clock than real sources). I have a
>> bunch of players here, I will test them as soon as I can.
>> Regarding precision: for our controller is theoretically and
>> effectively enough: The worst case is for 640x480, and even in
>> that case the difference between 60Hz and 59.94Hz is > 1 unit of
>> the measuring register. This still doesn't solve the problem of
>> having a bad source with a bad clock, but I don't know if we can
>> do much more about that.
> I would really like to see a table with different sources sending
> these different framerates and the value that your HW detects.
>
> If there is an obvious and clear difference, then this feature makes
> sense. If it is all over the place, then I need to think about this
> some more.
>
> To be honest, I expect that you will see 'an obvious and clear'
> difference, but that is no more than a gut feeling at the moment and
> I would like to see some proper test results.
 Ok, I will make a table. The test procedure will be like this:
 - Measure pixel clock value using certified HDMI analyzer
 - Measure pixel clock using our controller
 - Compare the values obtained from analyzer, controller and
 the values that the source is telling to send (the value
 displayed in source menu for example [though, some of them may
 not discriminate the exact frame rate, thats why analyzer should
 be used also]).

 Seems ok? I will need some time, something like a week because my
 setup was "borrowed".
>>> That sounds good. Sorry for adding to your workload, but there is no
>>> point to have a flag that in practice is meaningless.
>>>
>>> I'm actually very curious about the results!
>> I managed to do the tests but unfortunately I can't publish the
>> full results (at least until I get approval).
>>
>> I can say that the results look good. As you expected we have
>> some sources with a bad clock but this is correctly detected by
>> the controller (and also by the HDMI analyzer).
>>
>> Using the v4l2_calc_framerate function I managed to get this:
>>
>> | Source   | Resolution  | v4l2_calc_framerate()
>> --
>> | Analyzer 1 | 640x480@59.94 | 59.92
>> | Analyzer 1 | 640x480@60  | 60
>> | Analyzer 1 | 1920x1080@60  | 60
>> | Player 1 | 1920x1080@59.94 | 59.94
>> | Player 2 | 1920x1080@59.94 | 59.93
>> | Player 3 | 3840x2160@59.94 | 59.94
>> | Player 4 | 1920x1080@59.94 | 59.94
>> | Player 5 | 1920x1080@59.94 | 59.93
>> | Player 6 | 1280x720@50| 50
>> | Player 7 | 1920x1080@59.94 | 59.93
>> | Player 8 | 1920x1080@60  | 60
>> | Analyzer 2 | 720x480@59.94 | 59.94
>> | Analyzer 2 | 720x480@60  | 60
>> | Analyzer 2 | 1920x1080@59.94 | 59.93
>> | Analyzer 2 | 1920x180@60| 60
>> | Analyzer 2 | 3840x2160@23.98 | 23.97
>> | Analyzer 2 | 3840x2160@24  | 24
>> | Analyzer 2 | 3840x2160@29.97 | 29.96
>> | Analyzer 2 | 3840x2160@30  | 30
>> | Analyzer 2 | 3840x2160@59.94 | 59.93
>> | Analyzer 2 | 3840x2160@60  | 60
> Nice!
>
> Are the sources with a bad clock included in these results? I only see 
> deviations
> of 0.02 at most, so I don't think so.

The results include all the sources I have to test (Player x
indicates a real player available in the market while Analyzer x
indicates HDMI protocol analyzer). From the data I've collected
the players are the ones with the less precise clock, thats what
I was referring as a bad clock. But even with that deviations the
algorithm computes the value ok. I think I don't have any player
else to test here. Maybe, if you could, test the patch series
with cobalt + adv with a player and check the precision? ( I
think cobalt uses an adv as subdev, right? )

>
>> --
>>
>> What do you think? Shall we continue integrating this new patch
>> or drop it?
> Yes, we can continue. This is what

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-28 Thread Hans Verkuil 
On 27/03/17 13:58, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 24-03-2017 12:28, Hans Verkuil wrote:
>> On 03/24/17 13:21, Jose Abreu wrote:
>>> Hi Hans,
>>>
>>>
>>> On 24-03-2017 12:12, Hans Verkuil wrote:
 On 03/24/17 12:52, Jose Abreu wrote:
> Hi Hans,
>
>
>>> Can you please review this series, when possible? And if you
>>> could test it on cobalt it would be great :)
>> Hopefully next week. 
> Thanks :)
>
>> Did you have some real-world numbers w.r.t. measured
>> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
> I did make some measurements but I'm afraid I didn't yet test
> with many sources (I mostly tested with signal generators which
> should have a higher precision clock than real sources). I have a
> bunch of players here, I will test them as soon as I can.
> Regarding precision: for our controller is theoretically and
> effectively enough: The worst case is for 640x480, and even in
> that case the difference between 60Hz and 59.94Hz is > 1 unit of
> the measuring register. This still doesn't solve the problem of
> having a bad source with a bad clock, but I don't know if we can
> do much more about that.
 I would really like to see a table with different sources sending
 these different framerates and the value that your HW detects.

 If there is an obvious and clear difference, then this feature makes
 sense. If it is all over the place, then I need to think about this
 some more.

 To be honest, I expect that you will see 'an obvious and clear'
 difference, but that is no more than a gut feeling at the moment and
 I would like to see some proper test results.
>>> Ok, I will make a table. The test procedure will be like this:
>>> - Measure pixel clock value using certified HDMI analyzer
>>> - Measure pixel clock using our controller
>>> - Compare the values obtained from analyzer, controller and
>>> the values that the source is telling to send (the value
>>> displayed in source menu for example [though, some of them may
>>> not discriminate the exact frame rate, thats why analyzer should
>>> be used also]).
>>>
>>> Seems ok? I will need some time, something like a week because my
>>> setup was "borrowed".
>> That sounds good. Sorry for adding to your workload, but there is no
>> point to have a flag that in practice is meaningless.
>>
>> I'm actually very curious about the results!
> 
> I managed to do the tests but unfortunately I can't publish the
> full results (at least until I get approval).
> 
> I can say that the results look good. As you expected we have
> some sources with a bad clock but this is correctly detected by
> the controller (and also by the HDMI analyzer).
> 
> Using the v4l2_calc_framerate function I managed to get this:
> 
> | Source   | Resolution  | v4l2_calc_framerate()
> --
> | Analyzer 1 | 640x480@59.94 | 59.92
> | Analyzer 1 | 640x480@60  | 60
> | Analyzer 1 | 1920x1080@60  | 60
> | Player 1 | 1920x1080@59.94 | 59.94
> | Player 2 | 1920x1080@59.94 | 59.93
> | Player 3 | 3840x2160@59.94 | 59.94
> | Player 4 | 1920x1080@59.94 | 59.94
> | Player 5 | 1920x1080@59.94 | 59.93
> | Player 6 | 1280x720@50| 50
> | Player 7 | 1920x1080@59.94 | 59.93
> | Player 8 | 1920x1080@60  | 60
> | Analyzer 2 | 720x480@59.94 | 59.94
> | Analyzer 2 | 720x480@60  | 60
> | Analyzer 2 | 1920x1080@59.94 | 59.93
> | Analyzer 2 | 1920x180@60| 60
> | Analyzer 2 | 3840x2160@23.98 | 23.97
> | Analyzer 2 | 3840x2160@24  | 24
> | Analyzer 2 | 3840x2160@29.97 | 29.96
> | Analyzer 2 | 3840x2160@30  | 30
> | Analyzer 2 | 3840x2160@59.94 | 59.93
> | Analyzer 2 | 3840x2160@60  | 60

Nice!

Are the sources with a bad clock included in these results? I only see 
deviations
of 0.02 at most, so I don't think so.

> --
> 
> What do you think? Shall we continue integrating this new patch
> or drop it?

Yes, we can continue. This is what I wanted to know :-)
Thank you for testing this, much appreciated.

Regards,

Hans

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-27 Thread Jose Abreu 
Hi Hans,


On 24-03-2017 12:28, Hans Verkuil wrote:
> On 03/24/17 13:21, Jose Abreu wrote:
>> Hi Hans,
>>
>>
>> On 24-03-2017 12:12, Hans Verkuil wrote:
>>> On 03/24/17 12:52, Jose Abreu wrote:
 Hi Hans,


>> Can you please review this series, when possible? And if you
>> could test it on cobalt it would be great :)
> Hopefully next week. 
 Thanks :)

> Did you have some real-world numbers w.r.t. measured
> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
 I did make some measurements but I'm afraid I didn't yet test
 with many sources (I mostly tested with signal generators which
 should have a higher precision clock than real sources). I have a
 bunch of players here, I will test them as soon as I can.
 Regarding precision: for our controller is theoretically and
 effectively enough: The worst case is for 640x480, and even in
 that case the difference between 60Hz and 59.94Hz is > 1 unit of
 the measuring register. This still doesn't solve the problem of
 having a bad source with a bad clock, but I don't know if we can
 do much more about that.
>>> I would really like to see a table with different sources sending
>>> these different framerates and the value that your HW detects.
>>>
>>> If there is an obvious and clear difference, then this feature makes
>>> sense. If it is all over the place, then I need to think about this
>>> some more.
>>>
>>> To be honest, I expect that you will see 'an obvious and clear'
>>> difference, but that is no more than a gut feeling at the moment and
>>> I would like to see some proper test results.
>> Ok, I will make a table. The test procedure will be like this:
>> - Measure pixel clock value using certified HDMI analyzer
>> - Measure pixel clock using our controller
>> - Compare the values obtained from analyzer, controller and
>> the values that the source is telling to send (the value
>> displayed in source menu for example [though, some of them may
>> not discriminate the exact frame rate, thats why analyzer should
>> be used also]).
>>
>> Seems ok? I will need some time, something like a week because my
>> setup was "borrowed".
> That sounds good. Sorry for adding to your workload, but there is no
> point to have a flag that in practice is meaningless.
>
> I'm actually very curious about the results!

I managed to do the tests but unfortunately I can't publish the
full results (at least until I get approval).

I can say that the results look good. As you expected we have
some sources with a bad clock but this is correctly detected by
the controller (and also by the HDMI analyzer).

Using the v4l2_calc_framerate function I managed to get this:

| Source   | Resolution  | v4l2_calc_framerate()
--
| Analyzer 1 | 640x480@59.94 | 59.92
| Analyzer 1 | 640x480@60  | 60
| Analyzer 1 | 1920x1080@60  | 60
| Player 1 | 1920x1080@59.94 | 59.94
| Player 2 | 1920x1080@59.94 | 59.93
| Player 3 | 3840x2160@59.94 | 59.94
| Player 4 | 1920x1080@59.94 | 59.94
| Player 5 | 1920x1080@59.94 | 59.93
| Player 6 | 1280x720@50| 50
| Player 7 | 1920x1080@59.94 | 59.93
| Player 8 | 1920x1080@60  | 60
| Analyzer 2 | 720x480@59.94 | 59.94
| Analyzer 2 | 720x480@60  | 60
| Analyzer 2 | 1920x1080@59.94 | 59.93
| Analyzer 2 | 1920x180@60| 60
| Analyzer 2 | 3840x2160@23.98 | 23.97
| Analyzer 2 | 3840x2160@24  | 24
| Analyzer 2 | 3840x2160@29.97 | 29.96
| Analyzer 2 | 3840x2160@30  | 30
| Analyzer 2 | 3840x2160@59.94 | 59.93
| Analyzer 2 | 3840x2160@60  | 60
--

What do you think? Shall we continue integrating this new patch
or drop it?

Best regards,
Jose Miguel Abreu

>
> Regards,
>
>   Hans
>
>> Best regards,
>> Jose Miguel Abreu
>>
> I do want to see that, since this patch series only makes sense if you can
> actually make use of it to reliably detect the difference.
>
> I will try to test that myself with cobalt, but almost certainly I won't
> be able to tell the difference; if memory serves it can't detect the freq
> with high enough precision.
 Ok, thanks, this would be great because I didn't test the series
 exactly "as is" because I'm using 4.10. I did look at vivid
 driver but it already handles reduced frame rate, so it kind of
 does what it is proposed in this series. If this helper is
 integrated in the v4l2 core then I can send the patch to vivid.
>>> That would be nice to have in vivid.
>>>
>>> Regards,
>>>
>>> Hans
>>>

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Hans Verkuil 
On 03/24/17 13:21, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 24-03-2017 12:12, Hans Verkuil wrote:
>> On 03/24/17 12:52, Jose Abreu wrote:
>>> Hi Hans,
>>>
>>>
> Can you please review this series, when possible? And if you
> could test it on cobalt it would be great :)
 Hopefully next week. 
>>> Thanks :)
>>>
 Did you have some real-world numbers w.r.t. measured
 pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
>>> I did make some measurements but I'm afraid I didn't yet test
>>> with many sources (I mostly tested with signal generators which
>>> should have a higher precision clock than real sources). I have a
>>> bunch of players here, I will test them as soon as I can.
>>> Regarding precision: for our controller is theoretically and
>>> effectively enough: The worst case is for 640x480, and even in
>>> that case the difference between 60Hz and 59.94Hz is > 1 unit of
>>> the measuring register. This still doesn't solve the problem of
>>> having a bad source with a bad clock, but I don't know if we can
>>> do much more about that.
>> I would really like to see a table with different sources sending
>> these different framerates and the value that your HW detects.
>>
>> If there is an obvious and clear difference, then this feature makes
>> sense. If it is all over the place, then I need to think about this
>> some more.
>>
>> To be honest, I expect that you will see 'an obvious and clear'
>> difference, but that is no more than a gut feeling at the moment and
>> I would like to see some proper test results.
> 
> Ok, I will make a table. The test procedure will be like this:
> - Measure pixel clock value using certified HDMI analyzer
> - Measure pixel clock using our controller
> - Compare the values obtained from analyzer, controller and
> the values that the source is telling to send (the value
> displayed in source menu for example [though, some of them may
> not discriminate the exact frame rate, thats why analyzer should
> be used also]).
> 
> Seems ok? I will need some time, something like a week because my
> setup was "borrowed".

That sounds good. Sorry for adding to your workload, but there is no
point to have a flag that in practice is meaningless.

I'm actually very curious about the results!

Regards,

Hans

> 
> Best regards,
> Jose Miguel Abreu
> 
>>
 I do want to see that, since this patch series only makes sense if you can
 actually make use of it to reliably detect the difference.

 I will try to test that myself with cobalt, but almost certainly I won't
 be able to tell the difference; if memory serves it can't detect the freq
 with high enough precision.
>>> Ok, thanks, this would be great because I didn't test the series
>>> exactly "as is" because I'm using 4.10. I did look at vivid
>>> driver but it already handles reduced frame rate, so it kind of
>>> does what it is proposed in this series. If this helper is
>>> integrated in the v4l2 core then I can send the patch to vivid.
>> That would be nice to have in vivid.
>>
>> Regards,
>>
>>  Hans
>>
>

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Jose Abreu 
Hi Hans,


On 24-03-2017 12:12, Hans Verkuil wrote:
> On 03/24/17 12:52, Jose Abreu wrote:
>> Hi Hans,
>>
>>
 Can you please review this series, when possible? And if you
 could test it on cobalt it would be great :)
>>> Hopefully next week. 
>> Thanks :)
>>
>>> Did you have some real-world numbers w.r.t. measured
>>> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
>> I did make some measurements but I'm afraid I didn't yet test
>> with many sources (I mostly tested with signal generators which
>> should have a higher precision clock than real sources). I have a
>> bunch of players here, I will test them as soon as I can.
>> Regarding precision: for our controller is theoretically and
>> effectively enough: The worst case is for 640x480, and even in
>> that case the difference between 60Hz and 59.94Hz is > 1 unit of
>> the measuring register. This still doesn't solve the problem of
>> having a bad source with a bad clock, but I don't know if we can
>> do much more about that.
> I would really like to see a table with different sources sending
> these different framerates and the value that your HW detects.
>
> If there is an obvious and clear difference, then this feature makes
> sense. If it is all over the place, then I need to think about this
> some more.
>
> To be honest, I expect that you will see 'an obvious and clear'
> difference, but that is no more than a gut feeling at the moment and
> I would like to see some proper test results.

Ok, I will make a table. The test procedure will be like this:
- Measure pixel clock value using certified HDMI analyzer
- Measure pixel clock using our controller
- Compare the values obtained from analyzer, controller and
the values that the source is telling to send (the value
displayed in source menu for example [though, some of them may
not discriminate the exact frame rate, thats why analyzer should
be used also]).

Seems ok? I will need some time, something like a week because my
setup was "borrowed".

Best regards,
Jose Miguel Abreu

>
>>> I do want to see that, since this patch series only makes sense if you can
>>> actually make use of it to reliably detect the difference.
>>>
>>> I will try to test that myself with cobalt, but almost certainly I won't
>>> be able to tell the difference; if memory serves it can't detect the freq
>>> with high enough precision.
>> Ok, thanks, this would be great because I didn't test the series
>> exactly "as is" because I'm using 4.10. I did look at vivid
>> driver but it already handles reduced frame rate, so it kind of
>> does what it is proposed in this series. If this helper is
>> integrated in the v4l2 core then I can send the patch to vivid.
> That would be nice to have in vivid.
>
> Regards,
>
>   Hans
>

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Hans Verkuil 
On 03/24/17 12:52, Jose Abreu wrote:
> Hi Hans,
> 
> 
>>> Can you please review this series, when possible? And if you
>>> could test it on cobalt it would be great :)
>> Hopefully next week. 
> 
> Thanks :)
> 
>> Did you have some real-world numbers w.r.t. measured
>> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?
> 
> I did make some measurements but I'm afraid I didn't yet test
> with many sources (I mostly tested with signal generators which
> should have a higher precision clock than real sources). I have a
> bunch of players here, I will test them as soon as I can.
> Regarding precision: for our controller is theoretically and
> effectively enough: The worst case is for 640x480, and even in
> that case the difference between 60Hz and 59.94Hz is > 1 unit of
> the measuring register. This still doesn't solve the problem of
> having a bad source with a bad clock, but I don't know if we can
> do much more about that.

I would really like to see a table with different sources sending
these different framerates and the value that your HW detects.

If there is an obvious and clear difference, then this feature makes
sense. If it is all over the place, then I need to think about this
some more.

To be honest, I expect that you will see 'an obvious and clear'
difference, but that is no more than a gut feeling at the moment and
I would like to see some proper test results.

> 
>>
>> I do want to see that, since this patch series only makes sense if you can
>> actually make use of it to reliably detect the difference.
>>
>> I will try to test that myself with cobalt, but almost certainly I won't
>> be able to tell the difference; if memory serves it can't detect the freq
>> with high enough precision.
> 
> Ok, thanks, this would be great because I didn't test the series
> exactly "as is" because I'm using 4.10. I did look at vivid
> driver but it already handles reduced frame rate, so it kind of
> does what it is proposed in this series. If this helper is
> integrated in the v4l2 core then I can send the patch to vivid.

That would be nice to have in vivid.

Regards,

Hans

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Jose Abreu 
Hi Hans,


>> Can you please review this series, when possible? And if you
>> could test it on cobalt it would be great :)
> Hopefully next week. 

Thanks :)

> Did you have some real-world numbers w.r.t. measured
> pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?

I did make some measurements but I'm afraid I didn't yet test
with many sources (I mostly tested with signal generators which
should have a higher precision clock than real sources). I have a
bunch of players here, I will test them as soon as I can.
Regarding precision: for our controller is theoretically and
effectively enough: The worst case is for 640x480, and even in
that case the difference between 60Hz and 59.94Hz is > 1 unit of
the measuring register. This still doesn't solve the problem of
having a bad source with a bad clock, but I don't know if we can
do much more about that.

>
> I do want to see that, since this patch series only makes sense if you can
> actually make use of it to reliably detect the difference.
>
> I will try to test that myself with cobalt, but almost certainly I won't
> be able to tell the difference; if memory serves it can't detect the freq
> with high enough precision.

Ok, thanks, this would be great because I didn't test the series
exactly "as is" because I'm using 4.10. I did look at vivid
driver but it already handles reduced frame rate, so it kind of
does what it is proposed in this series. If this helper is
integrated in the v4l2 core then I can send the patch to vivid.

Best regards,
Jose Miguel Abreu

>
> Regards,
>
>   Hans

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Hans Verkuil 
On 03/24/17 12:03, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 21-03-2017 11:49, Jose Abreu wrote:
>> Hi all,
>>
>> This is a follow up patch from this discussion [1]. It should be
>> seen more as a starting point to introduce better handling of
>> time per frame in v4l2. Quoting Hans Verkuil from [1]:
>>
>> 1) "Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set,
>> then the hw can detect the difference between regular fps
>> and 1000/1001 fps. Note: this is only valid for timings of
>> VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set."
>>
>> 2) "Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers
>> if V4L2_DV_FL_CAN_DETECT_REDUCED_FPS is set."
>>
>> 3) "For standard VIC codes the pixelclock returned by
>> query_dv_timings is that of the corresponding VIC timing,
>> not what is measured. This will ensure fixed fps values"
>>
>> 4) "g_parm should calculate the fps based on the v4l2_bt_timings
>> struct, looking at the REDUCES_FPS flags. For those receivers that
>> cannot detect the difference, the fps will be 24/30/60 Hz, for
>> those that can detect the difference g_parm can check if both
>> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS and V4L2_DV_FL_REDUCED_FPS are
>> set and reduce the fps by 1000/1001."
>>
>> ---
>> In terms of implementation:
>>  - Point 1) is done in patch 1/3
>>  - Point 2) and 3) should be done by a HDMI Receiver driver
>>  (I think?).
>>  - Point 4) is done in patch 2/3.
>>  - The patch 3/3 is a simple implementation (which was not
>>  tested) in the cobalt driver
>> ---
>>  
>> [1] https://patchwork.kernel.org/patch/9609441/
>>
>> Best regards,
>> Jose Miguel Abreu
>>
>> Cc: Carlos Palminha 
>> Cc: Mauro Carvalho Chehab 
>> Cc: Hans Verkuil 
>> Cc: linux-media@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>>
>> Jose Abreu (3):
>>   [media] videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS
>>   [media] v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper
>>   [media] cobalt: Use v4l2_calc_timeperframe helper
>>
>>  drivers/media/pci/cobalt/cobalt-v4l2.c|  9 +--
>>  drivers/media/v4l2-core/v4l2-dv-timings.c | 39 
>> +++
>>  include/media/v4l2-dv-timings.h   | 11 +
>>  include/uapi/linux/videodev2.h|  7 ++
>>  4 files changed, 64 insertions(+), 2 deletions(-)
>>
> 
> Can you please review this series, when possible? And if you
> could test it on cobalt it would be great :)

Hopefully next week. Did you have some real-world numbers w.r.t. measured
pixelclock frequencies and 60 vs 59.94 Hz and 24 vs 23.976 Hz?

I do want to see that, since this patch series only makes sense if you can
actually make use of it to reliably detect the difference.

I will try to test that myself with cobalt, but almost certainly I won't
be able to tell the difference; if memory serves it can't detect the freq
with high enough precision.

Regards,

Hans

Re: [PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-24 Thread Jose Abreu 
Hi Hans,


On 21-03-2017 11:49, Jose Abreu wrote:
> Hi all,
>
> This is a follow up patch from this discussion [1]. It should be
> seen more as a starting point to introduce better handling of
> time per frame in v4l2. Quoting Hans Verkuil from [1]:
>
> 1) "Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set,
> then the hw can detect the difference between regular fps
> and 1000/1001 fps. Note: this is only valid for timings of
> VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set."
>
> 2) "Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers
> if V4L2_DV_FL_CAN_DETECT_REDUCED_FPS is set."
>
> 3) "For standard VIC codes the pixelclock returned by
> query_dv_timings is that of the corresponding VIC timing,
> not what is measured. This will ensure fixed fps values"
>
> 4) "g_parm should calculate the fps based on the v4l2_bt_timings
> struct, looking at the REDUCES_FPS flags. For those receivers that
> cannot detect the difference, the fps will be 24/30/60 Hz, for
> those that can detect the difference g_parm can check if both
> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS and V4L2_DV_FL_REDUCED_FPS are
> set and reduce the fps by 1000/1001."
>
> ---
> In terms of implementation:
>   - Point 1) is done in patch 1/3
>   - Point 2) and 3) should be done by a HDMI Receiver driver
>   (I think?).
>   - Point 4) is done in patch 2/3.
>   - The patch 3/3 is a simple implementation (which was not
>   tested) in the cobalt driver
> ---
>   
> [1] https://patchwork.kernel.org/patch/9609441/
>
> Best regards,
> Jose Miguel Abreu
>
> Cc: Carlos Palminha 
> Cc: Mauro Carvalho Chehab 
> Cc: Hans Verkuil 
> Cc: linux-media@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
>
> Jose Abreu (3):
>   [media] videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS
>   [media] v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper
>   [media] cobalt: Use v4l2_calc_timeperframe helper
>
>  drivers/media/pci/cobalt/cobalt-v4l2.c|  9 +--
>  drivers/media/v4l2-core/v4l2-dv-timings.c | 39 
> +++
>  include/media/v4l2-dv-timings.h   | 11 +
>  include/uapi/linux/videodev2.h|  7 ++
>  4 files changed, 64 insertions(+), 2 deletions(-)
>

Can you please review this series, when possible? And if you
could test it on cobalt it would be great :)

Best regards,
Jose Miguel Abreu

[PATCH 0/3] Handling of reduced FPS in V4L2

2017-03-21 Thread Jose Abreu 
Hi all,

This is a follow up patch from this discussion [1]. It should be
seen more as a starting point to introduce better handling of
time per frame in v4l2. Quoting Hans Verkuil from [1]:

1) "Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set,
then the hw can detect the difference between regular fps
and 1000/1001 fps. Note: this is only valid for timings of
VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set."

2) "Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers
if V4L2_DV_FL_CAN_DETECT_REDUCED_FPS is set."

3) "For standard VIC codes the pixelclock returned by
query_dv_timings is that of the corresponding VIC timing,
not what is measured. This will ensure fixed fps values"

4) "g_parm should calculate the fps based on the v4l2_bt_timings
struct, looking at the REDUCES_FPS flags. For those receivers that
cannot detect the difference, the fps will be 24/30/60 Hz, for
those that can detect the difference g_parm can check if both
V4L2_DV_FL_CAN_DETECT_REDUCED_FPS and V4L2_DV_FL_REDUCED_FPS are
set and reduce the fps by 1000/1001."

---
In terms of implementation:
- Point 1) is done in patch 1/3
- Point 2) and 3) should be done by a HDMI Receiver driver
(I think?).
- Point 4) is done in patch 2/3.
- The patch 3/3 is a simple implementation (which was not
tested) in the cobalt driver
---

[1] https://patchwork.kernel.org/patch/9609441/

Best regards,
Jose Miguel Abreu

Cc: Carlos Palminha 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org

Jose Abreu (3):
  [media] videodev2.h: Add new DV flag CAN_DETECT_REDUCED_FPS
  [media] v4l2-dv-timings: Introduce v4l2_calc_timeperframe helper
  [media] cobalt: Use v4l2_calc_timeperframe helper

 drivers/media/pci/cobalt/cobalt-v4l2.c|  9 +--
 drivers/media/v4l2-core/v4l2-dv-timings.c | 39 +++
 include/media/v4l2-dv-timings.h   | 11 +
 include/uapi/linux/videodev2.h|  7 ++
 4 files changed, 64 insertions(+), 2 deletions(-)

-- 
1.9.1