[PATCH resend] video: omap24xxcam: Fix compilation
Add linux/sched.h because of missing declaration of TASK_NORMAL. This patch fixes the following error: drivers/media/video/omap24xxcam.c: In function 'omap24xxcam_vbq_complete': drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/omap24xxcam.c:415: error: (Each undeclared identifier is reported only once drivers/media/video/omap24xxcam.c:415: error: for each function it appears in.) Signed-off-by: Thomas Weber we...@corscience.de --- drivers/media/video/omap24xxcam.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap24xxcam.c b/drivers/media/video/omap24xxcam.c index 0175527..f6626e8 100644 --- a/drivers/media/video/omap24xxcam.c +++ b/drivers/media/video/omap24xxcam.c @@ -36,6 +36,7 @@ #include linux/clk.h #include linux/io.h #include linux/slab.h +#include linux/sched.h #include media/v4l2-common.h #include media/v4l2-ioctl.h -- 1.7.4.rc3 -- 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: WL1273 FM Radio driver...
Hello. Mark Brown wrote: On Wed, Feb 02, 2011 at 01:35:01PM -0200, Mauro Carvalho Chehab wrote: [Reflowed into 80 columns.] My concerns is that the V4L2-specific part of the code should be at drivers/media. I prefer that the specific MFD I/O part to be at drivers/mfd, just like the other drivers. Currently that's not the case - the I/O functionality is not in any meaningful sense included in the MFD, it's provided by the V4L portion. I've been away for two and a half weeks so I haven't been able to comment... But before I start to make changes, I'd still like to ask for a comment on my original plan, which was to have the I/O functions in the MFD driver and also have there things like interrupt handling etc. My vision was that the MFD part would have the application logic and the child drivers would be just true interfaces to the core functionality, because I kind of saw the children to be of equal importance and because the codec and the v4l2 driver share some controls like for example the volume control. If you'd care to take a look an earlier version of the MFD driver here: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/23602/match=aaltonen So the question is if I put only the I/O stuff into the MFD driver or can I have the other application logic there as well? Thanks, Matti -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Sat, 5 Feb 2011, Anatolij Gustschin wrote: On Sat, 5 Feb 2011 17:36:37 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... Verified with both capture.c and mplayer. Could you, please, verify whether you get the same behaviour and what the problem could be? Now I did some further testing with idmac patch applied and with added debug print in the IDMAC interrupt handler. There is no problem. Testing with capture.c (4 buffers used as default) shows that buffer numbers toggle correctly for all 100 captured frames: Hm, interesting, I'll have to look at my testing in more detail then (once back from FOSDEM). Could you maybe try mplayer too? I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. 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: [PATCH 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? Thanks, Anatolij -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. 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
[PATCH v4] Add support for M5MO-LS 8 Mega Pixel camera
Add I2C/V4L2 subdev driver for M5MO-LS camera sensor with integrated
image processor.
Signed-off-by: Heungjun Kim riverful@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Hello,
This is fourth version of M5MOLS 8 Mega Pixel camera sensor.
The fourth version changes are below:
1. combine splitted i2c_transfer functions to single I2C operation
2. remove unneeded checking for control values
3. fix some typos and code clean
The third version changes are below:
1. the method to writing register accordint to state value
2. changing mdelay to usleep_range because of not hogging
The second versions changes are below:
1. remove I2C function macro, and use static inline for type-safe.
2. use the v4l2 control framework documented at v4l2-control.txt.
3. Add regulator enable/disable functions
4. fix any coding problems
The first version patch is here:
http://www.spinics.net/lists/linux-media/msg26246.html
This driver is tested on s5pc210 board using s5p-fimc driver.
Thanks for any ideas.
Regards,
Heungjun Kim
Samsung Electronics DMC RD Center
---
drivers/media/video/Kconfig |2 +
drivers/media/video/Makefile |1 +
drivers/media/video/m5mols/Kconfig |6 +
drivers/media/video/m5mols/Makefile |3 +
drivers/media/video/m5mols/m5mols.h | 233 +++
drivers/media/video/m5mols/m5mols_controls.c | 165 +
drivers/media/video/m5mols/m5mols_core.c | 911 ++
drivers/media/video/m5mols/m5mols_reg.h | 103 +++
include/media/m5mols.h | 31 +
9 files changed, 1455 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/m5mols/Kconfig
create mode 100644 drivers/media/video/m5mols/Makefile
create mode 100644 drivers/media/video/m5mols/m5mols.h
create mode 100644 drivers/media/video/m5mols/m5mols_controls.c
create mode 100644 drivers/media/video/m5mols/m5mols_core.c
create mode 100644 drivers/media/video/m5mols/m5mols_reg.h
create mode 100644 include/media/m5mols.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d40a8fc..6a03aad 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,6 +746,8 @@ config VIDEO_NOON010PC30
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
+source drivers/media/video/m5mols/Kconfig
+
config SOC_CAMERA
tristate SoC camera support
depends on VIDEO_V4L2 HAS_DMA I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 251b7ca..adb9361 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
diff --git a/drivers/media/video/m5mols/Kconfig
b/drivers/media/video/m5mols/Kconfig
new file mode 100644
index 000..425732b
--- /dev/null
+++ b/drivers/media/video/m5mols/Kconfig
@@ -0,0 +1,6 @@
+config VIDEO_M5MOLS
+ tristate Fujitsu M5MO-LS 8MP sensor support
+ depends on I2C VIDEO_V4L2
+ ---help---
+ 혻This driver supports Fujitsu M5MO-LS camera sensor with ISP
+
diff --git a/drivers/media/video/m5mols/Makefile
b/drivers/media/video/m5mols/Makefile
new file mode 100644
index 000..b5d19bf
--- /dev/null
+++ b/drivers/media/video/m5mols/Makefile
@@ -0,0 +1,3 @@
+m5mols-objs:= m5mols_core.o m5mols_controls.o
+
+obj-$(CONFIG_VIDEO_M5MOLS) += m5mols.o
diff --git a/drivers/media/video/m5mols/m5mols.h
b/drivers/media/video/m5mols/m5mols.h
new file mode 100644
index 000..3b4f6e8
--- /dev/null
+++ b/drivers/media/video/m5mols/m5mols.h
@@ -0,0 +1,233 @@
+/*
+ * Header for M5MOLS 8M Pixel camera sensor with ISP
+ *
+ * Copyright (C) 2011 Samsung Electronics Co., Ltd
+ * Author: HeungJun Kim, riverful@samsung.com
+ *
+ * Copyright (C) 2009 Samsung Electronics Co., Ltd
+ * Author: Dongsoo Nathaniel Kim, dongsoo45@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef M5MOLS_H
+#define M5MOLS_H
+
+#include media/v4l2-subdev.h
+#include m5mols_reg.h
+
+#define v4l2msg(fmt, arg...) do {\
+ v4l2_dbg(1, m5mols_debug, info-sd, fmt, ## arg); \
+} while (0)
+
+extern int m5mols_debug;
+
+enum m5mols_mode {
+ MODE_SYSINIT,
+ MODE_PARMSET,
+ MODE_MONITOR,
+ MODE_UNKNOWN,
+};
+
+enum m5mols_i2c_size {
Re: WL1273 FM Radio driver...
On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. -- 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/5] uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
Hi Stephan, On Monday 31 January 2011 20:05:24 Stephan Lachowsky wrote: On Fri, 2011-01-07 at 08:00 -0800, Laurent Pinchart wrote: From: Martin Rubli martin_ru...@logitech.com This ioctl extends UVCIOC_CTRL_GET/SET by not only allowing to get/set XU controls but to also send arbitrary UVC commands to XU controls, namely GET_CUR, SET_CUR, GET_MIN, GET_MAX, GET_RES, GET_LEN, GET_INFO and GET_DEF. This is required for applications to work with XU controls, so that they can properly query the size and allocate the necessary buffers. Signed-off-by: Martin Rubli martin_ru...@logitech.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com I think that this is a great improvement to the existing ioctls, but I'd like some feedback on the vacuum around bUnitID. The XU descriptor basically associates a unique address (bUnitID) with a specific extension unit (guidExtensionCode). It is the GUID that specifies the semantics of the control, and bUnitID simply provides routing to a specific instance. Now, the ioctls as currently implemented are very flexible, but I feel that there should be some mechanism for discovering the bUnitID(s) associated with a specific guidExtensionCode. Currently there is no way to do this: you must either dead reckon the bUnitID value, or parse the USB descriptors in user space to come up with the value needed for UVCIOC_CTRL_GET/SET/QUERY (UVCIOC_CTRL_MAP matches on the GUID, which makes bUnitID opaque to the user). I think this functionality has been missed in the dynctrl ioctls since their inception. As UVC XU controls are standardized it is inevitable that different vendors will implement the same control with different bUnitID values. I propose that we add something along the lines of UVCIOC_CTRL_ENUM to enumerate through the XUs so that userspace can simply discover the guidExtensionCode - bUnitID mappings that exist on the specific device (or any other type of XU reporting they wish). I would be willing to implement the patch provided I get some feedback that this functionality belongs in the driver. We had implemented something similar prior to just using to UVCIOC_CTRL_MAP'ings. My current plan is to use the media controller API for this. All UVC entities would be mapped to media controller entities, and a new ioctl (not available yet) will be used to retrieve driver-specific entity details. -- 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: WL1273 FM Radio driver...
Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: saa7134, em28xx, cx231xx, etc. The audio drivers for them are also under /drivers/media, as it is not easy to de-couple audio and video/radio part on those devices. For bttv and some USB boards (that use snd-usb-audio), the audio part is at /sound, as the audio part on them are independent and don't need to share anything, as audio is provided by a completely independent group of registers. I suggest to use the same logic for wl1273. 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 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Hi Guennadi, How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Is this a real usage scenario? It feels that this is not what most users will do and it certainly is not relevant for our application. Is it possible that if you are interested in such a scenario that you do the testing? We have spent quite a lot of time to fix the driver for real (well full frame) capturing already and I am relucatant to spend more time for corner cases. Maybe we should document this as known limitations of the setup? What do you think? I'll much rather have a driver working for real world scenarios than for marginal test cases. Thanks Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.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: WL1273 FM Radio driver...
On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: There is an audio driver for this chip and it is using those functions. -- 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: WL1273 FM Radio driver...
On Mon, 2011-02-07 at 10:48 -0200, ext Mauro Carvalho Chehab wrote: Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: saa7134, em28xx, cx231xx, etc. The audio drivers for them are also under /drivers/media, as it is not easy to de-couple audio and video/radio part on those devices. For bttv and some USB boards (that use snd-usb-audio), the audio part is at /sound, as the audio part on them are independent and don't need to share anything, as audio is provided by a completely independent group of registers. I suggest to use the same logic for wl1273. So you are suggesting a more or less complete rewrite, so that I'd create a directory like media/radio/wl1273 and then place there all of the driver files: wl1273-radio.c, wl1273-alsa.c and maybe wl1273-core.c? Cheers, Matti 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 -- 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: WL1273 FM Radio driver...
On Mon, Feb 07, 2011 at 03:27:12PM +0200, Matti J. Aaltonen wrote: So you are suggesting a more or less complete rewrite, so that I'd create a directory like media/radio/wl1273 and then place there all of the driver files: wl1273-radio.c, wl1273-alsa.c and maybe wl1273-core.c? Don't move the ASoC driver out of the ASoC code, it's a complete pain for maintaining it and only makes the problems with having to build v4l worse. -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Hi Detlev On Mon, 7 Feb 2011, Detlev Zundel wrote: Hi Guennadi, How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Is this a real usage scenario? It feels that this is not what most users will do and it certainly is not relevant for our application. QVGA at 25 / 50 / 60 fps is _certainly_ very much a real-life scenario. Is it possible that if you are interested in such a scenario that you do the testing? We have spent quite a lot of time to fix the driver for real (well full frame) capturing already and I am relucatant to spend more time for corner cases. Maybe we should document this as known limitations of the setup? What do you think? I'll much rather have a driver working for real world scenarios than for marginal test cases. I am interested in avoiding regressions. In principle, this is a DMA driver, which I am not maintaining. Dan asked for my ack, so, I tested it and found an issue, which I would prefer to have resolved before committing. Of course, I don't have a decisive voice in this matter, so, the patch can also be merged without my ack. Otherwise - of course you don't have to continue testing, I will try to look at the issue as the time permits, and Dan will have to decide, whether he is prepared to commit this patch in its present form, or he would prefer this issue to be clarified. 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: [PATCH 2/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011 12:35:44 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Testing of 960x243 frames at 30 fps has been done during all my previous tests. I didn't see any issues at 30 fps. Anatolij -- 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: WL1273 FM Radio driver...
Em 07-02-2011 11:10, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? 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: WL1273 FM Radio driver...
On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 11:10, Mark Brown escreveu: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?). Note that due to the decomposed nature of embedded audio hardware the audio part of the chip needs to be represended within the audio subsystem even if the control were all in the media side - this isn't an isolated bit of hardware on an expansion card, it's fairly tightly coupled into the rest of the system. -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:35:44 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Testing of 960x243 frames at 30 fps has been done during all my previous tests. I didn't see any issues at 30 fps. Thanks for the clarification. You certainly realise, that your frame is 3 times as large as mine. Sorry for not mentioning this before, I do appreciate your effort, and have a generally positive feeling at least regarding your IDMAC patch, but I don't want to just trust my feeling, that's why I tried to study the patch a bit more carefully. I also understand that you don't have infinite time to dedicate to this work. Neither do I. So, I will try as good as I can to try to find out the reason for this behaviour, any help from your side is greatly appreciated. But if we don't clarify this before the 2.6.39 merge window, I'm not sure, whether it would be smart to commit the patch as is. 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: WL1273 FM Radio driver...
On Mon, 2011-02-07 at 11:48 -0200, ext Mauro Carvalho Chehab wrote: Em 07-02-2011 11:10, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? There's the MFD driver driver/mfd/wl1273-core.c, which is to offer the (I2C) I/O functions to the child drivers: drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c. Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done... Matti 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: WL1273 FM Radio driver...
On Mon, 2011-02-07 at 13:52 +, ext Mark Brown wrote: On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 11:10, Mark Brown escreveu: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?). Yes, nothing's been merged yet. There are only dependencies between the parts of this driver... I cannot comment on upcoming boards, I just hope we could agree on a sensible structure for this thing. Matti. -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
Hi Guennadi, Hi Detlev On Mon, 7 Feb 2011, Detlev Zundel wrote: Hi Guennadi, How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Is this a real usage scenario? It feels that this is not what most users will do and it certainly is not relevant for our application. QVGA at 25 / 50 / 60 fps is _certainly_ very much a real-life scenario. Yes, sure. It was the 64x48 pixel you suggested which I believe to be of doubtful value here. Is it possible that if you are interested in such a scenario that you do the testing? We have spent quite a lot of time to fix the driver for real (well full frame) capturing already and I am relucatant to spend more time for corner cases. Maybe we should document this as known limitations of the setup? What do you think? I'll much rather have a driver working for real world scenarios than for marginal test cases. I am interested in avoiding regressions. In principle, this is a DMA driver, which I am not maintaining. Dan asked for my ack, so, I tested it and found an issue, which I would prefer to have resolved before committing. Of course, I don't have a decisive voice in this matter, so, the patch can also be merged without my ack. Otherwise - of course you don't have to continue testing, I will try to look at the issue as the time permits, and Dan will have to decide, whether he is prepared to commit this patch in its present form, or he would prefer this issue to be clarified. I'm fully in line with not wanting any regressions. But is it a regression if two independent testers report that the patch _improves_ the current situation? As was shown by Anatolijs log, the current driver certainly has a bug with respect to the handling of individual frames. This buggy behaviour only never showed up because nobody used the driver on such a granularity. We certainly appreciate if you can look into your scenario. Thanks Detlev -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.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: WL1273 FM Radio driver...
Em 07-02-2011 12:09, Matti J. Aaltonen escreveu: On Mon, 2011-02-07 at 11:48 -0200, ext Mauro Carvalho Chehab wrote: Em 07-02-2011 11:10, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:48:03AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 10:02, Mark Brown escreveu: On Mon, Feb 07, 2011 at 10:00:16AM -0200, Mauro Carvalho Chehab wrote: the MFD part (for example, wl1273_fm_read_reg/wl1273_fm_write_cmd/wl1273_fm_write_data). The logic that are related to control the radio (wl1273_fm_set_audio, wl1273_fm_set_volume, etc) are not related to access the device via the MFD bus. They should be at the media part of the driver, where they belong. Those functions are being used by the audio driver. Not sure if I understood your comments. Several media drivers have alsa drivers: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? There's the MFD driver driver/mfd/wl1273-core.c, which is to offer the (I2C) I/O functions to the child drivers: drivers/media/radio/radio-wl1273.c and sound/soc/codecs/wl1273.c. Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done... I think that the better would be to move the audio part (sound/soc/codecs/wl1273.c) as drivers/media/radio/wl1273/wl1273-alsa.c. Is there any problem on moving it, or the alsa driver is also tightly coupled on the rest of the sound/soc stuff? I remember that, in the past, there were someone that proposed to move /sound into /media/sound, and move some common stuff between them into /media/common. Btw, there are(where?) some problems between -alsa and -media subsystems: basically, the audio core needs to be initialized before the drivers. However, this sometimes don't happen (I can't remember the exact situation - perhaps builtin compilations?), but we ended by needing to explicitly delaying the init of some drivers with: late_initcall(saa7134_alsa_init); To avoid some OOPS conditions. Matti 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: WL1273 FM Radio driver...
Em 07-02-2011 12:17, Matti J. Aaltonen escreveu: On Mon, 2011-02-07 at 13:52 +, ext Mark Brown wrote: On Mon, Feb 07, 2011 at 11:48:17AM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 11:10, Mark Brown escreveu: There is an audio driver for this chip and it is using those functions. Where are the other drivers that depend on it? Nothing's been merged yet to my knowledge, Matti can comment on any incoming boards which will use it (rx51?). Yes, nothing's been merged yet. There are only dependencies between the parts of this driver... I cannot comment on upcoming boards, I just hope we could agree on a sensible structure for this thing. We don't need any brand names or specific details, but it would be good to have an overview, in general lines, about the architecture, in order to help you to map how this would fit. In particular, the architecturre of things that are tightly coupled and can't be splitted by some bus abstraction. 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: WL1273 FM Radio driver...
On Mon, Feb 07, 2011 at 01:57:10PM -0200, Mauro Carvalho Chehab wrote: Em 07-02-2011 12:09, Matti J. Aaltonen escreveu: Both children depend on the MFD driver for I/O and the codec also depends on the presence of the radio-wl1273 driver because without the v4l2 part nothing can be done... I think that the better would be to move the audio part (sound/soc/codecs/wl1273.c) as drivers/media/radio/wl1273/wl1273-alsa.c. Is there any problem on moving it, or the alsa driver is also tightly coupled on the rest of the sound/soc stuff? As I said in my previous e-mail it's tightly coupled. I remember that, in the past, there were someone that proposed to move /sound into /media/sound, and move some common stuff between them into /media/common. This is the first embedded audio driver that's had interface with media stuff, the driver situation for embedded audio is very different to that for PCs. Embedded audio subsystems are tightly coupled integrations of many different devices, the sound card userspace sees is produced by coordinating the actions of several different drivers. Btw, there are(where?) some problems between -alsa and -media subsystems: basically, the audio core needs to be initialized before the drivers. However, this sometimes don't happen (I can't remember the exact situation - perhaps builtin compilations?), but we ended by needing to explicitly delaying the init of some drivers with: late_initcall(saa7134_alsa_init); To avoid some OOPS conditions. This isn't a problem for embedded audio, instantiation of the cards is deferred until all the components for the card have registered with the core so nothing will happen until dependencies are satisfied, though it is a problem with the wl1273 driver as it currently stands due to the lack of a functional MFD. -- 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 resend] video: omap24xxcam: Fix compilation
On Mon, 7 Feb 2011 09:49:07 +0100 Thomas Weber wrote: Add linux/sched.h because of missing declaration of TASK_NORMAL. This patch fixes the following error: drivers/media/video/omap24xxcam.c: In function 'omap24xxcam_vbq_complete': drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/omap24xxcam.c:415: error: (Each undeclared identifier is reported only once drivers/media/video/omap24xxcam.c:415: error: for each function it appears in.) Signed-off-by: Thomas Weber we...@corscience.de --- drivers/media/video/omap24xxcam.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Hi, Please use media: or multimedia: or media/video: in the subject line, not just video:. video: traditionally is used for drivers/video/, not drivers/media/video. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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/2 v2] dma: ipu_idmac: do not lose valid received data in the irq handler
On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:35:44 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 7 Feb 2011, Anatolij Gustschin wrote: On Mon, 7 Feb 2011 12:09:15 +0100 (CET) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: ... I can't try mplayer since I don't have mplayer setup for this. But looking at the mplayer source I don't see why it should behave differently. Depending on mode mplayer queues 2 or 6 buffers. Testing with my test app with 6 queued buffers shows no issues, here the buffer numbers toggle correctly, too. Ok, I've done a couple more tests. With larger frames, and, therefore lower fps - yes, with your patch buffers toggle correctly. Whereas in my tests with smaller frames and higher fps either only one buffer is used, or one is used much more often, than the other, e.g., 0 0 0 1 0 0 0 1 0... Could you try to verify? Without your patch with any fps buffers toggle consistently. How small are the frames in you test? What is the highest fps value in your test? QVGA, don't know fps exactly, pretty high, between 20 and 60fps, I think. Just try different frams sizes, go down to 64x48 or something. Testing of 960x243 frames at 30 fps has been done during all my previous tests. I didn't see any issues at 30 fps. Ok, I've found the reason. Buffer number repeats, when there is an underrun, which is happening in my tests, when frames are arriving quickly enough, but the user-space is not fast enough to process them, e.g., when it is writing them to files over NFS or even just displaying on the LCD. Without your patch these underruns happen just as well, they just don't get recognised, because there's always one buffer delayed, so, the queue is never empty. Dan, please add my Reviewed-(and-tested-)by: Guennadi Liakhovetski g.liakhovet...@gmx.de 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
[patch] [media] stv090x: handle allocation failures
kmalloc() can fail so check whether state-internal is NULL.
append_internal() can return NULL on allocation failures so check that.
Also if we hit the error condition later in the function then there is
a memory leak and we need to call remove_dev() to fix it.
Signed-off-by: Dan Carpenter erro...@gmail.com
---
Compile tested only. I'm not very familiar with this code.
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index d3362d0..85101e8 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -4783,7 +4783,13 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
} else {
state-internal = kmalloc(sizeof(struct stv090x_internal),
GFP_KERNEL);
+ if (!state-internal)
+ goto error;
temp_int = append_internal(state-internal);
+ if (!temp_int) {
+ kfree(state-internal);
+ goto error;
+ }
state-internal-num_used = 1;
state-internal-mclk = 0;
state-internal-dev_ver = 0;
@@ -4796,7 +4802,7 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
if (stv090x_setup(state-frontend) 0) {
dprintk(FE_ERROR, 1, Error setting up device);
- goto error;
+ goto err_remove;
}
}
@@ -4811,6 +4817,8 @@ struct dvb_frontend *stv090x_attach(const struct
stv090x_config *config,
return state-frontend;
+err_remove:
+ remove_dev(state-internal);
error:
kfree(state);
return NULL;
--
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: PROBLEM: kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891
Hi The STREAMOFF issue has not appeared after having tested with kernel version 2.6.38-rc2 for a while. I am happy :-) Regards Rune -- We are proud to present our new web-pages at www.aptomar.com Do not miss our video-window to the world; aptotube Rune Sætre rune.sae...@aptomar.com aptomar as www.aptomar.com On Wed, 19 Jan 2011, Rune Saetre wrote: Hi Yes. I will try it out and post a message as soon as I have some experience with it. Regards Rune -- We are proud to present our new web-pages at www.aptomar.com Do not miss our video-window to the world; aptotube Rune Sætre rune.sae...@aptomar.com aptomar as www.aptomar.com On Wed, 19 Jan 2011, Patrik Jakobsson wrote: On 01/18/2011 05:30 PM, Hans Verkuil wrote: On Tuesday, January 18, 2011 17:14:03 Patrik Jakobsson wrote: Hello Rune I'm trying to learn more about the linux kernel so I figured helping with bugs is a good way to get started. On 01/18/2011 02:20 AM, Rune Saetre wrote: Hi The crash is not as consistent as I first believed. I have managed to stop and start capturing several (but not many) times without the driver crashing now. To me it seems that the resource locking (functions res_get, res_check, res_locked and res_free) is subject to race condition. I looked at older versions of the code and found that there used to be locks around some of these pieces. It was removed in commit: 0499a5aa777f8e56e46df362f0bb9d9d116186f9 - V4L/DVB: em28xx: remove BKL Other V4L drivers use pretty much the same code (res_get, res_free, etc.) for resource locking but still have the mutex_lock/unlock around it. Does anyone know why this was removed? Because now the video4linux core does the locking. Anyway, I'm pretty sure this is the bug that was fixed here: http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09413.html This fix will be in 2.6.38. The change in the locking mechanism had nothing to do this particular bug. It was just incorrect administration of resources. Regards, Hans Thanks for the explanation. I see now how the V4L core locks around the ioctls. The member unlocked_ioctl of struct v4l2_file_operations confused me a little. Maybe serialized_ioctl would be a better name? Not a big issue though. Hopefully the patch fixes your problem Rune. Thanks Patrik Jakobsson Thanks Patrik Jakobsson The trace logs also differ slightly. Here is the last one: Jan 18 02:12:08 mate kernel: [ 117.219326] [ cut here ] Jan 18 02:12:08 mate kernel: [ 117.219412] kernel BUG at drivers/media/video/em28xx/em28xx-video.c:891! Jan 18 02:12:08 mate kernel: [ 117.219507] invalid opcode: [#1] PREEMPT SMP Jan 18 02:12:08 mate kernel: [ 117.219597] last sysfs file: /sys/devices/virtual/block/dm-8/stat Jan 18 02:12:08 mate kernel: [ 117.219681] CPU 1 Jan 18 02:12:08 mate kernel: [ 117.219714] Modules linked in: acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_conservative ppdev lp nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs binfmt_misc fuse dummy bridge stp ext2 mbcache coretemp kvm_intel kvm loop firewire_sbp2 tuner snd_hda_codec_realtek arc4 snd_hda_intel snd_usb_audio snd_hda_codec ecb snd_seq_dummy snd_pcm_oss snd_mixer_oss saa7115 snd_pcm ir_lirc_codec lirc_dev ir_sony_decoder snd_hwdep snd_usbmidi_lib em28xx ir_jvc_decoder ir_rc6_decoder snd_seq_oss snd_seq_midi snd_rawmidi r8169 ir_rc5_decoder mii ir_nec_decoder snd_seq_midi_event i915 v4l2_common iwlagn iwlcore snd_seq ir_core drm_kms_helper drm videobuf_vmalloc snd_timer snd_seq_device videobuf_core pcmcia joydev mac80211 uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 tveeprom cfg80211 rfkill i2c_i801 i2c_algo_bit tpm_tis tpm yenta_socket snd intel_agp shpchp pci_hotplug video output pcmcia_rsrc wmi pcmcia_core soundcore snd_page_alloc parport_pc parport i2c_cor Jan 18 02:12:08 mate kernel: irda tpm_bios intel_gtt pcspkr crc_ccitt psmouse evdev serio_raw container processor battery ac button reiserfs dm_mod raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod ide_cd_mod cdrom sd_mod ata_generic pata_acpi ata_piix crc_t10dif ide_pci_generic ahci libahci sdhci_pci firewire_ohci sdhci libata scsi_mod piix ide_core firewire_core mmc_core uhci_hcd tg3 thermal crc_itu_t thermal_sys ehci_hcd [last unloaded: scsi_wait_scan] Jan 18 02:12:08 mate kernel: [ 117.220091] Jan 18 02:12:08 mate kernel: [ 117.220091] Pid: 3154, comm: camera_factory_ Not tainted 2.6.37-rst #1 Victoria/TravelMate 6292 Jan 18 02:12:08 mate kernel: [ 117.220091] RIP: 0010:[a05a37f4] [a05a37f4] res_free+0x14/0x49 [em28xx] Jan 18 02:12:08 mate kernel: [ 117.220091] RSP: 0018:8800794a1c48 EFLAGS: 00010297 Jan 18 02:12:08 mate kernel: [ 117.220091] RAX: 0001 RBX: 88007b94dc00 RCX: Jan 18 02:12:08 mate kernel: [ 117.220091] RDX: RSI: 8800378e7000 RDI: 88007b94dc00 Jan 18
[cron job] v4l-dvb daily build: WARNINGS
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:Mon Feb 7 19:00:28 CET 2011 git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f git media-master: 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: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: WARNINGS 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.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: OK linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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 00/20] world-writable files in sysfs and debugfs
Thanks, I've applied the x86 platform driver ones. -- Matthew Garrett | mj...@srcf.ucam.org -- 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
soc-camera: vb2 continued: mx3_camera
Hi One more soc-camera host driver has been converted to videobuf2: mx3_camera for i.MX3* SoCs. I also added Anatolij's patches to the branch. Please, review / test. The branch is available at git://linuxtv.org/gliakhovetski/v4l-dvb.git soc_camera-vb2 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: [PATCH v4] Add support for M5MO-LS 8 Mega Pixel camera
Hi HeungJun, On 02/07/2011 12:44 PM, Heungjun Kim wrote: Add I2C/V4L2 subdev driver for M5MO-LS camera sensor with integrated image processor. There is something wrong with this patch. It looks like it got mangled by the mailer. I can see some Korean characters in it and checkpatch.pl returns errors: ERROR: patch seems to be corrupt (line wrapped?) #122: FILE: drivers/media/video/Kconfig:747: =20 ERROR: spaces required around that '=' (ctx:WxV) #208: FILE: drivers/media/video/m5mols/m5mols.h:36: + I2C_8BIT=3D 1, ^ ERROR: spaces required around that '=' (ctx:WxV) #209: FILE: drivers/media/video/m5mols/m5mols.h:37: + I2C_16BIT =3D 2, ^ ERROR: spaces required around that '=' (ctx:WxV) #210: FILE: drivers/media/video/m5mols/m5mols.h:38: + I2C_32BIT =3D 4, ^ ... ERROR: spaces required around that '=' (ctx:WxV) #1500: FILE: drivers/media/video/m5mols/m5mols_core.c:892: + .remove =3D m5mols_remove, ^ ERROR: spaces required around that '=' (ctx:WxV) #1501: FILE: drivers/media/video/m5mols/m5mols_core.c:893: + .id_table =3D m5mols_id, ^ WARNING: please, no space before tabs #1672: FILE: include/media/m5mols.h:23: +* ^I^Ito be called after enabling and before disabling$ total: 344 errors, 6 warnings, 1514 lines checked Regards, Sylwester -- 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] DVB-USB: Remote Control for TwinhanDTV StarBox DVB-S USB and clones
bug fix for Twinhan DTV StarBox USB2.0 DVB-S model no:7021 and clones
remote control stuff will work now
#kernel=2.6.37 highly recommended
Signed-off-by: Tomasz G. Burak tome...@op.pl
---
--- drivers/media/dvb/dvb-usb/vp702x.c.orig 2011-01-05 01:50:19.0 +0100
+++ drivers/media/dvb/dvb-usb/vp702x.c 2011-02-05 17:50:44.000 00 +0100
@@ -175,34 +175,81 @@ static int vp702x_streaming_ctrl(struct
/* keys for the enclosed remote control */
static struct ir_scancode ir_codes_vp702x_table[] = {
- { 0x0001, KEY_1 },
- { 0x0002, KEY_2 },
+ { 0x004d, KEY_SCREEN }, /* Full screen */
+ { 0x0016, KEY_POWER2 }, /* Power */
+ { 0x0003, KEY_1 }, /* 1 */
+ { 0x0001, KEY_2 }, /* 2 */
+ { 0x0006, KEY_3 }, /* 3 */
+ { 0x0009, KEY_4 }, /* 4 */
+ { 0x001d, KEY_5 }, /* 5 */
+ { 0x001f, KEY_6 }, /* 6 */
+ { 0x000d, KEY_7 }, /* 6 */
+ { 0x0019, KEY_8 }, /* 7 */
+ { 0x001b, KEY_9 }, /* 8 */
+ { 0x0011, KEY_RECORD }, /* REC */
+ { 0x0015, KEY_0 }, /* 9 */
+ { 0x0017, KEY_FAVORITES }, /* Heart symbol - Favorite */
+ { 0x0040, KEY_REWIND }, /* Rewind */
+ { 0x0005, KEY_CHANNELUP }, /* CH+ */
+ { 0x0012, KEY_FASTFORWARD }, /* Forward */
+ { 0x000a, KEY_VOLUMEDOWN }, /* VOL- */
+ { 0x0014, KEY_PLAY }, /* Play */
+ { 0x001e, KEY_VOLUMEUP }, /* VOL+ */
+ { 0x000e, KEY_PREVIOUS }, /* Recall */
+ { 0x0002, KEY_CHANNELDOWN }, /* CH- */
+ { 0x001a, KEY_STOP }, /* Stop */
+ { 0x004c, KEY_PAUSE }, /* Time Shift - Pause */
+ { 0x0010, KEY_MUTE }, /* Mute */
+ { 0x000c, KEY_CANCEL }, /* Cancel */
+ { 0x0054, KEY_PRINT }, /* Capture */
+ { 0x0048, KEY_INFO }, /* Preview */
+ { 0x001c, KEY_EPG }, /* EPG */
+ { 0x0004, KEY_LIST }, /* RecordList */
+ { 0x, KEY_TAB }, /* Tab */
+ { 0x000f, KEY_TEXT }, /* Teletext */
+
+ { 0x0041, KEY_PREVIOUSSONG },
+ { 0x0042, KEY_NEXTSONG },
+ { 0x004b, KEY_UP },
+ { 0x0051, KEY_DOWN },
+ { 0x004e, KEY_LEFT },
+ { 0x0052, KEY_RIGHT },
+ { 0x004f, KEY_ENTER },
+ { 0x0054, KEY_AUDIO }, /* MTS - Switch to secondary audio. */
+ { 0x0013, KEY_CANCEL },
+ { 0x004a, KEY_CLEAR },
+ { 0x0043, KEY_SUBTITLE }, /* Subtitle/CC */
+ { 0x0008, KEY_VIDEO }, /* A/V */
+ { 0x0007, KEY_SLEEP }, /* Hibernate */
+ { 0x0045, KEY_ZOOM }, /* Zoom+ */
+ { 0x0018, KEY_RED},
+ { 0x0053, KEY_GREEN},
+ { 0x005e, KEY_YELLOW},
+ { 0x005f, KEY_BLUE}
};
-/* remote control stuff (does not work with my box) */
static int vp702x_rc_query(struct dvb_usb_device *d, u32 *event, int
*state)
{
u8 key[10];
int i;
-/* remove the following return to enabled remote querying */
- return 0;
-
vp702x_usb_in_op(d,READ_REMOTE_REQ,0,0,key,10);
- deb_rc(remote query key: %x %d\n,key[1],key[1]);
+ deb_rc(remote query key: %x %d\n,key[3],key[3]);
if (key[1] == 0x44) {
*state = REMOTE_NO_KEY_PRESSED;
return 0;
}
- for (i = 0; i ARRAY_SIZE(ir_codes_vp702x_table); i++)
- if (rc5_custom(ir_codes_vp702x_table[i]) == key[1]) {
- *state = REMOTE_KEY_PRESSED;
- *event = ir_codes_vp702x_table[i].keycode;
- break;
- }
+ if (key[2] == key[3] + key[4]) {
+ for (i = 0; i ARRAY_SIZE(ir_codes_vp702x_table); i++)
+ if (rc5_data(ir_codes_vp702x_table[i]) == key[3]) {
+ *state = REMOTE_KEY_PRESSED;
+ *event = ir_codes_vp702x_table[i].keycode;
+ break;
+ }
+ }
return 0;
}
--
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] Add support for M5MO-LS 8 Mega Pixel camera
I've checked runnig checkpatch.pl, but I've not seen this message before. And I re-check the patch sent now, but it's not. Probably, It's issue between git send-email and our mail server setting. I'll check once again, and resend. Thanks let me know. Regards Heungjun Kim 2011-02-08 오전 6:45, Sylwester Nawrocki 쓴 글: Hi HeungJun, On 02/07/2011 12:44 PM, Heungjun Kim wrote: Add I2C/V4L2 subdev driver for M5MO-LS camera sensor with integrated image processor. There is something wrong with this patch. It looks like it got mangled by the mailer. I can see some Korean characters in it and checkpatch.pl returns errors: ERROR: patch seems to be corrupt (line wrapped?) #122: FILE: drivers/media/video/Kconfig:747: =20 ERROR: spaces required around that '=' (ctx:WxV) #208: FILE: drivers/media/video/m5mols/m5mols.h:36: + I2C_8BIT=3D 1, ^ ERROR: spaces required around that '=' (ctx:WxV) #209: FILE: drivers/media/video/m5mols/m5mols.h:37: + I2C_16BIT =3D 2, ^ ERROR: spaces required around that '=' (ctx:WxV) #210: FILE: drivers/media/video/m5mols/m5mols.h:38: + I2C_32BIT =3D 4, ^ ... ERROR: spaces required around that '=' (ctx:WxV) #1500: FILE: drivers/media/video/m5mols/m5mols_core.c:892: + .remove =3D m5mols_remove, ^ ERROR: spaces required around that '=' (ctx:WxV) #1501: FILE: drivers/media/video/m5mols/m5mols_core.c:893: + .id_table =3D m5mols_id, ^ WARNING: please, no space before tabs #1672: FILE: include/media/m5mols.h:23: +* ^I^Ito be called after enabling and before disabling$ total: 344 errors, 6 warnings, 1514 lines checked Regards, Sylwester -- 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
