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

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

[Hans Verkuil]

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).

- mx2_camera: i.MX27 Camera Sensor Interface

  Have not seen any development since April 2013 (mx2-camera: move interface
  activation and deactivation to clock callbacks by Guennadi). No idea if it still
  works or if it is still in use. Does anyone know?

- mx3_camera: i.MX3x Camera Sensor Interface

  Have not seen any development since July 2013 (add support for asynchronous
  subdevice registration by Guennadi). Same as for mx2_camera: does it still work?
  Is it still in use?

- omap1_camera: OMAP1 Camera Interface

  It uses vb1, so that's one very good reason for removing it. And as far as I
  know it is unused and likely won't work.

- sh_mobile_ceu_camera: SuperH Mobile CEU Interface

  I worked on this, but I know it does function anymore. I'd say that this can
  be removed.

- sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface

  I don't have hardware to test, but I'd be surprised if it still works. Can
  someone test? If it is broken, then it can be moved to staging.

- rcar_vin: R-Car Video Input (VIN)
  Will be replaced with a regular driver as mentioned above.

- atmel-isi: ATMEL Image Sensor Interface (ISI)

  I believe this is still actively maintained. Would someone be willing to
  convert this? It doesn't look like a complex driver.

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.

Regards,

	Hans

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

[Mauro Carvalho Chehab]

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).
> 
> - mx2_camera: i.MX27 Camera Sensor Interface
> 
>   Have not seen any development since April 2013 (mx2-camera: move interface
>   activation and deactivation to clock callbacks by Guennadi). No idea if it still
>   works or if it is still in use. Does anyone know?
> 
> - mx3_camera: i.MX3x Camera Sensor Interface
> 
>   Have not seen any development since July 2013 (add support for asynchronous
>   subdevice registration by Guennadi). Same as for mx2_camera: does it still work?
>   Is it still in use?
> 
> - omap1_camera: OMAP1 Camera Interface
> 
>   It uses vb1, so that's one very good reason for removing it. And as far as I
>   know it is unused and likely won't work.
> 
> - sh_mobile_ceu_camera: SuperH Mobile CEU Interface
> 
>   I worked on this, but I know it does function anymore. I'd say that this can
>   be removed.
> 
> - sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface
> 
>   I don't have hardware to test, but I'd be surprised if it still works. Can
>   someone test? If it is broken, then it can be moved to staging.
> 
> - rcar_vin: R-Car Video Input (VIN)
>   Will be replaced with a regular driver as mentioned above.
> 
> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> 
>   I believe this is still actively maintained. Would someone be willing to
>   convert this? It doesn't look like a complex driver.
> 
> 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 guess we should try to remove the soc_camera.h dependency from them,
making the still alive drivers to use the I2C sensor drivers directly.

The point is that such sensors could be useful somewhere else.
For example, there are at least one or two such drivers that could be used
on em28xx-based cameras to replace some really ugly hacks there. Also,
gspca have sensor i2c code hardcoded on it.

So, I would hate to lose those sensor drivers in the process.

Regards,
Mauro
-- 
Thanks,
Mauro

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

[Hans Verkuil]

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).
>>
>> - mx2_camera: i.MX27 Camera Sensor Interface
>>
>>   Have not seen any development since April 2013 (mx2-camera: move interface
>>   activation and deactivation to clock callbacks by Guennadi). No idea if it still
>>   works or if it is still in use. Does anyone know?
>>
>> - mx3_camera: i.MX3x Camera Sensor Interface
>>
>>   Have not seen any development since July 2013 (add support for asynchronous
>>   subdevice registration by Guennadi). Same as for mx2_camera: does it still work?
>>   Is it still in use?
>>
>> - omap1_camera: OMAP1 Camera Interface
>>
>>   It uses vb1, so that's one very good reason for removing it. And as far as I
>>   know it is unused and likely won't work.
>>
>> - sh_mobile_ceu_camera: SuperH Mobile CEU Interface
>>
>>   I worked on this, but I know it does function anymore. I'd say that this can
>>   be removed.
>>
>> - sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface
>>
>>   I don't have hardware to test, but I'd be surprised if it still works. Can
>>   someone test? If it is broken, then it can be moved to staging.
>>
>> - rcar_vin: R-Car Video Input (VIN)
>>   Will be replaced with a regular driver as mentioned above.
>>
>> - atmel-isi: ATMEL Image Sensor Interface (ISI)
>>
>>   I believe this is still actively maintained. Would someone be willing to
>>   convert this? It doesn't look like a complex driver.
>>
>> 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.

