Re: Codec controls question

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

Hi Laurent,

On 05/18/2011 06:03 PM, Laurent Pinchart wrote:
> On Wednesday 18 May 2011 17:57:37 Sylwester Nawrocki wrote:
>> On 05/18/2011 05:22 PM, Hans Verkuil wrote:
>>>
>>> I have experimented with control events to change ranges and while it can
>>> be done technically it is in practice a bit of a mess. I think personally
>>> it is just easier to have separate controls.
>>>
>>> We are going to have similar problems if different video inputs are
>>> controlled by different i2c devices with different (but partially
>>> overlapping) controls. So switching an input also changes the controls. I
>>> have experimented with this while working on control events and it became
>>> very messy indeed. I won't do this for the first version of control
>>> events.
>>>
>>> One subtle but real problem with changing control ranges on the fly is
>>> that it makes it next to impossible to save all control values to a file
>>> and restore them later. That is a desirable feature that AFAIK is
>>> actually in use already.
>>
>> What are your views on creating controls in subdev s_power operation ?
>> Some sensors/ISPs have control ranges dependant on a firmware revision.
>> So before creating the controls min/max/step values need to be read from
>> them over I2C. We chose to postpone enabling ISP's power until a
>> corresponding video (or subdev) device node is opened. And thus controls
>> are not created during driver probing, because there is no enough
>> information to do this.
> 
> You can power the device up during probe, read the hardware/firmware version, 
> power it down and create/initialize controls depending on the retrieved 
> information.

Yes, I suppose this is what all drivers should normally do. But if for example
there are 2 sensor's registered during a media device initialization and it takes
about 100ms and 600 ms to initialize each one respectively, then if the driver
is compiled in the kernel the system boot time would increase by 700ms.   
If the whole driver is compiled as a LKM this could be acceptable though.

I'm still not convinced, the most straightforward method would be to power up
the sensor in probe(), but there comes that unfortunate delay. 

> 
>> I don't see a possibility for the applications to be able to access the
>> controls before they are created as this happens during a first device
>> (either video or subdev) open(). And they are destroyed only in
>> video/subdev device relase().
>>
>> Do you see any potential issues with this scheme ?
> 

Thanks,
-- 
Sylwester Nawrocki
Samsung Poland R&D Center