Re: [RFC] move sensor control out of kernel

[Paulius Zaleckas <paulius.zaleckas@teltonika.lt>]

Hi,

Take a look at my comments bellow. These are just my thoughts. Maybe I 
am not right...

Best regards,
Paulius Zaleckas

eric miao wrote:
> I know some one has different opinion, but since the sensor control logic is
> getting more and more complicated, and provided that differences between
> sensors and vendors are already too many. Is it better to move sensor
> control out of kernel.

I agree that sensor control drivers are very different and most of them 
work only with specific data bus driver. That is really big problem.
"soc-camera" framework developed by Guennadi Liakhovetski IMO is the 
right solution.

> Most sensors come with a serial control channel, I2C as can be seen
> most commonly. Access to the control information can be done by
> i2c-dev interface if possible, thus the driver can be freed as an I2C
> stub only. So technically, this is practical.

Keep in mind that i2c is used not only for camera sensor control, but 
for other devices also.

> The benefits I can think of now are:
> 
> 1. simplified sensor driver design

It is pretty simple with soc-camera framework also. And the best thing 
is that it is unified. If you implement sensor driver in userspace then 
what kind of interface should V4L data bus driver expose.

> 2. sensor control related debugging can be moved to user space thus
>     reducing the debugging effort
> 
> 3. accessing registers in user space can be done by many other ways
>     say, UART. E.g.
>     ADCM2650 and ADCM2670 differs in the control channel connection,
>     one by I2C and the other by UART, the user space control logic has
>     only to decide which device node to open: /dev/i2c/xxx or /dev/ttyXX

I think it is the same for kernel also... Think about serial, PS/2 and 
USB mouse.

> Another biggest concern to the V4L2 API itself, sensor nowadays has
> more control ability than it used to be, some smart sensor provides
> even more like auto focus control, lens control, flash mode, and many
> other features that current V4L2 API cannot cover.

Implement these controls. Make a patch and send it here. If everything 
is OK it should be merged and V4L will be capable to handle these controls.

> Besides, along with the complicated image processing chain, it might
> be better described by kinds of pipeline, like what gstreamer is doing
> now. Moving some or most of the logic to user space will also significantly
> reduce the effort of kernel development.

Yes. It will also dramatically increase development efforts in userspace 
applications. And there will be a lot of different implementations in 
these applications. Actually a lot more than it is in the kernel now.

> Now the problem is: we don't have a standard in user space :(
> 
> Just a topic, any comments. Thanks
> 

My conclusion: your idea just moves problem from kernel to userspace, 
but doesn't solve it...

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list