The code is still available in git, even if we remove them. I don't really
like the idea of keeping code in the kernel that very likely won't work after
the soc-camera dependencies are removed.

Regards,

	Hans

> 
> I guess we should try to remove the soc_camera.h dependency from them,
> making the still alive drivers to use the I2C sensor drivers directly.
> 
> The point is that such sensors could be useful somewhere else.
> For example, there are at least one or two such drivers that could be used
> on em28xx-based cameras to replace some really ugly hacks there. Also,
> gspca have sensor i2c code hardcoded on it.
> 
> So, I would hate to lose those sensor drivers in the process.
> 
> Regards,
> Mauro
> 

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

[Robert Jarzmik]

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.

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.

Cheers.

-- 
Robert

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

[Hans Verkuil]

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

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

[Robert Jarzmik]

Hans Verkuil <hverkuil@xs4all.nl> writes:

>> 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 prepared the patch.

Now the question is : how will handle the pxa_camera patches, ie. taking them
through his tree ?

I'm under the impression that Guennadi is very busy, so for the MAINTAINERS
patch as for the next ones, which tree will be handling them ? Moreover as most
probably I will be the biggest contributor, who will be reviewing me ?

We might also pave a path of Guennadi's point (3), ie. have pxa_camera "become
independent V4L2 host".

> 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.
Ok, I'll have a look too.

Cheers.

--
Robert

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

[Hans Verkuil]

On 02/20/2016 10:33 PM, Robert Jarzmik wrote:
> Hans Verkuil <hverkuil@xs4all.nl> writes:
> 
>>> 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 prepared the patch.
> 
> Now the question is : how will handle the pxa_camera patches, ie. taking them
> through his tree ?
> 
> I'm under the impression that Guennadi is very busy, so for the MAINTAINERS
> patch as for the next ones, which tree will be handling them ? Moreover as most
> probably I will be the biggest contributor, who will be reviewing me ?

Guennadi is the soc-camera maintainer. So once pxa_camera no longer uses soc-camera
('independent v4l2 host') it would be me who would review the code and manages
patches.

BTW, where can I get pxa hardware? It is always nice if I am able to test code
as well. But I haven't been able to find a source for this platform.

Regards,

	Hans

> We might also pave a path of Guennadi's point (3), ie. have pxa_camera "become
> independent V4L2 host".
> 
>> 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.
> Ok, I'll have a look too.
> 
> Cheers.
> 
> --
> Robert
> 

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

[Guennadi Liakhovetski]

Hi Hans,

On Fri, 19 Feb 2016, Hans Verkuil wrote:

> 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.

Thanks for your proposal. Sure, I'm not holding onto soc-camera just for 
the sake of it. I'm open to whatever is found useful. As long as all 
active soc-camera users are happy with it being EOLed and respective 
drivers either disappearing or having to be transformed to stand-alone 
ones, I'm fine with that too!

Thanks
Guennadi

> 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).
> 
> - mx2_camera: i.MX27 Camera Sensor Interface
> 
>   Have not seen any development since April 2013 (mx2-camera: move interface
>   activation and deactivation to clock callbacks by Guennadi). No idea if it still
>   works or if it is still in use. Does anyone know?
> 
> - mx3_camera: i.MX3x Camera Sensor Interface
> 
>   Have not seen any development since July 2013 (add support for asynchronous
>   subdevice registration by Guennadi). Same as for mx2_camera: does it still work?
>   Is it still in use?
> 
> - omap1_camera: OMAP1 Camera Interface
> 
>   It uses vb1, so that's one very good reason for removing it. And as far as I
>   know it is unused and likely won't work.
> 
> - sh_mobile_ceu_camera: SuperH Mobile CEU Interface
> 
>   I worked on this, but I know it does function anymore. I'd say that this can
>   be removed.
> 
> - sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface
> 
>   I don't have hardware to test, but I'd be surprised if it still works. Can
>   someone test? If it is broken, then it can be moved to staging.
> 
> - rcar_vin: R-Car Video Input (VIN)
>   Will be replaced with a regular driver as mentioned above.
> 
> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> 
>   I believe this is still actively maintained. Would someone be willing to
>   convert this? It doesn't look like a complex driver.
> 
> 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.
> 
> Regards,
> 
> 	Hans
> 

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

