[patch] media/ov511: cleanup: remove unneeded null check
We dereference ov unconditionally throughout the function so there is
no way it can be NULL here. This code has been around for ages so if
it were possible for ov to be NULL someone would have complained.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
index 6085d55..a109120 100644
--- a/drivers/media/video/ov511.c
+++ b/drivers/media/video/ov511.c
@@ -5940,7 +5940,7 @@ ov51x_disconnect(struct usb_interface *intf)
ov-dev = NULL;
/* Free the memory */
- if (ov !ov-user) {
+ if (!ov-user) {
mutex_lock(ov-cbuf_lock);
kfree(ov-cbuf);
ov-cbuf = 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
[patch -next 2/2] media/s2255drv: remove dead code
My concern initially was we dereference dev in the parameter list to
s2255_dev_err() but it turns out that code path is never used.
The s2255_stop_readpipe() is only called from one place and dev is
never null. So this patch just removes the whole condition here.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index ac9c40c..3c7a79f 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -2524,10 +2528,7 @@ static int s2255_stop_acquire(struct s2255_dev *dev,
unsigned long chn)
static void s2255_stop_readpipe(struct s2255_dev *dev)
{
struct s2255_pipeinfo *pipe = dev-pipe;
- if (dev == NULL) {
- s2255_dev_err(dev-udev-dev, invalid device\n);
- return;
- }
+
pipe-state = 0;
if (pipe-stream_urb) {
/* cancel urb */
--
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 -next 1/2] media/s2255drv: return if vdev not found
The original code didn't handle the case where vdev was not found so I
added a check for that.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index ac9c40c..1f9a49e 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
@@ -1716,11 +1716,15 @@ static int s2255_open(struct file *file)
dprintk(1, s2255: open called (dev=%s)\n,
video_device_node_name(vdev));
- for (i = 0; i MAX_CHANNELS; i++)
+ for (i = 0; i MAX_CHANNELS; i++) {
if (dev-vdev[i] == vdev) {
cur_channel = i;
break;
}
+ }
+ if (i == MAX_CHANNELS)
+ return -ENODEV;
+
/*
* open lock necessary to prevent multiple instances
* of v4l-conf (or other programs) from simultaneously
--
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: tm6000 calculating urb buffer
Stefan Ringel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.05.2010 21:50, schrieb Mauro Carvalho Chehab: Stefan Ringel wrote: datagram from urb to videobuf urb copy to temp copy to 1. videobuf buffer2. audiobuf 3. vbi 184 Packets --- 184 * 3072-- 4. etc. a 3072 bytes bytes 184 * 3072 * 3072 bytes 180 bytes (184 bytes - 4 bytes header ) In order to receive 184 packets with 3072 bytes each, the USB code will try to allocate the next power-of-two memory block capable of receiving such data block. As: 184 * 3072 = 565248, the kernel allocator will seek for a continuous block of 1 MB, that can do DMA transfers (required by ehci driver). On a typical machine, due to memory fragmentation, in general, there aren't many of such blocks. So, this will increase the probability of not having any such large block available, causing an horrible dump at kernel, plus a -ENOMEM on the driver, generally requiring a reboot if you want to run the driver again. And direct copy from urb to videobuf/alsa/vbi in 184 Bytes segments. urb 1. videobuf copy to2. audiobuf 3. vbi 184 Packets --- 4. etc. a 3072 bytes 180 Bytes (without headers) That's basically what that logic does. It preserves the header if you select TM6000 format (so, no checks for the start of the block, etc), or copies just the data, if you select YUY2 or UYUV. or how can I copy 180 Bytes Data from 184 Bytes block with an anligment of 184 urb pipe (184 * 3072 Bytes)? A 184 x 3072 URB pipe is a big problem. We used a large pipe in the past, and this won't work. For example, on a notebook I used to run some tests with 1 GB of ram after starting X and do anything (like opening a browser), the URB allocation used to fail, as there weren't any available 1MB segment at the DMA area. Even without starting X, after a few tests, it would eventually have fragmented the memory and the driver stops working. and 3072 * 46 = 141312 bytes and it can through 184 ! it's 1/4 smaller. It is a worthy trial to use this value for the number of packets. Yet, as someone might have run the device on windows before, it will still need to seek for the segment start. 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: tm6000
On Wed, 5 May 2010 13:44:38 +0800 Bee Hock Goh beeh...@gmail.com wrote: Did you comment off the code in the get_next_buff that clear the previous frame data? No. Git tree + my last patch. With my best regards, Dmitry. On Wed, May 5, 2010 at 12:50 PM, Dmitri Belimov d.beli...@gmail.com wrote: Hi At this moment I can start mplayer and see green field with some junk without crash. Info from mplayer - received 497 frames, drop 69 incorrect frames. Compile without support DVB-T for our cards. Now try understand init process working drivers and diff with linux. P.S. Linux kernel is 2.6.33 With my best regards, Dmitry. -- 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
-next: staging/cx25821: please revert 7a02f549fcc
This was my patch: cx25821: fix double unlock in medusa_video_init() It accidentally got merged two times. The version from the staging tree is not correct. Please can you revert it: 7a02f549fcc30fe6be0c0024beae9a3db22e1af6 Staging: cx25821: fix double unlock in medusa_video_init() I guess this is going through the V4L/DVB so it needs to be reverted there as well as in the -staging tree. Sorry for the inconvenience. regards, dan carpenter PS. The correct version is: 423f5c0d016 V4L/DVB (13955): cx25821: fix double unlock in medusa_video_init(). That one is needed and fixes a bug -- 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] Rework for support xc5000
On Wed, 5 May 2010 10:16:27 +0800
Bee Hock Goh beeh...@gmail.com wrote:
There does not seem to be any radio support in the tm6000 codes.
tun_setup.mode_mask |= (T_ANALOG_TV | T_RADIO);
Is the T_RADIO mode still required since this is a cleanup?
Now radio may be not work. But we want write complete driver.
This for set T_RADIO
Cleanup is tun_setup.mode_mask = ~(T_RADIO)
With my best regards, Dmitry.
On Wed, May 5, 2010 at 6:53 AM, Dmitri Belimov d.beli...@gmail.com
wrote:
Hi
Set correct GPIO number for BEHOLD_WANDER/VOYAGER
Add xc5000 callback function
Small rework tm6000_cards_setup function
Small rework tm6000_config_tuner, build mode_mask by config
information Rework for support xc5000 silicon tuner
Add some information messages for more better understand an errors.
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c index f795a3e..17e3d4c
100644 --- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -231,7 +231,9 @@ struct tm6000_board tm6000_boards[] = {
.has_remote = 1,
},
.gpio = {
- .tuner_reset = TM6000_GPIO_2,
+ .tuner_reset = TM6010_GPIO_0,
+ .demod_reset = TM6010_GPIO_1,
+ .power_led = TM6010_GPIO_6,
},
},
[TM6010_BOARD_BEHOLD_VOYAGER] = {
@@ -247,7 +249,8 @@ struct tm6000_board tm6000_boards[] = {
.has_remote = 1,
},
.gpio = {
- .tuner_reset = TM6000_GPIO_2,
+ .tuner_reset = TM6010_GPIO_0,
+ .power_led = TM6010_GPIO_6,
},
},
[TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
@@ -320,6 +323,31 @@ struct usb_device_id tm6000_id_table [] = {
{ },
};
+/* Tuner callback to provide the proper gpio changes needed for
xc5000 */ +int tm6000_xc5000_callback(void *ptr, int component, int
command, int arg) +{
+ int rc = 0;
+ struct tm6000_core *dev = ptr;
+
+ if (dev-tuner_type != TUNER_XC5000)
+ return 0;
+
+ switch (command) {
+ case XC5000_TUNER_RESET:
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x01);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x00);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x01);
+ break;
+ }
+ return (rc);
+}
+
+
/* Tuner callback to provide the proper gpio changes needed for
xc2028 */
int tm6000_tuner_callback(void *ptr, int component, int command,
int arg) @@ -438,6 +466,21 @@ int tm6000_cards_setup(struct
tm6000_core *dev) tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev-gpio.demod_on, 0x00); msleep(15);
break;
+ case TM6010_BOARD_BEHOLD_WANDER:
+ /* Power led on (blue) */
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev-gpio.power_led, 0x01);
+ msleep(15);
+ /* Reset zarlink zl10353 */
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev-gpio.demod_reset, 0x00);
+ msleep(50);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev-gpio.demod_reset, 0x01);
+ msleep(15);
+ break;
+ case TM6010_BOARD_BEHOLD_VOYAGER:
+ /* Power led on (blue) */
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
dev-gpio.power_led, 0x01);
+ msleep(15);
+ break;
default:
break;
}
@@ -449,42 +492,38 @@ int tm6000_cards_setup(struct tm6000_core
*dev)
* If a device uses a different sequence or different GPIO
pins for
* reset, just add the code at the board-specific part
*/
- for (i = 0; i 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-gpio.tuner_reset,
0x00);
- if (rc 0) {
- printk(KERN_ERR Error %i doing GPIO1
reset\n, rc);
- return rc;
- }
-
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-gpio.tuner_reset,
0x01);
- if (rc 0) {
- printk(KERN_ERR Error %i doing GPIO1
reset\n, rc);
- return rc;
- }
- msleep(10);
Re: tm6000
If you do that you will get some decent looking video. On Wed, May 5, 2010 at 3:27 PM, Dmitri Belimov d.beli...@gmail.com wrote: On Wed, 5 May 2010 13:44:38 +0800 Bee Hock Goh beeh...@gmail.com wrote: Did you comment off the code in the get_next_buff that clear the previous frame data? No. Git tree + my last patch. With my best regards, Dmitry. On Wed, May 5, 2010 at 12:50 PM, Dmitri Belimov d.beli...@gmail.com wrote: Hi At this moment I can start mplayer and see green field with some junk without crash. Info from mplayer - received 497 frames, drop 69 incorrect frames. Compile without support DVB-T for our cards. Now try understand init process working drivers and diff with linux. P.S. Linux kernel is 2.6.33 With my best regards, Dmitry. -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 31/03/2009 21:10, Antti Palosaari wrote: Moi Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: remove experimental af9015: add new USB ID for KWorld USB DVB-T TV Stick II (VS-DVB-T 395U) af9015: add support for TrekStor DVB-T USB Stick af9015: remove wrong definitions af9015: add support for AverMedia AVerTV Volar Black HD (A850) Patches are for the Kernel 2.6.30, only small changes. regards Antti Palosaari any chance of support for the TDA18218 in this driver i found patches on the net and i am currently fighting them i also note that the driver on ite's web site has been updated and get_dvb_firmware can no longer extract the firmware thanks -- simon -- 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: UVC Webcam
Hi Gijo, On Thursday 29 April 2010 12:54:16 Gijo Prems wrote: Hello, I have some queries related to linux uvc client driver(uvcvideo) and general uvc webcam functionality. 1. There is a wDelay (during probe-commit) parameter which camera exposes to the host signifying the delay (Latency) inside the camera. Does the UVC driver on Linux Host expose this parameter to the application if they require it? No it doesn't. And what would be the use case of this parameter? I don't know, and that's exactly why the parameter isn't exposed :-) 2. How the audio and video sync (lipsync) would happen on host side? There's no sync at the moment. UVC supports timestamping the packets sent to the host, but the driver ignores the timestamps. 3. How buffers are allocated on the host side? Which parameter from camera needs to be set to signify the correct buffer allocation? There are two sets of buffers, the USB buffers and the V4L2 buffers. The uvcvideo driver allocates one USB buffer per URB (the number of URBs is hardcoded to 5). The USB buffer size is set to the payload size returned by the device, bounded to a maximum value of 32 times the endpoint max packet size. For V4L2 buffers, the uvcvideo driver uses the V4L2 MMAP streaming mode. Applications are supposed to first set the format (VIDIOC_S_FMT), and then ask the driver to allocate buffers (VIDIOC_REQBUFS). 4. Are there any parameters in USB audio class which allocate the buffers and handles the latency at host? I don't know much about the USB audio class, sorry. It would be great if someone could put some thoughts on these. -- 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
[PATCH] tda10048: fix the uncomplete function tda10048_read_ber
Hello,
Completes the bit-error-rate read function with the CBER register (before
Viterbi decoder). The returned value is 1e8*actual_ber to be positive.
Also includes some typo mistakes.
Signed-off-by: Guillaume Audirac guillaume.audi...@webag.fr
---
drivers/media/dvb/frontends/tda10048.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 4e2a7c8..9006107 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -25,6 +25,7 @@
#include linux/string.h
#include linux/slab.h
#include linux/delay.h
+#include linux/math64.h
#include asm/div64.h
#include dvb_frontend.h
#include dvb_math.h
@@ -112,7 +113,7 @@
#define TDA10048_FREE_REG_10xB2
#define TDA10048_FREE_REG_20xB3
#define TDA10048_CONF_C3_1 0xC0
-#define TDA10048_CYBER_CTRL0xC2
+#define TDA10048_CVBER_CTRL0xC2
#define TDA10048_CBER_NMAX_LSB 0xC4
#define TDA10048_CBER_NMAX_MSB 0xC5
#define TDA10048_CBER_LSB 0xC6
@@ -120,7 +121,7 @@
#define TDA10048_VBER_LSB 0xC8
#define TDA10048_VBER_MID 0xC9
#define TDA10048_VBER_MSB 0xCA
-#define TDA10048_CYBER_LUT 0xCC
+#define TDA10048_CVBER_LUT 0xCC
#define TDA10048_UNCOR_CTRL0xCD
#define TDA10048_UNCOR_CPT_LSB 0xCE
#define TDA10048_UNCOR_CPT_MSB 0xCF
@@ -183,7 +184,7 @@ static struct init_tab {
{ TDA10048_AGC_IF_MAX, 0xff },
{ TDA10048_AGC_THRESHOLD_MSB, 0x00 },
{ TDA10048_AGC_THRESHOLD_LSB, 0x70 },
- { TDA10048_CYBER_CTRL, 0x38 },
+ { TDA10048_CVBER_CTRL, 0x38 },
{ TDA10048_AGC_GAINS, 0x12 },
{ TDA10048_CONF_XO, 0x00 },
{ TDA10048_CONF_TS1, 0x07 },
@@ -765,6 +766,8 @@ static int tda10048_set_frontend(struct dvb_frontend *fe,
/* Enable demod TPS auto detection and begin acquisition */
tda10048_writereg(state, TDA10048_AUTO, 0x57);
+ /* trigger cber and vber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x3B);
return 0;
}
@@ -830,12 +833,27 @@ static int tda10048_read_status(struct dvb_frontend
*fe, fe_status_t *status)
static int tda10048_read_ber(struct dvb_frontend *fe, u32 *ber)
{
struct tda10048_state *state = fe-demodulator_priv;
+ static u32 cber_current;
+ u32 cber_nmax;
+ u64 cber_tmp;
dprintk(1, %s()\n, __func__);
- /* TODO: A reset may be required here */
- *ber = tda10048_readreg(state, TDA10048_CBER_MSB) 8 |
- tda10048_readreg(state, TDA10048_CBER_LSB);
+ /* update cber on interrupt */
+ if (tda10048_readreg(state, TDA10048_SOFT_IT_C3) 0x01) {
+ cber_tmp = tda10048_readreg(state, TDA10048_CBER_MSB) 8 |
+ tda10048_readreg(state, TDA10048_CBER_LSB);
+ cber_nmax = tda10048_readreg(state, TDA10048_CBER_NMAX_MSB)
8 |
+ tda10048_readreg(state, TDA10048_CBER_NMAX_LSB);
+ cber_tmp *= 1;
+ cber_tmp *= 2;
+ cber_tmp = div_u64(cber_tmp, (cber_nmax * 32) + 1);
+ cber_current = (u32)cber_tmp;
+ /* retrigger cber acquisition */
+ tda10048_writereg(state, TDA10048_CVBER_CTRL, 0x39);
+ }
+ /* actual cber is (*ber)/1e8 */
+ *ber = cber_current;
return 0;
}
--
1.6.3.3
--
Guillaume
--
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
Help Central
This is to inform you that you have exceeded your email quota limit of 625MB and you need to increase your email quota limit because in less than 48 hours your email will be disable. Increase your email quota limit and continue to use your webmail account. To increase your email quota limit to 2.7GB, click the below link: http://www.emailmeform.com/fid.php?formid=687794 Thank you for your understanding. Copyright ©2010 Webmail Helpdest Support Centre -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. On Wed, May 5, 2010 at 5:29 PM, Simon Kenyon si...@koala.ie wrote: On 31/03/2009 21:10, Antti Palosaari wrote: Moi Mauro, Please pull from http://linuxtv.org/hg/~anttip/af9015/ for the following: af9015: remove experimental af9015: add new USB ID for KWorld USB DVB-T TV Stick II (VS-DVB-T 395U) af9015: add support for TrekStor DVB-T USB Stick af9015: remove wrong definitions af9015: add support for AverMedia AVerTV Volar Black HD (A850) Patches are for the Kernel 2.6.30, only small changes. regards Antti Palosaari any chance of support for the TDA18218 in this driver i found patches on the net and i am currently fighting them i also note that the driver on ite's web site has been updated and get_dvb_firmware can no longer extract the firmware thanks -- simon -- 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: [PATCH] tda10048: fix the uncomplete function tda10048_read_ber
Completes the bit-error-rate read function with the CBER register (before Viterbi decoder). The returned value is 1e8*actual_ber to be positive. Also includes some typo mistakes. Signed-off-by: Guillaume Audirac guillaume.audi...@webag.fr Thanks Guillaume, I have a pile of other patches I'm ready to present for merge so I'll pull this into one of my dev trees and present this for merge also of course, I'll test it first! :) Thanks again for working on this. Regards, - Steve -- Steven Toth - 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
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Antti, Thanks for coming out to clarify. So the step going forward is to getting clearance from Lauris? I didnt really look at the codes but the your tree with the tda18218 patch seem to working very well for me. http://ubuntuforums.org/showthread.php?p=8936585 On Wed, May 5, 2010 at 8:58 PM, Antti Palosaari cr...@iki.fi wrote: On 05/05/2010 03:36 PM, Bee Hock Goh wrote: There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Do we have kernel merge permission from driver author Lauris Ding? Also this driver is a little but ugly and needs some rework before release. I don't have such device and not even time to hack. I hope someone else could take this driver and fix it for release. 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 03:36 PM, Bee Hock Goh wrote: There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Do we have kernel merge permission from driver author Lauris Ding? Also this driver is a little but ugly and needs some rework before release. I don't have such device and not even time to hack. I hope someone else could take this driver and fix it for release. 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: tm6000
Dmitri Belimov wrote: On Wed, 5 May 2010 13:44:38 +0800 Bee Hock Goh beeh...@gmail.com wrote: Did you comment off the code in the get_next_buff that clear the previous frame data? No. Git tree + my last patch. A green tree can happen due to lots of conditions, like: 1) it is not receiving data from xc3028 (or xc5000); 2) wrong gpio setup; 3) data sent too fast to tm6000; 4) need to add some new workarounds to another tm6000 firmware/hardware bug; 5) the device stopped answer and got disconnected from USB buffer; 6) signal were too weak after changing to some channel (it seems that the tm6000 chip stops reception with weak signals - I remember I had to add a code that re-enables xc3028 every time a channel is changed due to this bug, since, after disabled, even if the signal become strong, it keeps showing a green screen); 7) you hit yet another bug on this device ;) -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. i do know about the patch in fact that is what i have been playing with but it just replaces an existing stcik with the definition for the one that i have i thought that was a bit hacky - mainly because the patch failed on my hg checkout so i have been editing the code to try and add it (not replace) and indeed the stick is detected - just no signal trying to work out what the problem is also trying to get the latest firmware - second part of my question to the list i don't know where the original patch came from as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it -- simon -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon si...@koala.ie wrote: On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. i do know about the patch in fact that is what i have been playing with but it just replaces an existing stcik with the definition for the one that i have i thought that was a bit hacky - mainly because the patch failed on my hg checkout so i have been editing the code to try and add it (not replace) and indeed the stick is detected - just no signal trying to work out what the problem is also trying to get the latest firmware - second part of my question to the list i don't know where the original patch came from as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it -- simon -- 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: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Use the attached firmware which work well for me. An earlier firmware will hung the stick and this version fixed that issue. On Wed, May 5, 2010 at 10:07 PM, Bee Hock Goh beeh...@gmail.com wrote: You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon si...@koala.ie wrote: On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. i do know about the patch in fact that is what i have been playing with but it just replaces an existing stcik with the definition for the one that i have i thought that was a bit hacky - mainly because the patch failed on my hg checkout so i have been editing the code to try and add it (not replace) and indeed the stick is detected - just no signal trying to work out what the problem is also trying to get the latest firmware - second part of my question to the list i don't know where the original patch came from as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it -- simon -- 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 rt73.bin Description: Binary data
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On Wed, May 5, 2010 at 10:13 PM, Bee Hock Goh beeh...@gmail.com wrote: Use the attached firmware which work well for me. An earlier firmware will hung the stick and this version fixed that issue. On Wed, May 5, 2010 at 10:07 PM, Bee Hock Goh beeh...@gmail.com wrote: You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. On Wed, May 5, 2010 at 10:00 PM, Simon Kenyon si...@koala.ie wrote: On 05/05/2010 13:36, Bee Hock Goh wrote: Simon, There is already a patch that will make af9105/tda18218 work. However, it seem that there is no active effort to merge with the mainstream code. I have been running that codes with mythtv(recording only) for quite a while and its working fine. https://patchwork.kernel.org/patch/82494/ Mauro, I have send a mail to Nikola asking if he will be willing to submit the codes to the v4l-dvb tree but I do not have any reply yet. Can I extract thenecessary files/patch from http://linuxtv.org/hg/~anttip/af9015/ and let you merge with the git tree? I also notice that in ubuntu, it can detect the card and installed proprietary code. Unfortunately, tda18218 is not supported. i do know about the patch in fact that is what i have been playing with but it just replaces an existing stcik with the definition for the one that i have i thought that was a bit hacky - mainly because the patch failed on my hg checkout so i have been editing the code to try and add it (not replace) and indeed the stick is detected - just no signal trying to work out what the problem is also trying to get the latest firmware - second part of my question to the list i don't know where the original patch came from as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it -- simon -- 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 dvb-usb-af9015.fw Description: Binary data
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
On 05/05/2010 15:07, Bee Hock Goh wrote: You need to follow this link: http://ubuntuforums.org/showthread.php?p=8936585 If you download the correct version of the antti af9015 tree, you can apply the patch correctly and it will work(a tda18218/af9015 stick) without any code change. thanks for your help that thread talks about using an old version of the tree i will try it just to make sure that i am doing the correct thing with my edits but it is not a long term solution the patch replaces the entry to another stick rather than fix up the code to add an extra one i don't think that it will make it into the tree in its current state that and all the magic constants regards -- simon -- 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/IR: Add missing include file to rc-map.c
From: Peter Huewe peterhu...@gmx.de This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe peterhu...@gmx.de --- KernelVersion: linux-next-20100505 References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2571452/ [2] http://kisskb.ellerman.id.au/kisskb/buildresult/2571188/ [3] http://kisskb.ellerman.id.au/kisskb/buildresult/2571479/ [4] http://kisskb.ellerman.id.au/kisskb/buildresult/2571429/ [5] http://kisskb.ellerman.id.au/kisskb/buildresult/2571432/ drivers/media/IR/rc-map.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c index caf6a27..46a8f15 100644 --- a/drivers/media/IR/rc-map.c +++ b/drivers/media/IR/rc-map.c @@ -14,6 +14,7 @@ #include media/ir-core.h #include linux/spinlock.h +#include linux/delay.h /* Used to handle IR raw handler extensions */ static LIST_HEAD(rc_map_list); -- 1.6.4.4 -- 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: -next: staging/cx25821: please revert 7a02f549fcc
Dan Carpenter wrote:
This was my patch: cx25821: fix double unlock in medusa_video_init()
It accidentally got merged two times. The version from the staging tree
is not correct. Please can you revert it:
7a02f549fcc30fe6be0c0024beae9a3db22e1af6 Staging: cx25821: fix double
unlock in medusa_video_init()
Hmm... true.
I guess this is going through the V4L/DVB so it needs to be reverted
there as well as in the -staging tree.
There's no need to touch at staging tree, since this change come from v4l-dvb
tree.
After reviewing the logic at the function, instead of just adding a patch to
revert the wrong one, the better is to apply a different logic: add a goto
that will always unlock and return the error.
This simplifies the code a little bit, and, instead of just return -EINVAL,
it will return the error condition reported by the called functions.
Btw, cx25821-core currently doesn't handle the error returned by
medusa_video_init().
Palash,
Could you please add the proper validation code for the error conditions that
may
happen during device init?
Cheers,
Mauro
--
V4L/DVB: cx25821: fix error condition logic at medusa_video_init()
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 77ccef4..7545314 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -778,9 +778,9 @@ int medusa_set_saturation(struct cx25821_dev *dev, int
saturation, int decoder)
int medusa_video_init(struct cx25821_dev *dev)
{
- u32 value = 0, tmp = 0;
- int ret_val = 0;
- int i = 0;
+ u32 value, tmp = 0;
+ int ret_val;
+ int i;
mutex_lock(dev-lock);
@@ -790,20 +790,15 @@ int medusa_video_init(struct cx25821_dev *dev)
value = cx25821_i2c_read(dev-i2c_bus[0], MON_A_CTRL, tmp);
value = 0xF0FF;
ret_val = cx25821_i2c_write(dev-i2c_bus[0], MON_A_CTRL, value);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* Turn off Master source switch enable */
value = cx25821_i2c_read(dev-i2c_bus[0], MON_A_CTRL, tmp);
value = 0xFFDF;
ret_val = cx25821_i2c_write(dev-i2c_bus[0], MON_A_CTRL, value);
-
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
+ if (ret_val 0)
+ goto error;
mutex_unlock(dev-lock);
@@ -817,31 +812,25 @@ int medusa_video_init(struct cx25821_dev *dev)
value = 0xFF70FF70;
value |= 0x00090008;/* set en_active */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], DENC_AB_CTRL, value);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* enable input is VIP/656 */
value = cx25821_i2c_read(dev-i2c_bus[0], BYP_AB_CTRL, tmp);
value |= 0x00040100;/* enable VIP */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], BYP_AB_CTRL, value);
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
+ if (ret_val 0)
+ goto error;
+
/* select AFE clock to output mode */
value = cx25821_i2c_read(dev-i2c_bus[0], AFE_AB_DIAG_CTRL, tmp);
value = 0x83FF;
- ret_val =
- cx25821_i2c_write(dev-i2c_bus[0], AFE_AB_DIAG_CTRL,
- value | 0x1000);
+ ret_val = cx25821_i2c_write(dev-i2c_bus[0], AFE_AB_DIAG_CTRL,
+ value | 0x1000);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* Turn on all of the data out and control output pins. */
value = cx25821_i2c_read(dev-i2c_bus[0], PIN_OE_CTRL, tmp);
value = 0xFEF0FE00;
@@ -868,9 +857,9 @@ int medusa_video_init(struct cx25821_dev *dev)
mutex_unlock(dev-lock);
ret_val = medusa_set_videostandard(dev);
+ return ret_val;
- if (ret_val 0)
- return -EINVAL;
-
- return 1;
+error:
+ mutex_unlock(dev-lock);
+ return ret_val;
}
--
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: -next: staging/cx25821: please revert 7a02f549fcc
Will do. Thanks for passing over the info.
Regards,
Palash
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: Wednesday, May 05, 2010 8:30 AM
To: Dan Carpenter; Palash Bandyopadhyay
Cc: Greg Kroah-Hartman; linux-media@vger.kernel.org
Subject: Re: -next: staging/cx25821: please revert 7a02f549fcc
Dan Carpenter wrote:
This was my patch: cx25821: fix double unlock in medusa_video_init()
It accidentally got merged two times. The version from the staging tree
is not correct. Please can you revert it:
7a02f549fcc30fe6be0c0024beae9a3db22e1af6 Staging: cx25821: fix double
unlock in medusa_video_init()
Hmm... true.
I guess this is going through the V4L/DVB so it needs to be reverted
there as well as in the -staging tree.
There's no need to touch at staging tree, since this change come from v4l-dvb
tree.
After reviewing the logic at the function, instead of just adding a patch to
revert the wrong one, the better is to apply a different logic: add a goto
that will always unlock and return the error.
This simplifies the code a little bit, and, instead of just return -EINVAL,
it will return the error condition reported by the called functions.
Btw, cx25821-core currently doesn't handle the error returned by
medusa_video_init().
Palash,
Could you please add the proper validation code for the error conditions that
may
happen during device init?
Cheers,
Mauro
--
V4L/DVB: cx25821: fix error condition logic at medusa_video_init()
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 77ccef4..7545314 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -778,9 +778,9 @@ int medusa_set_saturation(struct cx25821_dev *dev, int
saturation, int decoder)
int medusa_video_init(struct cx25821_dev *dev)
{
- u32 value = 0, tmp = 0;
- int ret_val = 0;
- int i = 0;
+ u32 value, tmp = 0;
+ int ret_val;
+ int i;
mutex_lock(dev-lock);
@@ -790,20 +790,15 @@ int medusa_video_init(struct cx25821_dev *dev)
value = cx25821_i2c_read(dev-i2c_bus[0], MON_A_CTRL, tmp);
value = 0xF0FF;
ret_val = cx25821_i2c_write(dev-i2c_bus[0], MON_A_CTRL, value);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* Turn off Master source switch enable */
value = cx25821_i2c_read(dev-i2c_bus[0], MON_A_CTRL, tmp);
value = 0xFFDF;
ret_val = cx25821_i2c_write(dev-i2c_bus[0], MON_A_CTRL, value);
-
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
+ if (ret_val 0)
+ goto error;
mutex_unlock(dev-lock);
@@ -817,31 +812,25 @@ int medusa_video_init(struct cx25821_dev *dev)
value = 0xFF70FF70;
value |= 0x00090008;/* set en_active */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], DENC_AB_CTRL, value);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* enable input is VIP/656 */
value = cx25821_i2c_read(dev-i2c_bus[0], BYP_AB_CTRL, tmp);
value |= 0x00040100;/* enable VIP */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], BYP_AB_CTRL, value);
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
+ if (ret_val 0)
+ goto error;
+
/* select AFE clock to output mode */
value = cx25821_i2c_read(dev-i2c_bus[0], AFE_AB_DIAG_CTRL, tmp);
value = 0x83FF;
- ret_val =
- cx25821_i2c_write(dev-i2c_bus[0], AFE_AB_DIAG_CTRL,
- value | 0x1000);
+ ret_val = cx25821_i2c_write(dev-i2c_bus[0], AFE_AB_DIAG_CTRL,
+ value | 0x1000);
+ if (ret_val 0)
+ goto error;
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
/* Turn on all of the data out and control output pins. */
value = cx25821_i2c_read(dev-i2c_bus[0], PIN_OE_CTRL, tmp);
value = 0xFEF0FE00;
@@ -868,9 +857,9 @@ int medusa_video_init(struct cx25821_dev *dev)
mutex_unlock(dev-lock);
ret_val = medusa_set_videostandard(dev);
+ return ret_val;
- if (ret_val 0)
- return -EINVAL;
-
- return 1;
+error:
+ mutex_unlock(dev-lock);
+ return ret_val;
}
Conexant E-mail Firewall (Conexant.Com) made the following annotations
-
** Legal Disclaimer
This
Re: [GIT PATCHES FOR 2.6.35] sn9c20x updates
On Sat, May 1, 2010 at 10:36 AM, Brian Johnson brij...@gmail.com wrote: The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: git://gitorious.org/v4l-dvb/v4l-dvb.git devel Added a bugfix for the mt9v111 sensor gspca - sn9c20x: Fix non working mt9v111 sensor Regards, Brian Johnson -- 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/RFC 5/7] dsbr100: properly initialize the radio
This patch adds a flag to indicate if the radio has been
initialized or not. If the flag has not been set upon open,
the radio initialized to a known state.
It combines the STARTED/STOPPED indicators into a single
MUTED flag and defines a couple of macros for determining
the status of the radio.
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c | 54 +++-
1 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index c949ace..e2fed0b 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -125,10 +125,13 @@ devices, that would be 76 and 91. */
#define FREQ_MAX 108.0
#define FREQ_MUL 16000
-/* defines for radio-status */
-#define STARTED0
-#define STOPPED1
+enum dsbr100_status {
+ INITIALIZED = 1 0,
+ MUTED = 1 1
+};
+#define radio_initialized(r) (r-status INITIALIZED)
+#define radio_muted(r) (r-status MUTED)
#define videodev_to_radio(d) container_of(d, struct dsbr100_device, videodev)
static int usb_dsbr100_probe(struct usb_interface *intf,
@@ -151,7 +154,7 @@ struct dsbr100_device {
struct mutex lock; /* buffer locking */
int curfreq;
int stereo;
- int status;
+ enum dsbr100_status status;
};
static struct usb_device_id usb_dsbr100_device_table [] = {
@@ -205,7 +208,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
goto usb_control_msg_failed;
}
- radio-status = STARTED;
+ radio-status = ~MUTED;
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
@@ -246,7 +249,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
goto usb_control_msg_failed;
}
- radio-status = STOPPED;
+ radio-status |= MUTED;
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
@@ -532,6 +535,33 @@ unlock:
return retval;
}
+static int usb_dsbr100_open(struct file *file)
+{
+ struct dsbr100_device *radio = video_drvdata(file);
+ int retval = 0;
+
+ mutex_lock(radio-lock);
+
+ if (!radio-usbdev) {
+ retval = -EIO;
+ goto unlock;
+ }
+
+ if (unlikely(!radio_initialized(radio))) {
+ retval = dsbr100_stop(radio);
+
+ if (retval 0)
+ goto unlock;
+
+ retval = 0;
+ radio-status |= INITIALIZED;
+ }
+
+unlock:
+ mutex_unlock(radio-lock);
+ return retval;
+}
+
/* Suspend device - stop device. */
static int usb_dsbr100_suspend(struct usb_interface *intf, pm_message_t
message)
{
@@ -540,17 +570,17 @@ static int usb_dsbr100_suspend(struct usb_interface
*intf, pm_message_t message)
mutex_lock(radio-lock);
- if (radio-status == STARTED) {
+ if (!radio_muted(radio)) {
retval = dsbr100_stop(radio);
if (retval 0)
dev_warn(intf-dev, dsbr100_stop failed\n);
- /* After dsbr100_stop() status set to STOPPED.
+ /* After dsbr100_stop() status set to MUTED.
* If we want driver to start radio on resume
-* we set status equal to STARTED.
+* we set status equal to not MUTED
* On resume we will check status and run radio if needed.
*/
- radio-status = STARTED;
+ radio-status = ~MUTED;
}
mutex_unlock(radio-lock);
@@ -567,7 +597,7 @@ static int usb_dsbr100_resume(struct usb_interface *intf)
mutex_lock(radio-lock);
- if (radio-status == STARTED) {
+ if (radio_initialized(radio) !radio_muted(radio)) {
retval = dsbr100_start(radio);
if (retval 0)
dev_warn(intf-dev, dsbr100_start failed\n);
@@ -593,6 +623,7 @@ static void usb_dsbr100_video_device_release(struct
video_device *videodev)
static const struct v4l2_file_operations usb_dsbr100_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = usb_dsbr100_ioctl,
+ .open = usb_dsbr100_open,
};
static const struct v4l2_ioctl_ops usb_dsbr100_ioctl_ops = {
@@ -650,7 +681,6 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
radio-usbdev = interface_to_usbdev(intf);
radio-curfreq = FREQ_MIN * FREQ_MUL;
- radio-status = STOPPED;
video_set_drvdata(radio-videodev, radio);
--
1.7.1
--
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/RFC 2/7] dsbr100: fix potential use after free
Signed-off-by: David Ellingsworth da...@identd.dyndns.org --- drivers/media/radio/dsbr100.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c index 673eda8..2f96e13 100644 --- a/drivers/media/radio/dsbr100.c +++ b/drivers/media/radio/dsbr100.c @@ -354,8 +354,8 @@ static void usb_dsbr100_disconnect(struct usb_interface *intf) radio-removed = 1; mutex_unlock(radio-lock); - video_unregister_device(radio-videodev); v4l2_device_disconnect(radio-v4l2_dev); + video_unregister_device(radio-videodev); } -- 1.7.1 -- 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/RFC 1/7] dsbr100: implement proper locking
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c | 77 +---
1 files changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index ed9cd7a..673eda8 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -182,7 +182,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -207,11 +207,9 @@ static int dsbr100_start(struct dsbr100_device *radio)
}
radio-status = STARTED;
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -225,7 +223,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -250,11 +248,9 @@ static int dsbr100_stop(struct dsbr100_device *radio)
}
radio-status = STOPPED;
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -269,7 +265,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
int request;
int freq = (radio-curfreq / 16 * 80) / 1000 + 856;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -306,12 +302,10 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
}
radio-stereo = !((radio-transfer_buffer)[0] 0x01);
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
radio-stereo = -1;
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -324,7 +318,7 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
{
int retval;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -340,8 +334,6 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
} else {
radio-stereo = !(radio-transfer_buffer[0] 0x01);
}
-
- mutex_unlock(radio-lock);
}
/* USB subsystem interface begins here */
@@ -385,10 +377,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio-removed)
- return -EIO;
-
if (v-index 0)
return -EINVAL;
@@ -410,12 +398,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
-
- /* safety check */
- if (radio-removed)
- return -EIO;
-
if (v-index 0)
return -EINVAL;
@@ -428,17 +410,12 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct dsbr100_device *radio = video_drvdata(file);
int retval;
- /* safety check */
- if (radio-removed)
- return -EIO;
-
- mutex_lock(radio-lock);
radio-curfreq = f-frequency;
- mutex_unlock(radio-lock);
retval = dsbr100_setfreq(radio);
if (retval 0)
dev_warn(radio-usbdev-dev, Set frequency failed\n);
+
return 0;
}
@@ -447,10 +424,6 @@ static int vidioc_g_frequency(struct file *file, void
*priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio-removed)
- return -EIO;
-
f-type = V4L2_TUNER_RADIO;
f-frequency = radio-curfreq;
return 0;
@@ -472,10 +445,6 @@ static int vidioc_g_ctrl(struct file *file, void *priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio-removed)
- return -EIO;
-
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
ctrl-value = radio-status;
@@ -490,10 +459,6 @@ static int
[PATCH/RFC 3/7] dsbr100: only change frequency upon success
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index 2f96e13..b62fe40 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -259,11 +259,12 @@ usb_control_msg_failed:
}
/* set a frequency, freq is defined by v4l's TUNER_LOW, i.e. 1/16th kHz */
-static int dsbr100_setfreq(struct dsbr100_device *radio)
+static int dsbr100_setfreq(struct dsbr100_device *radio, int freq)
{
int retval;
int request;
- int freq = (radio-curfreq / 16 * 80) / 1000 + 856;
+
+ freq = (freq / 16 * 80) / 1000 + 856;
BUG_ON(!mutex_is_locked(radio-lock));
@@ -302,6 +303,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
}
radio-stereo = !((radio-transfer_buffer)[0] 0x01);
+ radio-curfreq = freq;
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
@@ -408,11 +410,8 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct v4l2_frequency *f)
{
struct dsbr100_device *radio = video_drvdata(file);
- int retval;
-
- radio-curfreq = f-frequency;
+ int retval = dsbr100_setfreq(radio, f-frequency);
- retval = dsbr100_setfreq(radio);
if (retval 0)
dev_warn(radio-usbdev-dev, Set frequency failed\n);
--
1.7.1
--
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/RFC 6/7] dsbr100: cleanup usb probe routine
This patch simplifies the error paths within the
usb_dsbr100_probe routine. It also removes an unnecessary
local variable.
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index e2fed0b..cd4eed7 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -646,33 +646,28 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct dsbr100_device *radio;
- struct v4l2_device *v4l2_dev;
int retval;
radio = kzalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
-
if (!radio)
return -ENOMEM;
radio-transfer_buffer = kmalloc(TB_LEN, GFP_KERNEL);
-
if (!(radio-transfer_buffer)) {
- kfree(radio);
- return -ENOMEM;
+ retval = -ENOMEM;
+ goto err_nobuf;
}
- v4l2_dev = radio-v4l2_dev;
-
- retval = v4l2_device_register(intf-dev, v4l2_dev);
+ retval = v4l2_device_register(intf-dev, radio-v4l2_dev);
if (retval 0) {
- v4l2_err(v4l2_dev, couldn't register v4l2_device\n);
- kfree(radio-transfer_buffer);
- kfree(radio);
- return retval;
+ v4l2_err(radio-v4l2_dev, couldn't register v4l2_device\n);
+ goto err_v4l2;
}
- strlcpy(radio-videodev.name, v4l2_dev-name,
sizeof(radio-videodev.name));
- radio-videodev.v4l2_dev = v4l2_dev;
+ strlcpy(radio-videodev.name, radio-v4l2_dev.name,
+ sizeof(radio-videodev.name));
+
+ radio-videodev.v4l2_dev = radio-v4l2_dev;
radio-videodev.fops = usb_dsbr100_fops;
radio-videodev.ioctl_ops = usb_dsbr100_ioctl_ops;
radio-videodev.release = usb_dsbr100_video_device_release;
@@ -686,14 +681,20 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
retval = video_register_device(radio-videodev, VFL_TYPE_RADIO,
radio_nr);
if (retval 0) {
- v4l2_err(v4l2_dev, couldn't register video device\n);
- v4l2_device_unregister(v4l2_dev);
- kfree(radio-transfer_buffer);
- kfree(radio);
- return -EIO;
+ v4l2_err(radio-v4l2_dev, couldn't register video device\n);
+ goto err_vdev;
}
+
usb_set_intfdata(intf, radio);
return 0;
+
+err_vdev:
+ v4l2_device_unregister(radio-v4l2_dev);
+err_v4l2:
+ kfree(radio-transfer_buffer);
+err_nobuf:
+ kfree(radio);
+ return retval;
}
static int __init dsbr100_init(void)
--
1.7.1
--
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/RFC 4/7] dsbr100: remove disconnected indicator
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index b62fe40..c949ace 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -151,7 +151,6 @@ struct dsbr100_device {
struct mutex lock; /* buffer locking */
int curfreq;
int stereo;
- int removed;
int status;
};
@@ -353,7 +352,7 @@ static void usb_dsbr100_disconnect(struct usb_interface
*intf)
usb_set_intfdata (intf, NULL);
mutex_lock(radio-lock);
- radio-removed = 1;
+ radio-usbdev = NULL;
mutex_unlock(radio-lock);
v4l2_device_disconnect(radio-v4l2_dev);
@@ -521,7 +520,7 @@ static long usb_dsbr100_ioctl(struct file *file, unsigned
int cmd,
mutex_lock(radio-lock);
- if (radio-removed) {
+ if (!radio-usbdev) {
retval = -EIO;
goto unlock;
}
@@ -649,7 +648,6 @@ static int usb_dsbr100_probe(struct usb_interface *intf,
mutex_init(radio-lock);
- radio-removed = 0;
radio-usbdev = interface_to_usbdev(intf);
radio-curfreq = FREQ_MIN * FREQ_MUL;
radio-status = STOPPED;
--
1.7.1
--
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/RFC 0/7] dsbr100: driver cleanup
This patch series addresses several issues in the dsbr100 driver. This series is based on the v4l-dvb master git branch and has been compile tested only. It should be tested before applying. The following patches are included in this series: [PATCH/RFC 1/7] dsbr100: implement proper locking [PATCH/RFC 2/7] dsbr100: fix potential use after free [PATCH/RFC 3/7] dsbr100: only change frequency upon success [PATCH/RFC 4/7] dsbr100: remove disconnected indicator [PATCH/RFC 5/7] dsbr100: properly initialize the radio [PATCH/RFC 6/7] dsbr100: cleanup usb probe routine [PATCH/RFC 7/7] dsbr100: simplify access to radio device Regards, David Ellingsworth -- 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/RFC 7/7] dsbr100: simplify access to radio device
This patch replaces calls to video_drvdata with
references to struct file-private_data which is
set during usb_dsbr100_open. This value is passed
by video_ioctl2 via the *priv argument and is
accessible via file-private_data otherwise.
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
---
drivers/media/radio/dsbr100.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index cd4eed7..64ba0c8 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -366,7 +366,7 @@ static void usb_dsbr100_disconnect(struct usb_interface
*intf)
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio, sizeof(v-card));
@@ -379,7 +379,7 @@ static int vidioc_querycap(struct file *file, void *priv,
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
if (v-index 0)
return -EINVAL;
@@ -411,7 +411,7 @@ static int vidioc_s_tuner(struct file *file, void *priv,
static int vidioc_s_frequency(struct file *file, void *priv,
struct v4l2_frequency *f)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
int retval = dsbr100_setfreq(radio, f-frequency);
if (retval 0)
@@ -423,7 +423,7 @@ static int vidioc_s_frequency(struct file *file, void *priv,
static int vidioc_g_frequency(struct file *file, void *priv,
struct v4l2_frequency *f)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
f-type = V4L2_TUNER_RADIO;
f-frequency = radio-curfreq;
@@ -444,7 +444,7 @@ static int vidioc_queryctrl(struct file *file, void *priv,
static int vidioc_g_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
@@ -457,7 +457,7 @@ static int vidioc_g_ctrl(struct file *file, void *priv,
static int vidioc_s_ctrl(struct file *file, void *priv,
struct v4l2_control *ctrl)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = priv;
int retval;
switch (ctrl-id) {
@@ -518,7 +518,7 @@ static int vidioc_s_audio(struct file *file, void *priv,
static long usb_dsbr100_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
- struct dsbr100_device *radio = video_drvdata(file);
+ struct dsbr100_device *radio = file-private_data;
long retval = 0;
mutex_lock(radio-lock);
@@ -557,6 +557,7 @@ static int usb_dsbr100_open(struct file *file)
radio-status |= INITIALIZED;
}
+ file-private_data = radio;
unlock:
mutex_unlock(radio-lock);
return retval;
--
1.7.1
--
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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Wed May 5 19:00:28 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14644:4a8d6d981f07 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 562dac038aef2a1719710b5703b15732cbc4354b gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: ERRORS linux-2.6.33-armv5: ERRORS linux-2.6.34-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: ERRORS linux-2.6.34-rc1-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: ERRORS linux-2.6.34-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: ERRORS linux-2.6.34-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS 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: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: 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] fix dvb frontend lockup
matthieu castet a écrit :
Hi,
With my current kernel (2.6.32), if my dvb device is removed while in use, I
got [1].
After checking the source code, the problem seems to happen also in master :
If there are users (for example users == -2) :
- dvb_unregister_frontend :
- stop kernel thread with dvb_frontend_stop :
- fepriv-exit = 1;
- thread loop catch stop event and break while loop
- fepriv-thread = NULL; and fepriv-exit = 0;
- dvb_unregister_frontend wait on fepriv-dvbdev-wait_queue that
fepriv-dvbdev-users==-1.
The user finish :
- dvb_frontend_release - set users to -1
- don't wait wait_queue because fepriv-exit != 1
= dvb_unregister_frontend never exit the wait queue.
Matthieu
[ 4920.484047] khubd D c2008000 0 198 2 0x
[ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000 c13fa000 f
64c8000
[ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001 f64c8000 c
102daad
[ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404 f644de58 f
092b0a8
[ 4920.484084] Call Trace:
[ 4920.484102] [c102daad] ? default_wake_function+0x0/0x8
[ 4920.484147] [f8cb09e1] ? dvb_unregister_frontend+0x95/0xcc [dvb_core]
[ 4920.484157] [c1044412] ? autoremove_wake_function+0x0/0x2d
[ 4920.484168] [f8dd1af2] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb]
[ 4920.484176] [f8dd12f1] ? dvb_usb_exit+0x26/0x88 [dvb_usb]
[ 4920.484184] [f8dd138d] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb]
[ 4920.484217] [f7fe1b08] ? usb_unbind_interface+0x3f/0xb4 [usbcore]
[ 4920.484227] [c11a4178] ? __device_release_driver+0x74/0xb7
[ 4920.484233] [c11a4247] ? device_release_driver+0x15/0x1e
[ 4920.484243] [c11a3a33] ? bus_remove_device+0x6e/0x87
[ 4920.484249] [c11a26d6] ? device_del+0xfa/0x152
[ 4920.484264] [f7fdf609] ? usb_disable_device+0x59/0xb9 [usbcore]
[ 4920.484279] [f7fdb9ee] ? usb_disconnect+0x70/0xdc [usbcore]
[ 4920.484294] [f7fdc728] ? hub_thread+0x521/0xe1d [usbcore]
[ 4920.484301] [c1044412] ? autoremove_wake_function+0x0/0x2d
[ 4920.484316] [f7fdc207] ? hub_thread+0x0/0xe1d [usbcore]
[ 4920.484321] [c10441e0] ? kthread+0x61/0x66
[ 4920.484327] [c104417f] ? kthread+0x0/0x66
[ 4920.484336] [c1003d47] ? kernel_thread_helper+0x7/0x10
Here a patch that fix the issue
Signed-off-by: Matthieu CASTET castet.matth...@free.fr
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 55ea260..6932def 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -95,6 +95,10 @@ MODULE_PARM_DESC(dvb_mfe_wait_time, Wait up to mfe_wait_time seconds on open(
* FESTATE_LOSTLOCK. When the lock has been lost, and we're searching it again.
*/
+#define DVB_FE_NO_EXIT 0
+#define DVB_FE_NORMAL_EXIT 1
+#define DVB_FE_DEVICE_REMOVED 2
+
static DEFINE_MUTEX(frontend_mutex);
struct dvb_frontend_private {
@@ -497,7 +501,7 @@ static int dvb_frontend_is_exiting(struct dvb_frontend *fe)
{
struct dvb_frontend_private *fepriv = fe-frontend_priv;
- if (fepriv-exit)
+ if (fepriv-exit != DVB_FE_NO_EXIT)
return 1;
if (fepriv-dvbdev-writers == 1)
@@ -559,7 +563,7 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
- fepriv-exit = 1;
+ fepriv-exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -673,7 +677,10 @@ restart:
}
fepriv-thread = NULL;
- fepriv-exit = 0;
+ if (kthread_should_stop())
+ fepriv-exit = DVB_FE_DEVICE_REMOVED;
+ else
+ fepriv-exit = DVB_FE_NO_EXIT;
mb();
dvb_frontend_wakeup(fe);
@@ -686,7 +693,7 @@ static void dvb_frontend_stop(struct dvb_frontend *fe)
dprintk (%s\n, __func__);
- fepriv-exit = 1;
+ fepriv-exit = DVB_FE_NORMAL_EXIT;
mb();
if (!fepriv-thread)
@@ -755,7 +762,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
dprintk (%s\n, __func__);
if (fepriv-thread) {
- if (!fepriv-exit)
+ if (fepriv-exit == DVB_FE_NO_EXIT)
return 0;
else
dvb_frontend_stop (fe);
@@ -767,7 +774,7 @@ static int dvb_frontend_start(struct dvb_frontend *fe)
return -EINTR;
fepriv-state = FESTATE_IDLE;
- fepriv-exit = 0;
+ fepriv-exit = DVB_FE_NO_EXIT;
fepriv-thread = NULL;
mb();
@@ -1490,7 +1497,7 @@ static int dvb_frontend_ioctl(struct inode *inode, struct file *file,
dprintk(%s (%d)\n, __func__, _IOC_NR(cmd));
- if (fepriv-exit)
+ if (fepriv-exit != DVB_FE_NO_EXIT)
return -ENODEV;
if ((file-f_flags O_ACCMODE) == O_RDONLY
@@ -1916,6 +1923,8 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)
int ret;
dprintk (%s\n, __func__);
+ if (fepriv-exit == DVB_FE_DEVICE_REMOVED)
+ return -ENODEV;
if (adapter-mfe_shared) {
mutex_lock (adapter-mfe_lock);
@@ -2008,7 +2017,7 @@ static int dvb_frontend_release(struct inode *inode, struct file *file)
ret = dvb_generic_release (inode, file);
if (dvbdev-users == -1) {
- if (fepriv-exit == 1) {
+ if (fepriv-exit != DVB_FE_NO_EXIT) {
[PATCH] videobuf: remove external function videobuf_dma_sync()
While analyzing one of the videobuf patches, I noticed that
videobuf_dma_sync is only used internally inside videobuf-dma-sg.
So, let's remove this function, merging the code at __videobuf_dma_sync()
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index f733833..b49f1e2 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -279,17 +279,6 @@ int videobuf_dma_map(struct videobuf_queue *q, struct
videobuf_dmabuf *dma)
}
EXPORT_SYMBOL_GPL(videobuf_dma_map);
-int videobuf_dma_sync(struct videobuf_queue *q, struct videobuf_dmabuf *dma)
-{
- MAGIC_CHECK(dma-magic, MAGIC_DMABUF);
- BUG_ON(!dma-sglen);
-
- dma_sync_sg_for_cpu(q-dev, dma-sglist, dma-nr_pages, dma-direction);
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(videobuf_dma_sync);
-
int videobuf_dma_unmap(struct videobuf_queue *q, struct videobuf_dmabuf *dma)
{
MAGIC_CHECK(dma-magic, MAGIC_DMABUF);
@@ -542,10 +531,15 @@ static int __videobuf_sync(struct videobuf_queue *q,
struct videobuf_buffer *buf)
{
struct videobuf_dma_sg_memory *mem = buf-priv;
- BUG_ON(!mem);
+ BUG_ON(!mem || !mem-dma.sglen);
+
MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
+ MAGIC_CHECK(mem-dma.magic, MAGIC_DMABUF);
- return videobuf_dma_sync(q, mem-dma);
+ dma_sync_sg_for_cpu(q-dev, mem-dma.sglist,
+ mem-dma.nr_pages, mem-dma.direction);
+
+ return 0;
}
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
diff --git a/include/media/videobuf-dma-sg.h b/include/media/videobuf-dma-sg.h
index dbfd8cf..a195f3b 100644
--- a/include/media/videobuf-dma-sg.h
+++ b/include/media/videobuf-dma-sg.h
@@ -97,7 +97,6 @@ int videobuf_dma_init_overlay(struct videobuf_dmabuf *dma,
int direction,
int videobuf_dma_free(struct videobuf_dmabuf *dma);
int videobuf_dma_map(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
-int videobuf_dma_sync(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
int videobuf_dma_unmap(struct videobuf_queue *q, struct videobuf_dmabuf *dma);
struct videobuf_dmabuf *videobuf_to_dma(struct videobuf_buffer *buf);
--
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: -next: staging/cx25821: please revert 7a02f549fcc
On Wed, May 05, 2010 at 12:30:01PM -0300, Mauro Carvalho Chehab wrote:
This simplifies the code a little bit, and, instead of just return -EINVAL,
it will return the error condition reported by the called functions.
Thanks for that.
There was one return that got missed. Probably you can fold it into
your patch?
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index 7545314..34616dc 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -849,10 +849,8 @@ int medusa_video_init(struct cx25821_dev *dev)
value |= 7;
ret_val = cx25821_i2c_write(dev-i2c_bus[0], PIN_OE_CTRL, value);
- if (ret_val 0) {
- mutex_unlock(dev-lock);
- return -EINVAL;
- }
+ if (ret_val 0)
+ goto error;
mutex_unlock(dev-lock);
--
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] videobuf-vmalloc: remove __videobuf_sync()
videobuf-core checks if .sync ops is defined before calling.
So, we don't need a do-nothing function.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
--
Cheers,
Mauro
diff --git a/drivers/media/video/videobuf-vmalloc.c
b/drivers/media/video/videobuf-vmalloc.c
index f8b5b56..583728f 100644
--- a/drivers/media/video/videobuf-vmalloc.c
+++ b/drivers/media/video/videobuf-vmalloc.c
@@ -229,12 +229,6 @@ static int __videobuf_iolock(struct videobuf_queue *q,
return 0;
}
-static int __videobuf_sync(struct videobuf_queue *q,
- struct videobuf_buffer *buf)
-{
- return 0;
-}
-
static int __videobuf_mmap_mapper(struct videobuf_queue *q,
struct videobuf_buffer *buf,
struct vm_area_struct *vma)
@@ -301,7 +295,6 @@ static struct videobuf_qtype_ops qops = {
.alloc= __videobuf_alloc,
.iolock = __videobuf_iolock,
- .sync = __videobuf_sync,
.mmap_mapper = __videobuf_mmap_mapper,
.vaddr= videobuf_to_vmalloc,
};
--
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/RFC 1/7] dsbr100: implement proper locking
On Wednesday 05 May 2010 19:05:24 David Ellingsworth wrote:
Signed-off-by: David Ellingsworth da...@identd.dyndns.org
Does this actually fix bugs or does this just clean up the locking?
I ask because I am planning to make it easier to do locking for ioctl calls.
Basically there will be pre-hook and post-hook callbacks that are called before
and after an ioctl and where you can do the locking. I am waiting for a patch
series related to priority handling to go in first, then I will work on this
change.
So from my perspective I am OK with this if it fixes bugs, but if it is
just a clean up, then it might be better to wait until my new callbacks are in.
I won't block this, though. It's just FYI.
Regards,
Hans
---
drivers/media/radio/dsbr100.c | 77 +---
1 files changed, 33 insertions(+), 44 deletions(-)
diff --git a/drivers/media/radio/dsbr100.c b/drivers/media/radio/dsbr100.c
index ed9cd7a..673eda8 100644
--- a/drivers/media/radio/dsbr100.c
+++ b/drivers/media/radio/dsbr100.c
@@ -182,7 +182,7 @@ static int dsbr100_start(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -207,11 +207,9 @@ static int dsbr100_start(struct dsbr100_device *radio)
}
radio-status = STARTED;
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -225,7 +223,7 @@ static int dsbr100_stop(struct dsbr100_device *radio)
int retval;
int request;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -250,11 +248,9 @@ static int dsbr100_stop(struct dsbr100_device *radio)
}
radio-status = STOPPED;
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -269,7 +265,7 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
int request;
int freq = (radio-curfreq / 16 * 80) / 1000 + 856;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -306,12 +302,10 @@ static int dsbr100_setfreq(struct dsbr100_device *radio)
}
radio-stereo = !((radio-transfer_buffer)[0] 0x01);
- mutex_unlock(radio-lock);
return (radio-transfer_buffer)[0];
usb_control_msg_failed:
radio-stereo = -1;
- mutex_unlock(radio-lock);
dev_err(radio-usbdev-dev,
%s - usb_control_msg returned %i, request %i\n,
__func__, retval, request);
@@ -324,7 +318,7 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
{
int retval;
- mutex_lock(radio-lock);
+ BUG_ON(!mutex_is_locked(radio-lock));
retval = usb_control_msg(radio-usbdev,
usb_rcvctrlpipe(radio-usbdev, 0),
@@ -340,8 +334,6 @@ static void dsbr100_getstat(struct dsbr100_device *radio)
} else {
radio-stereo = !(radio-transfer_buffer[0] 0x01);
}
-
- mutex_unlock(radio-lock);
}
/* USB subsystem interface begins here */
@@ -385,10 +377,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
{
struct dsbr100_device *radio = video_drvdata(file);
- /* safety check */
- if (radio-removed)
- return -EIO;
-
if (v-index 0)
return -EINVAL;
@@ -410,12 +398,6 @@ static int vidioc_g_tuner(struct file *file, void *priv,
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
- struct dsbr100_device *radio = video_drvdata(file);
-
- /* safety check */
- if (radio-removed)
- return -EIO;
-
if (v-index 0)
return -EINVAL;
@@ -428,17 +410,12 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct dsbr100_device *radio = video_drvdata(file);
int retval;
- /* safety check */
- if (radio-removed)
- return -EIO;
-
- mutex_lock(radio-lock);
radio-curfreq = f-frequency;
- mutex_unlock(radio-lock);
retval = dsbr100_setfreq(radio);
if (retval 0)
dev_warn(radio-usbdev-dev, Set frequency failed\n);
+
return 0;
}
@@ -447,10 +424,6 @@ static int
[GIT PATCHES FOR 2.6.35] tvp7002 fixes
The following changes since commit d3be2fab3a10b6c798a5f9970146d166d3345c37: Jean-François Moine (1): V4L/DVB: gspca - zc3xx: Fix the gamma calculation from the contrast are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git tvp7002 Tested on a DM6467T eval board. Regards, Hans Mats Randgaard (3): v4l2-subdev.h: Add support for enum_dv_preset tvp7002.c: Add support for enum_dv_presets tvp7002.c: fix some copy-paste errors in the comments drivers/media/video/tvp7002.c | 40 +--- include/media/v4l2-subdev.h |2 ++ 2 files changed, 31 insertions(+), 11 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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
[videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call?
Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? I'll appreciate your inputs on this matter. Regards, Sergio -- 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 v1 1/1] V4L: Add sync before a hardware operation to videobuf.
Pawel Osciak wrote:
Architectures with non-coherent CPU cache (e.g. ARM) may require a cache
flush or invalidation before starting a hardware operation if the data in
a video buffer being queued has been touched by the CPU.
This patch adds calls to sync before a hardware operation that are expected
to be interpreted and handled by each memory type-specific module.
Whether it is a sync before or after the operation can be determined from
the current buffer state: VIDEOBUF_DONE and VIDEOBUF_ERROR indicate a sync
called after an operation.
Hi Pawel,
After analyzing this patch, maybe the better is to add a check for dma
coherency. So, instead of directly calling sync,the better is to check
if !dma_is_consistent(), to avoid adding a penalty on architectures
where the cache is coherent.
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index bb0a1c8..e56c67a 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -561,6 +561,8 @@ int videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
+ CALL(q, sync, q, buf);
+
list_add_tail(buf-stream, q-stream);
if (q-streaming) {
spin_lock_irqsave(q-irqlock, flags);
@@ -761,6 +763,8 @@ static ssize_t videobuf_read_zerocopy(struct
videobuf_queue *q,
if (0 != retval)
goto done;
+ CALL(q, sync, q, q-read_buf);
+
/* start capture wait */
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
@@ -826,6 +830,8 @@ ssize_t videobuf_read_one(struct videobuf_queue *q,
goto done;
}
+ CALL(q, sync, q, q-read_buf);
+
spin_lock_irqsave(q-irqlock, flags);
q-ops-buf_queue(q, q-read_buf);
spin_unlock_irqrestore(q-irqlock, flags);
@@ -893,6 +899,9 @@ static int __videobuf_read_start(struct videobuf_queue *q)
err = q-ops-buf_prepare(q, q-bufs[i], field);
if (err)
return err;
+
+ CALL(q, sync, q, q-read_buf);
+
list_add_tail(q-bufs[i]-stream, q-stream);
}
spin_lock_irqsave(q-irqlock, flags);
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index fa78555..2b153f8 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -50,6 +50,9 @@ MODULE_LICENSE(GPL);
#define dprintk(level, fmt, arg...) if (debug = level) \
printk(KERN_DEBUG vbuf-sg: fmt , ## arg)
+#define is_sync_after(vb) \
+ (vb-state == VIDEOBUF_DONE || vb-state == VIDEOBUF_ERROR)
+
/* - */
struct scatterlist*
@@ -516,6 +519,9 @@ static int __videobuf_sync(struct videobuf_queue *q,
BUG_ON(!mem);
MAGIC_CHECK(mem-magic,MAGIC_SG_MEM);
+ if (!is_sync_after(buf))
+ return 0;
+
return videobuf_dma_sync(q,mem-dma);
}
--
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
[RFC] Third OLPC viafb patch series (camera driver)
This is, perhaps, the last set of viafb patches I'll send around before the merge window. This series completes the task of adding the via-camera driver - in the correct spot, this time. To that end, it has to reorganize the viafb header files a bit. V4L2 folks: only the final patch in this series really needs your attention. Note that it has no hope of appying or working without a long series of predecessor patches; the full set, prior to this series, is currently in linux-next. If the driver is acceptable to you, I'd prefer to merge it through my viafb tree to be sure all the prerequisites land in mainline at the right time. As usual, this series can be found at: git://git.lwn.net/linux-2.6.git viafb-posted The camera driver has been cleaned up a bit since the last time around. But the main thing I had to do was to make some of the header files globally visible so I could put the camera driver with the rest of the V4L2 crowd. This will also let us move the core, i2c, and gpio drivers to drivers/mfd, should we want to in the future. There shouldn't be any functionality changes beyond the new driver. Comments? Thanks, jon Jonathan Corbet (5): viafb: fold via_io.h into via-core.h viafb: get rid of i2c debug cruft viafb: Eliminate some global.h references viafb: move some include files to include/linux Add the viafb video capture driver b/drivers/media/video/Kconfig | 10 b/drivers/media/video/Makefile|2 b/drivers/media/video/via-camera.c| 1368 ++ b/drivers/media/video/via-camera.h| 93 ++ b/drivers/video/via/accel.c |4 b/drivers/video/via/dvi.c |4 b/drivers/video/via/hw.c |3 b/drivers/video/via/hw.h |1 b/drivers/video/via/lcd.c |4 b/drivers/video/via/share.h | 11 b/drivers/video/via/via-core.c| 22 b/drivers/video/via/via-gpio.c|5 b/drivers/video/via/via_i2c.c | 14 b/drivers/video/via/via_modesetting.c |2 b/drivers/video/via/via_utility.c |1 b/drivers/video/via/viafbdev.c|4 b/drivers/video/via/viamode.c |1 b/drivers/video/via/vt1636.c |4 b/include/linux/via-core.h| 221 + b/include/linux/via-gpio.h| 14 b/include/linux/via_i2c.h | 42 + b/include/media/v4l2-chip-ident.h |4 drivers/video/via/via-core.h | 173 drivers/video/via/via-gpio.h | 14 drivers/video/via/via_i2c.h | 42 - drivers/video/via/via_io.h| 67 - 26 files changed, 1798 insertions(+), 332 deletions(-) -- 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 2/5] viafb: get rid of i2c debug cruft
It's ugly and adds a global.h dependency.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/video/via/via_i2c.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c
index febc1dd..84ec2d6 100644
--- a/drivers/video/via/via_i2c.c
+++ b/drivers/video/via/via_i2c.c
@@ -52,7 +52,7 @@ static void via_i2c_setscl(void *data, int state)
val |= 0x80;
break;
default:
- DEBUG_MSG(viafb_i2c: specify wrong i2c type.\n);
+ printk(KERN_ERR viafb_i2c: specify wrong i2c type.\n);
}
via_write_reg(adap_data-io_port, adap_data-ioport_index, val);
spin_unlock_irqrestore(i2c_vdev-reg_lock, flags);
@@ -104,7 +104,7 @@ static void via_i2c_setsda(void *data, int state)
val |= 0x40;
break;
default:
- DEBUG_MSG(viafb_i2c: specify wrong i2c type.\n);
+ printk(KERN_ERR viafb_i2c: specify wrong i2c type.\n);
}
via_write_reg(adap_data-io_port, adap_data-ioport_index, val);
spin_unlock_irqrestore(i2c_vdev-reg_lock, flags);
@@ -175,8 +175,6 @@ static int create_i2c_bus(struct i2c_adapter *adapter,
struct via_port_cfg *adap_cfg,
struct pci_dev *pdev)
{
- DEBUG_MSG(KERN_DEBUG viafb: creating bus adap=0x%p,
algo_bit_data=0x%p, adap_cfg=0x%p\n, adapter, algo, adap_cfg);
-
algo-setsda = via_i2c_setsda;
algo-setscl = via_i2c_setscl;
algo-getsda = via_i2c_getsda;
--
1.7.0.1
--
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 1/5] viafb: fold via_io.h into via-core.h
Preparatory move toward the ultimate goal of moving pan-subdevice stuff
into include/linux.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/video/via/hw.h |1 -
drivers/video/via/share.h | 11 ++
drivers/video/via/via-core.h| 48 -
drivers/video/via/via_io.h | 67 ---
drivers/video/via/via_modesetting.c |2 +-
drivers/video/via/via_utility.c |1 +
drivers/video/via/viamode.c |1 +
7 files changed, 53 insertions(+), 78 deletions(-)
delete mode 100644 drivers/video/via/via_io.h
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index a58701f..a109de3 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -24,7 +24,6 @@
#include viamode.h
#include global.h
-#include via_io.h
#include via_modesetting.h
#define viafb_read_reg(p, i) via_read_reg(p, i)
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 861b414..7f0de7f 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -43,14 +43,9 @@
/* Video Memory Size */
#define VIDEO_MEMORY_SIZE_16M0x100
-/* standard VGA IO port
-*/
-#define VIAStatus 0x3DA
-#define VIACR 0x3D4
-#define VIASR 0x3C4
-#define VIAGR 0x3CE
-#define VIAAR 0x3C0
-
+/*
+ * Lengths of the VPIT structure arrays.
+ */
#define StdCR 0x19
#define StdSR 0x04
#define StdGR 0x09
diff --git a/drivers/video/via/via-core.h b/drivers/video/via/via-core.h
index 087c562..7ffb521 100644
--- a/drivers/video/via/via-core.h
+++ b/drivers/video/via/via-core.h
@@ -1,7 +1,8 @@
/*
* Copyright 1998-2009 VIA Technologies, Inc. All Rights Reserved.
* Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2009 Jonathan Corbet cor...@lwn.net
+ * Copyright 2009-2010 Jonathan Corbet cor...@lwn.net
+ * Copyright 2010 Florian Tobias Schandinat florianschandi...@gmx.de
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public
@@ -22,6 +23,8 @@
#ifndef __VIA_CORE_H__
#define __VIA_CORE_H__
+#include linux/types.h
+#include linux/io.h
#include linux/spinlock.h
#include linux/pci.h
@@ -170,4 +173,47 @@ int viafb_dma_copy_out_sg(unsigned int offset, struct
scatterlist *sg, int nsg);
#define VGA_WIDTH 640
#define VGA_HEIGHT 480
+/*
+ * Indexed port operations. Note that these are all multi-op
+ * functions; every invocation will be racy if you're not holding
+ * reg_lock.
+ */
+
+#define VIAStatus 0x3DA /* Non-indexed port */
+#define VIACR 0x3D4
+#define VIASR 0x3C4
+#define VIAGR 0x3CE
+#define VIAAR 0x3C0
+
+static inline u8 via_read_reg(u16 port, u8 index)
+{
+ outb(index, port);
+ return inb(port + 1);
+}
+
+static inline void via_write_reg(u16 port, u8 index, u8 data)
+{
+ outb(index, port);
+ outb(data, port + 1);
+}
+
+static inline void via_write_reg_mask(u16 port, u8 index, u8 data, u8 mask)
+{
+ u8 old;
+
+ outb(index, port);
+ old = inb(port + 1);
+ outb((data mask) | (old ~mask), port + 1);
+}
+
+#define VIA_MISC_REG_READ 0x03CC
+#define VIA_MISC_REG_WRITE 0x03C2
+
+static inline void via_write_misc_reg_mask(u8 data, u8 mask)
+{
+ u8 old = inb(VIA_MISC_REG_READ);
+ outb((data mask) | (old ~mask), VIA_MISC_REG_WRITE);
+}
+
+
#endif /* __VIA_CORE_H__ */
diff --git a/drivers/video/via/via_io.h b/drivers/video/via/via_io.h
deleted file mode 100644
index a3d2aca..000
--- a/drivers/video/via/via_io.h
+++ /dev/null
@@ -1,67 +0,0 @@
-/*
- * Copyright 1998-2008 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2010 Florian Tobias Schandinat florianschandi...@gmx.de
- *
- * 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, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
- * the implied warranty of MERCHANTABILITY or FITNESS FOR
- * A PARTICULAR PURPOSE.See the GNU General Public License
- * for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-/*
- * basic io functions
- */
-
-#ifndef __VIA_IO_H__
-#define __VIA_IO_H__
-
-#include linux/types.h
-#include linux/io.h
-
-#define VIA_MISC_REG_READ 0x03CC
-#define VIA_MISC_REG_WRITE 0x03C2
-
-/*
- * Indexed port operations. Note that these are all multi-op
- * functions; every invocation will be racy if you're not holding
- * reg_lock.
-
[PATCH 5/5] Add the viafb video capture driver
Add a driver for the video capture port on VIA integrated chipsets. This
version has a remaining OLPCism or two and expects to be talking to an
ov7670; those can be improved as the need arises.
This work was supported by the One Laptop Per Child project.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Kconfig | 10 +
drivers/media/video/Makefile |2 +
drivers/media/video/via-camera.c | 1368 ++
drivers/media/video/via-camera.h | 93 +++
drivers/video/via/accel.c|2 +-
drivers/video/via/via-core.c | 16 +-
include/linux/via-core.h |4 +-
include/media/v4l2-chip-ident.h |4 +
8 files changed, 1495 insertions(+), 4 deletions(-)
create mode 100644 drivers/media/video/via-camera.c
create mode 100644 drivers/media/video/via-camera.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f8fc865..198636b 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -833,6 +833,16 @@ config VIDEO_CAFE_CCIC
CMOS camera controller. This is the controller found on first-
generation OLPC systems.
+config VIDEO_VIA_CAMERA
+ tristate VIAFB camera controller support
+ depends on FB_VIA
+ select VIDEOBUF_DMA_SG
+ select VIDEO_OV7670
+ help
+ Driver support for the integrated camera controller in VIA
+ Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
+ with ov7670 sensors.
+
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 b88b617..089bb24 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -123,6 +123,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
+obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
+
obj-$(CONFIG_USB_DABUSB)+= dabusb.o
obj-$(CONFIG_USB_OV511) += ov511.o
obj-$(CONFIG_USB_SE401) += se401.o
diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c
new file mode 100644
index 000..7b1ff0c
--- /dev/null
+++ b/drivers/media/video/via-camera.c
@@ -0,0 +1,1368 @@
+/*
+ * Driver for the VIA Chrome integrated camera controller.
+ *
+ * Copyright 2009,2010 Jonathan Corbet cor...@lwn.net
+ * Distributable under the terms of the GNU General Public License, version 2
+ *
+ * This work was supported by the One Laptop Per Child project
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/list.h
+#include linux/pci.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-chip-ident.h
+#include media/videobuf-dma-sg.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/dma-mapping.h
+#include linux/pm_qos_params.h
+#include linux/via-core.h
+#include linux/via-gpio.h
+#include linux/via_i2c.h
+
+#include via-camera.h
+
+MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
+MODULE_DESCRIPTION(VIA framebuffer-based camera controller driver);
+MODULE_LICENSE(GPL);
+
+static int flip_image;
+module_param(flip_image, bool, 0444);
+MODULE_PARM_DESC(flip_image,
+ If set, the sensor will be instructed to flip the image
+ vertically.);
+
+#ifdef CONFIG_OLPC_XO_1_5
+static int override_serial;
+module_param(override_serial, bool, 0444);
+MODULE_PARM_DESC(override_serial,
+ The camera driver will normally refuse to load if
+ the XO 1.5 serial port is enabled. Set this option
+ to force the issue.);
+#endif
+
+/*
+ * Basic window sizes.
+ */
+#define VGA_WIDTH 640
+#define VGA_HEIGHT 480
+#define QCIF_WIDTH 176
+#defineQCIF_HEIGHT 144
+
+/*
+ * The structure describing our camera.
+ */
+enum viacam_opstate { S_IDLE = 0, S_RUNNING = 1 };
+
+static struct via_camera {
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct v4l2_subdev *sensor;
+ struct platform_device *platdev;
+ struct viafb_dev *viadev;
+ struct mutex lock;
+ enum viacam_opstate opstate;
+ unsigned long flags;
+ /*
+* GPIO info for power/reset management
+*/
+ int power_gpio;
+ int reset_gpio;
+ /*
+* I/O memory stuff.
+*/
+ void __iomem *mmio; /* Where the registers live */
+ void __iomem *fbmem;/* Frame buffer memory */
+ u32 fb_offset; /* Reserved memory offset (FB) */
+ /*
+* Capture buffers and related. The controller supports
+* up to three, so that's what we have here. These buffers
+* live in frame buffer memory, so we don't call them DMA.
+*/
+ unsigned int
[PATCH 4/5] viafb: move some include files to include/linux
These are the files which should be available to subdevices compiled
outside of drivers/video/via.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/video/via/accel.c |2 +-
drivers/video/via/dvi.c |4 +-
drivers/video/via/hw.c |3 +-
drivers/video/via/lcd.c |4 +-
drivers/video/via/via-core.c|6 +-
drivers/video/via/via-core.h| 219 ---
drivers/video/via/via-gpio.c|4 +-
drivers/video/via/via-gpio.h| 14 ---
drivers/video/via/via_i2c.c |4 +-
drivers/video/via/via_i2c.h | 42 ---
drivers/video/via/via_modesetting.c |2 +-
drivers/video/via/via_utility.c |2 +-
drivers/video/via/viafbdev.c|4 +-
drivers/video/via/viamode.c |2 +-
drivers/video/via/vt1636.c |4 +-
include/linux/via-core.h| 219 +++
include/linux/via-gpio.h| 14 +++
include/linux/via_i2c.h | 42 +++
18 files changed, 296 insertions(+), 295 deletions(-)
delete mode 100644 drivers/video/via/via-core.h
delete mode 100644 drivers/video/via/via-gpio.h
delete mode 100644 drivers/video/via/via_i2c.h
create mode 100644 include/linux/via-core.h
create mode 100644 include/linux/via-gpio.h
create mode 100644 include/linux/via_i2c.h
diff --git a/drivers/video/via/accel.c b/drivers/video/via/accel.c
index 189aba4..e44893e 100644
--- a/drivers/video/via/accel.c
+++ b/drivers/video/via/accel.c
@@ -18,7 +18,7 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include via-core.h
+#include linux/via-core.h
#include global.h
/*
diff --git a/drivers/video/via/dvi.c b/drivers/video/via/dvi.c
index 6271b76..39b040b 100644
--- a/drivers/video/via/dvi.c
+++ b/drivers/video/via/dvi.c
@@ -18,8 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include via-core.h
-#include via_i2c.h
+#include linux/via-core.h
+#include linux/via_i2c.h
#include global.h
static void tmds_register_write(int index, u8 data);
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index e356fe8..b996803 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -18,7 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include via-core.h
+
+#include linux/via-core.h
#include global.h
static struct pll_map pll_value[] = {
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 04eec31..2ab0f15 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -18,8 +18,8 @@
* Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
-#include via-core.h
-#include via_i2c.h
+#include linux/via-core.h
+#include linux/via_i2c.h
#include global.h
#include lcdtbl.h
diff --git a/drivers/video/via/via-core.c b/drivers/video/via/via-core.c
index c7d37a0..15fcaab 100644
--- a/drivers/video/via/via-core.c
+++ b/drivers/video/via/via-core.c
@@ -7,9 +7,9 @@
/*
* Core code for the Via multifunction framebuffer device.
*/
-#include via-core.h
-#include via_i2c.h
-#include via-gpio.h
+#include linux/via-core.h
+#include linux/via_i2c.h
+#include linux/via-gpio.h
#include global.h
#include linux/module.h
diff --git a/drivers/video/via/via-core.h b/drivers/video/via/via-core.h
deleted file mode 100644
index 7ffb521..000
--- a/drivers/video/via/via-core.h
+++ /dev/null
@@ -1,219 +0,0 @@
-/*
- * Copyright 1998-2009 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2008 S3 Graphics, Inc. All Rights Reserved.
- * Copyright 2009-2010 Jonathan Corbet cor...@lwn.net
- * Copyright 2010 Florian Tobias Schandinat florianschandi...@gmx.de
- *
- * 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, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTIES OR REPRESENTATIONS; without even
- * the implied warranty of MERCHANTABILITY or FITNESS FOR
- * A PARTICULAR PURPOSE.See the GNU General Public License
- * for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- */
-
-#ifndef __VIA_CORE_H__
-#define __VIA_CORE_H__
-#include linux/types.h
-#include linux/io.h
-#include linux/spinlock.h
-#include linux/pci.h
-
-/*
- * A description of each known serial I2C/GPIO port.
- */
-enum via_port_type {
- VIA_PORT_NONE = 0,
- VIA_PORT_I2C,
- VIA_PORT_GPIO,
-};
-
-enum via_port_mode {
- VIA_MODE_OFF = 0,
- VIA_MODE_I2C, /* Used as I2C port */
-
[PATCH 3/5] viafb: Eliminate some global.h references
The various subdev drivers (other than the framebuffer itself) no longer need this file. Signed-off-by: Jonathan Corbet cor...@lwn.net --- drivers/video/via/via-gpio.c |1 - drivers/video/via/via_i2c.c |4 +++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/via/via-gpio.c b/drivers/video/via/via-gpio.c index 63cb7ac..67d699c 100644 --- a/drivers/video/via/via-gpio.c +++ b/drivers/video/via/via-gpio.c @@ -10,7 +10,6 @@ #include linux/platform_device.h #include via-core.h #include via-gpio.h -#include global.h /* * The ports we know about. Note that the port-25 gpios are not diff --git a/drivers/video/via/via_i2c.c b/drivers/video/via/via_i2c.c index 84ec2d6..2291765 100644 --- a/drivers/video/via/via_i2c.c +++ b/drivers/video/via/via_i2c.c @@ -20,9 +20,11 @@ */ #include linux/platform_device.h +#include linux/delay.h +#include linux/spinlock.h +#include linux/module.h #include via-core.h #include via_i2c.h -#include global.h /* * There can only be one set of these, so there's no point in having -- 1.7.0.1 -- 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 -next] media: fix vivi build error
From: Randy Dunlap randy.dun...@oracle.com vivi uses find_font(), which is only available when FONTS is enabled, so make vivi depend on FONTS. ERROR: find_font [drivers/media/video/vivi.ko] undefined! Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/video/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20100505.orig/drivers/media/video/Kconfig +++ linux-next-20100505/drivers/media/video/Kconfig @@ -559,7 +559,7 @@ config VIDEO_DAVINCI_VPIF config VIDEO_VIVI tristate Virtual Video Driver - depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 + depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 FONTS select FONT_8x16 select VIDEOBUF_VMALLOC default n -- 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
setting up a tevii s660
Hullo I've been struggling with this for a couple of days. I have checked archives, but missed anything useful. I've got a tevii s660 (dvbs2 via usb). It works with some limitations on windows xp (I cannot get HD signals decoded, but think that's a limitation of the software that comes on the CD). I'm trying to get this working on Linux. I've tried VMs based on fedora 12 and mythbuntu (VMWare Fusion on a MacBookPro, both based on kernel 2.6.32), using the drivers from tevii's site (www.tevii.com/support.asp) . these drivers are slightly modified versions of the v4l tip - but don't appear to be modified where I've not yet managed to get the drivers working :-(. Mythbuntu seems to be closest to working. Goodness knows how tevii tested the code, but it doesn't seem to work as far as I can see. My issues could just be down to using a VM. I believe that I need to load up the modules ds3000 and dvb-usb- dw2102, + add a rule to /etc/udev/rules.d and a script to /etc/udev/ scripts. I think that I must be missing quite a lot of context, tho'. When I look at the code in dw2102.c, which seems to support the s660, the bit that downloads the firmware looks broken and if I add a default clause to the switch that does the download, the s660's missed the download process. This could be why when I do get anything out of the device it looks like I'm just getting repeated bytes (the same value repeated, different values at different times, sometimes nothing). I'm finding it non-trivial working out the call sequences of the code or devising repeatable tests. Can anyone kick me off on getting this working? I'd like to at least get to the point where scandvb can tune the device. It does look like some folk have had success in the past, but probably with totally different codebase (there are posts that refer to the teviis660 module, which I cannot find). Any pointer gratefully accepted. I'll feed back any success if I can be pointed at where to drop document it. tia Tim -- 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call?
Aguirre, Sergio wrote: Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? I don't see any problem on propagating the memory type to buffer_setup, if this is really needed. Yet, I can't see why you would restrict the buffer size to 32 MB on one case, and not restrict the size at all with non-MMAP types. I'll appreciate your inputs on this matter. Regards, Sergio -- 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 -- 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call?
-Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Wednesday, May 05, 2010 6:24 PM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call? Aguirre, Sergio wrote: Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? I don't see any problem on propagating the memory type to buffer_setup, if this is really needed. Yet, I can't see why you would restrict the buffer size to 32 MB on one case, and not restrict the size at all with non-MMAP types. Ok, my reason for doing that is because I thought that there should be a memory limit in whichever place you're doing the buffer allocations. MMAP is allocating buffers in kernel, so kernel should provide a memory restriction, if applies. USERPTR is allocating buffers in userspace, so userspace should provide a memory restriction, if applies. Please correct me if my reasoning is not correct. Regards, Sergio I'll appreciate your inputs on this matter. Regards, Sergio -- 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 -- 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: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call?
Aguirre, Sergio wrote: -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Wednesday, May 05, 2010 6:24 PM To: Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: Re: [videobuf] Query: Condition bytesize limit in videobuf_reqbufs - buf_setup() call? Aguirre, Sergio wrote: Hi all, While working on an old port of the omap3 camera-isp driver, I have faced some problem. Basically, when calling VIDIOC_REQBUFS with a certain buffer Count, we had a software limit for total size, calculated depending on: Total bytesize = bytesperline x height x count So, we had an arbitrary limit to, say 32 MB, which was generic. Now, we want to condition it ONLY when MMAP buffers will be used. Meaning, we don't want to keep that policy when the kernel is not allocating the space But the thing is that, according to videobuf documentation, buf_setup is the one who should put a RAM usage limit. BUT the memory type passed to reqbufs is not propagated to buf_setup, therefore forcing me to go to a non-standard memory limitation in my reqbufs callback function, instead of doing it properly inside buf_setup. Is this scenario a good consideration to change buf_setup API, and propagate buffers memory type aswell? I don't see any problem on propagating the memory type to buffer_setup, if this is really needed. Yet, I can't see why you would restrict the buffer size to 32 MB on one case, and not restrict the size at all with non-MMAP types. Ok, my reason for doing that is because I thought that there should be a memory limit in whichever place you're doing the buffer allocations. MMAP is allocating buffers in kernel, so kernel should provide a memory restriction, if applies. USERPTR is allocating buffers in userspace, so userspace should provide a memory restriction, if applies. Please correct me if my reasoning is not correct. Your rationale makes some sense. For the effects of the remaining discussion, let's forget about videobuf-vmalloc, as I'm assuming your troubles are with a driver using videobuf-contig or videobuf-dma_sg. With all memory types, kernel will need to command DMA transfers to those buffers. It still keeps sense to have a restriction on kernelspace, to avoid, for example, the risk of userspace to fill all DMA capable memory with video buffers, preventing its usage by other subsystems (usb, disk, net, etc). So, such limit should still be enforced in kernel, otherwise, you may open an space for DoS attacks. The limit between read(), MMAP, USERPTR and OVERLAY might eventually be different, but I can't see why you might want to put different limits for each case, as the resource that this check is protecting is the DMA-capable memory area. No matter how you're allocating it, you'll need to enforce the same degree of protection. -- 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] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
Hi Arnout,
Arnout Vandecappelle wrote:
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
Your patch looked sane to my eyes. I just noticed one warning at the dprintk,
when compiled with 32 bits address space, and a few coding style issues.
I needed to rebase it also, due to some changes at videobuf.
However, you missed your SOB. Could you please send it? I'm enclosing
the version with my changes for you to sign.
---
V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
Date: Wed, 17 Mar 2010 22:53:05 -
From: Arnout Vandecappelle arn...@mind.be
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
[mche...@redhat.com: Fixed CodingStyle and warning at dprintk on i386]
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
drivers/media/video/videobuf-dma-sg.c | 20
1 file changed, 20 insertions(+)
--- work.orig/drivers/media/video/videobuf-dma-sg.c
+++ work/drivers/media/video/videobuf-dma-sg.c
@@ -145,6 +145,7 @@ static int videobuf_dma_init_user_locked
{
unsigned long first, last;
int err, rw = 0;
+ struct vm_area_struct *vma;
dma-direction = direction;
switch (dma-direction) {
@@ -162,6 +163,25 @@ static int videobuf_dma_init_user_locked
last = ((data+size-1) PAGE_MASK) PAGE_SHIFT;
dma-offset = data ~PAGE_MASK;
dma-nr_pages = last-first+1;
+
+ /* In case the buffer is user-allocated and is actually an IO buffer for
+ some other hardware, we cannot map pages for it. It in fact behaves
+ the same as an overlay. */
+ vma = find_vma(current-mm, data);
+ if (vma (vma-vm_flags VM_IO)) {
+ /* Only a single contiguous buffer is supported. */
+ if (vma-vm_end data + size) {
+ dprintk(1, init user: non-contiguous IO buffer.\n);
+ /* same error that get_user_pages() would give */
+ return -EFAULT;
+ }
+ dma-bus_addr = (vma-vm_pgoff PAGE_SHIFT) +
+ (data - vma-vm_start);
+ dprintk(1, init user IO [0x%lx+0x%lx = %d pages at 0x%llx]\n,
+ data, size, dma-nr_pages, (long long)dma-bus_addr);
+ return 0;
+ }
+
dma-pages = kmalloc(dma-nr_pages * sizeof(struct page *), GFP_KERNEL);
if (NULL == dma-pages)
return -ENOMEM;
--
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] tda10048: fix the uncomplete function tda10048_read_ber
Hello Steven, Thanks Guillaume, I have a pile of other patches I'm ready to present for merge so I'll pull this into one of my dev trees and present this for merge also of course, I'll test it first! :) Thanks again for working on this. You're welcome. I am just starting reviewing the driver. I have already noticed a few errors in it. I will keep on sending obvious patches. I can quickly summarise some of the missing important features: - missing lock algorithm which should use the SCAN_CPT register to make it efficient - missing frequency offset detection (thanks to AUTOOFFSET=1 and OFFSET_F) -- Guillaume -- 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
