V4l2 Sensor driver and V4l2 ctrls

V4l2 Sensor driver and V4l2 ctrls

[asadpt iqroot]

Hi All,

In reference sensor drivers, they used the
V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
It is a standard ctrl and created using v4l2_ctrl_new_std().

The doubts are:

1. Whether in our sensor driver, we need to create this Control Id or
not. How to take the decision on this. Since this is the standard
ctrl. When we need to use these standard ctrls??

2. In Sensor driver, the ctrls creation is anything depends on the
bridge driver.
Based on bridge driver, whether we need to create any ctrls in Sensor driver.

This question belongs to design of the sensor driver.



Thanks & Regards

Re: V4l2 Sensor driver and V4l2 ctrls

[Hans Verkuil]

On 30/03/18 08:16, asadpt iqroot wrote:
> Hi All,
> 
> In reference sensor drivers, they used the
> V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
> It is a standard ctrl and created using v4l2_ctrl_new_std().
> 
> The doubts are:
> 
> 1. Whether in our sensor driver, we need to create this Control Id or
> not. How to take the decision on this. Since this is the standard
> ctrl. When we need to use these standard ctrls??

No. This control is for HDMI receivers, not for sensors.

Regards,

	Hans

> 
> 2. In Sensor driver, the ctrls creation is anything depends on the
> bridge driver.
> Based on bridge driver, whether we need to create any ctrls in Sensor driver.
> 
> This question belongs to design of the sensor driver.
> 
> 
> 
> Thanks & Regards
> 

Re: V4l2 Sensor driver and V4l2 ctrls

[asadpt iqroot]

Hi Hans,

Thanks for the reply.

In HDMI receivers, when we need to use this control. What scenario?

-Thanks.


On 30 March 2018 at 12:13, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 30/03/18 08:16, asadpt iqroot wrote:
>> Hi All,
>>
>> In reference sensor drivers, they used the
>> V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
>> It is a standard ctrl and created using v4l2_ctrl_new_std().
>>
>> The doubts are:
>>
>> 1. Whether in our sensor driver, we need to create this Control Id or
>> not. How to take the decision on this. Since this is the standard
>> ctrl. When we need to use these standard ctrls??
>
> No. This control is for HDMI receivers, not for sensors.
>
> Regards,
>
>         Hans
>
>>
>> 2. In Sensor driver, the ctrls creation is anything depends on the
>> bridge driver.
>> Based on bridge driver, whether we need to create any ctrls in Sensor driver.
>>
>> This question belongs to design of the sensor driver.
>>
>>
>>
>> Thanks & Regards
>>
>

Re: V4l2 Sensor driver and V4l2 ctrls

[Hans Verkuil]

On 30/03/18 09:23, asadpt iqroot wrote:
> Hi Hans,
> 
> Thanks for the reply.
> 
> In HDMI receivers, when we need to use this control. What scenario?

https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/extended-controls.html#digital-video-control-reference

"Detects whether the receiver receives power from the source (e.g. HDMI carries 5V on one of the pins)."

Regards,

	Hans

> 
> -Thanks.
> 
> 
> On 30 March 2018 at 12:13, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 30/03/18 08:16, asadpt iqroot wrote:
>>> Hi All,
>>>
>>> In reference sensor drivers, they used the
>>> V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
>>> It is a standard ctrl and created using v4l2_ctrl_new_std().
>>>
>>> The doubts are:
>>>
>>> 1. Whether in our sensor driver, we need to create this Control Id or
>>> not. How to take the decision on this. Since this is the standard
>>> ctrl. When we need to use these standard ctrls??
>>
>> No. This control is for HDMI receivers, not for sensors.
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>> 2. In Sensor driver, the ctrls creation is anything depends on the
>>> bridge driver.
>>> Based on bridge driver, whether we need to create any ctrls in Sensor driver.
>>>
>>> This question belongs to design of the sensor driver.
>>>
>>>
>>>
>>> Thanks & Regards
>>>
>>

Re: V4l2 Sensor driver and V4l2 ctrls

[asadpt iqroot]

Hi Hans,

Thanks for the reply.

