Re: [RFC] Move some soc-camera drivers to staging in preparation for removal

[Hans Verkuil <hverkuil@xs4all.nl>]

On 02/19/2016 07:01 PM, Robert Jarzmik wrote:
> Hans Verkuil <hverkuil@xs4all.nl> writes:
> 
>> On 02/19/2016 05:24 PM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 19 Feb 2016 14:24:08 +0100
>>> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>>>
>>>> Hi all,
>>>>
>>>> The soc-camera framework is a problem for reusability of sub-device drivers since
>>>> those need access to the soc-camera framework. Which defeats the purpose of the
>>>> sub-device framework. It is the reason why we still have a media/i2c/soc-camera
>>>> directory for subdevs that can only work with soc-camera.
>>>>
>>>> Ideally I would like to drop soc-camera completely, but it is still in use.
>>>>
>>>> One of the largest users is Renesas with their r-car SoC, but Niklas Söderlund
>>>> made a replacement driver that should make it possible to remove the soc-camera
>>>> r-car driver, hopefully this year.
>>>>
>>>> What I would like to do is to move soc-camera drivers that we consider obsolete
>>>> to staging, and remove them in 1-2 kernel cycles if nobody steps up.
>>>>
>>>> See also this past thread from Guennadi:
>>>>
>>>> http://www.spinics.net/lists/linux-media/msg89253.html
>>>>
>>>> And yes, I said in that thread that I was OK with keeping soc-camera as-is. But
>>>> it still happens that companies pick this framework for new devices (the driver
>>>> for the Tegra K1 for example). It is another reason besides the reusability issue
>>>> for remove this framework more aggressively then I intended originally.
>>>>
>>>>
>>>> We have the following drivers:
>>>>
>>>> - pxa_camera for the PXA27x Quick Capture Interface
>>>>
>>>>   Apparently this architecture still gets attention (see the link to the thread
>>>>   above). But it does use vb1 which we really want to phase out soon. Does anyone
>>>>   know if this driver still works with the latest kernel? Because it is using vb1
>>>>   it is a strong candidate for removing it (or replacing it with something better
>>>>   if someone steps up).
> Most certainly.
> 
> pxa27x_camera is actively maintained, the latest submission request for merge
> is 11 days ago :
>   https://lkml.org/lkml/2016/2/8/789
> 
> I can submit a patch in MAINTAINERS if you wish to take it in my bucket.

Please do! That's an easy patch, and then it is clear someone is actively maintaining
this.

> 
> I am maintaining the pxa architecture, and I do have the hardware to test the
> submissions. As you will see in the above message the driver works fine with
> v4.5-rc2.
> 
> If you want modifications, let me know, explain to me what you want, and I'll
> see how to carry them out (because vb1 out of context is obfuscated to me). A
> good explanation would a an example of another driver pxa_camera should look
> like, so that I can see the difference in the APIs from soc_camera and evaluate
> the work to be done.
> 
>>>> Now I am not planning to remove soc-camera (yet), but at least we should get
>>>> rid of unmaintained drivers, especially if they don't work anymore or if they
>>>> use the old vb1 mess.
>>>>
>>>> And we can then take a good look at what remains.
>>>
>>> You're forgetting the I2C sensor cam drivers. There are 14 such drivers
>>> under drivers/media/i2c/soc_camera/.
>>
>> I didn't forget those, but I thought that we should tackle those later.
>> It's not so easy to remove the soc-camera dependency from them. I tried
>> that once, and I think I could only make one or two of those drivers soc-camera
>> independent :-(
>>
>> And without hardware you have no idea if they still work.
> Same thing as above, I can commit at least for mt9m111.c, for which I have both
> the hardware and the knowledge. I cannot speak for the other drivers.
> 
> So all in all, if you point me in the right direction, I'll take care of the
> changes in pxa_camera.c and mt9m111.c.

Good to know.

I will investigate this driver in more detail so I can explain what would be needed
to get this driver out of soc-camera.

BTW, vb1 refers to videobuf-core.h whereas vb2 refers to its successor videobuf2-core.h
and videobuf2-v4l2.h. The vb2 framework is vastly superior and integrates nicely with
dmabuf for buffer sharing between hardware components.

Regards,

	Hans