Re: [PATCH v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
Hi Mauro and Devin, first I'm a she. Could you please check if the enclosed patch fixes the tuner issue? Use it instead of the patch you've made. If it doesn't work, please send us the dmesg logs with tuner-xc2028 debug enabled. Great, it works! :) Much, much thanks. Please let this patch upstream as fast as possible. Regards, Alina -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATH v2] cxd2820r: fix possible out-of-array lookup
When I2C_WRITE is used the msg[] array contains one element only.
Don't access msg[1] in that case. Also moved rest of msg2[1]
setting to be used only if needed.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
---
diff -r ae517614bf00 drivers/media/dvb/frontends/cxd2820r_core.c
--- a/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 15:44:49
2011 +0200
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 16:20:17
2011 +0200
@@ -747,12 +747,7 @@ static int cxd2820r_tuner_i2c_xfer(struc
.flags = 0,
.len = sizeof(obuf),
.buf = obuf,
- }, {
- .addr = priv-cfg.i2c_address,
- .flags = I2C_M_RD,
- .len = msg[1].len,
- .buf = msg[1].buf,
- }
+ },
};
obuf[0] = 0x09;
@@ -760,6 +755,11 @@ static int cxd2820r_tuner_i2c_xfer(struc
if (num == 2) { /* I2C read */
obuf[1] = (msg[0].addr 1) | I2C_M_RD; /* I2C RD flag */
msg2[0].len = sizeof(obuf) - 1; /* maybe HW bug ? */
+
+ msg2[1].addr = priv-cfg.i2c_address,
+ msg2[1].flags = I2C_M_RD,
+ msg2[1].len = msg[1].len,
+ msg2[1].buf = msg[1].buf,
}
memcpy(obuf[2], msg[0].buf, msg[0].len);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] adp1653: check error code of adp1653_init_controls
On Thu, 2011-07-28 at 16:34 +0200, Laurent Pinchart wrote:
- adp1653_init_controls(flash);
+ ret = adp1653_init_controls(flash);
+ if (ret)
+ goto free_and_quit;
ret = media_entity_init(flash-subdev.entity, 0, NULL, 0);
if (ret 0)
- kfree(flash);
+ goto free_and_quit;
+ return 0;
+
+free_and_quit:
+ v4l2_ctrl_handler_free(flash-ctrls);
+ kfree(flash);
return ret;
What about
ret = adp1653_init_controls(flash);
if (ret)
goto done;
ret = media_entity_init(flash-subdev.entity, 0, NULL, 0);
done:
if (ret 0) {
v4l2_ctrl_handler_free(flash-ctrls);
kfree(flash);
}
return ret;
There is no difference at first glance. However, your variant is less
straight to understand for my opinion.
--
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Dear all, I'm playing with imx27ipcam reference design and I would like to use more recent (or actual) kernel than the one in BSP (2.6.19). I had no problems with running 2.6.39 version from mainline, and now I want to get some signal from CMOS chip. As there is no driver for mt9d131 yet I modified the mt9m111 driver to communicate wit it. Driver gets correctly initialized mx2-camera mx2-camera.0: initialising mx2-camera mx2-camera.0: Camera clock frequency: 625 mx2-camera mx2-camera.0: Using EMMA camera 0-0: Probing 0-0 mx27ipcam_camera_power: 1 mx27ipcam_camera_reset mx2-camera mx2-camera.0: Camera driver attached to camera 0 mt9m111 0-0048: read reg.000 - 1519 mt9m111 0-0048: Detected a MT9D131 chip ID 1519 camera 0-0: Found 8 supported formats. mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx27ipcam_camera_power: 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 625 For example this command should capture several frames ffmpeg -s qvga -r 30 -t 2 -pix_fmt yuyv422 -f video4linux2 -i /dev/video0 temp_vid.h263 however there is some problems with dma_contig allocation mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed [video4linux2 @ 0xfa8c50]mmap: Cannot allocate memory /dev/video0: Input/output error ... camera 0-0: mmap called, vma=0xc397fd30 camera 0-0: vma start=0x4014c000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fcd8 camera 0-0: vma start=0x40ee8000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fc80 camera 0-0: vma start=0x40fa4000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fc28 camera 0-0: vma start=0x4109a000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fbd0 camera 0-0: vma start=0x41124000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fb78 camera 0-0: vma start=0x4118a000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fb20 camera 0-0: vma start=0x41241000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fac8 camera 0-0: vma start=0x41277000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fa70 camera 0-0: vma start=0x412c3000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fa18 camera 0-0: vma start=0x41377000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f9c0 camera 0-0: vma start=0x41416000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f968 camera 0-0: vma start=0x4147f000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f910 camera 0-0: vma start=0x414a5000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f8b8 camera 0-0: vma start=0x41542000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f860 camera 0-0: vma start=0x415ba000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f808 mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed camera 0-0: vma start=0x41667000, size=155648, ret=-12 mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx27ipcam_camera_power: 0 camera 0-0: camera device close It seems like there is no dma buffer initialized for mx2_camera driver. Could please anyone give me some hint how to deal with it? regards Jan -- Tato zpráva byla vytvořena převratným poštovním klientem Opery: http://www.opera.com/mail/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] v4l: events: Define frame start event
On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: Hi Sakari, Hi, Laurent! On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: [snip] +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldbuffer_sequence/structfield/entry + entry + The sequence number of the buffer to be handled next or + currently handled by the driver. What happens if a particular piece of hardware can capture two (or more) simultaneous streams from the same video source (an unscaled compressed stream and a scaled down uncompressed stream for instance) ? Applications don't need to start both streams at the same time, what buffer sequence number should be reported in that case ? I think that if the video data comes from the same source, the sequence numbers should definitely be in sync. This would mean that for the second stream the first sequence number wouldn't be zero. Then we should document this somewhere. Here is probably not the best place to document that, but the buffer_sequence documentation should still refer to the explanation. I also find the wording a bit unclear. The buffer to be handled next could mean the buffer that will be given to an application at the next DQBUF call. Maybe we should refer to frame sequence numbers instead of buffer sequence numbers. What's the difference? I would consider the two the same. ...buffer to be written next to by the hardware? + /entry + /row + /tbody + /tgroup +/table + table pgwide=1 frame=none id=changes-flags titleChanges/title tgroup cols=3 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 275be96..812b63c 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -139,6 +139,24 @@ /entry /row row + entryconstantV4L2_EVENT_FRAME_SYNC/constant/entry + entry4/entry + entry + paraTriggered immediately when the reception of a + frame has begun. This event has a + v4l2-event-frame-sync; associated with it./para + + paraA driver will only generate this event when the + hardware can generate it. This might not be the case + e.g. when the hardware has no DMA buffer to write the + image data to. In such cases the + structfieldbuffer_sequence/structfield field in + v4l2-event-frame-sync; will not be incremented either. + This causes two consecutive buffer sequence numbers to + have n times frame interval in between them./para I don't think that's correct. Don't many drivers still increment the sequence number in that case, to make it possible for applications to detect frame loss ? I think I understood once that the OMAP 3 ISP driver didn't do this in all cases but I later learned that this isn't the case. I still would be actually a bit surprised if there was not hardware that could not do this. Do you think the text is relevant in this context, or should it be removed? I think you should just mention that the event *might* not be generated if the hardware needs to be stopped in case of buffer underrun for instance. Ack. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Hello, On Fri, Jul 29, 2011 at 09:31:28AM +0200, Jan Pohanka wrote: I'm playing with imx27ipcam reference design and I would like to use more recent (or actual) kernel than the one in BSP (2.6.19). I had no problems with running 2.6.39 version from mainline, and now I want to get some signal from CMOS chip. As there is no driver for mt9d131 yet I modified the mt9m111 driver to communicate wit it. Driver gets correctly initialized mx2-camera mx2-camera.0: initialising mx2-camera mx2-camera.0: Camera clock frequency: 625 mx2-camera mx2-camera.0: Using EMMA camera 0-0: Probing 0-0 mx27ipcam_camera_power: 1 mx27ipcam_camera_reset mx2-camera mx2-camera.0: Camera driver attached to camera 0 mt9m111 0-0048: read reg.000 - 1519 mt9m111 0-0048: Detected a MT9D131 chip ID 1519 camera 0-0: Found 8 supported formats. mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx27ipcam_camera_power: 0 mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 625 For example this command should capture several frames ffmpeg -s qvga -r 30 -t 2 -pix_fmt yuyv422 -f video4linux2 -i /dev/video0 temp_vid.h263 however there is some problems with dma_contig allocation mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed [video4linux2 @ 0xfa8c50]mmap: Cannot allocate memory /dev/video0: Input/output error ... camera 0-0: mmap called, vma=0xc397fd30 camera 0-0: vma start=0x4014c000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fcd8 camera 0-0: vma start=0x40ee8000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fc80 camera 0-0: vma start=0x40fa4000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fc28 camera 0-0: vma start=0x4109a000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fbd0 camera 0-0: vma start=0x41124000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fb78 camera 0-0: vma start=0x4118a000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fb20 camera 0-0: vma start=0x41241000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fac8 camera 0-0: vma start=0x41277000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fa70 camera 0-0: vma start=0x412c3000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397fa18 camera 0-0: vma start=0x41377000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f9c0 camera 0-0: vma start=0x41416000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f968 camera 0-0: vma start=0x4147f000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f910 camera 0-0: vma start=0x414a5000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f8b8 camera 0-0: vma start=0x41542000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f860 camera 0-0: vma start=0x415ba000, size=155648, ret=0 camera 0-0: mmap called, vma=0xc397f808 mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed camera 0-0: vma start=0x41667000, size=155648, ret=-12 mx2-camera mx2-camera.0: Camera driver detached from camera 0 mx27ipcam_camera_power: 0 camera 0-0: camera device close Check out what arch/arm/mach-imx/mach-pcm037.c does to give some memory to the camera device. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
On Thu, Jul 28, 2011 at 02:42:52PM +0200, Hans Verkuil wrote:
On Thursday, July 28, 2011 14:29:38 Guennadi Liakhovetski wrote:
On Thu, 28 Jul 2011, Hans Verkuil wrote:
On Thursday, July 28, 2011 06:11:38 Pawel Osciak wrote:
Hi Guennadi,
On Wed, Jul 20, 2011 at 01:43, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
A possibility to preallocate and initialise buffers of different sizes
in V4L2 is required for an efficient implementation of asnapshot mode.
This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and
VIDIOC_PREPARE_BUF and defines respective data structures.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
snip
This looks nicer, I like how we got rid of destroy and gave up on
making holes, it would've given us a lot of headaches. I'm thinking
about some issues though and also have some comments/questions further
below.
Already mentioned by others mixing of REQBUFS and CREATE_BUFS.
Personally I'd like to allow mixing, including REQBUFS for non-zero,
because I think it would be easy to do. I think it could work in the
same way as REQBUFS for !=0 works currently (at least in vb2), if we
already have some buffers allocated and they are not in use, we free
them and a new set is allocated. So I guess it could just stay this
way. REQBUFS(0) would of course free everything.
Passing format to CREATE_BUFS will make vb2 a bit format-aware, as it
would have to pass it forward to the driver somehow. The obvious way
would be just vb2 calling the driver's s_fmt handler, but that won't
work, as you can't pass indexes to s_fmt. So we'd have to implement a
new driver callback for setting formats per index. I guess there is no
way around it, unless we actually take the format struct out of
CREATE_BUFS and somehow do it via S_FMT. The single-planar structure
is full already though, the only way would be to use
v4l2_pix_format_mplane instead with plane count = 1 (or more if
needed).
I just got an idea for this: use TRY_FMT. That will do exactly what
you want. In fact, perhaps we should remove the format struct from
CREATE_BUFS and use __u32 sizes[VIDEO_MAX_PLANES] instead. Let the
application call TRY_FMT and initialize the sizes array instead of
putting that into vb2. We may need a num_planes field as well. If the
sizes are all 0 (or num_planes is 0), then the driver can use the current
format, just as it does with REQBUFS.
Hm, I think, I like this idea. It gives applications more flexibility and
removes the size == 0 vs. size != 0 dilemma. So, we get
/* VIDIOC_CREATE_BUFS */
struct v4l2_create_buffers {
__u32 index; /* output: buffers
index...index + count - 1 have been created */
__u32 count;
__u32 num_planes;
__u32 sizes[VIDEO_MAX_PLANES];
enum v4l2_memorymemory;
enum v4l2_buf_type type;
__u32 reserved[8];
};
?
Yes. I'd probably rearrange the fields a bit, though:
/* VIDIOC_CREATE_BUFS */
struct v4l2_create_buffers {
__u32 index; /* output: buffers
index...index + count - 1 have been created */
__u32 count;
__u32 type;
__u32 memory;
__u32 num_planes;
__u32 sizes[VIDEO_MAX_PLANES];
__u32 reserved[8];
};
The order of the count, type and memory fields is now identical to that of
v4l2_requestbuffers.
I also changed the enums to u32 since without the v4l2_format struct we
shouldn't
use enums. As an additional bonus this also simplifies the compat32 code.
I have to say I like what I see above. :-)
I have one comment at this point, which is what I always have: reserved
fields. If we want to later add per-plane fields, 8 u32s isn't much for
that. CREATE_BUFS isn't time critical either at all, so I'd go with 19 (to
align the buffer size to a power of 2) or even more.
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
On Wed, Jul 27, 2011 at 11:55:55PM -0300, Mauro Carvalho Chehab wrote: Hi Sylwester, Em 27-07-2011 13:35, Sylwester Nawrocki escreveu: Hi Mauro, The following changes since commit f0a21151140da01c71de636f482f2eddec2840cc: Merge tag 'v3.0' into staging/for_v3.1 (2011-07-22 13:33:14 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung fimc-for-mauro Sylwester Nawrocki (28): s5p-fimc: Add support for runtime PM in the mem-to-mem driver s5p-fimc: Add media entity initialization s5p-fimc: Remove registration of video nodes from probe() s5p-fimc: Remove sclk_cam clock handling s5p-fimc: Limit number of available inputs to one s5p-fimc: Remove sensor management code from FIMC capture driver s5p-fimc: Remove v4l2_device from video capture and m2m driver s5p-fimc: Add the media device driver s5p-fimc: Conversion to use struct v4l2_fh s5p-fimc: Conversion to the control framework s5p-fimc: Add media operations in the capture entity driver s5p-fimc: Add PM helper function for streaming control s5p-fimc: Correct color format enumeration s5p-fimc: Convert to use media pipeline operations s5p-fimc: Add subdev for the FIMC processing block s5p-fimc: Add support for camera capture in JPEG format s5p-fimc: Add v4l2_device notification support for single frame capture s5p-fimc: Use consistent names for the buffer list functions s5p-fimc: Add runtime PM support in the camera capture driver s5p-fimc: Correct crop offset alignment on exynos4 s5p-fimc: Remove single-planar capability flags noon010pc30: Do not ignore errors in initial controls setup noon010pc30: Convert to the pad level ops noon010pc30: Clean up the s_power callback noon010pc30: Remove g_chip_ident operation handler s5p-csis: Handle all available power supplies s5p-csis: Rework of the system suspend/resume helpers s5p-csis: Enable v4l subdev device node From the last time you've submitted a similar set of patches: Why? The proper way to select an input is via S_INPUT. The driver may also optionally allow changing it via the media device, but it should not be a mandatory requirement, as the media device API is optional. The problem I'm trying to solve here is sharing the sensors and mipi-csi receivers between multiple FIMC H/W instances. Previously the driver supported attaching a sensor to only one selected FIMC at compile time. You could, for instance, specify all sensors as the selected FIMC's platform data and then use S_INPUT to choose between them. The sensor could not be used together with any other FIMC. But this is desired due to different capabilities of the FIMC IP instances. And now, instead of hardcoding a sensor assigment to particular video node, the sensors are bound to the media device. The media device driver takes the list of sensors and attaches them one by one to subsequent FIMC instances when it is initializing. Each sensor has a link to each FIMC but only one of them is active by default. That said an user application can use selected camera by opening corresponding video node. Which camera is at which node can be queried with G_INPUT. I could try to implement the previous S_INPUT behaviour, but IMHO this would lead to considerable and unnecessary driver code complication due to supporting overlapping APIs From this current pull request: From c6fb462c38be60a45d16a29a9e56c886ee0aa08c Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki s.nawro...@samsung.com Date: Fri, 10 Jun 2011 20:36:51 +0200 Subject: s5p-fimc: Conversion to the control framework Cc: Linux Media Mailing List linux-media@vger.kernel.org Make the driver inherit sensor controls when video node only API compatibility mode is enabled. The control framework allows to properly handle sensor controls through controls inheritance when pipeline is re-configured at media device level. ... - .vidioc_queryctrl = fimc_vidioc_queryctrl, - .vidioc_g_ctrl = fimc_vidioc_g_ctrl, - .vidioc_s_ctrl = fimc_cap_s_ctrl, ... I'll need to take some time to review this patchset. So, it will likely miss the bus for 3.1. While the code inside this patch looked ok, your comments scared me ;) In summary: The V4L2 API is not a legacy API that needs a compatibility mode. Removing controls like VIDIOC_S_INPUT, VIDIOC_*CTRL, etc in favor of the media controller API is wrong. This specific patch itself seems ok, but it is easy to loose the big picture on a series of 28 patches with about 4000 lines changed. I remember this was discussed among with the last pull request on the patches. I don't remember seeing your reply in the thread
Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Friday 29 July 2011 06:02:54 Mauro Carvalho Chehab wrote: Em 28-07-2011 19:57, Sylwester Nawrocki escreveu: On 07/28/2011 03:20 PM, Mauro Carvalho Chehab wrote: Accumulating sub-dev controls at the video node is the right thing to do. An MC-aware application will need to handle with that, but that doesn't sound to be hard. All such application would need to do is to first probe the subdev controls, and, when parsing the videodev controls, not register controls with duplicated ID's, or to mark them with some special attribute. IMHO it's not a big issue in general. Still, both subdev and the host device may support same control id. And then even though the control ids are same on the subdev and the host they could mean physically different controls (since when registering a subdev at the host driver the host's controls take precedence and doubling subdev controls are skipped). True, but, except for specific usecases, the host control is enough. Not for embedded devices. In many case the control won't even be implemented by the host. If your system has two sensors connected to the same host, they will both expose an exposure time control. Which one do you configure through the video node ? The two sensors will likely have different bounds for the same control, how do you report that ? Those controls are also quite useless for generic V4L2 applications, which will want auto-exposure anyway. This needs to be implemented in userspace in libv4l. Also there might be some preference at user space, at which stage of the pipeline to apply some controls. This is where the subdev API helps, and plain video node API does not. Again, this is for specific usecases. On such cases, what is expected is that the more generic control will be exported via V4L2 API. Thus it's a bit hard to imagine that we could do something like optionally not to inherit controls as the subdev/MC API is optional. :) This was actually implemented. There are some cases at ivtv/cx18 driver where both the bridge and a subdev provides the same control (audio volume, for example). The idea is to allow the bridge driver to touch at the subdev control without exposing it to userspace, since the desire was that the bridge driver itself would expose such control, using a logic that combines changing the subdev and the bridge registers for volume. This seem like hard coding a policy in the driver;) Then there is no way (it might not be worth the effort though) to play with volume level at both devices, e.g. to obtain optimal S/N ratio. In general, playing with just one control is enough. Andy had a different opinion when this issue were discussed, and he thinks that playing with both is better. At the end, this is a developers decision, depending on how much information (and bug reports) he had. ivtv/cx18 is a completely different use case, where hardware configurations are known, and experiments possible to find out which control(s) to use and how. In this case you can't know in advance what the sensor and host drivers will be used for. Even if you did, fine image quality tuning requires accessing pretty much all controls individually anyway. This is a hack...sorry, just joking ;-) Seriously, I think the situation with the userspace subdevs is a bit different. Because with one API we directly expose some functionality for applications, with other we code it in the kernel, to make the devices appear uniform at user space. Not sure if I understood you. V4L2 export drivers functionality to userspace in an uniform way. MC api is for special applications that might need to access some internal functions on embedded devices. Of course, there are some cases where it doesn't make sense to export a subdev control via V4L2 API. Also, the sensor subdev can be configured in the video node driver as well as through the subdev device node. Both APIs can do the same thing but in order to let the subdev API work as expected the video node driver must be forbidden to configure the subdev. Why? For the sensor, a V4L2 API call will look just like a bridge driver call. The subdev will need a mutex anyway, as two MC applications may be opening it simultaneously. I can't see why it should forbid changing the control from the bridge driver call. Please do not forget there might be more than one subdev to configure and that the bridge itself is also a subdev (which exposes a scaler interface, for instance). A situation pretty much like in Figure 4.4 [1] (after the scaler there is also a video node to configure, but we may assume that pixel resolution at the scaler pad 1 is same as at the video node). Assuming the format and crop configuration flow is from sensor to host scaler direction, if we have tried to configure _all_ subdevs when the last stage of the pipeline is configured (i.e. video node) the whole
Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Hi Uwe,
thank you for answer. You are right I give no memory to camera device in
mach-imx27ipcam.c. I have tried to do it in same way as it is in
mach-pcm037.c but no success. Here is my init function
static int __init mx27ipcam_camera_init(void) {
int dma, ret = -ENOMEM;
struct platform_device *pdev;
printk(MX2 camera initialization.\n);
pdev = imx27_add_mx2_camera(mx27ipcam_camera);
if (IS_ERR(pdev)) {
printk(pdev error\n);
return PTR_ERR(pdev);
}
dma = dma_declare_coherent_memory(pdev-dev,
mx2_camera_base, mx2_camera_base,
MX2_CAMERA_BUF_SIZE,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
if (!(dma DMA_MEMORY_MAP))
goto err;
ret = platform_device_add(pdev);
if (ret) {
printk(platform_device_add error\n);
err:
platform_device_put(pdev);
}
return ret;
}
I do not understand fully this business around allocation so it may be
wrong.
regards
Jan
Dne Fri, 29 Jul 2011 09:51:43 +0200 Uwe Kleine-König
u.kleine-koe...@pengutronix.de napsal(a):
Hello,
On Fri, Jul 29, 2011 at 09:31:28AM +0200, Jan Pohanka wrote:
I'm playing with imx27ipcam reference design and I would like to use
more recent (or actual) kernel than the one in BSP (2.6.19). I had
no problems with running 2.6.39 version from mainline, and now I
want to get some signal from CMOS chip. As there is no driver for
mt9d131 yet I modified the mt9m111 driver to communicate wit it.
Driver gets correctly initialized
mx2-camera mx2-camera.0: initialising
mx2-camera mx2-camera.0: Camera clock frequency: 625
mx2-camera mx2-camera.0: Using EMMA
camera 0-0: Probing 0-0
mx27ipcam_camera_power: 1
mx27ipcam_camera_reset
mx2-camera mx2-camera.0: Camera driver attached to camera 0
mt9m111 0-0048: read reg.000 - 1519
mt9m111 0-0048: Detected a MT9D131 chip ID 1519
camera 0-0: Found 8 supported formats.
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx27ipcam_camera_power: 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 625
For example this command should capture several frames
ffmpeg -s qvga -r 30 -t 2 -pix_fmt yuyv422 -f video4linux2 -i
/dev/video0 temp_vid.h263
however there is some problems with dma_contig allocation
mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed
[video4linux2 @ 0xfa8c50]mmap: Cannot allocate memory
/dev/video0: Input/output error
...
camera 0-0: mmap called, vma=0xc397fd30
camera 0-0: vma start=0x4014c000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fcd8
camera 0-0: vma start=0x40ee8000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fc80
camera 0-0: vma start=0x40fa4000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fc28
camera 0-0: vma start=0x4109a000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fbd0
camera 0-0: vma start=0x41124000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fb78
camera 0-0: vma start=0x4118a000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fb20
camera 0-0: vma start=0x41241000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fac8
camera 0-0: vma start=0x41277000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fa70
camera 0-0: vma start=0x412c3000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397fa18
camera 0-0: vma start=0x41377000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f9c0
camera 0-0: vma start=0x41416000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f968
camera 0-0: vma start=0x4147f000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f910
camera 0-0: vma start=0x414a5000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f8b8
camera 0-0: vma start=0x41542000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f860
camera 0-0: vma start=0x415ba000, size=155648, ret=0
camera 0-0: mmap called, vma=0xc397f808
mx2-camera mx2-camera.0: dma_alloc_coherent size 155648 failed
camera 0-0: vma start=0x41667000, size=155648, ret=-12
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx27ipcam_camera_power: 0
camera 0-0: camera device close
Check out what arch/arm/mach-imx/mach-pcm037.c does to give some memory
to the camera device.
Best regards
Uwe
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Laurent,
I've been reviewing and testing your patch as promised.
On 27 July 2011 19:51, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ int ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON);
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_1,
+ (mt9p031-m 8) | (mt9p031-n - 1));
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-p1 - 1);
+ if (ret 0)
+ return ret;
+
+ mdelay(1);
mdelay() is a busyloop. Either msleep(), if the timing isn't critical, and
if it is, then usleep_range().
Timing isn't critical, but that's a stream-on delay, so I'll use
usleep_range().
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON |
+ MT9P031_PLL_CONTROL_USEPLL);
+ mdelay(1);
Javier, is this second mdelay() needed ?
No, sorry, I included it because I was having problems with PLLs and
wanted to be very cautious. You can safely remove it. It is not
specified in the datasheet and I've just tested it myself.
Apart from the minor issues mentioned by Sakari, I think dynamic
calculation of PLL dividers should be postponed for a next version
thus not delaying this one to enter mainline.
However I'm having problems for testing your version with linux-3.0
and my old test yavta + mplayer:
On my PC:
nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo
w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11
On my Beagleboard:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP
CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]'
Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0
Format set: SGRBG12 370x243
Setting up format SGRBG12 370x243 on pad OMAP3 ISP CCDC/0
Format set: SGRBG12 370x243
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0
Format set: SGRBG8 320x240
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1
Format set: SGRBG8 320x240
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40082000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x400a8000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4016a000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x402be000.
Unable to start streaming: 32.
What are you using for testing?
By the way, this is my last day in the office till August the 14th.
Furthermore, I've got no intention to be the maintainer of the driver,
since probably the main contributor to the patch was Guennadi.
However, as we'll be using this driver for a project that will last
for a year, count on me for testing, reviewing patches, etc... Because
out interest on this patch going into mainline is high.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Hi Jan,
On Fri, Jul 29, 2011 at 10:59:55AM +0200, Jan Pohanka wrote:
thank you for answer. You are right I give no memory to camera
device in mach-imx27ipcam.c. I have tried to do it in same way as it
is in mach-pcm037.c but no success. Here is my init function
static int __init mx27ipcam_camera_init(void) {
int dma, ret = -ENOMEM;
struct platform_device *pdev;
printk(MX2 camera initialization.\n);
pdev = imx27_add_mx2_camera(mx27ipcam_camera);
if (IS_ERR(pdev)) {
printk(pdev error\n);
return PTR_ERR(pdev);
}
dma = dma_declare_coherent_memory(pdev-dev,
mx2_camera_base, mx2_camera_base,
MX2_CAMERA_BUF_SIZE,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
if (!(dma DMA_MEMORY_MAP))
goto err;
ret = platform_device_add(pdev);
if (ret) {
printk(platform_device_add error\n);
err:
platform_device_put(pdev);
}
return ret;
}
and you also have a reserve callback? See commit
90026c8c823bff54172eab33a5e7fcecfd3df635 for all details.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] v4l: events: Define frame start event
Hi Sakari, On Friday 29 July 2011 09:44:46 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: [snip] +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldbuffer_sequence/structfield/entry + entry + The sequence number of the buffer to be handled next or + currently handled by the driver. What happens if a particular piece of hardware can capture two (or more) simultaneous streams from the same video source (an unscaled compressed stream and a scaled down uncompressed stream for instance) ? Applications don't need to start both streams at the same time, what buffer sequence number should be reported in that case ? I think that if the video data comes from the same source, the sequence numbers should definitely be in sync. This would mean that for the second stream the first sequence number wouldn't be zero. Then we should document this somewhere. Here is probably not the best place to document that, but the buffer_sequence documentation should still refer to the explanation. I also find the wording a bit unclear. The buffer to be handled next could mean the buffer that will be given to an application at the next DQBUF call. Maybe we should refer to frame sequence numbers instead of buffer sequence numbers. What's the difference? I would consider the two the same. If we have multiple simultaneous streams from the same source, I think it would make sense to start thinking about frame sequence numbers instead of buffer sequence numbers. The buffer sequence number would then just store the frame sequence number of the frame stored in the buffer. This would (in my opinion) simplify the spec's understanding. ...buffer to be written next to by the hardware? What about ...buffer that will store the image ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] v4l: events: Define frame start event
On Fri, Jul 29, 2011 at 11:38:16AM +0200, Laurent Pinchart wrote: Hi Sakari, On Friday 29 July 2011 09:44:46 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: [snip] +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldbuffer_sequence/structfield/entry + entry + The sequence number of the buffer to be handled next or + currently handled by the driver. What happens if a particular piece of hardware can capture two (or more) simultaneous streams from the same video source (an unscaled compressed stream and a scaled down uncompressed stream for instance) ? Applications don't need to start both streams at the same time, what buffer sequence number should be reported in that case ? I think that if the video data comes from the same source, the sequence numbers should definitely be in sync. This would mean that for the second stream the first sequence number wouldn't be zero. Then we should document this somewhere. Here is probably not the best place to document that, but the buffer_sequence documentation should still refer to the explanation. I also find the wording a bit unclear. The buffer to be handled next could mean the buffer that will be given to an application at the next DQBUF call. Maybe we should refer to frame sequence numbers instead of buffer sequence numbers. What's the difference? I would consider the two the same. If we have multiple simultaneous streams from the same source, I think it would make sense to start thinking about frame sequence numbers instead of buffer sequence numbers. The buffer sequence number would then just store the frame sequence number of the frame stored in the buffer. This would (in my opinion) simplify the spec's understanding. Another good point from you, I agree with this. ...buffer to be written next to by the hardware? What about ...buffer that will store the image ? But which image? And if there is no buffer, no image is written to it either. frame to be processed or being processed by the hardware? -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] v4l: events: Define frame start event
On Friday 29 July 2011 11:54:03 Sakari Ailus wrote: On Fri, Jul 29, 2011 at 11:38:16AM +0200, Laurent Pinchart wrote: On Friday 29 July 2011 09:44:46 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: [snip] +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldbuffer_sequence/structfield/entry + entry + The sequence number of the buffer to be handled next or + currently handled by the driver. What happens if a particular piece of hardware can capture two (or more) simultaneous streams from the same video source (an unscaled compressed stream and a scaled down uncompressed stream for instance) ? Applications don't need to start both streams at the same time, what buffer sequence number should be reported in that case ? I think that if the video data comes from the same source, the sequence numbers should definitely be in sync. This would mean that for the second stream the first sequence number wouldn't be zero. Then we should document this somewhere. Here is probably not the best place to document that, but the buffer_sequence documentation should still refer to the explanation. I also find the wording a bit unclear. The buffer to be handled next could mean the buffer that will be given to an application at the next DQBUF call. Maybe we should refer to frame sequence numbers instead of buffer sequence numbers. What's the difference? I would consider the two the same. If we have multiple simultaneous streams from the same source, I think it would make sense to start thinking about frame sequence numbers instead of buffer sequence numbers. The buffer sequence number would then just store the frame sequence number of the frame stored in the buffer. This would (in my opinion) simplify the spec's understanding. Another good point from you, I agree with this. ...buffer to be written next to by the hardware? What about ...buffer that will store the image ? But which image? And if there is no buffer, no image is written to it either. frame to be processed or being processed by the hardware? frame being received ? This is a *frame* sync event, it should contain the sequence number of the frame that triggered it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Dear Uwe,
which repository should I search 90026c8c823bff54172eab33a5e7fcecfd3df635
in? I have not found it in git.pengutronix.de/git/imx/linux-2.6.git nor in
vanilla sources.
regards Jan
Dne Fri, 29 Jul 2011 11:23:12 +0200 Uwe Kleine-König
u.kleine-koe...@pengutronix.de napsal(a):
Hi Jan,
On Fri, Jul 29, 2011 at 10:59:55AM +0200, Jan Pohanka wrote:
thank you for answer. You are right I give no memory to camera
device in mach-imx27ipcam.c. I have tried to do it in same way as it
is in mach-pcm037.c but no success. Here is my init function
static int __init mx27ipcam_camera_init(void) {
int dma, ret = -ENOMEM;
struct platform_device *pdev;
printk(MX2 camera initialization.\n);
pdev = imx27_add_mx2_camera(mx27ipcam_camera);
if (IS_ERR(pdev)) {
printk(pdev error\n);
return PTR_ERR(pdev);
}
dma = dma_declare_coherent_memory(pdev-dev,
mx2_camera_base, mx2_camera_base,
MX2_CAMERA_BUF_SIZE,
DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
if (!(dma DMA_MEMORY_MAP))
goto err;
ret = platform_device_add(pdev);
if (ret) {
printk(platform_device_add error\n);
err:
platform_device_put(pdev);
}
return ret;
}
and you also have a reserve callback? See commit
90026c8c823bff54172eab33a5e7fcecfd3df635 for all details.
Best regards
Uwe
--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:
http://www.opera.com/mail/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
On Friday 29 July 2011 11:10:48 javier Martin wrote:
Hi Laurent,
I've been reviewing and testing your patch as promised.
On 27 July 2011 19:51, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+static int mt9p031_pll_enable(struct mt9p031 *mt9p031)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(mt9p031-subdev);
+ int ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON);
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_1,
+ (mt9p031-m 8) | (mt9p031-n - 1));
+ if (ret 0)
+ return ret;
+
+ ret = mt9p031_write(client, MT9P031_PLL_CONFIG_2, mt9p031-p1 -
1); + if (ret 0)
+ return ret;
+
+ mdelay(1);
mdelay() is a busyloop. Either msleep(), if the timing isn't critical,
and if it is, then usleep_range().
Timing isn't critical, but that's a stream-on delay, so I'll use
usleep_range().
+ ret = mt9p031_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON |
+ MT9P031_PLL_CONTROL_USEPLL);
+ mdelay(1);
Javier, is this second mdelay() needed ?
No, sorry, I included it because I was having problems with PLLs and
wanted to be very cautious. You can safely remove it. It is not
specified in the datasheet and I've just tested it myself.
OK, I'll remove it and resubmit.
Apart from the minor issues mentioned by Sakari, I think dynamic
calculation of PLL dividers should be postponed for a next version
thus not delaying this one to enter mainline.
I agree (unless I find time to work on this before v3.2 :-)).
However I'm having problems for testing your version with linux-3.0
and my old test yavta + mplayer:
On my PC:
nc -l 3000 | ./mplayer - -demuxer rawvideo -rawvideo
w=320:h=240:format=ba81:size=76800 -vf ba81 -vo x11
On my Beagleboard:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
Setting up link 16:0 - 5:0 [1]
Setting up link 5:1 - 6:0 [1]
./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], OMAP3 ISP
CCDC:0[SGRBG8 320x240], OMAP3 ISP CCDC:1[SGRBG8 320x240]'
Setting up format SGRBG12 320x240 on pad mt9p031 2-0048/0
Format set: SGRBG12 370x243
You're trying to configure the sensor for 320x240. The sensor native size is
2592x1944. Maximum horizontal and vertical skipping values are 7 and 8
respectively according to the datasheet. The smallest achieavable resolution
(without cropping) is thus 370x243. That's why the driver returns 370x243.
Setting up format SGRBG12 370x243 on pad OMAP3 ISP CCDC/0
Format set: SGRBG12 370x243
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/0
Format set: SGRBG8 320x240
Setting up format SGRBG8 320x240 on pad OMAP3 ISP CCDC/1
Format set: SGRBG8 320x240
You then need to set the same format on the CCDC input and output. The CCDC
will restrict this further to 368x243, which is the format you will need to
give to yavta.
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40082000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x400a8000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4016a000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x402be000.
Unable to start streaming: 32.
What are you using for testing?
media-ctl and yavta.
By the way, this is my last day in the office till August the 14th.
Furthermore, I've got no intention to be the maintainer of the driver,
since probably the main contributor to the patch was Guennadi.
However, as we'll be using this driver for a project that will last
for a year, count on me for testing, reviewing patches, etc... Because
out interest on this patch going into mainline is high.
OK. I'll try to maintain the driver then, and I'll contact you if I need
testers/reviewers :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] v4l: events: Define frame start event
On Fri, Jul 29, 2011 at 11:57:17AM +0200, Laurent Pinchart wrote: On Friday 29 July 2011 11:54:03 Sakari Ailus wrote: On Fri, Jul 29, 2011 at 11:38:16AM +0200, Laurent Pinchart wrote: On Friday 29 July 2011 09:44:46 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 10:36:57PM +0200, Laurent Pinchart wrote: On Thursday 28 July 2011 22:28:57 Sakari Ailus wrote: On Thu, Jul 28, 2011 at 01:52:21PM +0200, Laurent Pinchart wrote: On Tuesday 26 July 2011 20:49:43 Sakari Ailus wrote: [snip] +table frame=none pgwide=1 id=v4l2-event-frame-sync + titlestruct structnamev4l2_event_frame_sync/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldbuffer_sequence/structfield/entry + entry + The sequence number of the buffer to be handled next or + currently handled by the driver. What happens if a particular piece of hardware can capture two (or more) simultaneous streams from the same video source (an unscaled compressed stream and a scaled down uncompressed stream for instance) ? Applications don't need to start both streams at the same time, what buffer sequence number should be reported in that case ? I think that if the video data comes from the same source, the sequence numbers should definitely be in sync. This would mean that for the second stream the first sequence number wouldn't be zero. Then we should document this somewhere. Here is probably not the best place to document that, but the buffer_sequence documentation should still refer to the explanation. I also find the wording a bit unclear. The buffer to be handled next could mean the buffer that will be given to an application at the next DQBUF call. Maybe we should refer to frame sequence numbers instead of buffer sequence numbers. What's the difference? I would consider the two the same. If we have multiple simultaneous streams from the same source, I think it would make sense to start thinking about frame sequence numbers instead of buffer sequence numbers. The buffer sequence number would then just store the frame sequence number of the frame stored in the buffer. This would (in my opinion) simplify the spec's understanding. Another good point from you, I agree with this. ...buffer to be written next to by the hardware? What about ...buffer that will store the image ? But which image? And if there is no buffer, no image is written to it either. frame to be processed or being processed by the hardware? frame being received ? This is a *frame* sync event, it should contain the sequence number of the frame that triggered it. I'm fine with frame being received. -- Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/59] V4L: sh_mobile_ceu_camera: remove duplicated code
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_ceu_camera.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index a322f83..aa187a4 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -1018,9 +1018,6 @@ static int sh_mobile_ceu_get_formats(struct
soc_camera_device *icd, unsigned int
cam-width = mf.width;
cam-height = mf.height;
- cam-width = mf.width;
- cam-height = mf.height;
-
icd-host_priv = cam;
} else {
cam = icd-host_priv;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/59] V4L: sh_mobile_ceu_camera: output image sizes must be a multiple of 4
CEU can only produce images with 4 pixel aligned width and height.
Enforce this alignment, adjust comments and simplify some calculations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_ceu_camera.c | 49 +--
1 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index e540898..2e5a01d 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -121,7 +121,7 @@ struct sh_mobile_ceu_dev {
};
struct sh_mobile_ceu_cam {
- /* CEU offsets within scaled by the CEU camera output */
+ /* CEU offsets within the camera output, before the CEU scaler */
unsigned int ceu_left;
unsigned int ceu_top;
/* Client output, as seen by the CEU */
@@ -628,22 +628,22 @@ static void sh_mobile_ceu_set_rect(struct
soc_camera_device *icd)
left_offset = cam-ceu_left;
top_offset = cam-ceu_top;
- /* CEU cropping (CFSZR) is applied _after_ the scaling filter (CFLCR) */
+ WARN_ON(icd-user_width 3 || icd-user_height 3);
+
+ width = icd-user_width;
+
if (pcdev-image_mode) {
in_width = cam-width;
if (!pcdev-is_16bit) {
in_width *= 2;
left_offset *= 2;
}
- width = icd-user_width;
- cdwdr_width = icd-user_width;
+ cdwdr_width = width;
} else {
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
+ int bytes_per_line = soc_mbus_bytes_per_line(width,
icd-current_fmt-host_fmt);
unsigned int w_factor;
- width = icd-user_width;
-
switch (icd-current_fmt-host_fmt-packing) {
case SOC_MBUS_PACKING_2X8_PADHI:
w_factor = 2;
@@ -653,10 +653,10 @@ static void sh_mobile_ceu_set_rect(struct
soc_camera_device *icd)
}
in_width = cam-width * w_factor;
- left_offset = left_offset * w_factor;
+ left_offset *= w_factor;
if (bytes_per_line 0)
- cdwdr_width = icd-user_width;
+ cdwdr_width = width;
else
cdwdr_width = bytes_per_line;
}
@@ -664,7 +664,7 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device
*icd)
height = icd-user_height;
in_height = cam-height;
if (V4L2_FIELD_NONE != pcdev-field) {
- height /= 2;
+ height = (height / 2) ~3;
in_height /= 2;
top_offset /= 2;
cdwdr_width *= 2;
@@ -686,6 +686,7 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device
*icd)
ceu_write(pcdev, CAMOR, camor);
ceu_write(pcdev, CAPWR, (in_height 16) | in_width);
+ /* CFSZR clipping is applied _after_ the scaling filter (CFLCR) */
ceu_write(pcdev, CFSZR, (height 16) | width);
ceu_write(pcdev, CDWDR, cdwdr_width);
}
@@ -1414,7 +1415,10 @@ static int sh_mobile_ceu_set_crop(struct
soc_camera_device *icd,
capsr = capture_save_reset(pcdev);
dev_dbg(dev, CAPSR 0x%x, CFLCR 0x%x\n, capsr, pcdev-cflcr);
- /* 1. - 2. Apply iterative camera S_CROP for new input window. */
+ /*
+* 1. - 2. Apply iterative camera S_CROP for new input window, read back
+* actual camera rectangle.
+*/
ret = client_s_crop(icd, a, cam_crop);
if (ret 0)
return ret;
@@ -1498,8 +1502,9 @@ static int sh_mobile_ceu_set_crop(struct
soc_camera_device *icd,
ceu_write(pcdev, CFLCR, cflcr);
}
- icd-user_width = out_width;
- icd-user_height = out_height;
+ icd-user_width = out_width ~3;
+ icd-user_height = out_height ~3;
+ /* Offsets are applied at the CEU scaling filter input */
cam-ceu_left= scale_down(rect-left - cam_rect-left, scale_cam_h)
~1;
cam-ceu_top = scale_down(rect-top - cam_rect-top, scale_cam_v)
~1;
@@ -1538,7 +1543,7 @@ static int sh_mobile_ceu_get_crop(struct
soc_camera_device *icd,
* CEU crop, mapped backed onto the client input (subrect).
*/
static void calculate_client_output(struct soc_camera_device *icd,
- struct v4l2_pix_format *pix, struct v4l2_mbus_framefmt *mf)
+ const struct v4l2_pix_format *pix, struct v4l2_mbus_framefmt
*mf)
{
struct sh_mobile_ceu_cam *cam = icd-host_priv;
struct device *dev = icd-parent;
@@ -1623,7 +1628,7 @@ static int sh_mobile_ceu_set_fmt(struct soc_camera_device
*icd,
}
/* 1.-4. Calculate client output geometry */
- calculate_client_output(icd, f-fmt.pix, mf);
+
[PATCH 02/59] V4L: sh_mobile_ceu_camera: don't try to improve client scaling, if perfect
If the client has managed to configure the precise output format,
we don't have to try to further improve it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_ceu_camera.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 2e5a01d..407b96a 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -1279,6 +1279,7 @@ static int client_s_fmt(struct soc_camera_device *icd,
unsigned int width = mf-width, height = mf-height, tmp_w, tmp_h;
unsigned int max_width, max_height;
struct v4l2_cropcap cap;
+ bool ceu_1to1;
int ret;
ret = v4l2_device_call_until_err(sd-v4l2_dev, (long)icd, video,
@@ -1288,7 +1289,14 @@ static int client_s_fmt(struct soc_camera_device *icd,
dev_geo(dev, camera scaled to %ux%u\n, mf-width, mf-height);
- if ((width == mf-width height == mf-height) || !ceu_can_scale)
+ if (width == mf-width height == mf-height) {
+ /* Perfect! The client has done it all. */
+ ceu_1to1 = true;
+ goto update_cache;
+ }
+
+ ceu_1to1 = false;
+ if (!ceu_can_scale)
goto update_cache;
cap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
@@ -1328,7 +1336,10 @@ update_cache:
if (ret 0)
return ret;
- update_subrect(cam);
+ if (ceu_1to1)
+ cam-subrect = cam-rect;
+ else
+ update_subrect(cam);
return 0;
}
@@ -1579,8 +1590,8 @@ static void calculate_client_output(struct
soc_camera_device *icd,
dev_geo(dev, 3: scales %u:%u\n, scale_h, scale_v);
/*
-* 4. Calculate client output window by applying combined scales to real
-*input window.
+* 4. Calculate desired client output window by applying combined scales
+*to client (real) input window.
*/
mf-width = scale_down(cam-rect.width, scale_h);
mf-height = scale_down(cam-rect.height, scale_v);
@@ -1627,7 +1638,7 @@ static int sh_mobile_ceu_set_fmt(struct soc_camera_device
*icd,
return -EINVAL;
}
- /* 1.-4. Calculate client output geometry */
+ /* 1.-4. Calculate desired client output geometry */
calculate_client_output(icd, pix, mf);
mf.field= pix-field;
mf.colorspace = pix-colorspace;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 40/59] V4L: mt9m001: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m001.c | 41 -
1 files changed, 0 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 750ce60..3555e85 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -166,45 +166,6 @@ static int mt9m001_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-static int mt9m001_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long width_flag = flags SOCAM_DATAWIDTH_MASK;
-
- /* Only one width bit may be set */
- if (!is_power_of_2(width_flag))
- return -EINVAL;
-
- if (icl-set_bus_param)
- return icl-set_bus_param(icl, width_flag);
-
- /*
-* Without board specific bus width settings we only support the
-* sensors native bus width
-*/
- if (width_flag == SOCAM_DATAWIDTH_10)
- return 0;
-
- return -EINVAL;
-}
-
-static unsigned long mt9m001_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- /* MT9M001 has all capture_format parameters fixed */
- unsigned long flags = SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_MASTER;
-
- if (icl-query_bus_param)
- flags |= icl-query_bus_param(icl) SOCAM_DATAWIDTH_MASK;
- else
- flags |= SOCAM_DATAWIDTH_10;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int mt9m001_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -461,8 +422,6 @@ static const struct v4l2_queryctrl mt9m001_controls[] = {
};
static struct soc_camera_ops mt9m001_ops = {
- .set_bus_param = mt9m001_set_bus_param,
- .query_bus_param= mt9m001_query_bus_param,
.controls = mt9m001_controls,
.num_controls = ARRAY_SIZE(mt9m001_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 42/59] V4L: imx074: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/imx074.c | 24 +---
1 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 63f17aa..20756e0 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -298,26 +298,6 @@ static struct v4l2_subdev_ops imx074_subdev_ops = {
.video = imx074_subdev_video_ops,
};
-/*
- * We have to provide soc-camera operations, but we don't have anything to say
- * there. The MIPI CSI2 driver will provide .query_bus_param and .set_bus_param
- */
-static unsigned long imx074_query_bus_param(struct soc_camera_device *icd)
-{
- return 0;
-}
-
-static int imx074_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- return -EINVAL;
-}
-
-static struct soc_camera_ops imx074_ops = {
- .query_bus_param= imx074_query_bus_param,
- .set_bus_param = imx074_set_bus_param,
-};
-
static int imx074_video_probe(struct soc_camera_device *icd,
struct i2c_client *client)
{
@@ -457,12 +437,11 @@ static int imx074_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(priv-subdev, client, imx074_subdev_ops);
- icd-ops= imx074_ops;
+ icd-ops= NULL;
priv-fmt = imx074_colour_fmts[0];
ret = imx074_video_probe(icd, client);
if (ret 0) {
- icd-ops = NULL;
kfree(priv);
return ret;
}
@@ -476,7 +455,6 @@ static int imx074_remove(struct i2c_client *client)
struct soc_camera_device *icd = client-dev.platform_data;
struct soc_camera_link *icl = to_soc_camera_link(icd);
- icd-ops = NULL;
if (icl-free_bus)
icl-free_bus(icl);
kfree(priv);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 37/59] V4L: pxa_camera: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/pxa_camera.c | 140 ++
1 files changed, 80 insertions(+), 60 deletions(-)
diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index d07df22..79fb22c 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -214,6 +214,7 @@ struct pxa_camera_dev {
unsigned long ciclk;
unsigned long mclk;
u32 mclk_divisor;
+ u16 width_flags;/* max 10 bits */
struct list_headcapture;
@@ -1020,37 +1021,20 @@ static int test_platform_param(struct pxa_camera_dev
*pcdev,
* quick capture interface supports both.
*/
*flags = (pcdev-platform_flags PXA_CAMERA_MASTER ?
- SOCAM_MASTER : SOCAM_SLAVE) |
- SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_DATA_ACTIVE_HIGH |
- SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_PCLK_SAMPLE_FALLING;
+ V4L2_MBUS_MASTER : V4L2_MBUS_SLAVE) |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_LOW |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTIVE_LOW |
+ V4L2_MBUS_DATA_ACTIVE_HIGH |
+ V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_PCLK_SAMPLE_FALLING;
/* If requested data width is supported by the platform, use it */
- switch (buswidth) {
- case 10:
- if (!(pcdev-platform_flags PXA_CAMERA_DATAWIDTH_10))
- return -EINVAL;
- *flags |= SOCAM_DATAWIDTH_10;
- break;
- case 9:
- if (!(pcdev-platform_flags PXA_CAMERA_DATAWIDTH_9))
- return -EINVAL;
- *flags |= SOCAM_DATAWIDTH_9;
- break;
- case 8:
- if (!(pcdev-platform_flags PXA_CAMERA_DATAWIDTH_8))
- return -EINVAL;
- *flags |= SOCAM_DATAWIDTH_8;
- break;
- default:
- return -EINVAL;
- }
+ if ((1 (buswidth - 1)) pcdev-width_flags)
+ return 0;
- return 0;
+ return -EINVAL;
}
static void pxa_camera_setup_cicr(struct soc_camera_device *icd,
@@ -1070,12 +1054,12 @@ static void pxa_camera_setup_cicr(struct
soc_camera_device *icd,
* Datawidth is now guaranteed to be equal to one of the three values.
* We fix bit-per-pixel equal to data-width...
*/
- switch (flags SOCAM_DATAWIDTH_MASK) {
- case SOCAM_DATAWIDTH_10:
+ switch (icd-current_fmt-host_fmt-bits_per_sample) {
+ case 10:
dw = 4;
bpp = 0x40;
break;
- case SOCAM_DATAWIDTH_9:
+ case 9:
dw = 3;
bpp = 0x20;
break;
@@ -1084,7 +1068,7 @@ static void pxa_camera_setup_cicr(struct
soc_camera_device *icd,
* Actually it can only be 8 now,
* default is just to silence compiler warnings
*/
- case SOCAM_DATAWIDTH_8:
+ case 8:
dw = 2;
bpp = 0;
}
@@ -1093,11 +1077,11 @@ static void pxa_camera_setup_cicr(struct
soc_camera_device *icd,
cicr4 |= CICR4_PCLK_EN;
if (pcdev-platform_flags PXA_CAMERA_MCLK_EN)
cicr4 |= CICR4_MCLK_EN;
- if (flags SOCAM_PCLK_SAMPLE_FALLING)
+ if (flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
cicr4 |= CICR4_PCP;
- if (flags SOCAM_HSYNC_ACTIVE_LOW)
+ if (flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
cicr4 |= CICR4_HSP;
- if (flags SOCAM_VSYNC_ACTIVE_LOW)
+ if (flags V4L2_MBUS_VSYNC_ACTIVE_LOW)
cicr4 |= CICR4_VSP;
cicr0 = __raw_readl(pcdev-base + CICR0);
@@ -1151,9 +1135,11 @@ static void pxa_camera_setup_cicr(struct
soc_camera_device *icd,
static int pxa_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct pxa_camera_dev *pcdev = ici-priv;
- unsigned long bus_flags, camera_flags, common_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long bus_flags, common_flags;
int ret;
struct pxa_cam *cam = icd-host_priv;
@@ -1162,44 +1148,58 @@ static int pxa_camera_set_bus_param(struct
soc_camera_device *icd, __u32 pixfmt)
if (ret 0)
return ret;
- camera_flags =
[PATCH 35/59] V4L: mt9m001, mt9v022: add a clarifying comment
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/media/video/mt9m001.c |6 ++ drivers/media/video/mt9v022.c |6 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index 7618b3c..750ce60 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c @@ -734,6 +734,12 @@ static int mt9m001_s_mbus_config(struct v4l2_subdev *sd, struct i2c_client *client = v4l2_get_subdevdata(sd); struct soc_camera_device *icd = client-dev.platform_data; struct soc_camera_link *icl = to_soc_camera_link(icd); + /* +* Cannot use icd-current_fmt-host_fmt-bits_per_sample, because that +* is the number of bits, that the host has to sample, not the number of +* bits, that we have to send. See mx3_camera.c for an example of 10-bit +* formats being truncated to 8 bits by the host. +*/ unsigned int bps = soc_mbus_get_fmtdesc(icd-current_fmt-code)-bits_per_sample; if (icl-set_bus_param) diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index 2fc6ca2..ddc11d0 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -875,6 +875,12 @@ static int mt9v022_s_mbus_config(struct v4l2_subdev *sd, struct soc_camera_link *icl = to_soc_camera_link(icd); struct mt9v022 *mt9v022 = to_mt9v022(client); unsigned long flags = soc_camera_apply_board_flags(icl, cfg); + /* +* Cannot use icd-current_fmt-host_fmt-bits_per_sample, because that +* is the number of bits, that the host has to sample, not the number of +* bits, that we have to send. See mx3_camera.c for an example of 10-bit +* formats being truncated to 8 bits by the host. +*/ unsigned int bps = soc_mbus_get_fmtdesc(icd-current_fmt-code)-bits_per_sample; int ret; u16 pixclk = 0; -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 41/59] V4L: mt9m111: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m111.c | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index c2fe5c9..d7a0773 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -363,21 +363,6 @@ static int mt9m111_reset(struct mt9m111 *mt9m111)
return ret;
}
-static unsigned long mt9m111_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long flags = SOCAM_MASTER | SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
-static int mt9m111_set_bus_param(struct soc_camera_device *icd, unsigned long
f)
-{
- return 0;
-}
-
static int mt9m111_make_rect(struct mt9m111 *mt9m111,
struct v4l2_rect *rect)
{
@@ -698,8 +683,6 @@ static const struct v4l2_queryctrl mt9m111_controls[] = {
};
static struct soc_camera_ops mt9m111_ops = {
- .query_bus_param= mt9m111_query_bus_param,
- .set_bus_param = mt9m111_set_bus_param,
.controls = mt9m111_controls,
.num_controls = ARRAY_SIZE(mt9m111_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/59] V4L: sh_mobile_csi2: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_csi2.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/sh_mobile_csi2.c
b/drivers/media/video/sh_mobile_csi2.c
index 09ef63d..6b40441 100644
--- a/drivers/media/video/sh_mobile_csi2.c
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -36,6 +36,7 @@ struct sh_csi2 {
struct v4l2_subdev subdev;
struct list_headlist;
unsigned intirq;
+ unsigned long mipi_flags;
void __iomem*base;
struct platform_device *pdev;
struct sh_csi2_client_config*client;
@@ -128,9 +129,34 @@ static int sh_csi2_s_fmt(struct v4l2_subdev *sd,
return 0;
}
+static int sh_csi2_g_mbus_config(struct v4l2_subdev *sd,
+struct v4l2_mbus_config *cfg)
+{
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_MASTER | V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+
+ return 0;
+}
+
+static int sh_csi2_s_mbus_config(struct v4l2_subdev *sd,
+const struct v4l2_mbus_config *cfg)
+{
+ struct sh_csi2 *priv = container_of(sd, struct sh_csi2, subdev);
+ struct soc_camera_device *icd = (struct soc_camera_device *)sd-grp_id;
+ struct v4l2_subdev *client_sd = soc_camera_to_subdev(icd);
+ struct v4l2_mbus_config client_cfg = {.type = V4L2_MBUS_CSI2,
+ .flags = priv-mipi_flags};
+
+ return v4l2_subdev_call(client_sd, video, s_mbus_config, client_cfg);
+}
+
static struct v4l2_subdev_video_ops sh_csi2_subdev_video_ops = {
.s_mbus_fmt = sh_csi2_s_fmt,
.try_mbus_fmt = sh_csi2_try_fmt,
+ .g_mbus_config = sh_csi2_g_mbus_config,
+ .s_mbus_config = sh_csi2_s_mbus_config,
};
static void sh_csi2_hwinit(struct sh_csi2 *priv)
@@ -251,6 +277,7 @@ static int sh_csi2_client_connect(struct sh_csi2 *priv)
return -EINVAL;
/* All good: camera MIPI configuration supported */
+ priv-mipi_flags = common_flags;
priv-client = pdata-clients + i;
priv-set_bus_param = icd-ops-set_bus_param;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/59] ARM: mach-shmobile: convert mackerel to mediabus flags
Prepare the board to switch to the new subdevice media-bus configuration
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/arm/mach-shmobile/board-mackerel.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 1610fbf..409606b 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1214,6 +1214,10 @@ static struct soc_camera_platform_info camera_info = {
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
+ .mbus_param = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH,
+ .mbus_type = V4L2_MBUS_PARALLEL,
.set_capture = camera_set_capture,
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/59] V4L: ov9740: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov9740.c | 33 ++---
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index edd1ffc..67b7020 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -14,8 +14,10 @@
#include linux/module.h
#include linux/i2c.h
#include linux/slab.h
-#include media/v4l2-chip-ident.h
+
#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
#define to_ov9740(sd) container_of(sd, struct ov9740_priv, subdev)
@@ -949,13 +951,30 @@ static struct soc_camera_ops ov9740_ops = {
.num_controls = ARRAY_SIZE(ov9740_controls),
};
+static int ov9740_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops ov9740_video_ops = {
- .s_stream = ov9740_s_stream,
- .s_mbus_fmt = ov9740_s_fmt,
- .try_mbus_fmt = ov9740_try_fmt,
- .enum_mbus_fmt = ov9740_enum_fmt,
- .cropcap= ov9740_cropcap,
- .g_crop = ov9740_g_crop,
+ .s_stream = ov9740_s_stream,
+ .s_mbus_fmt = ov9740_s_fmt,
+ .try_mbus_fmt = ov9740_try_fmt,
+ .enum_mbus_fmt = ov9740_enum_fmt,
+ .cropcap= ov9740_cropcap,
+ .g_crop = ov9740_g_crop,
+ .g_mbus_config = ov9740_g_mbus_config,
};
static struct v4l2_subdev_core_ops ov9740_core_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 31/59] V4L: mx1_camera: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mx1_camera.c | 71 ++---
1 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 087db12..18e94c7 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -78,11 +78,10 @@
#define CSI_IRQ_MASK (CSISR_SFF_OR_INT | CSISR_RFF_OR_INT | \
CSISR_STATFF_INT | CSISR_RXFF_INT | CSISR_SOF_INT)
-#define CSI_BUS_FLAGS (SOCAM_MASTER | SOCAM_HSYNC_ACTIVE_HIGH | \
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_LOW | \
- SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING | \
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_LOW | \
- SOCAM_DATAWIDTH_8)
+#define CSI_BUS_FLAGS (V4L2_MBUS_MASTER | V4L2_MBUS_HSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH |
V4L2_MBUS_VSYNC_ACTIVE_LOW | \
+ V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_PCLK_SAMPLE_FALLING | \
+ V4L2_MBUS_DATA_ACTIVE_HIGH | V4L2_MBUS_DATA_ACTIVE_LOW)
#define MAX_VIDEO_MEM 16 /* Video memory limit in megabytes */
@@ -490,59 +489,73 @@ static int mx1_camera_set_crop(struct soc_camera_device
*icd,
static int mx1_camera_set_bus_param(struct soc_camera_device *icd, __u32
pixfmt)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx1_camera_dev *pcdev = ici-priv;
- unsigned long camera_flags, common_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long common_flags;
unsigned int csicr1;
int ret;
- camera_flags = icd-ops-query_bus_param(icd);
-
/* MX1 supports only 8bit buswidth */
- common_flags = soc_camera_bus_param_compatible(camera_flags,
- CSI_BUS_FLAGS);
- if (!common_flags)
- return -EINVAL;
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (!ret) {
+ common_flags = soc_mbus_config_compatible(cfg, CSI_BUS_FLAGS);
+ if (!common_flags) {
+ dev_warn(icd-parent,
+Flags incompatible: camera 0x%x, host 0x%x\n,
+cfg.flags, CSI_BUS_FLAGS);
+ return -EINVAL;
+ }
+ } else if (ret != -ENOIOCTLCMD) {
+ return ret;
+ } else {
+ common_flags = CSI_BUS_FLAGS;
+ }
/* Make choises, based on platform choice */
- if ((common_flags SOCAM_VSYNC_ACTIVE_HIGH)
- (common_flags SOCAM_VSYNC_ACTIVE_LOW)) {
+ if ((common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ (common_flags V4L2_MBUS_VSYNC_ACTIVE_LOW)) {
if (!pcdev-pdata ||
pcdev-pdata-flags MX1_CAMERA_VSYNC_HIGH)
- common_flags = ~SOCAM_VSYNC_ACTIVE_LOW;
+ common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_LOW;
else
- common_flags = ~SOCAM_VSYNC_ACTIVE_HIGH;
+ common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_HIGH;
}
- if ((common_flags SOCAM_PCLK_SAMPLE_RISING)
- (common_flags SOCAM_PCLK_SAMPLE_FALLING)) {
+ if ((common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ (common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)) {
if (!pcdev-pdata ||
pcdev-pdata-flags MX1_CAMERA_PCLK_RISING)
- common_flags = ~SOCAM_PCLK_SAMPLE_FALLING;
+ common_flags = ~V4L2_MBUS_PCLK_SAMPLE_FALLING;
else
- common_flags = ~SOCAM_PCLK_SAMPLE_RISING;
+ common_flags = ~V4L2_MBUS_PCLK_SAMPLE_RISING;
}
- if ((common_flags SOCAM_DATA_ACTIVE_HIGH)
- (common_flags SOCAM_DATA_ACTIVE_LOW)) {
+ if ((common_flags V4L2_MBUS_DATA_ACTIVE_HIGH)
+ (common_flags V4L2_MBUS_DATA_ACTIVE_LOW)) {
if (!pcdev-pdata ||
pcdev-pdata-flags MX1_CAMERA_DATA_HIGH)
- common_flags = ~SOCAM_DATA_ACTIVE_LOW;
+ common_flags = ~V4L2_MBUS_DATA_ACTIVE_LOW;
else
- common_flags = ~SOCAM_DATA_ACTIVE_HIGH;
+ common_flags = ~V4L2_MBUS_DATA_ACTIVE_HIGH;
}
- ret = icd-ops-set_bus_param(icd,
[PATCH 28/59] sh: convert ap325rxa to mediabus flags
Prepare the board to switch to the new subdevice media-bus configuration
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/sh/boards/mach-ap325rxa/setup.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index e57b1df..547928f 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -348,6 +348,10 @@ static struct soc_camera_platform_info camera_info = {
.bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
SOCAM_DATA_ACTIVE_HIGH,
+ .mbus_param = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH,
+ .mbus_type = V4L2_MBUS_PARALLEL,
.set_capture = camera_set_capture,
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 50/59] sh: migor: remove unused ov772x buswidth flag
The ov772x driver only supports 8 bits per sample pixel codes, hence
the OV772X_FLAG_8BIT flag has no effect. Remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/sh/boards/mach-migor/setup.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setup.c
index 184fde1..97899a7 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -448,9 +448,7 @@ static struct i2c_board_info migor_i2c_camera[] = {
},
};
-static struct ov772x_camera_info ov7725_info = {
- .flags = OV772X_FLAG_8BIT,
-};
+static struct ov772x_camera_info ov7725_info;
static struct soc_camera_link ov7725_link = {
.power = ov7725_power,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 49/59] sh: ap3rxa: remove redundant soc-camera platform data fields
The sh_mobile_ceu_camera driver has been converted to use the V4L2
subdevice .[gs]_mbus_config() operations, therefore we don't need
SOCAM_* flags for the soc_camera_platform driver anymore. The ov772x
driver only supports 8 bits per sample pixel codes, hence the
OV772X_FLAG_8BIT flag has no effect. Remove both of them.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/sh/boards/mach-ap325rxa/setup.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index 547928f..f8242f6 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -345,9 +345,6 @@ static struct soc_camera_platform_info camera_info = {
.width = 640,
.height = 480,
},
- .bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
- SOCAM_DATA_ACTIVE_HIGH,
.mbus_param = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_HIGH,
@@ -505,8 +502,7 @@ static struct i2c_board_info ap325rxa_i2c_camera[] = {
};
static struct ov772x_camera_info ov7725_info = {
- .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP | \
- OV772X_FLAG_8BIT,
+ .flags = OV772X_FLAG_VFLIP | OV772X_FLAG_HFLIP,
.edgectrl = OV772X_AUTO_EDGECTRL(0xf, 0),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/59] ARM: ap4evb: switch imx074 configuration to default number of lanes
The sh_mobile_csi2 driver will change meaning of the .lanes platform
data field from bitmask of used lanes to number of used lanes.
To avoid a regression during this transition switch ap4evb to rely
on the 2 lane default.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/arm/mach-shmobile/board-ap4evb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 67b3d0b..47151dc 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -931,7 +931,7 @@ static struct platform_device ap4evb_camera = {
static struct sh_csi2_client_config csi2_clients[] = {
{
.phy= SH_CSI2_PHY_MAIN,
- .lanes = 3,
+ .lanes = 0,/* default: 2 lanes */
.channel= 0,
.pdev = ap4evb_camera,
},
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 55/59] V4L: sh_mobile_csi2: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_csi2.c | 31 ---
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/sh_mobile_csi2.c
b/drivers/media/video/sh_mobile_csi2.c
index 6b40441..6f9f2b7 100644
--- a/drivers/media/video/sh_mobile_csi2.c
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -40,8 +40,6 @@ struct sh_csi2 {
void __iomem*base;
struct platform_device *pdev;
struct sh_csi2_client_config*client;
- unsigned long (*query_bus_param)(struct soc_camera_device *);
- int (*set_bus_param)(struct soc_camera_device *, unsigned long);
};
static int sh_csi2_try_fmt(struct v4l2_subdev *sd,
@@ -200,22 +198,6 @@ static void sh_csi2_hwinit(struct sh_csi2 *priv)
iowrite32(tmp, priv-base + SH_CSI2_CHKSUM);
}
-static int sh_csi2_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- return 0;
-}
-
-static unsigned long sh_csi2_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- const unsigned long flags = SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_MASTER | SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int sh_csi2_client_connect(struct sh_csi2 *priv)
{
struct sh_csi2_pdata *pdata = priv-pdev-dev.platform_data;
@@ -280,11 +262,6 @@ static int sh_csi2_client_connect(struct sh_csi2 *priv)
priv-mipi_flags = common_flags;
priv-client = pdata-clients + i;
- priv-set_bus_param = icd-ops-set_bus_param;
- priv-query_bus_param = icd-ops-query_bus_param;
- icd-ops-set_bus_param = sh_csi2_set_bus_param;
- icd-ops-query_bus_param = sh_csi2_query_bus_param;
-
csi2_sd-grp_id = (long)icd;
pm_runtime_get_sync(dev);
@@ -296,17 +273,9 @@ static int sh_csi2_client_connect(struct sh_csi2 *priv)
static void sh_csi2_client_disconnect(struct sh_csi2 *priv)
{
- struct soc_camera_device *icd = (struct soc_camera_device
*)priv-subdev.grp_id;
-
priv-client = NULL;
priv-subdev.grp_id = 0;
- /* Driver is about to be unbound */
- icd-ops-set_bus_param = priv-set_bus_param;
- icd-ops-query_bus_param = priv-query_bus_param;
- priv-set_bus_param = NULL;
- priv-query_bus_param = NULL;
-
pm_runtime_put(v4l2_get_subdevdata(priv-subdev));
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 57/59] V4L: soc_camera_platform: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera_platform.c | 31 +
include/media/soc_camera_platform.h |1 -
2 files changed, 1 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/soc_camera_platform.c
b/drivers/media/video/soc_camera_platform.c
index 7045e45..f5ebe59 100644
--- a/drivers/media/video/soc_camera_platform.c
+++ b/drivers/media/video/soc_camera_platform.c
@@ -30,32 +30,12 @@ static struct soc_camera_platform_priv *get_priv(struct
platform_device *pdev)
return container_of(subdev, struct soc_camera_platform_priv, subdev);
}
-static struct soc_camera_platform_info *get_info(struct soc_camera_device *icd)
-{
- struct platform_device *pdev =
- to_platform_device(to_soc_camera_control(icd));
- return pdev-dev.platform_data;
-}
-
static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
{
struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
return p-set_capture(p, enable);
}
-static int soc_camera_platform_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- return 0;
-}
-
-static unsigned long
-soc_camera_platform_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_platform_info *p = get_info(icd);
- return p-bus_param;
-}
-
static int soc_camera_platform_fill_fmt(struct v4l2_subdev *sd,
struct v4l2_mbus_framefmt *mf)
{
@@ -142,11 +122,6 @@ static struct v4l2_subdev_ops platform_subdev_ops = {
.video = platform_subdev_video_ops,
};
-static struct soc_camera_ops soc_camera_platform_ops = {
- .set_bus_param = soc_camera_platform_set_bus_param,
- .query_bus_param= soc_camera_platform_query_bus_param,
-};
-
static int soc_camera_platform_probe(struct platform_device *pdev)
{
struct soc_camera_host *ici;
@@ -175,7 +150,7 @@ static int soc_camera_platform_probe(struct platform_device
*pdev)
/* Set the control device reference */
icd-control = pdev-dev;
- icd-ops = soc_camera_platform_ops;
+ icd-ops = NULL;
ici = to_soc_camera_host(icd-parent);
@@ -190,7 +165,6 @@ static int soc_camera_platform_probe(struct platform_device
*pdev)
return ret;
evdrs:
- icd-ops = NULL;
platform_set_drvdata(pdev, NULL);
kfree(priv);
return ret;
@@ -199,11 +173,8 @@ evdrs:
static int soc_camera_platform_remove(struct platform_device *pdev)
{
struct soc_camera_platform_priv *priv = get_priv(pdev);
- struct soc_camera_platform_info *p = pdev-dev.platform_data;
- struct soc_camera_device *icd = p-icd;
v4l2_device_unregister_subdev(priv-subdev);
- icd-ops = NULL;
platform_set_drvdata(pdev, NULL);
kfree(priv);
return 0;
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index a15f92b..8aa4200 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -21,7 +21,6 @@ struct soc_camera_platform_info {
const char *format_name;
unsigned long format_depth;
struct v4l2_mbus_framefmt format;
- unsigned long bus_param;
unsigned long mbus_param;
enum v4l2_mbus_type mbus_type;
struct soc_camera_device *icd;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 58/59] V4L: tw9910: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/tw9910.c | 53 ++---
1 files changed, 3 insertions(+), 50 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 4f9fbf2..40cc149 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -453,7 +453,7 @@ static const struct tw9910_scale_ctrl
*tw9910_select_norm(struct soc_camera_devi
}
/*
- * soc_camera_ops function
+ * subdevice operations
*/
static int tw9910_s_stream(struct v4l2_subdev *sd, int enable)
{
@@ -495,44 +495,6 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
return tw9910_power(client, enable);
}
-static int tw9910_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- u8 val = VSSL_VVALID | HSSL_DVALID;
-
- flags = soc_camera_apply_sensor_flags(icl, flags);
-
- /*
-* set OUTCTR1
-*
-* We use VVALID and DVALID signals to control VSYNC and HSYNC
-* outputs, in this mode their polarity is inverted.
-*/
- if (flags SOCAM_HSYNC_ACTIVE_LOW)
- val |= HSP_HI;
-
- if (flags SOCAM_VSYNC_ACTIVE_LOW)
- val |= VSP_HI;
-
- return i2c_smbus_write_byte_data(client, OUTCTR1, val);
-}
-
-static unsigned long tw9910_query_bus_param(struct soc_camera_device *icd)
-{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- struct tw9910_priv *priv = to_tw9910(client);
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW | SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_DATA_ACTIVE_HIGH | priv-info-buswidth;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int tw9910_s_std(struct v4l2_subdev *sd, v4l2_std_id norm)
{
int ret = -EINVAL;
@@ -840,11 +802,6 @@ static int tw9910_video_probe(struct soc_camera_device
*icd,
return 0;
}
-static struct soc_camera_ops tw9910_ops = {
- .set_bus_param = tw9910_set_bus_param,
- .query_bus_param= tw9910_query_bus_param,
-};
-
static struct v4l2_subdev_core_ops tw9910_subdev_core_ops = {
.g_chip_ident = tw9910_g_chip_ident,
.s_std = tw9910_s_std,
@@ -964,14 +921,12 @@ static int tw9910_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(priv-subdev, client, tw9910_subdev_ops);
- icd-ops = tw9910_ops;
+ icd-ops = NULL;
icd-iface = icl-bus_id;
ret = tw9910_video_probe(icd, client);
- if (ret) {
- icd-ops = NULL;
+ if (ret)
kfree(priv);
- }
return ret;
}
@@ -979,9 +934,7 @@ static int tw9910_probe(struct i2c_client *client,
static int tw9910_remove(struct i2c_client *client)
{
struct tw9910_priv *priv = to_tw9910(client);
- struct soc_camera_device *icd = client-dev.platform_data;
- icd-ops = NULL;
kfree(priv);
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 59/59] V4L: soc-camera: remove soc-camera client bus-param operations and supporting code
soc-camera has been completely ported over to V4L2 subdevice mbus-config
operations, soc-camera client bus-param operations and supporting code
can now be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera.c | 34
include/media/soc_camera.h | 52 ++
2 files changed, 8 insertions(+), 78 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index e05d1c7..ac23916 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -141,40 +141,6 @@ unsigned long soc_camera_apply_board_flags(struct
soc_camera_link *icl,
}
EXPORT_SYMBOL(soc_camera_apply_board_flags);
-/**
- * soc_camera_apply_sensor_flags() - apply platform SOCAM_SENSOR_INVERT_* flags
- * @icl: camera platform parameters
- * @flags: flags to be inverted according to platform configuration
- * @return:resulting flags
- */
-unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
- unsigned long flags)
-{
- unsigned long f;
-
- /* If only one of the two polarities is supported, switch to the
opposite */
- if (icl-flags SOCAM_SENSOR_INVERT_HSYNC) {
- f = flags (SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_LOW);
- if (f == SOCAM_HSYNC_ACTIVE_HIGH || f == SOCAM_HSYNC_ACTIVE_LOW)
- flags ^= SOCAM_HSYNC_ACTIVE_HIGH |
SOCAM_HSYNC_ACTIVE_LOW;
- }
-
- if (icl-flags SOCAM_SENSOR_INVERT_VSYNC) {
- f = flags (SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_LOW);
- if (f == SOCAM_VSYNC_ACTIVE_HIGH || f == SOCAM_VSYNC_ACTIVE_LOW)
- flags ^= SOCAM_VSYNC_ACTIVE_HIGH |
SOCAM_VSYNC_ACTIVE_LOW;
- }
-
- if (icl-flags SOCAM_SENSOR_INVERT_PCLK) {
- f = flags (SOCAM_PCLK_SAMPLE_RISING |
SOCAM_PCLK_SAMPLE_FALLING);
- if (f == SOCAM_PCLK_SAMPLE_RISING || f ==
SOCAM_PCLK_SAMPLE_FALLING)
- flags ^= SOCAM_PCLK_SAMPLE_RISING |
SOCAM_PCLK_SAMPLE_FALLING;
- }
-
- return flags;
-}
-EXPORT_SYMBOL(soc_camera_apply_sensor_flags);
-
#define pixfmtstr(x) (x) 0xff, ((x) 8) 0xff, ((x) 16) 0xff, \
((x) 24) 0xff
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 73337cf..1864e22 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -12,6 +12,7 @@
#ifndef SOC_CAMERA_H
#define SOC_CAMERA_H
+#include linux/bitops.h
#include linux/device.h
#include linux/mutex.h
#include linux/pm.h
@@ -194,8 +195,6 @@ struct soc_camera_format_xlate {
};
struct soc_camera_ops {
- unsigned long (*query_bus_param)(struct soc_camera_device *);
- int (*set_bus_param)(struct soc_camera_device *, unsigned long);
const struct v4l2_queryctrl *controls;
int num_controls;
};
@@ -238,53 +237,18 @@ static inline struct v4l2_queryctrl const
*soc_camera_find_qctrl(
return NULL;
}
-#define SOCAM_MASTER (1 0)
-#define SOCAM_SLAVE(1 1)
-#define SOCAM_HSYNC_ACTIVE_HIGH(1 2)
-#define SOCAM_HSYNC_ACTIVE_LOW (1 6)
-#define SOCAM_VSYNC_ACTIVE_HIGH(1 4)
-#define SOCAM_VSYNC_ACTIVE_LOW (1 5)
-#define SOCAM_DATAWIDTH_4 (1 3)
-#define SOCAM_DATAWIDTH_8 (1 7)
-#define SOCAM_DATAWIDTH_9 (1 8)
-#define SOCAM_DATAWIDTH_10 (1 9)
-#define SOCAM_DATAWIDTH_15 (1 14)
-#define SOCAM_DATAWIDTH_16 (1 15)
-#define SOCAM_PCLK_SAMPLE_RISING (1 12)
-#define SOCAM_PCLK_SAMPLE_FALLING (1 13)
-#define SOCAM_DATA_ACTIVE_HIGH (1 10)
-#define SOCAM_DATA_ACTIVE_LOW (1 11)
-#define SOCAM_MIPI_1LANE (1 16)
-#define SOCAM_MIPI_2LANE (1 17)
-#define SOCAM_MIPI_3LANE (1 18)
-#define SOCAM_MIPI_4LANE (1 19)
-#define SOCAM_MIPI (SOCAM_MIPI_1LANE | SOCAM_MIPI_2LANE | \
- SOCAM_MIPI_3LANE | SOCAM_MIPI_4LANE)
+#define SOCAM_DATAWIDTH(x) BIT((x) - 1)
+#define SOCAM_DATAWIDTH_4 SOCAM_DATAWIDTH(4)
+#define SOCAM_DATAWIDTH_8 SOCAM_DATAWIDTH(8)
+#define SOCAM_DATAWIDTH_9 SOCAM_DATAWIDTH(9)
+#define SOCAM_DATAWIDTH_10 SOCAM_DATAWIDTH(10)
+#define SOCAM_DATAWIDTH_15 SOCAM_DATAWIDTH(15)
+#define SOCAM_DATAWIDTH_16 SOCAM_DATAWIDTH(16)
#define SOCAM_DATAWIDTH_MASK (SOCAM_DATAWIDTH_4 | SOCAM_DATAWIDTH_8 | \
SOCAM_DATAWIDTH_9 | SOCAM_DATAWIDTH_10 | \
SOCAM_DATAWIDTH_15 | SOCAM_DATAWIDTH_16)
-static inline unsigned long soc_camera_bus_param_compatible(
- unsigned long camera_flags, unsigned long bus_flags)
-{
- unsigned long common_flags, hsync, vsync, pclk, data, buswidth, mode;
-
[PATCH 51/59] V4L: ov772x: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov772x.c | 25 -
include/media/ov772x.h |1 -
2 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index b70ffba..f77e899 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -621,29 +621,6 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-static int ov772x_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- return 0;
-}
-
-static unsigned long ov772x_query_bus_param(struct soc_camera_device *icd)
-{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- struct ov772x_priv *priv = i2c_get_clientdata(client);
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH;
-
- if (priv-info-flags OV772X_FLAG_8BIT)
- flags |= SOCAM_DATAWIDTH_8;
- else
- flags |= SOCAM_DATAWIDTH_10;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int ov772x_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
{
struct ov772x_priv *priv = container_of(sd, struct ov772x_priv, subdev);
@@ -1070,8 +1047,6 @@ static int ov772x_video_probe(struct soc_camera_device
*icd,
}
static struct soc_camera_ops ov772x_ops = {
- .set_bus_param = ov772x_set_bus_param,
- .query_bus_param= ov772x_query_bus_param,
.controls = ov772x_controls,
.num_controls = ARRAY_SIZE(ov772x_controls),
};
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index f9e27c0..00dbb7c 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -15,7 +15,6 @@
/* for flags */
#define OV772X_FLAG_VFLIP (1 0) /* Vertical flip image */
#define OV772X_FLAG_HFLIP (1 1) /* Horizontal flip image */
-#define OV772X_FLAG_8BIT (1 2) /* default 10 bit */
/*
* for Edge ctrl
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 47/59] V4L: ov5642: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov5642.c | 24 +---
1 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 60ffc60..6410bda 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -888,26 +888,6 @@ static struct v4l2_subdev_ops ov5642_subdev_ops = {
.video = ov5642_subdev_video_ops,
};
-/*
- * We have to provide soc-camera operations, but we don't have anything to say
- * there. The MIPI CSI2 driver will provide .query_bus_param and .set_bus_param
- */
-static unsigned long soc_ov5642_query_bus_param(struct soc_camera_device *icd)
-{
- return 0;
-}
-
-static int soc_ov5642_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- return -EINVAL;
-}
-
-static struct soc_camera_ops soc_ov5642_ops = {
- .query_bus_param= soc_ov5642_query_bus_param,
- .set_bus_param = soc_ov5642_set_bus_param,
-};
-
static int ov5642_video_probe(struct soc_camera_device *icd,
struct i2c_client *client)
{
@@ -961,7 +941,7 @@ static int ov5642_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(priv-subdev, client, ov5642_subdev_ops);
- icd-ops= soc_ov5642_ops;
+ icd-ops= NULL;
priv-fmt = ov5642_colour_fmts[0];
ret = ov5642_video_probe(icd, client);
@@ -971,7 +951,6 @@ static int ov5642_probe(struct i2c_client *client,
return 0;
error:
- icd-ops = NULL;
kfree(priv);
return ret;
}
@@ -982,7 +961,6 @@ static int ov5642_remove(struct i2c_client *client)
struct soc_camera_device *icd = client-dev.platform_data;
struct soc_camera_link *icl = to_soc_camera_link(icd);
- icd-ops = NULL;
if (icl-free_bus)
icl-free_bus(icl);
kfree(priv);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 33/59] V4L: ov2640: remove undefined struct
struct ov2640_camera_info isn't declared anywhere, remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov2640.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c
index 78bf602..31f361e 100644
--- a/drivers/media/video/ov2640.c
+++ b/drivers/media/video/ov2640.c
@@ -300,7 +300,6 @@ struct ov2640_win_size {
struct ov2640_priv {
struct v4l2_subdev subdev;
- struct ov2640_camera_info *info;
enum v4l2_mbus_pixelcodecfmt_code;
const struct ov2640_win_size*win;
int model;
@@ -1153,8 +1152,6 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
- priv-info = icl-priv;
-
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
icd-ops = ov2640_ops;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 54/59] V4L: rj54n1cb0c: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/rj54n1cb0c.c | 27 ---
1 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c
index d19c79b..c302211 100644
--- a/drivers/media/video/rj54n1cb0c.c
+++ b/drivers/media/video/rj54n1cb0c.c
@@ -499,31 +499,6 @@ static int rj54n1_s_stream(struct v4l2_subdev *sd, int
enable)
return reg_set(client, RJ54N1_STILL_CONTROL, (!enable) 7, 0x80);
}
-static int rj54n1_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- struct i2c_client *client = v4l2_get_subdevdata(sd);
- /* Figures 2.5-1 to 2.5-3 - default falling pixclk edge */
-
- if (flags SOCAM_PCLK_SAMPLE_RISING)
- return reg_write(client, RJ54N1_OUT_SIGPO, 1 4);
- else
- return reg_write(client, RJ54N1_OUT_SIGPO, 0);
-}
-
-static unsigned long rj54n1_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- const unsigned long flags =
- SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int rj54n1_set_rect(struct i2c_client *client,
u16 reg_x, u16 reg_y, u16 reg_xy,
u32 width, u32 height)
@@ -1240,8 +1215,6 @@ static const struct v4l2_queryctrl rj54n1_controls[] = {
};
static struct soc_camera_ops rj54n1_ops = {
- .set_bus_param = rj54n1_set_bus_param,
- .query_bus_param= rj54n1_query_bus_param,
.controls = rj54n1_controls,
.num_controls = ARRAY_SIZE(rj54n1_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 56/59] ARM: mach-shmobile: mackerel doesn't need legacy SOCAM_* flags anymore
The sh_mobile_ceu_camera driver has been converted to use the V4L2
subdevice .[gs]_mbus_config() operations, therefore we don't need
SOCAM_* flags for the soc_camera_platform driver anymore. Remove
them.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Paul Mundt let...@linux-sh.org
---
arch/arm/mach-shmobile/board-mackerel.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 409606b..8f1e8fa 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -1211,9 +1211,6 @@ static struct soc_camera_platform_info camera_info = {
.width = 640,
.height = 480,
},
- .bus_param = SOCAM_PCLK_SAMPLE_RISING | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_MASTER | SOCAM_DATAWIDTH_8 |
- SOCAM_DATA_ACTIVE_HIGH,
.mbus_param = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_HIGH,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 46/59] V4L: ov2640: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov2640.c | 40
1 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c
index 31f361e..2826aff 100644
--- a/drivers/media/video/ov2640.c
+++ b/drivers/media/video/ov2640.c
@@ -701,44 +701,6 @@ static int ov2640_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-static int ov2640_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long width_flag = flags SOCAM_DATAWIDTH_MASK;
-
- /* Only one width bit may be set */
- if (!is_power_of_2(width_flag))
- return -EINVAL;
-
- if (icl-set_bus_param)
- return icl-set_bus_param(icl, width_flag);
-
- /*
-* Without board specific bus width settings we support only the
-* sensors native bus width witch are tested working
-*/
- if (width_flag (SOCAM_DATAWIDTH_10 | SOCAM_DATAWIDTH_8))
- return 0;
-
- return 0;
-}
-
-static unsigned long ov2640_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH;
-
- if (icl-query_bus_param)
- flags |= icl-query_bus_param(icl) SOCAM_DATAWIDTH_MASK;
- else
- flags |= SOCAM_DATAWIDTH_10;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int ov2640_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -1067,8 +1029,6 @@ err:
}
static struct soc_camera_ops ov2640_ops = {
- .set_bus_param = ov2640_set_bus_param,
- .query_bus_param= ov2640_query_bus_param,
.controls = ov2640_controls,
.num_controls = ARRAY_SIZE(ov2640_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 39/59] V4L: soc-camera: camera client operations no longer compulsory
With the transition of all soc-camera host drivers to use V4L2
subdevice .[gs]_mbus_config() operations, soc-camera client operations
no longer have to be compulsory.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 8b16152..e05d1c7 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -482,7 +482,7 @@ static int soc_camera_open(struct file *file)
struct soc_camera_host *ici;
int ret;
- if (!icd-ops)
+ if (!to_soc_camera_control(icd))
/* No device driver attached */
return -ENODEV;
@@ -835,6 +835,9 @@ static int soc_camera_queryctrl(struct file *file, void
*priv,
return 0;
}
+ if (!icd-ops)
+ return -EINVAL;
+
/* Then device controls */
for (i = 0; i icd-ops-num_controls; i++)
if (qc-id == icd-ops-controls[i].id) {
@@ -1461,11 +1464,6 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
if (!icd-parent)
return -ENODEV;
- if (!icd-ops ||
- !icd-ops-query_bus_param ||
- !icd-ops-set_bus_param)
- return -EINVAL;
-
ret = video_register_device(icd-vdev, VFL_TYPE_GRABBER, -1);
if (ret 0) {
dev_err(icd-pdev, video_register_device failed: %d\n, ret);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 44/59] V4L: mt9t112: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9t112.c | 48 +---
1 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/drivers/media/video/mt9t112.c b/drivers/media/video/mt9t112.c
index a3368d8..608a3b6 100644
--- a/drivers/media/video/mt9t112.c
+++ b/drivers/media/video/mt9t112.c
@@ -743,46 +743,6 @@ static int mt9t112_init_camera(const struct i2c_client
*client)
}
/
- soc_camera_ops
-/
-static int mt9t112_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- struct mt9t112_priv *priv = to_mt9t112(client);
-
- if (soc_camera_apply_sensor_flags(icl, flags)
SOCAM_PCLK_SAMPLE_RISING)
- priv-flags |= PCLK_RISING;
-
- return 0;
-}
-
-static unsigned long mt9t112_query_bus_param(struct soc_camera_device *icd)
-{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- struct mt9t112_priv *priv = to_mt9t112(client);
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned long flags = SOCAM_MASTER | SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH;
-
- flags |= (priv-info-flags MT9T112_FLAG_PCLK_RISING_EDGE) ?
- SOCAM_PCLK_SAMPLE_RISING : SOCAM_PCLK_SAMPLE_FALLING;
-
- if (priv-info-flags MT9T112_FLAG_DATAWIDTH_8)
- flags |= SOCAM_DATAWIDTH_8;
- else
- flags |= SOCAM_DATAWIDTH_10;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
-static struct soc_camera_ops mt9t112_ops = {
- .set_bus_param = mt9t112_set_bus_param,
- .query_bus_param= mt9t112_query_bus_param,
-};
-
-/
v4l2_subdev_core_ops
/
static int mt9t112_g_chip_ident(struct v4l2_subdev *sd,
@@ -1117,13 +1077,11 @@ static int mt9t112_probe(struct i2c_client *client,
v4l2_i2c_subdev_init(priv-subdev, client, mt9t112_subdev_ops);
- icd-ops = mt9t112_ops;
+ icd-ops = NULL;
ret = mt9t112_camera_probe(icd, client);
- if (ret) {
- icd-ops = NULL;
+ if (ret)
kfree(priv);
- }
return ret;
}
@@ -1131,9 +1089,7 @@ static int mt9t112_probe(struct i2c_client *client,
static int mt9t112_remove(struct i2c_client *client)
{
struct mt9t112_priv *priv = to_mt9t112(client);
- struct soc_camera_device *icd = client-dev.platform_data;
- icd-ops = NULL;
kfree(priv);
return 0;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 43/59] V4L: mt9t031: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9t031.c | 31 ---
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index c5adb23..25fb833 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -58,11 +58,6 @@
#define MT9T031_COLUMN_SKIP32
#define MT9T031_ROW_SKIP 20
-#define MT9T031_BUS_PARAM (SOCAM_PCLK_SAMPLE_RISING | \
- SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | \
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | \
- SOCAM_MASTER | SOCAM_DATAWIDTH_10)
-
struct mt9t031 {
struct v4l2_subdev subdev;
struct v4l2_rect rect; /* Sensor window */
@@ -180,30 +175,6 @@ static int mt9t031_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-static int mt9t031_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
-
- /* The caller should have queried our parameters, check anyway */
- if (flags ~MT9T031_BUS_PARAM)
- return -EINVAL;
-
- if (flags SOCAM_PCLK_SAMPLE_FALLING)
- reg_clear(client, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000);
- else
- reg_set(client, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000);
-
- return 0;
-}
-
-static unsigned long mt9t031_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
-
- return soc_camera_apply_sensor_flags(icl, MT9T031_BUS_PARAM);
-}
-
enum {
MT9T031_CTRL_VFLIP,
MT9T031_CTRL_HFLIP,
@@ -263,8 +234,6 @@ static const struct v4l2_queryctrl mt9t031_controls[] = {
};
static struct soc_camera_ops mt9t031_ops = {
- .set_bus_param = mt9t031_set_bus_param,
- .query_bus_param= mt9t031_query_bus_param,
.controls = mt9t031_controls,
.num_controls = ARRAY_SIZE(mt9t031_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 34/59] V4L: mx3_camera: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mx3_camera.c | 197 +-
1 files changed, 89 insertions(+), 108 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index c045b47..3f37522f 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -109,6 +109,7 @@ struct mx3_camera_dev {
unsigned long platform_flags;
unsigned long mclk;
+ u16 width_flags;/* max 15 bits */
struct list_headcapture;
spinlock_t lock; /* Protects video buffer lists
*/
@@ -548,58 +549,27 @@ static int test_platform_param(struct mx3_camera_dev
*mx3_cam,
unsigned char buswidth, unsigned long *flags)
{
/*
+* If requested data width is supported by the platform, use it or any
+* possible lower value - i.MX31 is smart enough to shift bits
+*/
+ if (buswidth fls(mx3_cam-width_flags))
+ return -EINVAL;
+
+ /*
* Platform specified synchronization and pixel clock polarities are
* only a recommendation and are only used during probing. MX3x
* camera interface only works in master mode, i.e., uses HSYNC and
* VSYNC signals from the sensor
*/
- *flags = SOCAM_MASTER |
- SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_DATA_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_LOW;
-
- /*
-* If requested data width is supported by the platform, use it or any
-* possible lower value - i.MX31 is smart enough to schift bits
-*/
- if (mx3_cam-platform_flags MX3_CAMERA_DATAWIDTH_15)
- *flags |= SOCAM_DATAWIDTH_15 | SOCAM_DATAWIDTH_10 |
- SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_4;
- else if (mx3_cam-platform_flags MX3_CAMERA_DATAWIDTH_10)
- *flags |= SOCAM_DATAWIDTH_10 | SOCAM_DATAWIDTH_8 |
- SOCAM_DATAWIDTH_4;
- else if (mx3_cam-platform_flags MX3_CAMERA_DATAWIDTH_8)
- *flags |= SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_4;
- else if (mx3_cam-platform_flags MX3_CAMERA_DATAWIDTH_4)
- *flags |= SOCAM_DATAWIDTH_4;
-
- switch (buswidth) {
- case 15:
- if (!(*flags SOCAM_DATAWIDTH_15))
- return -EINVAL;
- break;
- case 10:
- if (!(*flags SOCAM_DATAWIDTH_10))
- return -EINVAL;
- break;
- case 8:
- if (!(*flags SOCAM_DATAWIDTH_8))
- return -EINVAL;
- break;
- case 4:
- if (!(*flags SOCAM_DATAWIDTH_4))
- return -EINVAL;
- break;
- default:
- dev_warn(mx3_cam-soc_host.v4l2_dev.dev,
-Unsupported bus width %d\n, buswidth);
- return -EINVAL;
- }
+ *flags = V4L2_MBUS_MASTER |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_LOW |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTIVE_LOW |
+ V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_PCLK_SAMPLE_FALLING |
+ V4L2_MBUS_DATA_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_LOW;
return 0;
}
@@ -607,9 +577,11 @@ static int test_platform_param(struct mx3_camera_dev
*mx3_cam,
static int mx3_camera_try_bus_param(struct soc_camera_device *icd,
const unsigned int depth)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx3_camera_dev *mx3_cam = ici-priv;
- unsigned long bus_flags, camera_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long bus_flags, common_flags;
int ret = test_platform_param(mx3_cam, depth, bus_flags);
dev_dbg(icd-parent, request bus width %d bit: %d\n, depth, ret);
@@ -617,15 +589,21 @@ static int mx3_camera_try_bus_param(struct
soc_camera_device *icd,
if (ret 0)
return ret;
- camera_flags = icd-ops-query_bus_param(icd);
-
- ret = soc_camera_bus_param_compatible(camera_flags, bus_flags);
- if (ret 0)
- dev_warn(icd-parent,
-Flags incompatible: camera %lx, host %lx\n,
-camera_flags, bus_flags);
+ ret =
[PATCH 48/59] V4L: ov6650: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov6650.c | 50 +
1 files changed, 2 insertions(+), 48 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index a26734d..654b2f5 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -419,52 +419,6 @@ static int ov6650_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-/* Alter bus settings on camera side */
-static int ov6650_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- int ret;
-
- flags = soc_camera_apply_sensor_flags(icl, flags);
-
- if (flags SOCAM_PCLK_SAMPLE_RISING)
- ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_PCLK_RISING, 0);
- else
- ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_PCLK_RISING);
- if (ret)
- return ret;
-
- if (flags SOCAM_HSYNC_ACTIVE_LOW)
- ret = ov6650_reg_rmw(client, REG_COMF, COMF_HREF_LOW, 0);
- else
- ret = ov6650_reg_rmw(client, REG_COMF, 0, COMF_HREF_LOW);
- if (ret)
- return ret;
-
- if (flags SOCAM_VSYNC_ACTIVE_HIGH)
- ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_VSYNC_HIGH, 0);
- else
- ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_VSYNC_HIGH);
-
- return ret;
-}
-
-/* Request bus settings on camera side */
-static unsigned long ov6650_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
-
- unsigned long flags = SOCAM_MASTER |
- SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
/* Get status of additional camera capabilities */
static int ov6650_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
{
@@ -1095,8 +1049,6 @@ static int ov6650_video_probe(struct soc_camera_device
*icd,
}
static struct soc_camera_ops ov6650_ops = {
- .set_bus_param = ov6650_set_bus_param,
- .query_bus_param= ov6650_query_bus_param,
.controls = ov6650_controls,
.num_controls = ARRAY_SIZE(ov6650_controls),
};
@@ -,6 +1063,7 @@ static struct v4l2_subdev_core_ops ov6650_core_ops = {
#endif
};
+/* Request bus settings on camera side */
static int ov6650_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
@@ -1129,6 +1082,7 @@ static int ov6650_g_mbus_config(struct v4l2_subdev *sd,
return 0;
}
+/* Alter bus settings on camera side */
static int ov6650_s_mbus_config(struct v4l2_subdev *sd,
const struct v4l2_mbus_config *cfg)
{
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 45/59] V4L: mt9v022: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9v022.c | 74 -
1 files changed, 0 insertions(+), 74 deletions(-)
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index ddc11d0..53149a7 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -200,78 +200,6 @@ static int mt9v022_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-static int mt9v022_set_bus_param(struct soc_camera_device *icd,
-unsigned long flags)
-{
- struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
- struct mt9v022 *mt9v022 = to_mt9v022(client);
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned int width_flag = flags SOCAM_DATAWIDTH_MASK;
- int ret;
- u16 pixclk = 0;
-
- /* Only one width bit may be set */
- if (!is_power_of_2(width_flag))
- return -EINVAL;
-
- if (icl-set_bus_param) {
- ret = icl-set_bus_param(icl, width_flag);
- if (ret)
- return ret;
- } else {
- /*
-* Without board specific bus width settings we only support the
-* sensors native bus width
-*/
- if (width_flag != SOCAM_DATAWIDTH_10)
- return -EINVAL;
- }
-
- flags = soc_camera_apply_sensor_flags(icl, flags);
-
- if (flags SOCAM_PCLK_SAMPLE_FALLING)
- pixclk |= 0x10;
-
- if (!(flags SOCAM_HSYNC_ACTIVE_HIGH))
- pixclk |= 0x1;
-
- if (!(flags SOCAM_VSYNC_ACTIVE_HIGH))
- pixclk |= 0x2;
-
- ret = reg_write(client, MT9V022_PIXCLK_FV_LV, pixclk);
- if (ret 0)
- return ret;
-
- if (!(flags SOCAM_MASTER))
- mt9v022-chip_control = ~0x8;
-
- ret = reg_write(client, MT9V022_CHIP_CONTROL, mt9v022-chip_control);
- if (ret 0)
- return ret;
-
- dev_dbg(client-dev, Calculated pixclk 0x%x, chip control 0x%x\n,
- pixclk, mt9v022-chip_control);
-
- return 0;
-}
-
-static unsigned long mt9v022_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
- unsigned int flags = SOCAM_MASTER | SOCAM_SLAVE |
- SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_DATA_ACTIVE_HIGH;
-
- if (icl-query_bus_param)
- flags |= icl-query_bus_param(icl) SOCAM_DATAWIDTH_MASK;
- else
- flags |= SOCAM_DATAWIDTH_10;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -558,8 +486,6 @@ static const struct v4l2_queryctrl mt9v022_controls[] = {
};
static struct soc_camera_ops mt9v022_ops = {
- .set_bus_param = mt9v022_set_bus_param,
- .query_bus_param= mt9v022_query_bus_param,
.controls = mt9v022_controls,
.num_controls = ARRAY_SIZE(mt9v022_controls),
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 30/59] V4L: atmel-isi: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/atmel-isi.c | 136 +--
1 files changed, 73 insertions(+), 63 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7b89f00..3e3d4cc 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -94,6 +94,7 @@ struct atmel_isi {
unsigned intirq;
struct isi_platform_data*pdata;
+ u16 width_flags;/* max 12 bits */
struct list_headvideo_buffer_list;
struct frame_buffer *active;
@@ -637,50 +638,42 @@ static bool isi_camera_packing_supported(const struct
soc_mbus_pixelfmt *fmt)
fmt-packing == SOC_MBUS_PACKING_EXTEND16);
}
-static unsigned long make_bus_param(struct atmel_isi *isi)
-{
- unsigned long flags;
- /*
-* Platform specified synchronization and pixel clock polarities are
-* only a recommendation and are only used during probing. Atmel ISI
-* camera interface only works in master mode, i.e., uses HSYNC and
-* VSYNC signals from the sensor
-*/
- flags = SOCAM_MASTER |
- SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_PCLK_SAMPLE_FALLING |
- SOCAM_DATA_ACTIVE_HIGH;
-
- if (isi-pdata-data_width_flags ISI_DATAWIDTH_10)
- flags |= SOCAM_DATAWIDTH_10;
-
- if (isi-pdata-data_width_flags ISI_DATAWIDTH_8)
- flags |= SOCAM_DATAWIDTH_8;
-
- if (flags SOCAM_DATAWIDTH_MASK)
- return flags;
-
- return 0;
-}
+#define ISI_BUS_PARAM (V4L2_MBUS_MASTER | \
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_HSYNC_ACTIVE_LOW |\
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_VSYNC_ACTIVE_LOW |\
+ V4L2_MBUS_PCLK_SAMPLE_RISING | \
+ V4L2_MBUS_PCLK_SAMPLE_FALLING | \
+ V4L2_MBUS_DATA_ACTIVE_HIGH)
static int isi_camera_try_bus_param(struct soc_camera_device *icd,
unsigned char buswidth)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct atmel_isi *isi = ici-priv;
- unsigned long camera_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long common_flags;
int ret;
- camera_flags = icd-ops-query_bus_param(icd);
- ret = soc_camera_bus_param_compatible(camera_flags,
- make_bus_param(isi));
- if (!ret)
- return -EINVAL;
- return 0;
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (!ret) {
+ common_flags = soc_mbus_config_compatible(cfg,
+ ISI_BUS_PARAM);
+ if (!common_flags) {
+ dev_warn(icd-parent,
+Flags incompatible: camera 0x%x, host 0x%x\n,
+cfg.flags, ISI_BUS_PARAM);
+ return -EINVAL;
+ }
+ } else if (ret != -ENOIOCTLCMD) {
+ return ret;
+ }
+
+ if ((1 (buswidth - 1)) isi-width_flags)
+ return 0;
+ return -EINVAL;
}
@@ -802,59 +795,71 @@ static int isi_camera_querycap(struct soc_camera_host
*ici,
static int isi_camera_set_bus_param(struct soc_camera_device *icd, u32 pixfmt)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct atmel_isi *isi = ici-priv;
- unsigned long bus_flags, camera_flags, common_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long common_flags;
int ret;
u32 cfg1 = 0;
- camera_flags = icd-ops-query_bus_param(icd);
-
- bus_flags = make_bus_param(isi);
- common_flags = soc_camera_bus_param_compatible(camera_flags, bus_flags);
- dev_dbg(icd-parent, Flags cam: 0x%lx host: 0x%lx common: 0x%lx\n,
- camera_flags, bus_flags, common_flags);
- if (!common_flags)
- return -EINVAL;
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (!ret) {
+ common_flags = soc_mbus_config_compatible(cfg,
+ ISI_BUS_PARAM);
+ if (!common_flags) {
+ dev_warn(icd-parent,
+
[PATCH 52/59] V4L: ov9640: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov9640.c | 28 +---
1 files changed, 1 insertions(+), 27 deletions(-)
diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c
index 4156c9f..352a8fb 100644
--- a/drivers/media/video/ov9640.c
+++ b/drivers/media/video/ov9640.c
@@ -286,29 +286,6 @@ static int ov9640_s_stream(struct v4l2_subdev *sd, int
enable)
return 0;
}
-/* Alter bus settings on camera side */
-static int ov9640_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- return 0;
-}
-
-/* Request bus settings on camera side */
-static unsigned long ov9640_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
-
- /*
-* REVISIT: the camera probably can do 10 bit transfers, but I don't
-* have those pins connected on my hardware.
-*/
- unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
/* Get status of additional camera capabilities */
static int ov9640_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
{
@@ -648,8 +625,6 @@ static int ov9640_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
return 0;
}
-
-
static int ov9640_video_probe(struct soc_camera_device *icd,
struct i2c_client *client)
{
@@ -707,8 +682,6 @@ err:
}
static struct soc_camera_ops ov9640_ops = {
- .set_bus_param = ov9640_set_bus_param,
- .query_bus_param= ov9640_query_bus_param,
.controls = ov9640_controls,
.num_controls = ARRAY_SIZE(ov9640_controls),
};
@@ -724,6 +697,7 @@ static struct v4l2_subdev_core_ops ov9640_core_ops = {
};
+/* Request bus settings on camera side */
static int ov9640_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/59] V4L: tw9910: remove a not really implemented cropping support
Cropping is not really correctly implemented by this driver and only
needlessly obfuscates the code. Remove it.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/tw9910.c | 129 +++---
1 files changed, 46 insertions(+), 83 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 742482e..686512e 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -203,6 +203,10 @@
#define RTSEL_FIELD 0x06 /* 0110 = FIELD */
#define RTSEL_RTCO 0x07 /* 0111 = RTCO ( Real Time Control ) */
+/* HSYNC start and end are constant for now */
+#define HSYNC_START0x0260
+#define HSYNC_END 0x0300
+
/*
* structure
*/
@@ -220,18 +224,6 @@ struct tw9910_scale_ctrl {
u16 vscale;
};
-struct tw9910_cropping_ctrl {
- u16 vdelay;
- u16 vactive;
- u16 hdelay;
- u16 hactive;
-};
-
-struct tw9910_hsync_ctrl {
- u16 start;
- u16 end;
-};
-
struct tw9910_priv {
struct v4l2_subdev subdev;
struct tw9910_video_info*info;
@@ -329,11 +321,6 @@ static const struct tw9910_scale_ctrl tw9910_pal_scales[]
= {
},
};
-static const struct tw9910_hsync_ctrl tw9910_hsync_ctrl = {
- .start = 0x0260,
- .end = 0x0300,
-};
-
/*
* general function
*/
@@ -378,21 +365,20 @@ static int tw9910_set_scale(struct i2c_client *client,
return ret;
}
-static int tw9910_set_hsync(struct i2c_client *client,
- const struct tw9910_hsync_ctrl *hsync)
+static int tw9910_set_hsync(struct i2c_client *client)
{
struct tw9910_priv *priv = to_tw9910(client);
int ret;
/* bit 10 - 3 */
ret = i2c_smbus_write_byte_data(client, HSBEGIN,
- (hsync-start 0x07F8) 3);
+ (HSYNC_START 0x07F8) 3);
if (ret 0)
return ret;
/* bit 10 - 3 */
ret = i2c_smbus_write_byte_data(client, HSEND,
- (hsync-end 0x07F8) 3);
+ (HSYNC_END 0x07F8) 3);
if (ret 0)
return ret;
@@ -400,8 +386,8 @@ static int tw9910_set_hsync(struct i2c_client *client,
/* bit 2 - 0 */
if (1 == priv-revision)
ret = tw9910_mask_set(client, HSLOWCTL, 0x77,
- (hsync-start 0x0007) 4 |
- (hsync-end0x0007));
+ (HSYNC_START 0x0007) 4 |
+ (HSYNC_END0x0007));
return ret;
}
@@ -433,8 +419,8 @@ static int tw9910_power(struct i2c_client *client, int
enable)
return tw9910_mask_set(client, ACNTL2, ACNTL2_PDN_MASK, acntl2);
}
-static const struct tw9910_scale_ctrl*
-tw9910_select_norm(struct soc_camera_device *icd, u32 width, u32 height)
+static const struct tw9910_scale_ctrl *tw9910_select_norm(struct
soc_camera_device *icd,
+ u32 width, u32 height)
{
const struct tw9910_scale_ctrl *scale;
const struct tw9910_scale_ctrl *ret = NULL;
@@ -510,10 +496,13 @@ static int tw9910_s_stream(struct v4l2_subdev *sd, int
enable)
static int tw9910_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
u8 val = VSSL_VVALID | HSSL_DVALID;
+ flags = soc_camera_apply_sensor_flags(icl, flags);
+
/*
* set OUTCTR1
*
@@ -600,19 +589,18 @@ static int tw9910_s_register(struct v4l2_subdev *sd,
}
#endif
-static int tw9910_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
+static int tw9910_set_frame(struct v4l2_subdev *sd, u32 *width, u32 *height)
{
- struct v4l2_rect *rect = a-c;
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct tw9910_priv *priv = to_tw9910(client);
struct soc_camera_device *icd = client-dev.platform_data;
- int ret = -EINVAL;
- u8 val;
+ int ret = -EINVAL;
+ u8 val;
/*
* select suitable norm
*/
- priv-scale = tw9910_select_norm(icd, rect-width, rect-height);
+ priv-scale = tw9910_select_norm(icd, *width, *height);
if (!priv-scale)
goto tw9910_set_fmt_error;
@@ -670,14 +658,12 @@ static int tw9910_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
/*
* set hsync
*/
- ret = tw9910_set_hsync(client, tw9910_hsync_ctrl);
+ ret = tw9910_set_hsync(client);
if (ret 0)
goto tw9910_set_fmt_error;
- rect-width
[PATCH 36/59] V4L: omap1_camera: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/omap1_camera.c | 52 ++-
1 files changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/omap1_camera.c
b/drivers/media/video/omap1_camera.c
index 8a947e6..f24bcaf 100644
--- a/drivers/media/video/omap1_camera.c
+++ b/drivers/media/video/omap1_camera.c
@@ -102,10 +102,10 @@
/* end of OMAP1 Camera Interface registers */
-#define SOCAM_BUS_FLAGS(SOCAM_MASTER | \
- SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH | \
- SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING | \
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8)
+#define SOCAM_BUS_FLAGS(V4L2_MBUS_MASTER | \
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_VSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_PCLK_SAMPLE_FALLING | \
+ V4L2_MBUS_DATA_ACTIVE_HIGH)
#define FIFO_SIZE ((THRESHOLD_MASK THRESHOLD_SHIFT) + 1)
@@ -1438,41 +1438,55 @@ static int omap1_cam_querycap(struct soc_camera_host
*ici,
static int omap1_cam_set_bus_param(struct soc_camera_device *icd,
__u32 pixfmt)
{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
struct device *dev = icd-parent;
struct soc_camera_host *ici = to_soc_camera_host(dev);
struct omap1_cam_dev *pcdev = ici-priv;
const struct soc_camera_format_xlate *xlate;
const struct soc_mbus_pixelfmt *fmt;
- unsigned long camera_flags, common_flags;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long common_flags;
u32 ctrlclock, mode;
int ret;
- camera_flags = icd-ops-query_bus_param(icd);
-
- common_flags = soc_camera_bus_param_compatible(camera_flags,
- SOCAM_BUS_FLAGS);
- if (!common_flags)
- return -EINVAL;
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (!ret) {
+ common_flags = soc_mbus_config_compatible(cfg,
SOCAM_BUS_FLAGS);
+ if (!common_flags) {
+ dev_warn(dev,
+Flags incompatible: camera 0x%x, host 0x%x\n,
+cfg.flags, SOCAM_BUS_FLAGS);
+ return -EINVAL;
+ }
+ } else if (ret != -ENOIOCTLCMD) {
+ return ret;
+ } else {
+ common_flags = SOCAM_BUS_FLAGS;
+ }
/* Make choices, possibly based on platform configuration */
- if ((common_flags SOCAM_PCLK_SAMPLE_RISING)
- (common_flags SOCAM_PCLK_SAMPLE_FALLING)) {
+ if ((common_flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ (common_flags V4L2_MBUS_PCLK_SAMPLE_FALLING)) {
if (!pcdev-pdata ||
pcdev-pdata-flags OMAP1_CAMERA_LCLK_RISING)
- common_flags = ~SOCAM_PCLK_SAMPLE_FALLING;
+ common_flags = ~V4L2_MBUS_PCLK_SAMPLE_FALLING;
else
- common_flags = ~SOCAM_PCLK_SAMPLE_RISING;
+ common_flags = ~V4L2_MBUS_PCLK_SAMPLE_RISING;
}
- ret = icd-ops-set_bus_param(icd, common_flags);
- if (ret 0)
+ cfg.flags = common_flags;
+ ret = v4l2_subdev_call(sd, video, s_mbus_config, cfg);
+ if (ret 0 ret != -ENOIOCTLCMD) {
+ dev_dbg(dev, camera s_mbus_config(0x%lx) returned %d\n,
+ common_flags, ret);
return ret;
+ }
ctrlclock = CAM_READ_CACHE(pcdev, CTRLCLOCK);
if (ctrlclock LCLK_EN)
CAM_WRITE(pcdev, CTRLCLOCK, ctrlclock ~LCLK_EN);
- if (common_flags SOCAM_PCLK_SAMPLE_RISING) {
+ if (common_flags V4L2_MBUS_PCLK_SAMPLE_RISING) {
dev_dbg(dev, CTRLCLOCK_REG |= POLCLK\n);
ctrlclock |= POLCLK;
} else {
@@ -1716,5 +1730,5 @@ MODULE_PARM_DESC(sg_mode, videobuf mode, 0: dma-contig
(default), 1: dma-sg);
MODULE_DESCRIPTION(OMAP1 Camera Interface driver);
MODULE_AUTHOR(Janusz Krzysztofik jkrzy...@tis.icnet.pl);
MODULE_LICENSE(GPL v2);
-MODULE_LICENSE(DRIVER_VERSION);
+MODULE_VERSION(DRIVER_VERSION);
MODULE_ALIAS(platform: DRIVER_NAME);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 53/59] V4L: ov9740: remove superfluous soc-camera client operations
Now that all soc-camera hosts have been ported to use V4L2 subdevice
mediabus-config operations and soc-camera client bus-parameter operations
have been made optional, they can be removed.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov9740.c | 22 +-
1 files changed, 1 insertions(+), 21 deletions(-)
diff --git a/drivers/media/video/ov9740.c b/drivers/media/video/ov9740.c
index 67b7020..5920f60 100644
--- a/drivers/media/video/ov9740.c
+++ b/drivers/media/video/ov9740.c
@@ -562,25 +562,6 @@ static int ov9740_s_stream(struct v4l2_subdev *sd, int
enable)
return ret;
}
-/* Alter bus settings on camera side */
-static int ov9740_set_bus_param(struct soc_camera_device *icd,
- unsigned long flags)
-{
- return 0;
-}
-
-/* Request bus settings on camera side */
-static unsigned long ov9740_query_bus_param(struct soc_camera_device *icd)
-{
- struct soc_camera_link *icl = to_soc_camera_link(icd);
-
- unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
- SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_DATA_ACTIVE_HIGH | SOCAM_DATAWIDTH_8;
-
- return soc_camera_apply_sensor_flags(icl, flags);
-}
-
/* select nearest higher resolution for capture */
static void ov9740_res_roundup(u32 *width, u32 *height)
{
@@ -945,12 +926,11 @@ err:
}
static struct soc_camera_ops ov9740_ops = {
- .set_bus_param = ov9740_set_bus_param,
- .query_bus_param= ov9740_query_bus_param,
.controls = ov9740_controls,
.num_controls = ARRAY_SIZE(ov9740_controls),
};
+/* Request bus settings on camera side */
static int ov9740_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 38/59] V4L: sh_mobile_ceu_camera: convert to the new mbus-config subdev operations
Switch from soc-camera specific .{query,set}_bus_param() to V4L2
subdevice .[gs]_mbus_config() operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_ceu_camera.c | 156 +++-
1 files changed, 82 insertions(+), 74 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index aa187a4..dedc981 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -144,30 +144,6 @@ static struct sh_mobile_ceu_buffer *to_ceu_vb(struct
vb2_buffer *vb)
return container_of(vb, struct sh_mobile_ceu_buffer, vb);
}
-static unsigned long make_bus_param(struct sh_mobile_ceu_dev *pcdev)
-{
- unsigned long flags;
-
- flags = SOCAM_MASTER |
- SOCAM_PCLK_SAMPLE_RISING |
- SOCAM_HSYNC_ACTIVE_HIGH |
- SOCAM_HSYNC_ACTIVE_LOW |
- SOCAM_VSYNC_ACTIVE_HIGH |
- SOCAM_VSYNC_ACTIVE_LOW |
- SOCAM_DATA_ACTIVE_HIGH;
-
- if (pcdev-pdata-flags SH_CEU_FLAG_USE_8BIT_BUS)
- flags |= SOCAM_DATAWIDTH_8;
-
- if (pcdev-pdata-flags SH_CEU_FLAG_USE_16BIT_BUS)
- flags |= SOCAM_DATAWIDTH_16;
-
- if (flags SOCAM_DATAWIDTH_MASK)
- return flags;
-
- return 0;
-}
-
static void ceu_write(struct sh_mobile_ceu_dev *priv,
unsigned long reg_offs, u32 data)
{
@@ -737,66 +713,90 @@ static void capture_restore(struct sh_mobile_ceu_dev
*pcdev, u32 capsr)
ceu_write(pcdev, CAPSR, capsr);
}
+/* Find the bus subdevice driver, e.g., CSI2 */
+static struct v4l2_subdev *find_bus_subdev(struct sh_mobile_ceu_dev *pcdev,
+ struct soc_camera_device *icd)
+{
+ if (!pcdev-csi2_pdev)
+ return soc_camera_to_subdev(icd);
+
+ return find_csi2(pcdev);
+}
+
+#define CEU_BUS_FLAGS (V4L2_MBUS_MASTER | \
+ V4L2_MBUS_PCLK_SAMPLE_RISING | \
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_HSYNC_ACTIVE_LOW |\
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | \
+ V4L2_MBUS_VSYNC_ACTIVE_LOW |\
+ V4L2_MBUS_DATA_ACTIVE_HIGH)
+
/* Capture is not running, no interrupts, no locking needed */
static int sh_mobile_ceu_set_bus_param(struct soc_camera_device *icd,
__u32 pixfmt)
{
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct sh_mobile_ceu_dev *pcdev = ici-priv;
- int ret;
- unsigned long camera_flags, common_flags, value;
- int yuv_lineskip;
+ struct v4l2_subdev *sd = find_bus_subdev(pcdev, icd);
struct sh_mobile_ceu_cam *cam = icd-host_priv;
+ struct v4l2_mbus_config cfg = {.type = V4L2_MBUS_PARALLEL,};
+ unsigned long value, common_flags = CEU_BUS_FLAGS;
u32 capsr = capture_save_reset(pcdev);
+ unsigned int yuv_lineskip;
+ int ret;
- camera_flags = icd-ops-query_bus_param(icd);
- common_flags = soc_camera_bus_param_compatible(camera_flags,
- make_bus_param(pcdev));
- if (!common_flags)
- return -EINVAL;
+ /*
+* If the client doesn't implement g_mbus_config, we just use our
+* platform data
+*/
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (!ret) {
+ common_flags = soc_mbus_config_compatible(cfg,
+ common_flags);
+ if (!common_flags)
+ return -EINVAL;
+ } else if (ret != -ENOIOCTLCMD) {
+ return ret;
+ }
/* Make choises, based on platform preferences */
- if ((common_flags SOCAM_HSYNC_ACTIVE_HIGH)
- (common_flags SOCAM_HSYNC_ACTIVE_LOW)) {
+ if ((common_flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ (common_flags V4L2_MBUS_HSYNC_ACTIVE_LOW)) {
if (pcdev-pdata-flags SH_CEU_FLAG_HSYNC_LOW)
- common_flags = ~SOCAM_HSYNC_ACTIVE_HIGH;
+ common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_HIGH;
else
- common_flags = ~SOCAM_HSYNC_ACTIVE_LOW;
+ common_flags = ~V4L2_MBUS_HSYNC_ACTIVE_LOW;
}
- if ((common_flags SOCAM_VSYNC_ACTIVE_HIGH)
- (common_flags SOCAM_VSYNC_ACTIVE_LOW)) {
+ if ((common_flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ (common_flags V4L2_MBUS_VSYNC_ACTIVE_LOW)) {
if (pcdev-pdata-flags SH_CEU_FLAG_VSYNC_LOW)
- common_flags = ~SOCAM_VSYNC_ACTIVE_HIGH;
+ common_flags = ~V4L2_MBUS_VSYNC_ACTIVE_HIGH;
else
- common_flags = ~SOCAM_VSYNC_ACTIVE_LOW;
+
[PATCH 25/59] V4L: soc_camera_platform: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera_platform.c | 12
include/media/soc_camera_platform.h |3 +++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_camera_platform.c
b/drivers/media/video/soc_camera_platform.c
index 8069cd6..7045e45 100644
--- a/drivers/media/video/soc_camera_platform.c
+++ b/drivers/media/video/soc_camera_platform.c
@@ -115,6 +115,17 @@ static int soc_camera_platform_cropcap(struct v4l2_subdev
*sd,
return 0;
}
+static int soc_camera_platform_g_mbus_config(struct v4l2_subdev *sd,
+struct v4l2_mbus_config *cfg)
+{
+ struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
+
+ cfg-flags = p-mbus_param;
+ cfg-type = p-mbus_type;
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops platform_subdev_video_ops = {
.s_stream = soc_camera_platform_s_stream,
.enum_mbus_fmt = soc_camera_platform_enum_fmt,
@@ -123,6 +134,7 @@ static struct v4l2_subdev_video_ops
platform_subdev_video_ops = {
.try_mbus_fmt = soc_camera_platform_fill_fmt,
.g_mbus_fmt = soc_camera_platform_fill_fmt,
.s_mbus_fmt = soc_camera_platform_fill_fmt,
+ .g_mbus_config = soc_camera_platform_g_mbus_config,
};
static struct v4l2_subdev_ops platform_subdev_ops = {
diff --git a/include/media/soc_camera_platform.h
b/include/media/soc_camera_platform.h
index 74f0fa1..a15f92b 100644
--- a/include/media/soc_camera_platform.h
+++ b/include/media/soc_camera_platform.h
@@ -13,6 +13,7 @@
#include linux/videodev2.h
#include media/soc_camera.h
+#include media/v4l2-mediabus.h
struct device;
@@ -21,6 +22,8 @@ struct soc_camera_platform_info {
unsigned long format_depth;
struct v4l2_mbus_framefmt format;
unsigned long bus_param;
+ unsigned long mbus_param;
+ enum v4l2_mbus_type mbus_type;
struct soc_camera_device *icd;
int (*set_capture)(struct soc_camera_platform_info *info, int enable);
};
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/59] V4L: soc-camera: compatible bus-width flags
With the new subdevice media-bus configuration methods bus-width is not configured along with other bus parameters, instead, it is derived from the data format. With those methods it is convenient to specify supported bus-widths in the platform data as (1 (width - 1)). We redefine SOCAM_DATAWIDTH_* flags to use the same convention to make platform data seemlessly reusable. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- include/media/soc_camera.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index 936a504..73337cf 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h @@ -241,19 +241,19 @@ static inline struct v4l2_queryctrl const *soc_camera_find_qctrl( #define SOCAM_MASTER (1 0) #define SOCAM_SLAVE(1 1) #define SOCAM_HSYNC_ACTIVE_HIGH(1 2) -#define SOCAM_HSYNC_ACTIVE_LOW (1 3) +#define SOCAM_HSYNC_ACTIVE_LOW (1 6) #define SOCAM_VSYNC_ACTIVE_HIGH(1 4) #define SOCAM_VSYNC_ACTIVE_LOW (1 5) -#define SOCAM_DATAWIDTH_4 (1 6) +#define SOCAM_DATAWIDTH_4 (1 3) #define SOCAM_DATAWIDTH_8 (1 7) #define SOCAM_DATAWIDTH_9 (1 8) #define SOCAM_DATAWIDTH_10 (1 9) -#define SOCAM_DATAWIDTH_15 (1 10) -#define SOCAM_DATAWIDTH_16 (1 11) +#define SOCAM_DATAWIDTH_15 (1 14) +#define SOCAM_DATAWIDTH_16 (1 15) #define SOCAM_PCLK_SAMPLE_RISING (1 12) #define SOCAM_PCLK_SAMPLE_FALLING (1 13) -#define SOCAM_DATA_ACTIVE_HIGH (1 14) -#define SOCAM_DATA_ACTIVE_LOW (1 15) +#define SOCAM_DATA_ACTIVE_HIGH (1 10) +#define SOCAM_DATA_ACTIVE_LOW (1 11) #define SOCAM_MIPI_1LANE (1 16) #define SOCAM_MIPI_2LANE (1 17) #define SOCAM_MIPI_3LANE (1 18) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 29/59] ARM: PXA: use gpio_set_value_cansleep() on pcm990
Camera-switching GPIOs are provided by a i2c GPIO extender, switching them can send the caller to sleep. Use the GPIO API *_cansleep methods explicitly to avoid runtime warnings. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Robert Jarzmik robert.jarz...@free.fr Cc: Eric Miao eric.y.m...@gmail.com --- arch/arm/mach-pxa/pcm990-baseboard.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c b/arch/arm/mach-pxa/pcm990-baseboard.c index 6d5b7e0..8ad2597 100644 --- a/arch/arm/mach-pxa/pcm990-baseboard.c +++ b/arch/arm/mach-pxa/pcm990-baseboard.c @@ -395,9 +395,9 @@ static int pcm990_camera_set_bus_param(struct soc_camera_link *link, } if (flags SOCAM_DATAWIDTH_8) - gpio_set_value(gpio_bus_switch, 1); + gpio_set_value_cansleep(gpio_bus_switch, 1); else - gpio_set_value(gpio_bus_switch, 0); + gpio_set_value_cansleep(gpio_bus_switch, 0); return 0; } -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/59] V4L: tw9910: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/tw9910.c | 49 -
1 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/tw9910.c b/drivers/media/video/tw9910.c
index 686512e..4f9fbf2 100644
--- a/drivers/media/video/tw9910.c
+++ b/drivers/media/video/tw9910.c
@@ -23,10 +23,12 @@
#include linux/kernel.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-chip-ident.h
-#include media/v4l2-subdev.h
+
#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/tw9910.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
#define GET_ID(val) ((val 0xF8) 3)
#define GET_REV(val) (val 0x07)
@@ -862,6 +864,47 @@ static int tw9910_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int tw9910_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_LOW |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_LOW |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int tw9910_s_mbus_config(struct v4l2_subdev *sd,
+ const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ u8 val = VSSL_VVALID | HSSL_DVALID;
+ unsigned long flags = soc_camera_apply_board_flags(icl, cfg);
+
+ /*
+* set OUTCTR1
+*
+* We use VVALID and DVALID signals to control VSYNC and HSYNC
+* outputs, in this mode their polarity is inverted.
+*/
+ if (flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
+ val |= HSP_HI;
+
+ if (flags V4L2_MBUS_VSYNC_ACTIVE_LOW)
+ val |= VSP_HI;
+
+ return i2c_smbus_write_byte_data(client, OUTCTR1, val);
+}
+
static struct v4l2_subdev_video_ops tw9910_subdev_video_ops = {
.s_stream = tw9910_s_stream,
.g_mbus_fmt = tw9910_g_fmt,
@@ -870,6 +913,8 @@ static struct v4l2_subdev_video_ops tw9910_subdev_video_ops
= {
.cropcap= tw9910_cropcap,
.g_crop = tw9910_g_crop,
.enum_mbus_fmt = tw9910_enum_fmt,
+ .g_mbus_config = tw9910_g_mbus_config,
+ .s_mbus_config = tw9910_s_mbus_config,
};
static struct v4l2_subdev_ops tw9910_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/59] V4L: ov2640: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov2640.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ov2640.c b/drivers/media/video/ov2640.c
index 9ce2fa0..78bf602 100644
--- a/drivers/media/video/ov2640.c
+++ b/drivers/media/video/ov2640.c
@@ -19,10 +19,11 @@
#include linux/slab.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-chip-ident.h
-#include media/v4l2-subdev.h
+
#include media/soc_camera.h
#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
#define VAL_SET(x, mask, rshift, lshift) \
x) rshift) mask) lshift)
@@ -1083,6 +1084,22 @@ static struct v4l2_subdev_core_ops
ov2640_subdev_core_ops = {
#endif
};
+static int ov2640_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops ov2640_subdev_video_ops = {
.s_stream = ov2640_s_stream,
.g_mbus_fmt = ov2640_g_fmt,
@@ -1091,6 +1108,7 @@ static struct v4l2_subdev_video_ops
ov2640_subdev_video_ops = {
.cropcap= ov2640_cropcap,
.g_crop = ov2640_g_crop,
.enum_mbus_fmt = ov2640_enum_fmt,
+ .g_mbus_config = ov2640_g_mbus_config,
};
static struct v4l2_subdev_ops ov2640_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/59] V4L: ov772x: rename macros to not pollute the global namespace
Macros, defined in a header under include/ should be kept in a local
namespace and not pollute the global one.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov772x.c |8
include/media/ov772x.h | 25 -
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 397870f..458265b 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -822,13 +822,13 @@ static int ov772x_set_params(struct i2c_client *client,
u32 *width, u32 *height,
goto ov772x_set_fmt_error;
ret = ov772x_mask_set(client,
- EDGE_TRSHLD, EDGE_THRESHOLD_MASK,
+ EDGE_TRSHLD, OV772X_EDGE_THRESHOLD_MASK,
priv-info-edgectrl.threshold);
if (ret 0)
goto ov772x_set_fmt_error;
ret = ov772x_mask_set(client,
- EDGE_STRNGT, EDGE_STRENGTH_MASK,
+ EDGE_STRNGT, OV772X_EDGE_STRENGTH_MASK,
priv-info-edgectrl.strength);
if (ret 0)
goto ov772x_set_fmt_error;
@@ -840,13 +840,13 @@ static int ov772x_set_params(struct i2c_client *client,
u32 *width, u32 *height,
* set upper and lower limit
*/
ret = ov772x_mask_set(client,
- EDGE_UPPER, EDGE_UPPER_MASK,
+ EDGE_UPPER, OV772X_EDGE_UPPER_MASK,
priv-info-edgectrl.upper);
if (ret 0)
goto ov772x_set_fmt_error;
ret = ov772x_mask_set(client,
- EDGE_LOWER, EDGE_LOWER_MASK,
+ EDGE_LOWER, OV772X_EDGE_LOWER_MASK,
priv-info-edgectrl.lower);
if (ret 0)
goto ov772x_set_fmt_error;
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 548bf11..f9e27c0 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -12,8 +12,6 @@
#ifndef __OV772X_H__
#define __OV772X_H__
-#include media/soc_camera.h
-
/* for flags */
#define OV772X_FLAG_VFLIP (1 0) /* Vertical flip image */
#define OV772X_FLAG_HFLIP (1 1) /* Horizontal flip image */
@@ -32,22 +30,23 @@ struct ov772x_edge_ctrl {
unsigned char lower;
};
-#define OV772X_MANUAL_EDGE_CTRL0x80 /* un-used bit of strength */
-#define EDGE_STRENGTH_MASK 0x1F
-#define EDGE_THRESHOLD_MASK0x0F
-#define EDGE_UPPER_MASK0xFF
-#define EDGE_LOWER_MASK0xFF
+#define OV772X_MANUAL_EDGE_CTRL0x80 /* un-used bit of strength
*/
+#define OV772X_EDGE_STRENGTH_MASK 0x1F
+#define OV772X_EDGE_THRESHOLD_MASK 0x0F
+#define OV772X_EDGE_UPPER_MASK 0xFF
+#define OV772X_EDGE_LOWER_MASK 0xFF
#define OV772X_AUTO_EDGECTRL(u, l) \
{ \
- .upper = (u EDGE_UPPER_MASK), \
- .lower = (l EDGE_LOWER_MASK), \
+ .upper = (u OV772X_EDGE_UPPER_MASK), \
+ .lower = (l OV772X_EDGE_LOWER_MASK), \
}
-#define OV772X_MANUAL_EDGECTRL(s, t) \
-{ \
- .strength = (s EDGE_STRENGTH_MASK) | OV772X_MANUAL_EDGE_CTRL,\
- .threshold = (t EDGE_THRESHOLD_MASK), \
+#define OV772X_MANUAL_EDGECTRL(s, t) \
+{ \
+ .strength = (s OV772X_EDGE_STRENGTH_MASK) | \
+ OV772X_MANUAL_EDGE_CTRL,\
+ .threshold = (t OV772X_EDGE_THRESHOLD_MASK), \
}
/*
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/59] V4L: ov6650: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov6650.c | 53 +-
1 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
index 456d9ad..a26734d 100644
--- a/drivers/media/video/ov6650.c
+++ b/drivers/media/video/ov6650.c
@@ -30,9 +30,9 @@
#include linux/slab.h
#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-chip-ident.h
-
/* Register definitions */
#define REG_GAIN 0x00/* range 00 - 3F */
#define REG_BLUE 0x01
@@ -,6 +,55 @@ static struct v4l2_subdev_core_ops ov6650_core_ops = {
#endif
};
+static int ov6650_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_MASTER |
+ V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_LOW |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_LOW |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int ov6650_s_mbus_config(struct v4l2_subdev *sd,
+ const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ unsigned long flags = soc_camera_apply_board_flags(icl, cfg);
+ int ret;
+
+ if (flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_PCLK_RISING, 0);
+ else
+ ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_PCLK_RISING);
+ if (ret)
+ return ret;
+
+ if (flags V4L2_MBUS_HSYNC_ACTIVE_LOW)
+ ret = ov6650_reg_rmw(client, REG_COMF, COMF_HREF_LOW, 0);
+ else
+ ret = ov6650_reg_rmw(client, REG_COMF, 0, COMF_HREF_LOW);
+ if (ret)
+ return ret;
+
+ if (flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ ret = ov6650_reg_rmw(client, REG_COMJ, COMJ_VSYNC_HIGH, 0);
+ else
+ ret = ov6650_reg_rmw(client, REG_COMJ, 0, COMJ_VSYNC_HIGH);
+
+ return ret;
+}
+
static struct v4l2_subdev_video_ops ov6650_video_ops = {
.s_stream = ov6650_s_stream,
.g_mbus_fmt = ov6650_g_fmt,
@@ -1122,6 +1171,8 @@ static struct v4l2_subdev_video_ops ov6650_video_ops = {
.s_crop = ov6650_s_crop,
.g_parm = ov6650_g_parm,
.s_parm = ov6650_s_parm,
+ .g_mbus_config = ov6650_g_mbus_config,
+ .s_mbus_config = ov6650_s_mbus_config,
};
static struct v4l2_subdev_ops ov6650_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/59] V4L: mt9t031: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9t031.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index 30547cc..c5adb23 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -16,6 +16,7 @@
#include linux/videodev2.h
#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-chip-ident.h
#include media/v4l2-subdev.h
@@ -807,6 +808,36 @@ static int mt9t031_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int mt9t031_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_PCLK_SAMPLE_FALLING | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int mt9t031_s_mbus_config(struct v4l2_subdev *sd,
+ const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ if (soc_camera_apply_board_flags(icl, cfg)
+ V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ return reg_clear(client, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000);
+ else
+ return reg_set(client, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000);
+}
+
static struct v4l2_subdev_video_ops mt9t031_subdev_video_ops = {
.s_stream = mt9t031_s_stream,
.s_mbus_fmt = mt9t031_s_fmt,
@@ -816,6 +847,8 @@ static struct v4l2_subdev_video_ops
mt9t031_subdev_video_ops = {
.g_crop = mt9t031_g_crop,
.cropcap= mt9t031_cropcap,
.enum_mbus_fmt = mt9t031_enum_fmt,
+ .g_mbus_config = mt9t031_g_mbus_config,
+ .s_mbus_config = mt9t031_s_mbus_config,
};
static struct v4l2_subdev_sensor_ops mt9t031_subdev_sensor_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/59] V4L: sh_mobile_csi2: verify client compatibility
Switch the meaning of the .lanes platform data parameter to specify
the number of used lanes instead of a bitmask. Verify bus configuration
compatibility with client's capabilities.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_csi2.c | 58 ++---
1 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sh_mobile_csi2.c
b/drivers/media/video/sh_mobile_csi2.c
index 2893a01..09ef63d 100644
--- a/drivers/media/video/sh_mobile_csi2.c
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -19,6 +19,7 @@
#include media/sh_mobile_ceu.h
#include media/sh_mobile_csi2.h
#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-common.h
#include media/v4l2-dev.h
#include media/v4l2-device.h
@@ -144,11 +145,21 @@ static void sh_csi2_hwinit(struct sh_csi2 *priv)
udelay(5);
iowrite32(0x, priv-base + SH_CSI2_SRST);
- if (priv-client-lanes 3)
- tmp |= priv-client-lanes 3;
- else
- /* Default - both lanes */
- tmp |= 3;
+ switch (pdata-type) {
+ case SH_CSI2C:
+ if (priv-client-lanes == 1)
+ tmp |= 1;
+ else
+ /* Default - both lanes */
+ tmp |= 3;
+ break;
+ case SH_CSI2I:
+ if (!priv-client-lanes || priv-client-lanes 4)
+ /* Default - all 4 lanes */
+ tmp |= 0xf;
+ else
+ tmp |= (1 priv-client-lanes) - 1;
+ }
if (priv-client-phy == SH_CSI2_PHY_MAIN)
tmp |= 0x8000;
@@ -185,7 +196,9 @@ static int sh_csi2_client_connect(struct sh_csi2 *priv)
struct v4l2_subdev *sd, *csi2_sd = priv-subdev;
struct soc_camera_device *icd = NULL;
struct device *dev = v4l2_get_subdevdata(priv-subdev);
- int i;
+ struct v4l2_mbus_config cfg;
+ unsigned long common_flags, csi2_flags;
+ int i, ret;
v4l2_device_for_each_subdev(sd, csi2_sd-v4l2_dev)
if (sd-grp_id) {
@@ -205,6 +218,39 @@ static int sh_csi2_client_connect(struct sh_csi2 *priv)
if (i == pdata-num_clients)
return -ENODEV;
+ /* Check if we can support this camera */
+ csi2_flags = V4L2_MBUS_CSI2_CONTINUOUS_CLOCK | V4L2_MBUS_CSI2_1_LANE;
+
+ switch (pdata-type) {
+ case SH_CSI2C:
+ if (pdata-clients[i].lanes != 1)
+ csi2_flags |= V4L2_MBUS_CSI2_2_LANE;
+ break;
+ case SH_CSI2I:
+ switch (pdata-clients[i].lanes) {
+ default:
+ csi2_flags |= V4L2_MBUS_CSI2_4_LANE;
+ case 3:
+ csi2_flags |= V4L2_MBUS_CSI2_3_LANE;
+ case 2:
+ csi2_flags |= V4L2_MBUS_CSI2_2_LANE;
+ }
+ }
+
+ cfg.type = V4L2_MBUS_CSI2;
+ ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
+ if (ret == -ENOIOCTLCMD)
+ common_flags = csi2_flags;
+ else if (!ret)
+ common_flags = soc_mbus_config_compatible(cfg,
+ csi2_flags);
+ else
+ common_flags = 0;
+
+ if (!common_flags)
+ return -EINVAL;
+
+ /* All good: camera MIPI configuration supported */
priv-client = pdata-clients + i;
priv-set_bus_param = icd-ops-set_bus_param;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/59] V4L: mt9t112: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9t112.c | 81 +
1 files changed, 42 insertions(+), 39 deletions(-)
diff --git a/drivers/media/video/mt9t112.c b/drivers/media/video/mt9t112.c
index d2e0a50..a3368d8 100644
--- a/drivers/media/video/mt9t112.c
+++ b/drivers/media/video/mt9t112.c
@@ -34,11 +34,7 @@
/* #define EXT_CLOCK 2400 */
/
-
-
macro
-
-
/
/*
* frame size
@@ -80,11 +76,7 @@
#define VAR8(id, offset) _VAR(id, offset, 0x8000)
/
-
-
struct
-
-
/
struct mt9t112_frame_size {
u16 width;
@@ -108,15 +100,12 @@ struct mt9t112_priv {
int model;
u32 flags;
/* for flags */
-#define INIT_DONE (10)
+#define INIT_DONE (1 0)
+#define PCLK_RISING(1 1)
};
/
-
-
supported format
-
-
/
static const struct mt9t112_format mt9t112_cfmts[] = {
@@ -154,11 +143,7 @@ static const struct mt9t112_format mt9t112_cfmts[] = {
};
/
-
-
general function
-
-
/
static struct mt9t112_priv *to_mt9t112(const struct i2c_client *client)
{
@@ -758,15 +743,18 @@ static int mt9t112_init_camera(const struct i2c_client
*client)
}
/
-
-
soc_camera_ops
-
-
/
static int mt9t112_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ struct i2c_client *client = to_i2c_client(to_soc_camera_control(icd));
+ struct mt9t112_priv *priv = to_mt9t112(client);
+
+ if (soc_camera_apply_sensor_flags(icl, flags)
SOCAM_PCLK_SAMPLE_RISING)
+ priv-flags |= PCLK_RISING;
+
return 0;
}
@@ -795,11 +783,7 @@ static struct soc_camera_ops mt9t112_ops = {
};
/
-
-
v4l2_subdev_core_ops
-
-
/
static int mt9t112_g_chip_ident(struct v4l2_subdev *sd,
struct v4l2_dbg_chip_ident *id)
@@ -850,11 +834,7 @@ static struct v4l2_subdev_core_ops mt9t112_subdev_core_ops
= {
/
-
-
v4l2_subdev_video_ops
-
-
/
static int mt9t112_s_stream(struct v4l2_subdev *sd, int enable)
{
@@ -877,8 +857,7 @@ static int mt9t112_s_stream(struct v4l2_subdev *sd, int
enable)
}
if (!(priv-flags INIT_DONE)) {
- u16 param = (MT9T112_FLAG_PCLK_RISING_EDGE
-priv-info-flags) ? 0x0001 : 0x;
+ u16 param = PCLK_RISING priv-flags ? 0x0001 : 0x;
ECHECKER(ret, mt9t112_init_camera(client));
@@ -1027,6 +1006,36 @@ static int mt9t112_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int mt9t112_g_mbus_config(struct v4l2_subdev *sd,
+struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_MASTER | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_DATA_ACTIVE_HIGH |
+ V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int mt9t112_s_mbus_config(struct v4l2_subdev *sd,
+const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ struct mt9t112_priv *priv = to_mt9t112(client);
+
+ if
[PATCH 11/59] V4L: mt9v022: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9v022.c | 76 -
1 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 51b0fcc..2fc6ca2 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -14,9 +14,10 @@
#include linux/delay.h
#include linux/log2.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-subdev.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/*
* mt9v022 i2c address 0x48, 0x4c, 0x58, 0x5c
@@ -848,6 +849,77 @@ static int mt9v022_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int mt9v022_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_MASTER | V4L2_MBUS_SLAVE |
+ V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_LOW |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_LOW |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int mt9v022_s_mbus_config(struct v4l2_subdev *sd,
+const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ struct mt9v022 *mt9v022 = to_mt9v022(client);
+ unsigned long flags = soc_camera_apply_board_flags(icl, cfg);
+ unsigned int bps =
soc_mbus_get_fmtdesc(icd-current_fmt-code)-bits_per_sample;
+ int ret;
+ u16 pixclk = 0;
+
+ dev_info(icd-pdev, set %d: %s, %dbps\n, icd-current_fmt-code,
+icd-current_fmt-host_fmt-name, bps);
+
+ if (icl-set_bus_param) {
+ ret = icl-set_bus_param(icl, 1 (bps - 1));
+ if (ret)
+ return ret;
+ } else if (bps != 10) {
+ /*
+* Without board specific bus width settings we only support the
+* sensors native bus width
+*/
+ return -EINVAL;
+ }
+
+ if (flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ pixclk |= 0x10;
+
+ if (!(flags V4L2_MBUS_HSYNC_ACTIVE_HIGH))
+ pixclk |= 0x1;
+
+ if (!(flags V4L2_MBUS_VSYNC_ACTIVE_HIGH))
+ pixclk |= 0x2;
+
+ ret = reg_write(client, MT9V022_PIXCLK_FV_LV, pixclk);
+ if (ret 0)
+ return ret;
+
+ if (!(flags V4L2_MBUS_MASTER))
+ mt9v022-chip_control = ~0x8;
+
+ ret = reg_write(client, MT9V022_CHIP_CONTROL, mt9v022-chip_control);
+ if (ret 0)
+ return ret;
+
+ dev_dbg(client-dev, Calculated pixclk 0x%x, chip control 0x%x\n,
+ pixclk, mt9v022-chip_control);
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops mt9v022_subdev_video_ops = {
.s_stream = mt9v022_s_stream,
.s_mbus_fmt = mt9v022_s_fmt,
@@ -857,6 +929,8 @@ static struct v4l2_subdev_video_ops
mt9v022_subdev_video_ops = {
.g_crop = mt9v022_g_crop,
.cropcap= mt9v022_cropcap,
.enum_mbus_fmt = mt9v022_enum_fmt,
+ .g_mbus_config = mt9v022_g_mbus_config,
+ .s_mbus_config = mt9v022_s_mbus_config,
};
static struct v4l2_subdev_sensor_ops mt9v022_subdev_sensor_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/59] V4L: rj54n1cb0c: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/rj54n1cb0c.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/rj54n1cb0c.c b/drivers/media/video/rj54n1cb0c.c
index 847ccc0..d19c79b 100644
--- a/drivers/media/video/rj54n1cb0c.c
+++ b/drivers/media/video/rj54n1cb0c.c
@@ -1337,6 +1337,38 @@ static struct v4l2_subdev_core_ops
rj54n1_subdev_core_ops = {
#endif
};
+static int rj54n1_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags =
+ V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_PCLK_SAMPLE_FALLING |
+ V4L2_MBUS_MASTER | V4L2_MBUS_DATA_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int rj54n1_s_mbus_config(struct v4l2_subdev *sd,
+ const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ /* Figures 2.5-1 to 2.5-3 - default falling pixclk edge */
+ if (soc_camera_apply_board_flags(icl, cfg)
+ V4L2_MBUS_PCLK_SAMPLE_RISING)
+ return reg_write(client, RJ54N1_OUT_SIGPO, 1 4);
+ else
+ return reg_write(client, RJ54N1_OUT_SIGPO, 0);
+}
+
static struct v4l2_subdev_video_ops rj54n1_subdev_video_ops = {
.s_stream = rj54n1_s_stream,
.s_mbus_fmt = rj54n1_s_fmt,
@@ -1346,6 +1378,8 @@ static struct v4l2_subdev_video_ops
rj54n1_subdev_video_ops = {
.g_crop = rj54n1_g_crop,
.s_crop = rj54n1_s_crop,
.cropcap= rj54n1_cropcap,
+ .g_mbus_config = rj54n1_g_mbus_config,
+ .s_mbus_config = rj54n1_s_mbus_config,
};
static struct v4l2_subdev_ops rj54n1_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/59] V4L: ov5642: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov5642.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
index 3cdae97..60ffc60 100644
--- a/drivers/media/video/ov5642.c
+++ b/drivers/media/video/ov5642.c
@@ -854,6 +854,17 @@ static int ov5642_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
return 0;
}
+static int ov5642_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ cfg-type = V4L2_MBUS_CSI2;
+ cfg-flags = V4L2_MBUS_CSI2_2_LANE |
+ V4L2_MBUS_CSI2_CHANNEL_0 |
+ V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops ov5642_subdev_video_ops = {
.s_mbus_fmt = ov5642_s_fmt,
.g_mbus_fmt = ov5642_g_fmt,
@@ -861,6 +872,7 @@ static struct v4l2_subdev_video_ops ov5642_subdev_video_ops
= {
.enum_mbus_fmt = ov5642_enum_fmt,
.g_crop = ov5642_g_crop,
.cropcap= ov5642_cropcap,
+ .g_mbus_config = ov5642_g_mbus_config,
};
static struct v4l2_subdev_core_ops ov5642_subdev_core_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/59] V4L: soc-camera: add helper functions for new bus configuration type
Add helper functions to process the new media bus configuration type
similar to soc_camera_apply_sensor_flags() and
soc_camera_bus_param_compatible().
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/soc_camera.c | 34 ++
drivers/media/video/soc_mediabus.c | 33 +
include/media/soc_camera.h |6 --
include/media/soc_mediabus.h |2 ++
4 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 5bdfe7e..8b16152 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -108,6 +108,40 @@ const struct soc_camera_format_xlate
*soc_camera_xlate_by_fourcc(
EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
/**
+ * soc_camera_apply_board_flags() - apply platform SOCAM_SENSOR_INVERT_* flags
+ * @icl: camera platform parameters
+ * @cfg: media bus configuration
+ * @return:resulting flags
+ */
+unsigned long soc_camera_apply_board_flags(struct soc_camera_link *icl,
+ const struct v4l2_mbus_config *cfg)
+{
+ unsigned long f, flags = cfg-flags;
+
+ /* If only one of the two polarities is supported, switch to the
opposite */
+ if (icl-flags SOCAM_SENSOR_INVERT_HSYNC) {
+ f = flags (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ if (f == V4L2_MBUS_HSYNC_ACTIVE_HIGH || f ==
V4L2_MBUS_HSYNC_ACTIVE_LOW)
+ flags ^= V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_HSYNC_ACTIVE_LOW;
+ }
+
+ if (icl-flags SOCAM_SENSOR_INVERT_VSYNC) {
+ f = flags (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
V4L2_MBUS_VSYNC_ACTIVE_LOW);
+ if (f == V4L2_MBUS_VSYNC_ACTIVE_HIGH || f ==
V4L2_MBUS_VSYNC_ACTIVE_LOW)
+ flags ^= V4L2_MBUS_VSYNC_ACTIVE_HIGH |
V4L2_MBUS_VSYNC_ACTIVE_LOW;
+ }
+
+ if (icl-flags SOCAM_SENSOR_INVERT_PCLK) {
+ f = flags (V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_PCLK_SAMPLE_FALLING);
+ if (f == V4L2_MBUS_PCLK_SAMPLE_RISING || f ==
V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ flags ^= V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_PCLK_SAMPLE_FALLING;
+ }
+
+ return flags;
+}
+EXPORT_SYMBOL(soc_camera_apply_board_flags);
+
+/**
* soc_camera_apply_sensor_flags() - apply platform SOCAM_SENSOR_INVERT_* flags
* @icl: camera platform parameters
* @flags: flags to be inverted according to platform configuration
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
index bea7c9c..cf7f219 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -383,6 +383,39 @@ const struct soc_mbus_pixelfmt *soc_mbus_get_fmtdesc(
}
EXPORT_SYMBOL(soc_mbus_get_fmtdesc);
+unsigned int soc_mbus_config_compatible(const struct v4l2_mbus_config *cfg,
+ unsigned int flags)
+{
+ unsigned long common_flags;
+ bool hsync = true, vsync = true, pclk, data, mode;
+ bool mipi_lanes, mipi_clock;
+
+ common_flags = cfg-flags flags;
+
+ switch (cfg-type) {
+ case V4L2_MBUS_PARALLEL:
+ hsync = common_flags (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ vsync = common_flags (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTIVE_LOW);
+ case V4L2_MBUS_BT656:
+ pclk = common_flags (V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_PCLK_SAMPLE_FALLING);
+ data = common_flags (V4L2_MBUS_DATA_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_LOW);
+ mode = common_flags (V4L2_MBUS_MASTER | V4L2_MBUS_SLAVE);
+ return (!hsync || !vsync || !pclk || !data || !mode) ?
+ 0 : common_flags;
+ case V4L2_MBUS_CSI2:
+ mipi_lanes = common_flags V4L2_MBUS_CSI2_LANES;
+ mipi_clock = common_flags (V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK
|
+V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
+ return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(soc_mbus_config_compatible);
+
static int __init soc_mbus_init(void)
{
return 0;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 7582952..936a504 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -300,8 +300,10 @@ static inline void soc_camera_limit_side(int *start, int
*length,
*start = start_min + length_max - *length;
}
-extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
-
[PATCH 17/59] V4L: ov9640: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/ov9640.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ov9640.c b/drivers/media/video/ov9640.c
index 3681a6f..4156c9f 100644
--- a/drivers/media/video/ov9640.c
+++ b/drivers/media/video/ov9640.c
@@ -25,9 +25,11 @@
#include linux/slab.h
#include linux/delay.h
#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-chip-ident.h
#include media/v4l2-common.h
-#include media/soc_camera.h
#include ov9640.h
@@ -722,6 +724,22 @@ static struct v4l2_subdev_core_ops ov9640_core_ops = {
};
+static int ov9640_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
+ V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops ov9640_video_ops = {
.s_stream = ov9640_s_stream,
.s_mbus_fmt = ov9640_s_fmt,
@@ -729,7 +747,7 @@ static struct v4l2_subdev_video_ops ov9640_video_ops = {
.enum_mbus_fmt = ov9640_enum_fmt,
.cropcap= ov9640_cropcap,
.g_crop = ov9640_g_crop,
-
+ .g_mbus_config = ov9640_g_mbus_config,
};
static struct v4l2_subdev_ops ov9640_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/59] V4L: mt9m111: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m111.c | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c
index a357aa8..c2fe5c9 100644
--- a/drivers/media/video/mt9m111.c
+++ b/drivers/media/video/mt9m111.c
@@ -14,9 +14,10 @@
#include linux/gpio.h
#include linux/delay.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-common.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/*
* MT9M111, MT9M112 and MT9M131:
@@ -1016,6 +1017,22 @@ static int mt9m111_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int mt9m111_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ cfg-flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops mt9m111_subdev_video_ops = {
.s_mbus_fmt = mt9m111_s_fmt,
.g_mbus_fmt = mt9m111_g_fmt,
@@ -1024,6 +1041,7 @@ static struct v4l2_subdev_video_ops
mt9m111_subdev_video_ops = {
.g_crop = mt9m111_g_crop,
.cropcap= mt9m111_cropcap,
.enum_mbus_fmt = mt9m111_enum_fmt,
+ .g_mbus_config = mt9m111_g_mbus_config,
};
static struct v4l2_subdev_ops mt9m111_subdev_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/59] V4L: mt9m001: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/mt9m001.c | 40 +++-
1 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index 4da9cca..7618b3c 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -13,9 +13,10 @@
#include linux/i2c.h
#include linux/log2.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
#include media/v4l2-subdev.h
#include media/v4l2-chip-ident.h
-#include media/soc_camera.h
/*
* mt9m001 i2c address 0x5d
@@ -710,6 +711,41 @@ static int mt9m001_enum_fmt(struct v4l2_subdev *sd,
unsigned int index,
return 0;
}
+static int mt9m001_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ /* MT9M001 has all capture_format parameters fixed */
+ cfg-flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
+ V4L2_MBUS_HSYNC_ACTIVE_HIGH | V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_DATA_ACTIVE_HIGH | V4L2_MBUS_MASTER;
+ cfg-type = V4L2_MBUS_PARALLEL;
+ cfg-flags = soc_camera_apply_board_flags(icl, cfg);
+
+ return 0;
+}
+
+static int mt9m001_s_mbus_config(struct v4l2_subdev *sd,
+ const struct v4l2_mbus_config *cfg)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+ unsigned int bps =
soc_mbus_get_fmtdesc(icd-current_fmt-code)-bits_per_sample;
+
+ if (icl-set_bus_param)
+ return icl-set_bus_param(icl, 1 (bps - 1));
+
+ /*
+* Without board specific bus width settings we only support the
+* sensors native bus width
+*/
+ return bps == 10 ? 0 : -EINVAL;
+}
+
static struct v4l2_subdev_video_ops mt9m001_subdev_video_ops = {
.s_stream = mt9m001_s_stream,
.s_mbus_fmt = mt9m001_s_fmt,
@@ -719,6 +755,8 @@ static struct v4l2_subdev_video_ops
mt9m001_subdev_video_ops = {
.g_crop = mt9m001_g_crop,
.cropcap= mt9m001_cropcap,
.enum_mbus_fmt = mt9m001_enum_fmt,
+ .g_mbus_config = mt9m001_g_mbus_config,
+ .s_mbus_config = mt9m001_s_mbus_config,
};
static struct v4l2_subdev_sensor_ops mt9m001_subdev_sensor_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/59] V4L: imx074: support the new mbus-config subdev ops
Extend the driver to also support [gs]_mbus_config() subdevice video
operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/imx074.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/imx074.c b/drivers/media/video/imx074.c
index 0382ea7..63f17aa 100644
--- a/drivers/media/video/imx074.c
+++ b/drivers/media/video/imx074.c
@@ -267,6 +267,17 @@ static int imx074_g_chip_ident(struct v4l2_subdev *sd,
return 0;
}
+static int imx074_g_mbus_config(struct v4l2_subdev *sd,
+ struct v4l2_mbus_config *cfg)
+{
+ cfg-type = V4L2_MBUS_CSI2;
+ cfg-flags = V4L2_MBUS_CSI2_2_LANE |
+ V4L2_MBUS_CSI2_CHANNEL_0 |
+ V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+
+ return 0;
+}
+
static struct v4l2_subdev_video_ops imx074_subdev_video_ops = {
.s_stream = imx074_s_stream,
.s_mbus_fmt = imx074_s_fmt,
@@ -275,6 +286,7 @@ static struct v4l2_subdev_video_ops imx074_subdev_video_ops
= {
.enum_mbus_fmt = imx074_enum_fmt,
.g_crop = imx074_g_crop,
.cropcap= imx074_cropcap,
+ .g_mbus_config = imx074_g_mbus_config,
};
static struct v4l2_subdev_core_ops imx074_subdev_core_ops = {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/59] Convert soc-camera to .[gs]_mbus_config() subdev operations
This patch-series converts all soc-camera client and host drivers and the
core from soc-camera specific .{query,set}_bus_param() operations to the
new .[gs]_mbus_config() subdev operations. In order to prevent bisect
breakage we first have to only add new methods to client drivers, then
convert all host drivers, taking care to preserve platform compatibility,
and only then soc-camera methods can be removed. These patches are also
available as a git branch:
git://linuxtv.org/gliakhovetski/v4l-dvb.git mbus-config
Tested on i.MX31, PXA270, SuperH, mach-shmobile. Compile-tested on many
others. Reviews and tests welcome!:-)
Sorry for a slightly longish set;-)
Thanks
Guennadi
Guennadi Liakhovetski (59):
V4L: sh_mobile_ceu_camera: output image sizes must be a multiple of 4
V4L: sh_mobile_ceu_camera: don't try to improve client scaling, if
perfect
V4L: sh_mobile_ceu_camera: fix field addresses in interleaved mode
V4L: sh_mobile_ceu_camera: remove duplicated code
V4L: imx074: support the new mbus-config subdev ops
V4L: soc-camera: add helper functions for new bus configuration type
V4L: mt9m001: support the new mbus-config subdev ops
V4L: mt9m111: support the new mbus-config subdev ops
V4L: mt9t031: support the new mbus-config subdev ops
V4L: mt9t112: support the new mbus-config subdev ops
V4L: mt9v022: support the new mbus-config subdev ops
V4L: ov2640: support the new mbus-config subdev ops
V4L: ov5642: support the new mbus-config subdev ops
V4L: ov6650: support the new mbus-config subdev ops
V4L: ov772x: rename macros to not pollute the global namespace
V4L: ov772x: support the new mbus-config subdev ops
V4L: ov9640: support the new mbus-config subdev ops
V4L: ov9740: support the new mbus-config subdev ops
V4L: rj54n1cb0c: support the new mbus-config subdev ops
ARM: ap4evb: switch imx074 configuration to default number of lanes
V4L: sh_mobile_csi2: verify client compatibility
V4L: sh_mobile_csi2: support the new mbus-config subdev ops
V4L: tw9910: remove a not really implemented cropping support
V4L: tw9910: support the new mbus-config subdev ops
V4L: soc_camera_platform: support the new mbus-config subdev ops
V4L: soc-camera: compatible bus-width flags
ARM: mach-shmobile: convert mackerel to mediabus flags
sh: convert ap325rxa to mediabus flags
ARM: PXA: use gpio_set_value_cansleep() on pcm990
V4L: atmel-isi: convert to the new mbus-config subdev operations
V4L: mx1_camera: convert to the new mbus-config subdev operations
V4L: mx2_camera: convert to the new mbus-config subdev operations
V4L: ov2640: remove undefined struct
V4L: mx3_camera: convert to the new mbus-config subdev operations
V4L: mt9m001, mt9v022: add a clarifying comment
V4L: omap1_camera: convert to the new mbus-config subdev operations
V4L: pxa_camera: convert to the new mbus-config subdev operations
V4L: sh_mobile_ceu_camera: convert to the new mbus-config subdev
operations
V4L: soc-camera: camera client operations no longer compulsory
V4L: mt9m001: remove superfluous soc-camera client operations
V4L: mt9m111: remove superfluous soc-camera client operations
V4L: imx074: remove superfluous soc-camera client operations
V4L: mt9t031: remove superfluous soc-camera client operations
V4L: mt9t112: remove superfluous soc-camera client operations
V4L: mt9v022: remove superfluous soc-camera client operations
V4L: ov2640: remove superfluous soc-camera client operations
V4L: ov5642: remove superfluous soc-camera client operations
V4L: ov6650: remove superfluous soc-camera client operations
sh: ap3rxa: remove redundant soc-camera platform data fields
sh: migor: remove unused ov772x buswidth flag
V4L: ov772x: remove superfluous soc-camera client operations
V4L: ov9640: remove superfluous soc-camera client operations
V4L: ov9740: remove superfluous soc-camera client operations
V4L: rj54n1cb0c: remove superfluous soc-camera client operations
V4L: sh_mobile_csi2: remove superfluous soc-camera client operations
ARM: mach-shmobile: mackerel doesn't need legacy SOCAM_* flags
anymore
V4L: soc_camera_platform: remove superfluous soc-camera client
operations
V4L: tw9910: remove superfluous soc-camera client operations
V4L: soc-camera: remove soc-camera client bus-param operations and
supporting code
arch/arm/mach-pxa/pcm990-baseboard.c |4 +-
arch/arm/mach-shmobile/board-ap4evb.c |2 +-
arch/arm/mach-shmobile/board-mackerel.c|7 +-
arch/sh/boards/mach-ap325rxa/setup.c | 10 +-
arch/sh/boards/mach-migor/setup.c |4 +-
drivers/media/video/atmel-isi.c| 136 ---
drivers/media/video/imx074.c | 36 ++---
drivers/media/video/mt9m001.c | 87 +-
drivers/media/video/mt9m111.c | 37 ++--
drivers/media/video/mt9t031.c | 64
drivers/media/video/mt9t112.c | 115
[PATCH 03/59] V4L: sh_mobile_ceu_camera: fix field addresses in interleaved mode
In interlaced interleaved mode field offset for deinterlacing depends
on the pixel format.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
drivers/media/video/sh_mobile_ceu_camera.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index 407b96a..a322f83 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -267,6 +267,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
unsigned long top1, top2;
unsigned long bottom1, bottom2;
u32 status;
+ bool planar;
int ret = 0;
/*
@@ -314,17 +315,29 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev
*pcdev)
phys_addr_top = vb2_dma_contig_plane_paddr(pcdev-active, 0);
- ceu_write(pcdev, top1, phys_addr_top);
- if (V4L2_FIELD_NONE != pcdev-field) {
- phys_addr_bottom = phys_addr_top + icd-user_width;
- ceu_write(pcdev, bottom1, phys_addr_bottom);
- }
-
switch (icd-current_fmt-host_fmt-fourcc) {
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV61:
+ planar = true;
+ break;
+ default:
+ planar = false;
+ }
+
+ ceu_write(pcdev, top1, phys_addr_top);
+ if (V4L2_FIELD_NONE != pcdev-field) {
+ if (planar)
+ phys_addr_bottom = phys_addr_top + icd-user_width;
+ else
+ phys_addr_bottom = phys_addr_top +
+ soc_mbus_bytes_per_line(icd-user_width,
+
icd-current_fmt-host_fmt);
+ ceu_write(pcdev, bottom1, phys_addr_bottom);
+ }
+
+ if (planar) {
phys_addr_top += icd-user_width *
icd-user_height;
ceu_write(pcdev, top2, phys_addr_top);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to support for HAUPPAUGE HVR-930C
2011/7/28 Benjamin Larsson benja...@southpole.se: 0x82 is the address of the chip handling the analog signals(?) Micronas AVF 4910BA1 maybe. I don't have the schematic of hauppauge card, so I can't say you if 082 is the AVF 4910 So change the names so it is clear that this part sends commands to that chip. As I already told my patch is a derivate work of Terratec H5 Patch. Mauro's patch should have the same issue I'm not sure I understand the I2C addressing but my tuner is at 0xc2 and the demod at 0x52. I hate binary operation however if you shift the address you should get same value... 0x52 = 0x29 1 0x29 = 0x52 1 Eddi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mx2_camera driver on mx27ipcam: dma_alloc_coherent size failed
Hello Jan, On Fri, Jul 29, 2011 at 12:14:09PM +0200, Jan Pohanka wrote: which repository should I search 90026c8c823bff54172eab33a5e7fcecfd3df635 in? I have not found it in git.pengutronix.de/git/imx/linux-2.6.git nor in vanilla sources. Seems my copy'n'paste foo isn't optimal. Commit dca7c0b4293a06d1ed9387e729a4882896abccc2 is the relevant, it's in vanilla. http://git.kernel.org/linus/dca7c0b4293a06d1ed9387e729a4882896abccc2 Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH for v3.1] v4l2-ioctl: fix ENOTTY handling.
Hi all,
While converting v4l2-compliance to correctly handle ENOTTY errors I found
several regressions in v4l2-ioctl.c:
1) VIDIOC_ENUM/G/S/TRY_FMT would return -ENOTTY if the op for the particular
format type was not set, even though the op for other types might have been
present. In such a case -EINVAL should have been returned.
2) The priority check could cause -EBUSY or -EINVAL to be returned instead of
-ENOTTY if the corresponding ioctl was unsupported.
3) Certain ioctls that have an internal implementation (ENUMSTD, G_STD, S_STD,
G_PARM and the extended control ioctls) could return -EINVAL when -ENOTTY
should have been returned or vice versa.
I first tried to fix this by adding extra code for each affected ioctl, but
that made the code rather ugly.
So I ended up with this code that first checks whether a certain ioctl is
supported or not and returns -ENOTTY if not.
Comments?
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ioctl.c | 466 +++---
1 files changed, 289 insertions(+), 177 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 002ce13..6a5062a 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -542,13 +542,14 @@ static long __video_do_ioctl(struct file *file,
void *fh = file-private_data;
struct v4l2_fh *vfh = NULL;
struct v4l2_format f_copy;
+ bool have_op;
int use_fh_prio = 0;
- long ret = -ENOTTY;
+ long ret = -EINVAL;
if (ops == NULL) {
printk(KERN_WARNING videodev: \%s\ has no ioctl_ops.\n,
vfd-name);
- return ret;
+ return -ENOTTY;
}
if ((vfd-debug V4L2_DEBUG_IOCTL)
@@ -562,6 +563,275 @@ static long __video_do_ioctl(struct file *file,
use_fh_prio = test_bit(V4L2_FL_USE_FH_PRIO, vfd-flags);
}
+ switch (cmd) {
+ case VIDIOC_QUERYCAP:
+ have_op = ops-vidioc_querycap;
+ break;
+ case VIDIOC_G_PRIORITY:
+ have_op = ops-vidioc_g_priority || use_fh_prio;
+ break;
+ case VIDIOC_S_PRIORITY:
+ have_op = ops-vidioc_s_priority || use_fh_prio;
+ break;
+ case VIDIOC_ENUM_FMT:
+ have_op = ops-vidioc_enum_fmt_vid_cap ||
+ ops-vidioc_enum_fmt_vid_out ||
+ ops-vidioc_enum_fmt_vid_cap_mplane ||
+ ops-vidioc_enum_fmt_vid_out_mplane ||
+ ops-vidioc_enum_fmt_vid_overlay ||
+ ops-vidioc_enum_fmt_type_private;
+ break;
+ case VIDIOC_G_FMT:
+ have_op = ops-vidioc_g_fmt_vid_cap ||
+ ops-vidioc_g_fmt_vid_out ||
+ ops-vidioc_g_fmt_vid_cap_mplane ||
+ ops-vidioc_g_fmt_vid_out_mplane ||
+ ops-vidioc_g_fmt_vbi_cap ||
+ ops-vidioc_g_fmt_vid_overlay ||
+ ops-vidioc_g_fmt_vid_out_overlay ||
+ ops-vidioc_g_fmt_vbi_out ||
+ ops-vidioc_g_fmt_sliced_vbi_cap ||
+ ops-vidioc_g_fmt_sliced_vbi_out ||
+ ops-vidioc_g_fmt_type_private;
+ break;
+ case VIDIOC_S_FMT:
+ have_op = ops-vidioc_s_fmt_vid_cap ||
+ ops-vidioc_s_fmt_vid_out ||
+ ops-vidioc_s_fmt_vid_cap_mplane ||
+ ops-vidioc_s_fmt_vid_out_mplane ||
+ ops-vidioc_s_fmt_vbi_cap ||
+ ops-vidioc_s_fmt_vid_overlay ||
+ ops-vidioc_s_fmt_vid_out_overlay ||
+ ops-vidioc_s_fmt_vbi_out ||
+ ops-vidioc_s_fmt_sliced_vbi_cap ||
+ ops-vidioc_s_fmt_sliced_vbi_out ||
+ ops-vidioc_s_fmt_type_private;
+ break;
+ case VIDIOC_TRY_FMT:
+ have_op = ops-vidioc_try_fmt_vid_cap ||
+ ops-vidioc_try_fmt_vid_out ||
+ ops-vidioc_try_fmt_vid_cap_mplane ||
+ ops-vidioc_try_fmt_vid_out_mplane ||
+ ops-vidioc_try_fmt_vbi_cap ||
+ ops-vidioc_try_fmt_vid_overlay ||
+ ops-vidioc_try_fmt_vid_out_overlay ||
+ ops-vidioc_try_fmt_vbi_out ||
+ ops-vidioc_try_fmt_sliced_vbi_cap ||
+ ops-vidioc_try_fmt_sliced_vbi_out ||
+ ops-vidioc_try_fmt_type_private;
+ break;
+ case VIDIOC_REQBUFS:
+ have_op = ops-vidioc_reqbufs;
+ break;
+ case VIDIOC_QUERYBUF:
+
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
All right, it works like a charm for me. It took me a bit to figure out that binning and skipping is controlled through ratio between cropping window size and actual format size but it is clear now. Just one thing; both VFLIP (this one is my fault) and HFLIP controls change the pixel format of the image and it no longer is GRBG. Given the following example image: G R G R B G B G If we apply VFLIP we'll have: B G B G G R G R And if we apply HFLIP we'll have: R G R G G B G B I am not sure how we could solve this issue, maybe through adjusting row and column start... In any case the driver is OK for me and the issue with VFLIP and HFLIP could be solved later on. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATH v2] cxd2820r: fix possible out-of-array lookup
On 07/29/2011 09:57 AM, HoP wrote:
When I2C_WRITE is used the msg[] array contains one element only.
Don't access msg[1] in that case. Also moved rest of msg2[1]
setting to be used only if needed.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
Acked-by: Antti Palosaari cr...@iki.fi
---
diff -r ae517614bf00 drivers/media/dvb/frontends/cxd2820r_core.c
--- a/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 15:44:49
2011 +0200
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c Thu Jul 28 16:20:17
2011 +0200
@@ -747,12 +747,7 @@ static int cxd2820r_tuner_i2c_xfer(struc
.flags = 0,
.len = sizeof(obuf),
.buf = obuf,
- }, {
- .addr = priv-cfg.i2c_address,
- .flags = I2C_M_RD,
- .len = msg[1].len,
- .buf = msg[1].buf,
- }
+ },
};
obuf[0] = 0x09;
@@ -760,6 +755,11 @@ static int cxd2820r_tuner_i2c_xfer(struc
if (num == 2) { /* I2C read */
obuf[1] = (msg[0].addr 1) | I2C_M_RD; /* I2C RD flag */
msg2[0].len = sizeof(obuf) - 1; /* maybe HW bug ? */
+
+ msg2[1].addr = priv-cfg.i2c_address,
+ msg2[1].flags = I2C_M_RD,
+ msg2[1].len = msg[1].len,
+ msg2[1].buf = msg[1].buf,
}
memcpy(obuf[2], msg[0].buf, msg[0].len);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to support for HAUPPAUGE HVR-930C
On 07/29/2011 02:15 PM, Eddi De Pieri wrote: 2011/7/28 Benjamin Larsson benja...@southpole.se: 0x82 is the address of the chip handling the analog signals(?) Micronas AVF 4910BA1 maybe. I don't have the schematic of hauppauge card, so I can't say you if 082 is the AVF 4910 Rather few Linux devels have those but generally it is rather easy to guess. Just look addresses from sniff, then you have driver working you can read and write to chip and try to see what happens. I'm not sure I understand the I2C addressing but my tuner is at 0xc2 and the demod at 0x52. I hate binary operation however if you shift the address you should get same value... 0x52 = 0x29 1 0x29 = 0x52 1 I2C uses 7 bit addressing and thus 0x29 is correct. Many times address like 0x52 is called as 8 bit I2C address even in chip documents. Anyhow, 0x29 is correct, also (0x52 1) can be used. I encourage to use .i2c_addr = 0x29; /* 0x52 1 */ to make clear which is 8 bit since 8bit is almost always seen in usb logs. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9p031: Aptina (Micron) MT9P031 5MP sensor driver
Hi Javier, On Friday 29 July 2011 14:31:12 javier Martin wrote: All right, it works like a charm for me. It took me a bit to figure out that binning and skipping is controlled through ratio between cropping window size and actual format size but it is clear now. Just one thing; both VFLIP (this one is my fault) and HFLIP controls change the pixel format of the image and it no longer is GRBG. Given the following example image: G R G R B G B G If we apply VFLIP we'll have: B G B G G R G R And if we apply HFLIP we'll have: R G R G G B G B I am not sure how we could solve this issue, maybe through adjusting row and column start... That's probably the easiest solution, yes. In any case the driver is OK for me and the issue with VFLIP and HFLIP could be solved later on. OK. Thanks for the review. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic
On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.
Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 51a23f4..666d4bb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -928,10 +928,6 @@ out:
static void rc_dev_release(struct device *device)
{
- struct rc_dev *dev = to_rc_dev(device);
-
- kfree(dev);
- module_put(THIS_MODULE);
}
Since this function become a no-op, does it make sense to just remove it
and not set a .release function for static struct device_type rc_dev_type?
Other than that, after reading through the patch several times, along with
the resulting rc-main.c and some input code, everything seems to make
sense to me. Will do some quick sanity-testing with a few of my various
devices before I give an ack though, just to be sure. :)
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to support for HAUPPAUGE HVR-930C
On Fri, Jul 29, 2011 at 7:15 AM, Eddi De Pieri e...@depieri.net wrote: 2011/7/28 Benjamin Larsson benja...@southpole.se: 0x82 is the address of the chip handling the analog signals(?) Micronas AVF 4910BA1 maybe. I don't have the schematic of hauppauge card, so I can't say you if 082 is the AVF 4910 Yes, it's an avf4910b. I did a Linux driver for the AVFA for the Viewcast boards, but there isn't a driver for the AFVB at this time. Should be pretty easy for you to whip one up though just by capturing the register sets under Windows and then replaying them for each of the three inputs. Devin So change the names so it is clear that this part sends commands to that chip. As I already told my patch is a derivate work of Terratec H5 Patch. Mauro's patch should have the same issue I'm not sure I understand the I2C addressing but my tuner is at 0xc2 and the demod at 0x52. Correct: the xc5000 is at 0xc2, the avf4910b is at 0x82 and the drx-k is at 0x52. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jul 29 19:00:34 CEST 2011 git hash:fc9a876efa9c41f208dcac1de9ad79e118c91670 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.0] media updates for v3.1
Em 29-07-2011 17:01, Alina Friedrichsen escreveu: Hi Mauro, please include your patch cx23885-dvb: Fix demod IF. It works fine! Yes, I saw your email. Thanks for testing! I'll submit it on the next patch series. Before sending upstream, we first merge on our tree, and then send to linux-next tree. The patches I've sent today are the ones I've prepared 2 days ago for merge. Also, as this patch fixes a bug that exists on the previous versions, it should also be c/c to sta...@kernel.org, in order to get it backported to 3.0 and a few other stable versions. Thanks! Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trying to support for HAUPPAUGE HVR-930C
On Fri, Jul 29, 2011 at 02:10:25PM -0400, Devin Heitmueller wrote: Yes, it's an avf4910b. I did a Linux driver for the AVFA for the Viewcast boards, but there isn't a driver for the AFVB at this time. Do you have a contact at Trident I can ask to get access to that data sheet? I have been looking for it for some time now as well. And do you know if there are significant differences between the avf4910a and the avf4910b? Daniel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic
On Jul 29, 2011, at 1:30 PM, Jarod Wilson wrote:
On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.
Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 51a23f4..666d4bb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -928,10 +928,6 @@ out:
static void rc_dev_release(struct device *device)
{
-struct rc_dev *dev = to_rc_dev(device);
-
-kfree(dev);
-module_put(THIS_MODULE);
}
Since this function become a no-op, does it make sense to just remove it
and not set a .release function for static struct device_type rc_dev_type?
Nope, that leads to this:
[ 765.095926] [ cut here ]
[ 765.098076] WARNING: at /home/jarod/src/linux-ir/drivers/base/core.c:143
device_release+0x73/0x7f()
[ 765.100215] Hardware name: empty
[ 765.102343] Device 'rc0' does not have a release() function, it is broken
and must be fixed.
Which may or not be bogus. But I've got a hanging modprobe -r em28xx-dvb
with this change in place. Now to test with it rolled back...
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic
Em 29-07-2011 14:30, Jarod Wilson escreveu:
On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.
Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 51a23f4..666d4bb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -928,10 +928,6 @@ out:
static void rc_dev_release(struct device *device)
{
-struct rc_dev *dev = to_rc_dev(device);
-
-kfree(dev);
-module_put(THIS_MODULE);
}
Since this function become a no-op, does it make sense to just remove it
and not set a .release function for static struct device_type rc_dev_type?
As you tested, this function needs to exist... well, other drivers sometimes
do the same, by defining it as a no-op function.
Other than that, after reading through the patch several times, along with
the resulting rc-main.c and some input code, everything seems to make
sense to me. Will do some quick sanity-testing with a few of my various
devices before I give an ack though, just to be sure. :)
Thanks! Yeah, a test with other devices is welcome, as we don't want fix for one
and break for the others ;)
The logic there looks simple, but it is, in fact, tricky, especially since
drivers may have polling tasks running, and they need to be cancelled before
freeing the resources.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] rc-main: Fix device de-registration logic
On Jul 29, 2011, at 5:25 PM, Mauro Carvalho Chehab wrote:
Em 29-07-2011 14:30, Jarod Wilson escreveu:
On Jul 29, 2011, at 1:53 AM, Mauro Carvalho Chehab wrote:
rc unregister logic were deadly broken, preventing some drivers to
be removed. Among the broken things, rc_dev_uevent() is being called
during device_del(), causing a data filling on an area that it is
not ready anymore.
Also, some drivers have a stop callback defined, that needs to be called
before data removal, as it stops data polling.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 51a23f4..666d4bb 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -928,10 +928,6 @@ out:
static void rc_dev_release(struct device *device)
{
- struct rc_dev *dev = to_rc_dev(device);
-
- kfree(dev);
- module_put(THIS_MODULE);
}
Since this function become a no-op, does it make sense to just remove it
and not set a .release function for static struct device_type rc_dev_type?
As you tested, this function needs to exist... well, other drivers sometimes
do the same, by defining it as a no-op function.
Other than that, after reading through the patch several times, along with
the resulting rc-main.c and some input code, everything seems to make
sense to me. Will do some quick sanity-testing with a few of my various
devices before I give an ack though, just to be sure. :)
Thanks! Yeah, a test with other devices is welcome, as we don't want fix for
one
and break for the others ;)
Done. Checked out mceusb, redrat3 and imon, all show no ill effects.
The logic there looks simple, but it is, in fact, tricky, especially since
drivers may have polling tasks running, and they need to be cancelled before
freeing the resources.
Indeed. Took a bit to wrap my head around it all, but I think I got it.
Acked-by: Jarod Wilson ja...@redhat.com
--
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
Hi Hans, On Wed, Jul 27, 2011 at 23:56, Hans Verkuil hverk...@xs4all.nl wrote: On Thursday, July 28, 2011 06:11:38 Pawel Osciak wrote: Hi Guennadi, On Wed, Jul 20, 2011 at 01:43, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- snip This looks nicer, I like how we got rid of destroy and gave up on making holes, it would've given us a lot of headaches. I'm thinking about some issues though and also have some comments/questions further below. Already mentioned by others mixing of REQBUFS and CREATE_BUFS. Personally I'd like to allow mixing, including REQBUFS for non-zero, because I think it would be easy to do. I think it could work in the same way as REQBUFS for !=0 works currently (at least in vb2), if we already have some buffers allocated and they are not in use, we free them and a new set is allocated. So I guess it could just stay this way. REQBUFS(0) would of course free everything. Passing format to CREATE_BUFS will make vb2 a bit format-aware, as it would have to pass it forward to the driver somehow. The obvious way would be just vb2 calling the driver's s_fmt handler, but that won't work, as you can't pass indexes to s_fmt. So we'd have to implement a new driver callback for setting formats per index. I guess there is no way around it, unless we actually take the format struct out of CREATE_BUFS and somehow do it via S_FMT. The single-planar structure is full already though, the only way would be to use v4l2_pix_format_mplane instead with plane count = 1 (or more if needed). I just got an idea for this: use TRY_FMT. That will do exactly what you want. In fact, perhaps we should remove the format struct from CREATE_BUFS and use __u32 sizes[VIDEO_MAX_PLANES] instead. Let the application call TRY_FMT and initialize the sizes array instead of putting that into vb2. We may need a num_planes field as well. If the sizes are all 0 (or num_planes is 0), then the driver can use the current format, just as it does with REQBUFS. Or am I missing something? I'm not sure I'm following. Could you give a usage example? Do you mean we want the application to: - SET_FMT and REQBUFS for normal buffers - TRY_FMT and CREATE_BUFS for additional buffers? I'm still not clear how would driver know for which set of buffers the *_FMT is being called... I'm pretty sure I'm misunderstanding your idea though... Another thing is the case of passing size to CREATE_BUFS. vb2, when allocating buffers, gets their sizes from the driver (via queue_setup), it never suggest any particular size. So that flow would have to be changed as well. I guess vb2 could pass the size to queue_setup in a similar way as it does with buffer count. This would mean though that the ioctl would fail if the driver didn't agree to the given size. Right now I don't see an option to negotiate the size with the driver via this option. I think the driver can always increase the size if needed and return the new size. Right, this can easily be done in vb2. But if we do that, it will introduce asymmetry with REQBUFS. For SET_FMT/TRY_FMT+REQBUFS the driver would only be able to adjust buffer sizes on *_FMT, while with *_FMT+CREATE_BUFS it could do that for both calls. Why do we need an additional chance to adjust? Or am I misunderstanding your suggestion? The more I think of it though, why do we need the size argument? It's not needed in the existing flows (that use S_FMT) and, more importantly, I don't think the application can know more than the driver can, so why giving that option? The driver should know the size for a format at least as well as the application... Also, is there a real use case of providing just size, will the driver know which format to use given a size? There are cases where you want a larger buffer size than the format really required. The most common case being 1920x1080 formats where you want to capture in a 1920x1088 buffer (since 1088 is a multiple of 16 and is more suitable for MPEG et al encoding). So, yes, you do want the option to set the size explicitly. Yes, that's true, but my point is in the current API it works too, because the driver can adjust the size on TRY/S_FMT. Even though the application knows that 1088 is needed instead of 1080, shouldn't the driver know it as well (or actually, know even better than the app) and be able to adjust? So when we CREATE_BUFS, the driver can adjust the format struct (or if we somehow use *_FMT for CREATE_BUFS buffers, it could adjust the size there). Sorry, I still can't see why we need an explicit size argument... snip I'm probably forgetting something, but why would we want to