[Guennadi Liakhovetski]

Adding a couple more people in the round, some emails may well bounce...

On Mon, 22 Feb 2016, Guennadi Liakhovetski wrote:

> Hi Hans,
> 
> On Fri, 19 Feb 2016, Hans Verkuil wrote:
> 
> > 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.
> 
> Thanks for your proposal. Sure, I'm not holding onto soc-camera just for 
> the sake of it. I'm open to whatever is found useful. As long as all 
> active soc-camera users are happy with it being EOLed and respective 
> drivers either disappearing or having to be transformed to stand-alone 
> ones, I'm fine with that too!
> 
> Thanks
> Guennadi
> 
> > 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).
> > 
> > - mx2_camera: i.MX27 Camera Sensor Interface
> > 
> >   Have not seen any development since April 2013 (mx2-camera: move interface
> >   activation and deactivation to clock callbacks by Guennadi). No idea if it still
> >   works or if it is still in use. Does anyone know?
> > 
> > - mx3_camera: i.MX3x Camera Sensor Interface
> > 
> >   Have not seen any development since July 2013 (add support for asynchronous
> >   subdevice registration by Guennadi). Same as for mx2_camera: does it still work?
> >   Is it still in use?
> > 
> > - omap1_camera: OMAP1 Camera Interface
> > 
> >   It uses vb1, so that's one very good reason for removing it. And as far as I
> >   know it is unused and likely won't work.
> > 
> > - sh_mobile_ceu_camera: SuperH Mobile CEU Interface
> > 
> >   I worked on this, but I know it does function anymore. I'd say that this can
> >   be removed.
> > 
> > - sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface
> > 
> >   I don't have hardware to test, but I'd be surprised if it still works. Can
> >   someone test? If it is broken, then it can be moved to staging.
> > 
> > - rcar_vin: R-Car Video Input (VIN)
> >   Will be replaced with a regular driver as mentioned above.
> > 
> > - atmel-isi: ATMEL Image Sensor Interface (ISI)
> > 
> >   I believe this is still actively maintained. Would someone be willing to
> >   convert this? It doesn't look like a complex driver.
> > 
> > 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.
> > 
> > Regards,
> > 
> > 	Hans
> > 
> 

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

[Laurent Pinchart]

Hi Guennadi,

On Monday 22 February 2016 08:11:31 Guennadi Liakhovetski wrote:
> On Mon, 22 Feb 2016, Guennadi Liakhovetski wrote:
> > On Fri, 19 Feb 2016, Hans Verkuil wrote:
> >> 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.
> >
> > Thanks for your proposal. Sure, I'm not holding onto soc-camera just for
> > the sake of it. I'm open to whatever is found useful. As long as all
> > active soc-camera users are happy with it being EOLed and respective
> > drivers either disappearing or having to be transformed to stand-alone
> > ones, I'm fine with that too!
> > 
> > Thanks
> > Guennadi
> > 
> >> 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).
> >> 
> >> - mx2_camera: i.MX27 Camera Sensor Interface
> >> 
> >>   Have not seen any development since April 2013 (mx2-camera: move
> >>   interface activation and deactivation to clock callbacks by Guennadi).
> >>   No idea if it still works or if it is still in use. Does anyone know?
> >> 
> >> - mx3_camera: i.MX3x Camera Sensor Interface
> >> 
> >>   Have not seen any development since July 2013 (add support for
> >>   asynchronous subdevice registration by Guennadi). Same as for
> >>   mx2_camera: does it still work? Is it still in use?
> >> 
> >> - omap1_camera: OMAP1 Camera Interface
> >> 
> >>   It uses vb1, so that's one very good reason for removing it. And as
> >>   far as I know it is unused and likely won't work.
> >> 
> >> - sh_mobile_ceu_camera: SuperH Mobile CEU Interface
> >> 
> >>   I worked on this, but I know it does function anymore. I'd say that
> >>   this can be removed.