In board, we have the HDMI connectors. Is it mandatory to use this ctrl
V4L2_CID_DV_RX_POWER_PRESENT. Based on this v4l2 ctrl, what v4l2 framework
will do? If I do not set any value to this ctrl, what will happen to
video streaming?

For example, if I did not add this control in driver, what will
happen? Whether this will
affect the functionality of the video streaming? or not.

Why do we have the standard v4l2 ctrl like this?

Thanks for the inputs.

On 30 March 2018 at 12:58, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 30/03/18 09:23, asadpt iqroot wrote:
>> Hi Hans,
>>
>> Thanks for the reply.
>>
>> In HDMI receivers, when we need to use this control. What scenario?
>
> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/extended-controls.html#digital-video-control-reference
>
> "Detects whether the receiver receives power from the source (e.g. HDMI carries 5V on one of the pins)."
>
> Regards,
>
>         Hans
>
>>
>> -Thanks.
>>
>>
>> On 30 March 2018 at 12:13, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On 30/03/18 08:16, asadpt iqroot wrote:
>>>> Hi All,
>>>>
>>>> In reference sensor drivers, they used the
>>>> V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
>>>> It is a standard ctrl and created using v4l2_ctrl_new_std().
>>>>
>>>> The doubts are:
>>>>
>>>> 1. Whether in our sensor driver, we need to create this Control Id or
>>>> not. How to take the decision on this. Since this is the standard
>>>> ctrl. When we need to use these standard ctrls??
>>>
>>> No. This control is for HDMI receivers, not for sensors.
>>>
>>> Regards,
>>>
>>>         Hans
>>>
>>>>
>>>> 2. In Sensor driver, the ctrls creation is anything depends on the
>>>> bridge driver.
>>>> Based on bridge driver, whether we need to create any ctrls in Sensor driver.
>>>>
>>>> This question belongs to design of the sensor driver.
>>>>
>>>>
>>>>
>>>> Thanks & Regards
>>>>
>>>
>

Re: V4l2 Sensor driver and V4l2 ctrls

[Hans Verkuil]

On 03/04/18 08:32, asadpt iqroot wrote:
> Hi Hans,
> 
> Thanks for the reply.
> 
> In board, we have the HDMI connectors. Is it mandatory to use this ctrl
> V4L2_CID_DV_RX_POWER_PRESENT. Based on this v4l2 ctrl, what v4l2 framework
> will do? If I do not set any value to this ctrl, what will happen to
> video streaming?

This control isn't for the kernel, it's to help userspace. Userspace can
subscribe to this control and receive an event whenever it changes value
(i.e. whenever the driver detects a change in the 5V HDMI line).

It then knows that it looks like something has been connected to the receiver
and it can start waiting for a stable signal, inform the user or just keep
track of it internally for debug purposes.

What HDMI receivers do you use? Analog Devices? NXP? SoC-based?

> 
> For example, if I did not add this control in driver, what will
> happen? Whether this will
> affect the functionality of the video streaming? or not.

No, it is just to inform userspace that something was connected or
disconnected. And to aid in debugging problems.

> Why do we have the standard v4l2 ctrl like this?

See above.

Note: if you plan on upstreaming your HDMI receiver driver, then this control
must be present.

Regards,

	Hans

