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

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.

Em Fri, 19 Feb 2016 14:24:08 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 71 lines

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.

Quoted 5 lines

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

Quoted 31 lines · Mauro Carvalho Chehab

Em Fri, 19 Feb 2016 14:24:08 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 28 lines

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:

Quoted 7 lines

Quoted 7 lines

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

Quoted 8 lines

Quoted 5 lines

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.

Quoted 32 lines · Hans Verkuil

Quoted 31 lines · Mauro Carvalho Chehab

Em Fri, 19 Feb 2016 14:24:08 +0100
Hans Verkuil <[email protected]> escreveu:

Quoted 28 lines

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:

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

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

Quoted 14 lines

Quoted 8 lines

Quoted 5 lines

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 :-(

Quoted 1 line

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.

Quoted 5 lines

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.

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.

Quoted 8 lines · Hans Verkuil

Quoted 5 lines

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

Quoted 3 lines

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

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

Hi Hans,

Quoted 16 lines · 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.

Quoted 8 lines

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

Quoted 55 lines

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

Quoted 63 lines · Guennadi Liakhovetski

Quoted 21 lines · 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:

Quoted 7 lines

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

Quoted 24 lines

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

Quoted 7 lines

Quoted 7 lines

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.

Quoted 4 lines

Quoted 4 lines

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

Quoted 8 lines

Quoted 8 lines

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

Quoted 5 lines

Quoted 5 lines

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.

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.

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Hi Laurent,

On Mon, 22 Feb 2016, Laurent Pinchart wrote:

[snip]

Quoted 3 lines

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]

Quoted 6 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Hi Guennadi,

(CC'ing Ludovic Desroches)

Quoted 29 lines · On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:

Hi Laurent,

On Mon, 22 Feb 2016, Laurent Pinchart wrote:

[snip]

Quoted 3 lines

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]

Quoted 6 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 7 lines

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 ?

Quoted 42 lines · Laurent Pinchart

Hi Guennadi,

(CC'ing Ludovic Desroches)

Quoted 29 lines · On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:

Hi Laurent,

On Mon, 22 Feb 2016, Laurent Pinchart wrote:

[snip]

Quoted 3 lines

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]

Quoted 6 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 7 lines

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!

Quoted 3 lines

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

Quoted 50 lines · Ludovic Desroches

Quoted 42 lines · Laurent Pinchart

Hi Guennadi,

(CC'ing Ludovic Desroches)

Quoted 29 lines · On Monday 22 February 2016 14:39:08 Guennadi Liakhovetski wrote:

Hi Laurent,

On Mon, 22 Feb 2016, Laurent Pinchart wrote:

[snip]

Quoted 3 lines

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]

Quoted 6 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 7 lines

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!

Quoted 3 lines

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.

Quoted 5 lines

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.