As far as I know Renesas (or at least the kernel upstream team) doesn't care. 
The driver is only used on five SH boards, I'd also say it can be removed.

> >> - sh_mobile_csi2: SuperH Mobile MIPI CSI-2 Interface
> >> 
> >>   I don't have hardware to test, but I'd be surprised if it still works.
> >>   Can someone test? If it is broken, then it can be moved to staging.

The sh-mobile-csi2 driver is only used by the sh-mobile-ceu-camera driver, so 
I'd drop it too.

> >> - rcar_vin: R-Car Video Input (VIN)
> >> 
> >>   Will be replaced with a regular driver as mentioned above.
> >> 
> >> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> >> 
> >>   I believe this is still actively maintained. Would someone be willing
> >>   to convert this? It doesn't look like a complex driver.

That would be nice, I would like to avoid dropping this one.

> >> 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.

-- 
Regards,

Laurent Pinchart

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

[Guennadi Liakhovetski]

Hi Laurent,

On Mon, 22 Feb 2016, Laurent Pinchart wrote:

[snip]

> As far as I know Renesas (or at least the kernel upstream team) doesn't care. 
> The driver is only used on five SH boards, I'd also say it can be removed.

[snip]

> > >> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> > >> 
> > >>   I believe this is still actively maintained. Would someone be willing
> > >>   to convert this? It doesn't look like a complex driver.
> 
> That would be nice, I would like to avoid dropping this one.

Thanks for clarifying the state of the CEU driver. I did say, that I am 
fine with dropping soc-camera gradually, and I stay with that. But I see 
now, that at least two drivers want to stay active: Atmel ISI and PXA270. 
One possibility is of course to make them independent drivers. If people 
are prepared to invest work into that - sure, would be great! If we 
however decide to keep soc-camera, I could propose the following: IIUC, 
the largest problem is sensor drivers, that cannot be reused for other 
non-soc-camera bridge drivers. The thing is, out of all the sensor drivers 
currently under drivers/media/i2c/soc_camera only a couple are in use on 
those active PXA270 and Atmel boards. I could propose the following:

1. Remove all bridge drivers, that noone cares about.
2. If anyone ever needs to use any of soc-camera-associated sensor 
   drivers, take them out of soc-camera and _remove_ any soc-camera 
   dependencies
3. If any soc-camera boards will need that specific driver, which in 
   itself is already unlikely, we'll have to fix that by teaching 
   soc-camera to work with generic sensor drivers!

Thanks
Guennadi

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

[Laurent Pinchart]

Hi Guennadi,