> 
> Thanks for the inputs.
> 
> On 30 March 2018 at 12:58, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 30/03/18 09:23, asadpt iqroot wrote:
>>> Hi Hans,
>>>
>>> Thanks for the reply.
>>>
>>> In HDMI receivers, when we need to use this control. What scenario?
>>
>> https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/extended-controls.html#digital-video-control-reference
>>
>> "Detects whether the receiver receives power from the source (e.g. HDMI carries 5V on one of the pins)."
>>
>> Regards,
>>
>>         Hans
>>
>>>
>>> -Thanks.
>>>
>>>
>>> On 30 March 2018 at 12:13, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> On 30/03/18 08:16, asadpt iqroot wrote:
>>>>> Hi All,
>>>>>
>>>>> In reference sensor drivers, they used the
>>>>> V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
>>>>> It is a standard ctrl and created using v4l2_ctrl_new_std().
>>>>>
>>>>> The doubts are:
>>>>>
>>>>> 1. Whether in our sensor driver, we need to create this Control Id or
>>>>> not. How to take the decision on this. Since this is the standard
>>>>> ctrl. When we need to use these standard ctrls??
>>>>
>>>> No. This control is for HDMI receivers, not for sensors.
>>>>
>>>> Regards,
>>>>
>>>>         Hans
>>>>
>>>>>
>>>>> 2. In Sensor driver, the ctrls creation is anything depends on the
>>>>> bridge driver.
>>>>> Based on bridge driver, whether we need to create any ctrls in Sensor driver.
>>>>>
>>>>> This question belongs to design of the sensor driver.
>>>>>
>>>>>
>>>>>
>>>>> Thanks & Regards
>>>>>
>>>>
>>

V4l2 Sensor driver and V4l2 ctrls

[MUHAMMED ASAD P T]

Hi,



Thanks for the reply. 



In board, HDMI connectors are there. If we did not add this ctrl in driver, what will happen to the functionality?

If we did not add this ctrl, then whether this affect the video streaming functionality or not?



What scenario, we need to add this ctrl?



Thanks for the inputs.



Thanks & Regards

- Asad

  IQ Root Technologies






---- On Fri, 30 Mar 2018 12:42:08 +0530 <valdis.kletnieks at vt.edu> wrote ----




On Fri, 30 Mar 2018 11:38:07 +0530, MUHAMMED ASAD P T said: 

 

> In reference sensor drivers, they used the V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl. 

> It is a standard ctrl and created using v4l2_ctrl_new_std(). 

 

> 1. Whether in our sensor driver, we need to create this Control Id or not. 

> How to take the decision on this. Since this is the standard ctrl. When we need 

> to use these standard ctrls?? 

 

When you're doing the same thing as the reference drivers, use the standard control. 

 

If you're doing something strange and different from the reference drivers, ask yourself 

why you're doing it, and whether doing the same thing as the reference drivers wouldn't 

be a better idea. 

 

In this specific case, RX_POWER_PRESENT sounds like a pretty common thing to 

be able to sense. So if that's what you're doing, use that control. If your sensor 

can't detect RX_POWER_PRESENT, complain to your hardware design team. :) 






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180403/8d6e2cc0/attachment-0001.html>

V4l2 Sensor driver and V4l2 ctrls

[valdis.kletnieks at vt.edu]

On Fri, 30 Mar 2018 11:38:07 +0530, MUHAMMED ASAD P T said:

> In reference sensor drivers, they used the V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.
> It is a standard ctrl and created using v4l2_ctrl_new_std().

> 1. Whether in our sensor driver, we need to create this Control Id or not.
> How to take the decision on this. Since this is the standard ctrl. When we need
> to use these standard ctrls??

When you're doing the same thing as the reference drivers, use the standard control.

If you're doing something strange and different from the reference drivers, ask yourself
why you're doing it, and whether doing the same thing as the reference drivers wouldn't
be a better idea.

In this specific case, RX_POWER_PRESENT sounds like a pretty common thing to
be able to sense.  So if that's what you're doing, use that control.  If your sensor
can't detect RX_POWER_PRESENT, complain to your hardware design team. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180330/5e9cee3b/attachment.sig>

V4l2 Sensor driver and V4l2 ctrls

[MUHAMMED ASAD P T]

Hi All,



In reference sensor drivers, they used the V4L2_CID_DV_RX_POWER_PRESENT v4l2 ctrl.

It is a standard ctrl and created using v4l2_ctrl_new_std(). 



The doubts are:



1. Whether in our sensor driver, we need to create this Control Id or not. How to take the decision on this. Since this is the standard ctrl. When we need to use these standard ctrls??



2. In Sensor driver, the ctrls creation is anything depends on the bridge driver.

Based on bridge driver, whether we need to create any ctrls in Sensor driver.



This question belongs to design of the sensor driver.







Thanks & Regards

- Asad

  IQ Root Technologies





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180330/afe0b082/attachment.html>