mbox series

[v2,0/4] media: soc_camera: ov9640: switch driver to v4l2_async

Message ID cover.1534339750.git.petrcvekcz@gmail.com (mailing list archive)
Headers show
Series media: soc_camera: ov9640: switch driver to v4l2_async | expand

Message

Petr Cvek Aug. 15, 2018, 1:30 p.m. UTC
From: Petr Cvek <petrcvekcz@gmail.com>

This patch series transfer the ov9640 driver from the soc_camera subsystem
into a standalone v4l2 driver. There is no changes except the required
v4l2_async calls, GPIO allocation, deletion of now unused variables,
a change from mdelay() to msleep() and an addition of SPDX identifiers
(as suggested in the v1 version RFC).

The config symbol has been changed from CONFIG_SOC_CAMERA_OV9640 to
CONFIG_VIDEO_OV9640.

Also as the drivers of the soc_camera seems to be orphaned I'm volunteering
as a maintainer of the driver (I own the hardware).

I've found the ov9640 seems to be used at least in (the future) HTC
Magician and Palm Zire72. These will need to define power and reset GPIOs
and remove the soc_camera definitions. I'm debugging it on magician now
(ov9640 was unusable on them since the pxa_camera switched from
the soc_camera).

Petr Cvek (4):
  media: soc_camera: ov9640: move ov9640 out of soc_camera
  media: i2c: ov9640: drop soc_camera code and switch to v4l2_async
  media: i2c: ov9640: add missing SPDX identifiers
  MAINTAINERS: Add Petr Cvek as a maintainer for the ov9640 driver

 MAINTAINERS                          |   6 +
 drivers/media/i2c/Kconfig            |   7 +
 drivers/media/i2c/Makefile           |   1 +
 drivers/media/i2c/ov9640.c           | 766 +++++++++++++++++++++++++++
 drivers/media/i2c/ov9640.h           | 207 ++++++++
 drivers/media/i2c/soc_camera/Kconfig |   6 +-
 6 files changed, 991 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/i2c/ov9640.c
 create mode 100644 drivers/media/i2c/ov9640.h

--
2.18.0

Comments

Sakari Ailus Sept. 14, 2018, 12:59 p.m. UTC | #1
Hi Petr,

On Wed, Aug 15, 2018 at 03:30:23PM +0200, petrcvekcz@gmail.com wrote:
> From: Petr Cvek <petrcvekcz@gmail.com>
> 
> This patch series transfer the ov9640 driver from the soc_camera subsystem
> into a standalone v4l2 driver. There is no changes except the required
> v4l2_async calls, GPIO allocation, deletion of now unused variables,
> a change from mdelay() to msleep() and an addition of SPDX identifiers
> (as suggested in the v1 version RFC).
> 
> The config symbol has been changed from CONFIG_SOC_CAMERA_OV9640 to
> CONFIG_VIDEO_OV9640.
> 
> Also as the drivers of the soc_camera seems to be orphaned I'm volunteering
> as a maintainer of the driver (I own the hardware).

Thanks for the set. The patches seem good to me as such but there's some
more work to do there. For one, the depedency to v4l2_clk should be
removed; the common clock framework has supported clocks from random
devices for many, many years now.

The PXA camera driver does still depend on v4l2_clk so I guess this is
better to do later on in a different patchset.
Petr Cvek Sept. 14, 2018, 9 p.m. UTC | #2
Dne 14.9.2018 v 14:59 Sakari Ailus napsal(a):
> Hi Petr,
> 
> On Wed, Aug 15, 2018 at 03:30:23PM +0200, petrcvekcz@gmail.com wrote:
>> From: Petr Cvek <petrcvekcz@gmail.com>
>>
>> This patch series transfer the ov9640 driver from the soc_camera subsystem
>> into a standalone v4l2 driver. There is no changes except the required
>> v4l2_async calls, GPIO allocation, deletion of now unused variables,
>> a change from mdelay() to msleep() and an addition of SPDX identifiers
>> (as suggested in the v1 version RFC).
>>
>> The config symbol has been changed from CONFIG_SOC_CAMERA_OV9640 to
>> CONFIG_VIDEO_OV9640.
>>
>> Also as the drivers of the soc_camera seems to be orphaned I'm volunteering
>> as a maintainer of the driver (I own the hardware).
> 
> Thanks for the set. The patches seem good to me as such but there's some
> more work to do there. For one, the depedency to v4l2_clk should be
> removed; the common clock framework has supported clocks from random
> devices for many, many years now.
> 
> The PXA camera driver does still depend on v4l2_clk so I guess this is
> better to do later on in a different patchset.
> 

Yeah I too would like to remove the v4l2_clk from both of them. We've
had the discussion about clock dependency around v1 patch set:
"[BUG, RFC] media: Wrong module gets acquired"

cheers,
Petr