(CC'ing Ludovic Desroches)

On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:
> Hi Laurent,
> 
> On Mon, 22 Feb 2016, Laurent Pinchart wrote:
> 
> [snip]
> 
> > As far as I know Renesas (or at least the kernel upstream team) doesn't
> > care. The driver is only used on five SH boards, I'd also say it can be
> > removed.
> [snip]
> 
> >>>> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> >>>> 
> >>>>   I believe this is still actively maintained. Would someone be
> >>>>   willing to convert this? It doesn't look like a complex driver.
> > 
> > That would be nice, I would like to avoid dropping this one.
> 
> Thanks for clarifying the state of the CEU driver. I did say, that I am
> fine with dropping soc-camera gradually, and I stay with that. But I see
> now, that at least two drivers want to stay active: Atmel ISI and PXA270.
> One possibility is of course to make them independent drivers. If people
> are prepared to invest work into that - sure, would be great! If we
> however decide to keep soc-camera, I could propose the following: IIUC,
> the largest problem is sensor drivers, that cannot be reused for other
> non-soc-camera bridge drivers. The thing is, out of all the sensor drivers
> currently under drivers/media/i2c/soc_camera only a couple are in use on
> those active PXA270 and Atmel boards. I could propose the following:
> 
> 1. Remove all bridge drivers, that noone cares about.
> 2. If anyone ever needs to use any of soc-camera-associated sensor
>    drivers, take them out of soc-camera and _remove_ any soc-camera
>    dependencies
> 3. If any soc-camera boards will need that specific driver, which in
>    itself is already unlikely, we'll have to fix that by teaching
>    soc-camera to work with generic sensor drivers!

That sounds like a good plan.

Ludovic, any chance someone at Atmel could convert the ISI driver ?

-- 
Regards,

Laurent Pinchart

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

[Ludovic Desroches]

On Mon, Feb 22, 2016 at 04:23:54PM +0200, Laurent Pinchart wrote:
> Hi Guennadi,
> 
> (CC'ing Ludovic Desroches)
> 
> On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:
> > Hi Laurent,
> > 
> > On Mon, 22 Feb 2016, Laurent Pinchart wrote:
> > 
> > [snip]
> > 
> > > As far as I know Renesas (or at least the kernel upstream team) doesn't
> > > care. The driver is only used on five SH boards, I'd also say it can be
> > > removed.
> > [snip]
> > 
> > >>>> - atmel-isi: ATMEL Image Sensor Interface (ISI)
> > >>>> 
> > >>>>   I believe this is still actively maintained. Would someone be
> > >>>>   willing to convert this? It doesn't look like a complex driver.
> > > 
> > > That would be nice, I would like to avoid dropping this one.
> > 
> > Thanks for clarifying the state of the CEU driver. I did say, that I am
> > fine with dropping soc-camera gradually, and I stay with that. But I see
> > now, that at least two drivers want to stay active: Atmel ISI and PXA270.
> > One possibility is of course to make them independent drivers. If people
> > are prepared to invest work into that - sure, would be great! If we
> > however decide to keep soc-camera, I could propose the following: IIUC,
> > the largest problem is sensor drivers, that cannot be reused for other
> > non-soc-camera bridge drivers. The thing is, out of all the sensor drivers
> > currently under drivers/media/i2c/soc_camera only a couple are in use on
> > those active PXA270 and Atmel boards. I could propose the following:
> > 
> > 1. Remove all bridge drivers, that noone cares about.
> > 2. If anyone ever needs to use any of soc-camera-associated sensor
> >    drivers, take them out of soc-camera and _remove_ any soc-camera
> >    dependencies
> > 3. If any soc-camera boards will need that specific driver, which in
> >    itself is already unlikely, we'll have to fix that by teaching
> >    soc-camera to work with generic sensor drivers!
> 
> That sounds like a good plan.
> 
> Ludovic, any chance someone at Atmel could convert the ISI driver ?

I add Songjun to the cc list. I think he has in mind to do this
conversion.

Songjun, can you confirm?

Full thread here:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/99290

Regards

Ludovic

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

[Wu, Songjun]

On 2/23/2016 00:08, Ludovic Desroches wrote:
> On Mon, Feb 22, 2016 at 04:23:54PM +0200, Laurent Pinchart wrote:
>> Hi Guennadi,
>>
>> (CC'ing Ludovic Desroches)
>>
>> On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:
>>> Hi Laurent,
>>>
>>> On Mon, 22 Feb 2016, Laurent Pinchart wrote:
>>>
>>> [snip]
>>>
>>>> As far as I know Renesas (or at least the kernel upstream team) doesn't
>>>> care. The driver is only used on five SH boards, I'd also say it can be
>>>> removed.
>>> [snip]
>>>
>>>>>>> - atmel-isi: ATMEL Image Sensor Interface (ISI)
>>>>>>>
>>>>>>>    I believe this is still actively maintained. Would someone be
>>>>>>>    willing to convert this? It doesn't look like a complex driver.
>>>>
>>>> That would be nice, I would like to avoid dropping this one.
>>>
>>> Thanks for clarifying the state of the CEU driver. I did say, that I am
>>> fine with dropping soc-camera gradually, and I stay with that. But I see
>>> now, that at least two drivers want to stay active: Atmel ISI and PXA270.
>>> One possibility is of course to make them independent drivers. If people
>>> are prepared to invest work into that - sure, would be great! If we
>>> however decide to keep soc-camera, I could propose the following: IIUC,
>>> the largest problem is sensor drivers, that cannot be reused for other
>>> non-soc-camera bridge drivers. The thing is, out of all the sensor drivers
>>> currently under drivers/media/i2c/soc_camera only a couple are in use on
>>> those active PXA270 and Atmel boards. I could propose the following:
>>>
>>> 1. Remove all bridge drivers, that noone cares about.
>>> 2. If anyone ever needs to use any of soc-camera-associated sensor
>>>     drivers, take them out of soc-camera and _remove_ any soc-camera
>>>     dependencies
>>> 3. If any soc-camera boards will need that specific driver, which in
>>>     itself is already unlikely, we'll have to fix that by teaching
>>>     soc-camera to work with generic sensor drivers!
>>
>> That sounds like a good plan.
>>
>> Ludovic, any chance someone at Atmel could convert the ISI driver ?
>
> I add Songjun to the cc list. I think he has in mind to do this
> conversion.
>
> Songjun, can you confirm?
>
> Full thread here:
> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/99290
>
Laurent, I will take the ISI driver, convert it from soc_camera to V4L2.

> Regards
>
> Ludovic
>

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

[Hans Verkuil]

On 02/23/2016 08:06 AM, Wu, Songjun wrote:
> 
> 
> On 2/23/2016 00:08, Ludovic Desroches wrote:
>> On Mon, Feb 22, 2016 at 04:23:54PM +0200, Laurent Pinchart wrote:
>>> Hi Guennadi,
>>>
>>> (CC'ing Ludovic Desroches)
>>>
>>> On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:
>>>> Hi Laurent,
>>>>
>>>> On Mon, 22 Feb 2016, Laurent Pinchart wrote:
>>>>
>>>> [snip]
>>>>
>>>>> As far as I know Renesas (or at least the kernel upstream team) doesn't
>>>>> care. The driver is only used on five SH boards, I'd also say it can be
>>>>> removed.
>>>> [snip]
>>>>
>>>>>>>> - atmel-isi: ATMEL Image Sensor Interface (ISI)
>>>>>>>>
>>>>>>>>    I believe this is still actively maintained. Would someone be
>>>>>>>>    willing to convert this? It doesn't look like a complex driver.
>>>>>
>>>>> That would be nice, I would like to avoid dropping this one.
>>>>
>>>> Thanks for clarifying the state of the CEU driver. I did say, that I am
>>>> fine with dropping soc-camera gradually, and I stay with that. But I see
>>>> now, that at least two drivers want to stay active: Atmel ISI and PXA270.
>>>> One possibility is of course to make them independent drivers. If people
>>>> are prepared to invest work into that - sure, would be great! If we
>>>> however decide to keep soc-camera, I could propose the following: IIUC,
>>>> the largest problem is sensor drivers, that cannot be reused for other
>>>> non-soc-camera bridge drivers. The thing is, out of all the sensor drivers
>>>> currently under drivers/media/i2c/soc_camera only a couple are in use on
>>>> those active PXA270 and Atmel boards. I could propose the following:
>>>>
>>>> 1. Remove all bridge drivers, that noone cares about.
>>>> 2. If anyone ever needs to use any of soc-camera-associated sensor
>>>>     drivers, take them out of soc-camera and _remove_ any soc-camera
>>>>     dependencies
>>>> 3. If any soc-camera boards will need that specific driver, which in
>>>>     itself is already unlikely, we'll have to fix that by teaching
>>>>     soc-camera to work with generic sensor drivers!
>>>
>>> That sounds like a good plan.
>>>
>>> Ludovic, any chance someone at Atmel could convert the ISI driver ?
>>
>> I add Songjun to the cc list. I think he has in mind to do this
>> conversion.
>>
>> Songjun, can you confirm?
>>
>> Full thread here:
>> http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/99290
>>
> Laurent, I will take the ISI driver, convert it from soc_camera to V4L2.

Great!

I'm happily surprised to see so much interest in replacing these soc-camera
drivers. It seems the time is right to do this.

Songjun, Robert, I think the upcoming r-car v2 patch series from Niklas is
likely to be a good starting point for the isi and pxa drivers to work from.
Besides, his work gave me the inspiration to start this discussion, so he's
to blame :-)

Guennadi, I'll prepare patches to move the omap1 and sh drivers to staging
in preparation of those being removed.

Does anyone know what the status is of the mx2 and mx3 drivers?

Regards,

	Hans