Asking advice for Camera/ISP driver framework design
Dear guys, I'm currently working on a camera/ISP Linux driver project.Of course,I want it to be a V4L2 driver,but I got a problem about how to design the driver framework. let me introduce the background of this ISP(Image signal processor) a little bit. 1.The ISP has two output paths,first one called main path which is used to transfer image data for taking picture and recording,the other one called preview path which is used to transfer image data for previewing. 2.the two paths have the same image data input from sensor,but their outputs are different,the output of main path is high quality and larger image,while the output of preview path is smaller image. 3.the two output paths have independent DMA engines used to move image data to system memory. The problem is currently, the V4L2 framework seems only support one buffer queue,and in my case,obviously,two buffer queues are required. Any idea/advice for implementing such kind of V4L2 driver? or any other better solutions? Thanks a lot! Cliff -- 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 4/4] v4l2: add blackfin capture bridge driver
I think, the direct use of vb2_plane_cookie() is discouraged. vb2_dma_contig_plane_dma_addr() should work for you. I guess you mean vb2_dma_contig_plane_paddr no, in the current kernel it's vb2_dma_contig_plane_dma_addr(). See http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.2 my git repo is http://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git branch is v4l_for_linus Is this the official git repo or in linuxtv.org? My patch is against 3.1 not 3.2. -- 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: recursive locking problem
On Wed, Sep 14, 2011 at 04:03:58AM +0300, Antti Palosaari wrote: On 09/09/2011 02:46 PM, Daniel Glöckner wrote: On Thu, Sep 08, 2011 at 07:34:32PM +0300, Antti Palosaari wrote: I am working with AF9015 I2C-adapter lock. I need lock I2C-bus since there is two tuners having same I2C address on same bus, demod I2C gate is used to select correct tuner. Would it be possible to use the i2c-mux framework to handle this? Each tuner will then have its own i2c bus. Interesting idea, but it didn't worked. It deadlocks. I think it locks since I2C-mux is controlled by I2C switch in same I2C bus, not GPIO or some other HW. Take a look at drivers/i2c/muxes/pca954x.c. You need to use parent-algo-master_xfer/smbus_xfer directly as the lock that protects you from having both gates open is the lock of the root i2c bus. 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: Question about USB interface index restriction in gspca
On Tue, 13 Sep 2011 21:14:28 +0200 Frank Schäfer fschaefer@googlemail.com wrote: I have a question about the following code in gspca.c: in function gspca_dev_probe(...): ... /* the USB video interface must be the first one */ if (dev-config-desc.bNumInterfaces != 1 intf-cur_altsetting-desc.bInterfaceNumber != 0) return -ENODEV; ... Is there a special reason for not allowing devices with USB interface index 0 for video ? I'm experimenting with a device that has the video interface at index 3 and two audio interfaces at index 0 and 1 (index two is missing !). And the follow-up question: can we assume that all device handled by the gspca-driver have vendor specific video interfaces ? Then we could change the code to ... /* the USB video interface must be of class vendor */ if (intf-cur_altsetting-desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC) return -ENODEV; ... Hi Frank, For webcam devices, the interface class is meaningful only when set to USB_CLASS_VIDEO (UVC). Otherwise, I saw many different values. For video on a particular interface, the subdriver must call the function gspca_dev_probe2() as this is done in spca1528 and xirlink_cit. Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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 4/4] v4l2: add blackfin capture bridge driver
+static int bcap_qbuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_fh *fh = file-private_data;
+ struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
+
+ if (!bcap_fh-io_allowed)
+ return -EACCES;
I suppose -EBUSY would be more appropriate here.
no, io_allowed is to control which file instance has the right to do I/O.
+ fmt =bcap_formats[i];
+ if (mbus_code)
+ *mbus_code = fmt-mbus_code;
+ if (bpp)
+ *bpp = fmt-bpp;
+ v4l2_fill_mbus_format(mbus_fmt, pixfmt,
+ fmt-mbus_code);
+ ret = v4l2_subdev_call(bcap-sd, video,
+ try_mbus_fmt,mbus_fmt);
+ if (ret 0)
+ return ret;
+ v4l2_fill_pix_format(pixfmt,mbus_fmt);
+ pixfmt-bytesperline = pixfmt-width * fmt-bpp;
+ pixfmt-sizeimage = pixfmt-bytesperline
+ * pixfmt-height;
Still pixfmt-pixelformat isn't filled.
no here pixfmt-pixelformat is passed in
+ return 0;
+ }
+ }
+ return -EINVAL;
I think you should return some default format, rather than giving up
when the fourcc doesn't match. However I'm not 100% sure this is
the specification requirement.
no, there is no default format for bridge driver because it knows
nothing about this.
all the format info bridge needs ask subdevice.
+static const struct ppi_ops ppi_ops = {
+ .attach_irq = ppi_attach_irq,
+ .detach_irq = ppi_detach_irq,
+ .start = ppi_start,
+ .stop = ppi_stop,
+ .set_params = ppi_set_params,
+ .update_addr = ppi_update_addr,
+};
How about moving this struct to the bottom of the file and getting rid of
all the above forward declarations ?
I'd like to put global varible before function in a file.
+
+void delete_ppi_instance(struct ppi_if *ppi)
+{
+ peripheral_free_list(ppi-info-pin_req);
+ kfree(ppi);
+}
As a side note, I was not sure if this is just a resend of your original
patches or a second version. It would be good to indicate that in the message
subject. I think it's not a big deal and makes the reviewers' life easier.
if I don't add a version number in subject, it means it is the first version.
--
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: [uclinux-dist-devel] [PATCH 4/4] v4l2: add blackfin capture bridge driver
i think at least these three are unused and should get punted
+static int __devinit bcap_probe(struct platform_device *pdev)
+{
+ struct bcap_device *bcap_dev;
+ struct video_device *vfd;
+ struct i2c_adapter *i2c_adap;
you need to include linux/i2c.h for this
no, bfin_capture.h already contains this.
--
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: [uclinux-dist-devel] [PATCH 4/4] v4l2: add blackfin capture bridge driver
On Wed, 14 Sep 2011, Scott Jiang wrote:
i think at least these three are unused and should get punted
+static int __devinit bcap_probe(struct platform_device *pdev)
+{
+ struct bcap_device *bcap_dev;
+ struct video_device *vfd;
+ struct i2c_adapter *i2c_adap;
you need to include linux/i2c.h for this
no, bfin_capture.h already contains this.
It doesn't matter. You're supposed to _explicitly_ include every header,
that is required to build your code.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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: [uclinux-dist-devel] [PATCH 3/4] v4l2: add vs6624 sensor driver
+#ifdef CONFIG_VIDEO_ADV_DEBUG just use DEBUG ? no, v4l2 use CONFIG_VIDEO_ADV_DEBUG + v4l_info(client, chip found @ 0x%02x (%s)\n, + client-addr 1, client-adapter-name); is that 1 correct ? i dont think so ... every driver under media I see use this, so what's wrong? -- 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: Asking advice for Camera/ISP driver framework design
2011/9/14 Cliff Cai cliffcai...@gmail.com: Dear guys, I'm currently working on a camera/ISP Linux driver project.Of course,I want it to be a V4L2 driver,but I got a problem about how to design the driver framework. let me introduce the background of this ISP(Image signal processor) a little bit. 1.The ISP has two output paths,first one called main path which is used to transfer image data for taking picture and recording,the other one called preview path which is used to transfer image data for previewing. 2.the two paths have the same image data input from sensor,but their outputs are different,the output of main path is high quality and larger image,while the output of preview path is smaller image. 3.the two output paths have independent DMA engines used to move image data to system memory. The problem is currently, the V4L2 framework seems only support one buffer queue,and in my case,obviously,two buffer queues are required. Any idea/advice for implementing such kind of V4L2 driver? or any other better solutions? Thanks a lot! Cliff -- 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 Your chip seems like davinci isp, only difference is dma. So you can reference davinci drivers. If dma interrupt doesn't happen at the same time, I guess you must wait because source image is the same. Scott -- 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: Compro U680F USB stick receiver for FM/DAB/DAB+/DVB-T.
Hi, Antti, Thanks for taking the time to answer my request. However, I am afraid I am not able to find the vendor drivers you mention - if I had I would not have posted about it. No matter how much time I spend scouring the Compro website I can only find Windows drivers - nothing about linux If you know where they are located could you please mail me a link? BR Erik. Quoting Antti Palosaari cr...@iki.fi: On 09/14/2011 01:31 AM, Erik Dam wrote: I recently came across this interesting little USB device which seems the so far best bet on covering all the relevant standards for these parts of the woods (although it still misses out on DVB-T2 support). However, I have so far been unable to determine whether any level of linux support exists (and therefore whether it's useful or not). Anybody know if drivers exist? According to properties it must be Realtek RTL2832U based. It is only chip can do FM/DAB+/DVB-T. There is no community supported drivers but vendor drivers exits. Try those. 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 v4] V4L: dynamically allocate video_device nodes in subdevices
Hi Guennadi,
On 09/13/2011 11:18 PM, Guennadi Liakhovetski wrote:
On Tue, 13 Sep 2011, Sylwester Nawrocki wrote:
On 09/13/2011 04:48 PM, Guennadi Liakhovetski wrote:
Currently only very few drivers actually use video_device nodes, embedded
in struct v4l2_subdev. Allocate these nodes dynamically for those drivers
to save memory for the rest.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
I have tested this patch with Samsung FIMC driver and with MC enabled
sensor driver.
After some hundreds of module load/unload I didn't observe anything unusual.
The patch seem to be safe for device node enabled subdevs. You can stick my:
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
if you feel so.
Thanks very much for testing! However, depending on your test scenario,
you might still not notice a problem by just loading and unloading of
modules. It would, however, be useful to execute just one test:
1. add one line v4l2-device.c:
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index a3b89f4..33226857 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -195,6 +195,7 @@ EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
static void v4l2_device_release_subdev_node(struct video_device *vdev)
{
struct v4l2_subdev *sd = video_get_drvdata(vdev);
+ dev_info(vdev-dev, %s()\n, __func__);
sd-devnode = NULL;
kfree(vdev);
}
2. with this patch start and stop capture
3. check dmesg - v4l2_device_release_subdev_node() output should not be
there yet
4. rmmod modules, then the output should be there
If you could test that - that would be great!
OK, I double checked if v4l2_device_release_subdev_node() is called at the right
time, i.e. I've also checked if the streaming works in between the module
unload/load.
I'd added the printk and everything behaved as expected, other than I've tracked
down a few minor bugs in the drivers in the meantime;)
I'll keep your patch applied in my development tree.
Thanks,
--
Sylwester Nawrocki
Samsung Poland RD Center
--
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: recursive locking problem
On 09/14/2011 09:19 AM, Daniel Glöckner wrote: On Wed, Sep 14, 2011 at 04:03:58AM +0300, Antti Palosaari wrote: On 09/09/2011 02:46 PM, Daniel Glöckner wrote: On Thu, Sep 08, 2011 at 07:34:32PM +0300, Antti Palosaari wrote: I am working with AF9015 I2C-adapter lock. I need lock I2C-bus since there is two tuners having same I2C address on same bus, demod I2C gate is used to select correct tuner. Would it be possible to use the i2c-mux framework to handle this? Each tuner will then have its own i2c bus. Interesting idea, but it didn't worked. It deadlocks. I think it locks since I2C-mux is controlled by I2C switch in same I2C bus, not GPIO or some other HW. Take a look at drivers/i2c/muxes/pca954x.c. You need to use parent-algo-master_xfer/smbus_xfer directly as the lock that protects you from having both gates open is the lock of the root i2c bus. Ah yes, rather similar case. I see it as commented in pca954x.c: /* Write to mux register. Don't use i2c_transfer()/i2c_smbus_xfer() for this as they will try to lock adapter a second time */ This looks even more hackish solution than calling existing demod .i2c_gate_ctrl() callback from USB-interface driver. But yes, it must work - not beautiful but workable workaround. 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: How to handle different media bus format and actual video output format in soc camera?
On 14 September 2011 12:34, javier Martin javier.mar...@vista-silicon.com wrote: Hi, I'm trying to add support for YUV420 format to mx2_camera.c soc-camera host driver. In my system, an imx27_visstrim_m10 board, this host is connected to a tvp5151 chip which is only able to transfer pixels in this format through the media bus: V4L2_MBUS_FMT_YUYV8_2X8. However, imx27 eMMa has the possibility to get this data from the bus and convert it to a YUV420 format on the fly. What is the right way to handle this properly in soc-camera? I've been analyzing some code related to the matter and it seems soc_camera_xlate_by_fourcc() [1] only supports raw formats from the sensor [2]. OK, I think I found a good example of this in the pxa driver. I post it here just in case someone has the same problem in a future: http://lxr.linux.no/#linux+v3.0.4/drivers/media/video/pxa_camera.c#L1246 -- 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: recursive locking problem
On Wed, Sep 14, 2011 at 01:45:47PM +0300, Antti Palosaari wrote: Interesting idea, but it didn't worked. It deadlocks. I think it locks since I2C-mux is controlled by I2C switch in same I2C bus, not GPIO or some other HW. Take a look at drivers/i2c/muxes/pca954x.c. You need to use parent-algo-master_xfer/smbus_xfer directly as the lock that protects you from having both gates open is the lock of the root i2c bus. Ah yes, rather similar case. I see it as commented in pca954x.c: /* Write to mux register. Don't use i2c_transfer()/i2c_smbus_xfer() for this as they will try to lock adapter a second time */ This looks even more hackish solution than calling existing demod .i2c_gate_ctrl() callback from USB-interface driver. But yes, it must work - not beautiful but workable workaround. This is not a hack. This is the official way to do it. The I2C mux framework was designed to allow multiplexers controlled through the same I2C bus. 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 4/4] v4l2: add blackfin capture bridge driver
On 09/14/2011 09:10 AM, Scott Jiang wrote:
+static int bcap_qbuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_fh *fh = file-private_data;
+ struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
+
+ if (!bcap_fh-io_allowed)
+ return -EACCES;
I suppose -EBUSY would be more appropriate here.
no, io_allowed is to control which file instance has the right to do I/O.
Looks like you are doing here what the v4l2 priority mechanism is meant for.
Have you considered the access priority (VIDIOC_G_PRIORITY/VIDIOC_S_PRIORITY
and friends)? Does it have any shortcomings?
+ fmt =bcap_formats[i];
+ if (mbus_code)
+ *mbus_code = fmt-mbus_code;
+ if (bpp)
+ *bpp = fmt-bpp;
+ v4l2_fill_mbus_format(mbus_fmt, pixfmt,
+ fmt-mbus_code);
+ ret = v4l2_subdev_call(bcap-sd, video,
+ try_mbus_fmt,mbus_fmt);
+ if (ret 0)
+ return ret;
+ v4l2_fill_pix_format(pixfmt,mbus_fmt);
+ pixfmt-bytesperline = pixfmt-width * fmt-bpp;
+ pixfmt-sizeimage = pixfmt-bytesperline
+ * pixfmt-height;
Still pixfmt-pixelformat isn't filled.
no here pixfmt-pixelformat is passed in
+ return 0;
+ }
+ }
+ return -EINVAL;
I think you should return some default format, rather than giving up
when the fourcc doesn't match. However I'm not 100% sure this is
the specification requirement.
no, there is no default format for bridge driver because it knows
nothing about this.
all the format info bridge needs ask subdevice.
It's the bridge driver that exports a device node and is responsible for
setting the default format. It should be possible to start streaming right
after opening the device, without VIDIOC_S_FMT, with some reasonable defaults.
If, as you say, the bridge knows nothing about formats what the bcap_formats[]
array is here for ?
+static const struct ppi_ops ppi_ops = {
+ .attach_irq = ppi_attach_irq,
+ .detach_irq = ppi_detach_irq,
+ .start = ppi_start,
+ .stop = ppi_stop,
+ .set_params = ppi_set_params,
+ .update_addr = ppi_update_addr,
+};
How about moving this struct to the bottom of the file and getting rid of
all the above forward declarations ?
I'd like to put global varible before function in a file.
+
+void delete_ppi_instance(struct ppi_if *ppi)
+{
+ peripheral_free_list(ppi-info-pin_req);
+ kfree(ppi);
+}
As a side note, I was not sure if this is just a resend of your original
patches or a second version. It would be good to indicate that in the message
subject. I think it's not a big deal and makes the reviewers' life easier.
if I don't add a version number in subject, it means it is the first version.
Sorry, please ignore this. I got confused by the mailer and thought the same
patches appeared twice on the list.
Thanks,
--
Sylwester Nawrocki
Samsung Poland RD Center
--
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] arm: omap: Fix build error in ispccdc.c
Ping? On Tue, Sep 06, 2011 at 10:02:15AM -0400, Joerg Roedel wrote: The following build error occurs with 3.1-rc5: CC drivers/media/video/omap3isp/ispccdc.o /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c: In function 'ccdc_lsc_config': /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c:427:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration] /home/data/repos/linux.trees.git/drivers/media/video/omap3isp/ispccdc.c:427:6: warning: assignment makes pointer from integer without a cast [enabled by default] This patch adds the missing 'linux/slab.h' include to fix the problem. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- drivers/media/video/omap3isp/ispccdc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c index 9d3459d..80796eb 100644 --- a/drivers/media/video/omap3isp/ispccdc.c +++ b/drivers/media/video/omap3isp/ispccdc.c @@ -31,6 +31,7 @@ #include linux/dma-mapping.h #include linux/mm.h #include linux/sched.h +#include linux/slab.h #include media/v4l2-event.h #include isp.h -- 1.7.4.1 -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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] arm: omap: Fix build error in ispccdc.c
Mauro, On Wednesday 14 September 2011 17:33:03 Roedel, Joerg wrote: Ping? I've acked the patch on September the 6th and asked in the e-mail if you could pick it and push it to v3.1. Is there anything else I need to do ? -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Sep 14 19:00:33 CEST 2011 git hash:2d04c13a507f5a01daa7422cd52250809573cfdb gcc version: i686-linux-gcc (GCC) 4.6.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: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS 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-3.0-i686: WARNINGS linux-3.1-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS 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 linux-3.0-x86_64: WARNINGS linux-3.1-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [PATCH] mmp_camera: add MODULE_ALIAS
On Wed, 7 Sep 2011 10:36:46 +0100 (BST) Daniel Drake d...@laptop.org wrote: This enables module autoloading. Signed-off-by: Daniel Drake d...@laptop.org No objections here, consider it acked. Mauro: as far as I'm concerned, Daniel can be considered a co-maintainer of the OLPC camera drivers. I'm not planning to forget about them, and I'll certainly still look at patches, but please don't ever hold up something from him if (as has, on very rare occasion, been known to happen) I get a little slow. Thanks, jon -- 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 4/4] v4l2: add blackfin capture bridge driver
2011/9/14 Sylwester Nawrocki s.nawro...@samsung.com:
On 09/14/2011 09:10 AM, Scott Jiang wrote:
+static int bcap_qbuf(struct file *file, void *priv,
+ struct v4l2_buffer *buf)
+{
+ struct bcap_device *bcap_dev = video_drvdata(file);
+ struct v4l2_fh *fh = file-private_data;
+ struct bcap_fh *bcap_fh = container_of(fh, struct bcap_fh, fh);
+
+ if (!bcap_fh-io_allowed)
+ return -EACCES;
I suppose -EBUSY would be more appropriate here.
no, io_allowed is to control which file instance has the right to do I/O.
Looks like you are doing here what the v4l2 priority mechanism is meant for.
Have you considered the access priority (VIDIOC_G_PRIORITY/VIDIOC_S_PRIORITY
and friends)? Does it have any shortcomings?
I refer to davinci driver, perhaps it is not good enough, I'd like to
modify it later.
+ fmt =bcap_formats[i];
+ if (mbus_code)
+ *mbus_code = fmt-mbus_code;
+ if (bpp)
+ *bpp = fmt-bpp;
+ v4l2_fill_mbus_format(mbus_fmt, pixfmt,
+ fmt-mbus_code);
+ ret = v4l2_subdev_call(bcap-sd, video,
+ try_mbus_fmt,mbus_fmt);
+ if (ret 0)
+ return ret;
+ v4l2_fill_pix_format(pixfmt,mbus_fmt);
+ pixfmt-bytesperline = pixfmt-width * fmt-bpp;
+ pixfmt-sizeimage = pixfmt-bytesperline
+ * pixfmt-height;
Still pixfmt-pixelformat isn't filled.
no here pixfmt-pixelformat is passed in
+ return 0;
+ }
+ }
+ return -EINVAL;
I think you should return some default format, rather than giving up
when the fourcc doesn't match. However I'm not 100% sure this is
the specification requirement.
no, there is no default format for bridge driver because it knows
nothing about this.
all the format info bridge needs ask subdevice.
It's the bridge driver that exports a device node and is responsible for
setting the default format. It should be possible to start streaming right
after opening the device, without VIDIOC_S_FMT, with some reasonable defaults.
If, as you say, the bridge knows nothing about formats what the bcap_formats[]
array is here for ?
accually this array is to convert mbus to pixformat. ppi supports any formats.
Ideally it should contain all formats in v4l2, but it is enough at
present for our platform.
If I find someone needs more, I will add it.
So return -EINVAL means this format is out of range, it can't be supported now.
about default format, I think I can only call bcap_g_fmt_vid_cap in
probe to get this info.
Dose anybody have a better solution?
--
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
