Re: RFC: Phase 1: Proposal to convert V4L1 drivers
On Sunday 21 March 2010 00:09:16 Hans de Goede wrote: Hi, On 03/20/2010 09:58 AM, Hans Verkuil wrote: Hi all, Well, I certainly fired everyone up with my RFC. Based on the replies I got I do think the time is right to start the removal process. Phase 1 would be to convert the remaining V4L1 drivers. To see what needs to be done I decided to analyse the remaining V4L1 drivers: - usbvideo (really four drivers: vicam, ibmcam, konicawc, quickcam_messenger) Hans de Goede added support for the quickcam_messenger to gspca, so that driver is scheduled for removal. Devin has hardware to test the vicam driver. David Ellingsworth has hardware to test the ibmcam driver. It would be great if Devin and David can either send it to Hans de Goede or work on it themselves. The konicawc is for an Intel YC76 webcam. I found one for sale here: http://www.ecrater.com/product.php?pid=6593985 Unfortunately the seller does not ship to the Netherlands or to Norway. Can some kind US developer buy it and donate it to Hans de Goede? It's fairly expensive at $39.99, but it's for a good cause. So in theory all these drivers can be tested and converted. - bw-qcam A parallel port Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. - c-qcam A parallel port color Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. - w9966 A parallel port LifeView FlyCam Supra webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. But these three are trivial to convert and the c-qcam can actually be tested. Because of that I see no reason to drop the support for this. - cpia_pp Parallel port webcam driver for the Creative Webcam II. I found one on eBay, so with luck I can get hold of the hardware and get it to HdG. Although I appreaciate your effort in getting this cam into my hands, I don't know what to with it once I have it, my stance on it can be summarized as: It is parallel port only so lets just drop it. - cpia_usb USB variant of cpia_pp. Deprecated since it is now supported by gspca. Ack, note that there is no sane way to make the gspca code also support the parallel port version, so if we would like to do that we would have to keep the pp part of the old cpia1 v4l1 driver which could do both pp and usb around, and convert that v4l2. This looks like it might be a lot more work, so at some point we will have to decide to either convert or drop it. snip So if we all pitch in, then can get everything converted without having to remove drivers. I'm not sure if the parallel port attached are worth keeping support for. But if someone else is willing to convert those, sure. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: RFC: Phase 1: Proposal to convert V4L1 drivers
On Sun, 2010-03-21 at 09:19 +0100, Hans Verkuil wrote: - cpia_pp Parallel port webcam driver for the Creative Webcam II. I found one on eBay, so with luck I can get hold of the hardware and get it to HdG. Although I appreaciate your effort in getting this cam into my hands, I don't know what to with it once I have it, my stance on it can be summarized as: It is parallel port only so lets just drop it. I have one of those in my toys. I can donate it to anyone in Europe. I guess that my willingness to get rid of it is a testimony to how important it is to me... Nico -- 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] af9015 : more robust eeprom parsing
the af9015 eeprom parsing accept 0x38 as 2nd demodulator. But this is
impossible because the
first one is already hardcoded to 0x38.
This remove a special case for AverMedia AVerTV Volar Black HD.
Also in af9015_copy_firmware don't hardcode the 2nd demodulator address to 0x3a.
Signed-off-by: Matthieu CASTET castet.matth...@free.fr
diff --git a/drivers/media/dvb/dvb-usb/af9015.c b/drivers/media/dvb/dvb-usb/af9015.c
index d797538..f93767e 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -493,7 +493,7 @@ static int af9015_copy_firmware(struct dvb_usb_device *d)
/* wait 2nd demodulator ready */
msleep(100);
- ret = af9015_read_reg_i2c(d, 0x3a, 0x98be, val);
+ ret = af9015_read_reg_i2c(d, af9015_af9013_config[1].demod_address, 0x98be, val);
if (ret)
goto error;
else
@@ -913,8 +913,13 @@ static int af9015_read_config(struct usb_device *udev)
ret = af9015_rw_udev(udev, req);
if (ret)
goto error;
- af9015_af9013_config[1].demod_address = val;
+ if (val != AF9015_I2C_DEMOD)
+ af9015_af9013_config[1].demod_address = val;
+ else
+ af9015_config.dual_mode = 0;
+ }
+ if (af9015_config.dual_mode) {
/* enable 2nd adapter */
for (i = 0; i af9015_properties_count; i++)
af9015_properties[i].num_adapters = 2;
@@ -1023,11 +1028,6 @@ error:
if (le16_to_cpu(udev-descriptor.idVendor) == USB_VID_AVERMEDIA
le16_to_cpu(udev-descriptor.idProduct) == USB_PID_AVERMEDIA_A850) {
deb_info(%s: AverMedia A850: overriding config\n, __func__);
- /* disable dual mode */
- af9015_config.dual_mode = 0;
- /* disable 2nd adapter */
- for (i = 0; i af9015_properties_count; i++)
- af9015_properties[i].num_adapters = 1;
/* set correct IF */
af9015_af9013_config[0].tuner_if = 4570;
Re: [PATCH 12/24] media/video: fix dangling pointers
Hello Hans, Fix I2C-drivers which missed setting clientdata to NULL before freeing the structure it points to. Also fix drivers which do this _after_ the structure was freed already. I feel I am missing something here. Why does clientdata have to be set to NULL when we are tearing down the device anyway? And if there is a good reason for doing this, then it should be done in v4l2_device_unregister_subdev or even in the i2c core, not in each drivers. Discussion to take this into the i2c-layer has already started. Regarding V4L, I noticed there is a v4l2_i2c_subdev_init() but no v4l2_i2c_subdev_exit(), so I grepped what drivers are doing. There are some which set clientdata to NULL, so I thought this was accepted in general. And why does coccinelle apparently find this in e.g. cs5345.c but not in saa7115.c, which has exactly the same construct? For that matter, I think It was the to_state()-call inside kfree() which prevented the match. I would need to extend my patch for V4L, it seems. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
dvb frontend lockup
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 -- 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 12/24] media/video: fix dangling pointers
Hi Hans, On Sat, 20 Mar 2010 23:02:49 +0100, Hans Verkuil wrote: On Saturday 20 March 2010 15:12:53 Wolfram Sang wrote: Fix I2C-drivers which missed setting clientdata to NULL before freeing the structure it points to. Also fix drivers which do this _after_ the structure was freed already. I feel I am missing something here. Why does clientdata have to be set to NULL when we are tearing down the device anyway? We're not tearing down the device, that's the point. We are only unbinding it from its driver. The device itself survives the operation. (This is different from the legacy i2c binding model where the device itself would indeed be removed at that point, and that would be the reason why so many i2c drivers have it wrong now.) And if there is a good reason for doing this, then it should be done in v4l2_device_unregister_subdev or even in the i2c core, not in each drivers. Mark Brown (Cc'd) suggested this already, but I have mixed feelings about this. My reasoning is: 1* It is good practice to have memory freed not too far from where it was allocated, otherwise there is always a risk of unmatched pairs. In this regard, it seems preferable to let each i2c driver kfree the device memory it kalloc'd, be it in probe() or remove(). 2* References to allocated memory should be dropped before that memory is freed. This means that we want to call i2c_set_clientdata(c, NULL) before kfree(d). As a corollary, we can't do the former in i2c-core and the later in device drivers. So we are in the difficult situation where we can't do both in i2c-core because that violates point 1 above, we can't do half in i2c-core and half in device drivers because this violates point 2 above, so we fall back to doing both in device drivers, which doesn't violate any point but duplicates the code all around. Now, if we decide to handle this at a deeper driver model layer (i2c-core instead of device drivers) then I'm not sure why we would stop there... Wouldn't it be the driver core's job to clear the reference and free the allocated memory? I get the feeling that this would be a job for managed resources as some drivers already do for I/O ports and IRQs. Managed resources don't care about symmetry of allocation and freeing, by design (so it can violate point 1 above.) Aha! Isn't it exactly what devm_kzalloc() is all about? At this point, I guess that each subsystem maintainer can decide to either apply Wolfram's patch, or switch the drivers to managed resources. Very nice that we don't have to make this a subsystem-wide decision, so every actor can do the changes if/when they see fit. And why does coccinelle apparently find this in e.g. cs5345.c but not in saa7115.c, which has exactly the same construct? For that matter, I think almost all v4l i2c drivers do this. That I can't say, sorry. -- Jean Delvare -- 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
i2c interface bugs in dvb drivers
Hi,
some dvb driver that export a i2c interface contains some mistakes because they
mainly used by driver (frontend, tuner) wrote for them.
But the i2c interface is exposed to everybody.
One mistake is expect msg[i].addr with 8 bits address instead of 7 bits
address. This make them use eeprom address at 0xa0 instead of 0x50. Also they
shift tuner address (qt1010 tuner is likely to be at address 0x62, but some put
it a 0xc4 (af9015, af9005, dtv5100)).
Other mistakes is in xfer callback. Often the controller support a limited i2c
support (n bytes write then m bytes read). The driver try to convert the linux
i2c msg to this pattern, but they often miss cases :
- msg[i].len can be null
- msg write are not always followed by msg read
And this can be dangerous if these interfaces are exported to userspace via
i2c-dev :
- some scanning program avoid eeprom by filtering 0x5x range, but now it is at
0xax range (well that should happen because scan limit should be 0x77)
- some read only command can be interpreted as write command.
What should be done ?
Fix the drivers.
Have a mode where i2c interface are not exported to everybody.
Don't care.
First why does the i2c stack doesn't check that the address is on 7 bits (like
the attached patch) ?
Also I believe a program for testing i2c interface corner case should catch
most of these bugs :
- null msg[i].len
- different transactions on a device :
- one write/read transaction
- one write transaction then one read transaction
[...]
Does a such program exist ?
Matthieu
PS : please keep me in CC
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 3202a86..91e63ea 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1150,6 +1150,17 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
(msgs[ret].flags I2C_M_RECV_LEN) ? + : );
}
#endif
+ for (ret = 0; ret num; ret++) {
+ if (msgs[ret].flags I2C_M_TEN) {
+/* XXX whats I2C_M_TEN range */
+if (msgs[ret].addr 0x03 || msgs[ret].addr 0x377)
+ return -EINVAL;
+ }
+ else {
+if (msgs[ret].addr 0x03 || msgs[ret].addr 0x77)
+ return -EINVAL;
+ }
+ }
if (in_atomic() || irqs_disabled()) {
ret = rt_mutex_trylock(adap-bus_lock);
Re: [PATCH 12/24] media/video: fix dangling pointers
On Sun, Mar 21, 2010 at 02:46:55PM +0100, Jean Delvare wrote: On Sat, 20 Mar 2010 23:02:49 +0100, Hans Verkuil wrote: I feel I am missing something here. Why does clientdata have to be set to NULL when we are tearing down the device anyway? We're not tearing down the device, that's the point. We are only unbinding it from its driver. The device itself survives the operation. That's the subsystem point of view, not the driver point of view. As far as the driver is concerned the device appears when probe() is called and vanishes after remove() has completed, any management the subsystem does in between is up to it. 1* It is good practice to have memory freed not too far from where it was allocated, otherwise there is always a risk of unmatched pairs. In this regard, it seems preferable to let each i2c driver kfree the device memory it kalloc'd, be it in probe() or remove(). I agree with this. There are also some use cases where the device data is actually static (eg, a generic description of the device or a reference to some other shared resource rather than per device allocated data). 2* References to allocated memory should be dropped before that memory is freed. This means that we want to call i2c_set_clientdata(c, NULL) before kfree(d). As a corollary, we can't do the former in i2c-core and the later in device drivers. This is where the mismatch between the subsystem view of the device lifetime and the driver view of the device lifetime comes into play. For the driver once the device is unregistered the device no longer exists - if the driver tries to work with the device it's buggy. This means that to the driver returning from the remove() function is dropping the reference to the data and there's no reason for the driver to take any other action. The device may hang around after the remove() has happened, but if the device driver knows or cares about it then it's doing something wrong. Similarly on probe() we can't assme anything about the pointer since even if we saw the device before we can't guarantee that some other driver didn't do so as well. The situation is similar to that with kfree() - we don't memset() data we're freeing with that, even though it might contain pointers to other things. So we are in the difficult situation where we can't do both in i2c-core because that violates point 1 above, we can't do half in i2c-core and half in device drivers because this violates point 2 above, so we fall back to doing both in device drivers, which doesn't violate any point but duplicates the code all around. Personally I'd much rather just not bother setting the driver data in the removal path, it seems unneeded. I had assumed that the subsystem code cared for some reason when I saw the patch series. -- 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] saa7134: add capture boards Hawell HW-404M7 and HW-808M7
Hi Hermann.
Sorry, i forgot it.
Resend patch with SOB.
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1269096094 -10800
# Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
# Parent 929298149eba4b6d0696124b9880113c25cd0788
saa7134: fix GPIO HW-404M7
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 18 23:47:27
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Mar 20 17:41:34
2010 +0300
@@ -5403,12 +5403,12 @@
.radio_type= UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .gpiomask = 0x01fc00,
+ .gpiomask = 0x389c00,
.inputs = {{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
- .gpio = 0x389c00,
+ .gpio = 0x01fc00,
} },
},
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 18 23:47:27
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Mar 20 17:41:34
2010 +0300
@@ -531,7 +531,6 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
- case SAA7134_BOARD_HAWELL_HW_404M7:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
В Вск, 21/03/2010 в 02:28 +0100, hermann pitton пишет:
Hi Vladimir,
Am Samstag, den 20.03.2010, 17:58 +0300 schrieb Vladimir Ermakov:
Hi Hermann.
1. It's my mistake. Fixed.
2. Dead code. Removed.
thanks for looking at it.
We likely need your SOB line again, since it is a new patch.
Here is my
Reviewed-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1269096094 -10800
# Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
# Parent 929298149eba4b6d0696124b9880113c25cd0788
saa7134: fix GPIO HW-404M7
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Mar 20
17:41:34 2010 +0300
@@ -5403,12 +5403,12 @@
.radio_type= UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .gpiomask = 0x01fc00,
+ .gpiomask = 0x389c00,
.inputs = {{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
- .gpio = 0x389c00,
+ .gpio = 0x01fc00,
} },
},
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Mar 20
17:41:34 2010 +0300
@@ -531,7 +531,6 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
- case SAA7134_BOARD_HAWELL_HW_404M7:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
В Птн, 19/03/2010 в 00:21 +0100, hermann pitton пишет:
Hi Vladimir,
thanks, your patch is already accepted, but if have a two comments.
Am Mittwoch, den 10.03.2010, 18:44 +0300 schrieb Vladimir Ermakov:
This patch adds new capture boards Hawell HW-404M7 and HW-808M7.
Those cards have 4 or 8 SAA7130 chips and for the work it only needs
initialize registers.
The value of those registers were dumped under Windows using flytest.
But board haven't EEPROM.
For the first chip:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389C00
Value: 0x00016C00
Later in the code you swapped mode (gpio mask) and value (out status).
This does not cause a functional problem in this case, but is visible
for example with saa7134 gpio_tracking=1.
Second, you did add the card to the flyvideo remotes in saa7134-input,
but this is only a line of dead code currently.
If it really has such a remote, you must also add the card to the switch
case dev-has_remote = SAA7134_REMOTE_GPIO in in the function
int saa7134_board_init1 in saa7134-cards.c or please remove it from
saa7134-input.c.
Thanks,
Hermann
Video input: 3
Audio input:
Re: [linux-dvb] Problem with decrypting dvb-s channels
A couple of months triggers me: for as far as I am aware dvb decoder cards need regular 'entitlement messages' to continue to work. And when the card is not in an active system for a long time it misses those messages and gets shut out. You need to ask the card issuer to re-activate the card (usually they offer this option on a website) and have the dvb-s card, cam and dish all powered up and tuned to a transponder controlled by the card-issuer. Usually they advise you to tune to a certain channel. I forgot to mentioned, the card has been active in a regular receiver when not used in the PC. If I put the card back in the receiver, the channels are decrypted successfully. -- 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 12/24] media/video: fix dangling pointers
On Sunday 21 March 2010 15:14:17 Mark Brown wrote: On Sun, Mar 21, 2010 at 02:46:55PM +0100, Jean Delvare wrote: On Sat, 20 Mar 2010 23:02:49 +0100, Hans Verkuil wrote: I feel I am missing something here. Why does clientdata have to be set to NULL when we are tearing down the device anyway? We're not tearing down the device, that's the point. We are only unbinding it from its driver. The device itself survives the operation. That's the subsystem point of view, not the driver point of view. As far as the driver is concerned the device appears when probe() is called and vanishes after remove() has completed, any management the subsystem does in between is up to it. Right. And from the point of view of the driver I see no reason why I would have to zero the client data pointer when I know nobody will ever access it again. If there is a good reason, then that is (again, from the PoV of the driver) completely unexpected and it is guaranteed that driver writers will continue to make that mistake in the future. 1* It is good practice to have memory freed not too far from where it was allocated, otherwise there is always a risk of unmatched pairs. In this regard, it seems preferable to let each i2c driver kfree the device memory it kalloc'd, be it in probe() or remove(). I agree with this. There are also some use cases where the device data is actually static (eg, a generic description of the device or a reference to some other shared resource rather than per device allocated data). Definitely. Freeing should be done in the i2c drivers. 2* References to allocated memory should be dropped before that memory is freed. This means that we want to call i2c_set_clientdata(c, NULL) before kfree(d). As a corollary, we can't do the former in i2c-core and the later in device drivers. This is where the mismatch between the subsystem view of the device lifetime and the driver view of the device lifetime comes into play. For the driver once the device is unregistered the device no longer exists - if the driver tries to work with the device it's buggy. This means that to the driver returning from the remove() function is dropping the reference to the data and there's no reason for the driver to take any other action. The device may hang around after the remove() has happened, but if the device driver knows or cares about it then it's doing something wrong. Similarly on probe() we can't assme anything about the pointer since even if we saw the device before we can't guarantee that some other driver didn't do so as well. The situation is similar to that with kfree() - we don't memset() data we're freeing with that, even though it might contain pointers to other things. Indeed. The client data is for the client. Once the client is gone (unbound) the client data can safely be set back to NULL. So we are in the difficult situation where we can't do both in i2c-core because that violates point 1 above, we can't do half in i2c-core and half in device drivers because this violates point 2 above, so we fall back to doing both in device drivers, which doesn't violate any point but duplicates the code all around. Personally I'd much rather just not bother setting the driver data in the removal path, it seems unneeded. I had assumed that the subsystem code cared for some reason when I saw the patch series. Anyway, should this really be necessary, then for the media drivers this should be done in v4l2_device_unregister_subdev() and not in every driver. But this just feels like an i2c core thing to me. After remove() is called the core should just set the client data to NULL. If there are drivers that rely on the current behavior, then those drivers should be reviewed first as to the reason why they need it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: RFC: Phase 1: Proposal to convert V4L1 drivers
On Saturday 20 March 2010 19:38:39 Gerard Klaver wrote: On Sat, 2010-03-20 at 09:58 +0100, Hans Verkuil wrote: Hi all, lines deleted - ov511 - ovcamchip - w9968cf - stv680 Conclusion: These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. However, all four should be easy to convert to v4l2, even without hardware. Volunteers? Regards, Hans Hello, I have a c-qcam with par. port, so i can do some test, see page below for some information webcam: http://gkall.hobby.nl/connectix-quickcam.html Well, no good deed goes unpunished, so I'd appreciate it if you could do some testing :-) I did a quick conversion of c-qcam to V4L2. You can find the tree here: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-v4l1 It is 'bug compatible' with the V4L1 driver. I.e. I only converted the API, I didn't check anything else. And I saw some very dubious contructs in the init and exit paths, so I am almost positive that it needs a bit more work. Please let me know how it goes and post the kernel messages that the driver prints when loaded, used and when unloaded. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: prof 7300
Op zondag 17 januari 2010 16:42:53 schreef Igor M. Liplianin: On 17 января 2010 16:42:27 joep admiraal wrote: I had some troubles with a prof 7300 dvb s-2 card. I am running OpenSuse 11.2 with a recent hg copy of the v4l-dvb repository. It was detected as a Hauppauge WinTV instead of a prof 7300. After some runs with info_printk statements I found a problem in linux/drivers/media/video/cx88.c As far as I can understand the code I would say card[core-nr] will always be smaller than ARRAY_SIZE(cx88_boards). Therefore core-boardnr is never looked up from the cx88_subids array. After I removed the check with ARRAY_SIZE the correct card is detected and I can watch tv with both my prof 7300 cards. Can someone confirm if the patch I made is correct or explain what the purpose is of the ARRAY_SIZE check? For search references: I was getting this error in dmesg: cx88[1]/2: dvb_register failed (err = -22) cx88[1]/2: cx8802 probe failed, err = -22 Regards, Joep Admiraal Do/did you have another TV tuner? Please check file /etc/modprobe.conf or files in /etc/modprobe.d/ for line like this options cx88xx card=n Then remove the line You can try to check your card modprobe cx88xx card=75 Hi Igor, Today I finally checked the modprobe file. Since this machine is running OpenSuse 11.2, I checked /etc/modprobe.d/50- tv.conf. I can confirm the line was present. After removing it and rebooting the machine, the card was detected correctly. This was off course tested without my hacked v4l. Thanks for your help. -- 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
0002-Staging-cx25821-fix-coding-style-issues-in-cx25821-c.patch
From d0cc598f638e6b1dc8c06c2327e67667d52095ed Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu olimpiu.pasca...@gmail.com
Date: Sun, 21 Mar 2010 19:18:19 +0200
Subject: [PATCH 2/2] Staging: cx25821: fix coding style issues in cx25821-core.c
This is a patch to cx25821-core.c file that fixes up warnings and errors found
by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com
---
drivers/staging/cx25821/cx25821-core.c | 156
1 files changed, 77 insertions(+), 79 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-core.c
b/drivers/staging/cx25821/cx25821-core.c
index 67f689d..c527473 100644
--- a/drivers/staging/cx25821/cx25821-core.c
+++ b/drivers/staging/cx25821/cx25821-core.c
@@ -31,6 +31,7 @@ MODULE_AUTHOR(Shu Lin - Hiep Huynh);
MODULE_LICENSE(GPL);
struct list_head cx25821_devlist;
+EXPORT_SYMBOL(cx25821_devlist);
static unsigned int debug;
module_param(debug, int, 0644);
@@ -312,6 +313,7 @@ struct sram_channel cx25821_sram_channels[] = {
.irq_bit = 11,
},
};
+EXPORT_SYMBOL(cx25821_sram_channels);
struct sram_channel *channel0 = cx25821_sram_channels[SRAM_CH00];
struct sram_channel *channel1 = cx25821_sram_channels[SRAM_CH01];
@@ -387,70 +389,74 @@ static void cx25821_registers_init(struct cx25821_dev
*dev)
{
u32 tmp;
- // enable RUN_RISC in Pecos
+ /* enable RUN_RISC in Pecos */
cx_write(DEV_CNTRL2, 0x20);
- // Set the master PCI interrupt masks to enable video, audio, MBIF, and
GPIO interrupts
- // I2C interrupt masking is handled by the I2C objects themselves.
+ /* Set the master PCI interrupt masks to enable video, audio, MBIF,
+* and GPIO interrupts
+* I2C interrupt masking is handled by the I2C objects themselves. */
cx_write(PCI_INT_MSK, 0x2001);
tmp = cx_read(RDR_TLCTL0);
- tmp = ~FLD_CFG_RCB_CK_EN; // Clear the RCB_CK_EN bit
+ tmp = ~FLD_CFG_RCB_CK_EN; /* Clear the RCB_CK_EN bit */
cx_write(RDR_TLCTL0, tmp);
- // PLL-A setting for the Audio Master Clock
+ /* PLL-A setting for the Audio Master Clock */
cx_write(PLL_A_INT_FRAC, 0x9807A58B);
- // PLL_A_POST = 0x1C, PLL_A_OUT_TO_PIN = 0x1
+ /* PLL_A_POST = 0x1C, PLL_A_OUT_TO_PIN = 0x1 */
cx_write(PLL_A_POST_STAT_BIST, 0x819C);
- // clear reset bit [31]
+ /* clear reset bit [31] */
tmp = cx_read(PLL_A_INT_FRAC);
cx_write(PLL_A_INT_FRAC, tmp 0x7FFF);
- // PLL-B setting for Mobilygen Host Bus Interface
+ /* PLL-B setting for Mobilygen Host Bus Interface */
cx_write(PLL_B_INT_FRAC, 0x9883A86F);
- // PLL_B_POST = 0xD, PLL_B_OUT_TO_PIN = 0x0
+ /* PLL_B_POST = 0xD, PLL_B_OUT_TO_PIN = 0x0 */
cx_write(PLL_B_POST_STAT_BIST, 0x818D);
- // clear reset bit [31]
+ /* clear reset bit [31] */
tmp = cx_read(PLL_B_INT_FRAC);
cx_write(PLL_B_INT_FRAC, tmp 0x7FFF);
- // PLL-C setting for video upstream channel
+ /* PLL-C setting for video upstream channel */
cx_write(PLL_C_INT_FRAC, 0x96A0EA3F);
- // PLL_C_POST = 0x3, PLL_C_OUT_TO_PIN = 0x0
+ /* PLL_C_POST = 0x3, PLL_C_OUT_TO_PIN = 0x0 */
cx_write(PLL_C_POST_STAT_BIST, 0x8103);
- // clear reset bit [31]
+ /* clear reset bit [31] */
tmp = cx_read(PLL_C_INT_FRAC);
cx_write(PLL_C_INT_FRAC, tmp 0x7FFF);
- // PLL-D setting for audio upstream channel
+ /* PLL-D setting for audio upstream channel */
cx_write(PLL_D_INT_FRAC, 0x98757F5B);
- // PLL_D_POST = 0x13, PLL_D_OUT_TO_PIN = 0x0
+ /* PLL_D_POST = 0x13, PLL_D_OUT_TO_PIN = 0x0 */
cx_write(PLL_D_POST_STAT_BIST, 0x8113);
- // clear reset bit [31]
+ /* clear reset bit [31] */
tmp = cx_read(PLL_D_INT_FRAC);
cx_write(PLL_D_INT_FRAC, tmp 0x7FFF);
- // This selects the PLL C clock source for the video upstream channel I
and J
+ /* This selects the PLL C clock source for the video upstream channel
+* I and J */
tmp = cx_read(VID_CH_CLK_SEL);
cx_write(VID_CH_CLK_SEL, (tmp 0x00FF) | 0x2400);
- // 656/VIP SRC Upstream Channel I J and 7 - Host Bus Interface for
channel A-C
- //select 656/VIP DST for downstream Channel A - C
+ /* 656/VIP SRC Upstream Channel I J and 7 - Host Bus Interface for
+* channel A-C
+* select 656/VIP DST for downstream Channel A - C */
tmp = cx_read(VID_CH_MODE_SEL);
- //cx_write( VID_CH_MODE_SEL, tmp | 0x1B0001FF);
+ /* cx_write( VID_CH_MODE_SEL, tmp | 0x1B0001FF); */
cx_write(VID_CH_MODE_SEL, tmp 0xFE00);
- // enables 656 port I and J as output
+ /* enables 656 port I and J as output */
tmp = cx_read(CLK_RST);
- tmp |= FLD_USE_ALT_PLL_REF;
0003-Staging-cx25821-fix-coding-style-issues-in-cx25821-g.patch
From fae275cf48fd318cbd88e59e90f119c3f75dab72 Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu olimpiu.pasca...@gmail.com
Date: Sun, 21 Mar 2010 19:44:01 +0200
Subject: [PATCH 3/3] Staging: cx25821: fix coding style issues in cx25821-gpio.c
This is a patch to cx25821-gpio.c file that fixes up warnings and errors found
by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com
---
drivers/staging/cx25821/cx25821-gpio.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-gpio.c
b/drivers/staging/cx25821/cx25821-gpio.c
index e8a37b4..2f154b3 100644
--- a/drivers/staging/cx25821/cx25821-gpio.c
+++ b/drivers/staging/cx25821/cx25821-gpio.c
@@ -31,7 +31,7 @@ void cx25821_set_gpiopin_direction(struct cx25821_dev *dev,
u32 gpio_register = 0;
u32 value = 0;
- // Check for valid pinNumber
+ /* Check for valid pinNumber */
if (pin_number = 47)
return;
@@ -39,14 +39,14 @@ void cx25821_set_gpiopin_direction(struct cx25821_dev *dev,
bit = pin_number - 31;
gpio_oe_reg = GPIO_HI_OE;
}
- // Here we will make sure that the GPIOs 0 and 1 are output. keep the
rest as is
+ /* Here we will make sure that the GPIOs 0 and 1 are output. keep the
+* rest as is */
gpio_register = cx_read(gpio_oe_reg);
- if (pin_logic_value == 1) {
+ if (pin_logic_value == 1)
value = gpio_register | Set_GPIO_Bit(bit);
- } else {
+ else
value = gpio_register Clear_GPIO_Bit(bit);
- }
cx_write(gpio_oe_reg, value);
}
@@ -58,11 +58,12 @@ static void cx25821_set_gpiopin_logicvalue(struct
cx25821_dev *dev,
u32 gpio_reg = GPIO_LO;
u32 value = 0;
- // Check for valid pinNumber
+ /* Check for valid pinNumber */
if (pin_number = 47)
return;
- cx25821_set_gpiopin_direction(dev, pin_number, 0); // change to
output direction
+ /* change to output direction */
+ cx25821_set_gpiopin_direction(dev, pin_number, 0);
if (pin_number 31) {
bit = pin_number - 31;
@@ -71,25 +72,23 @@ static void cx25821_set_gpiopin_logicvalue(struct
cx25821_dev *dev,
value = cx_read(gpio_reg);
- if (pin_logic_value == 0) {
+ if (pin_logic_value == 0)
value = Clear_GPIO_Bit(bit);
- } else {
+ else
value |= Set_GPIO_Bit(bit);
- }
cx_write(gpio_reg, value);
}
void cx25821_gpio_init(struct cx25821_dev *dev)
{
- if (dev == NULL) {
+ if (dev == NULL)
return;
- }
switch (dev-board) {
case CX25821_BOARD_CONEXANT_ATHENA10:
default:
- //set GPIO 5 to select the path for Medusa/Athena
+ /* set GPIO 5 to select the path for Medusa/Athena */
cx25821_set_gpiopin_logicvalue(dev, 5, 1);
mdelay(20);
break;
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
0004-Staging-cx25821-fix-coding-style-issues-in-cx25821-i.patch
From 5f02f6af270ce061174806a039d8d44a35b2ce5e Mon Sep 17 00:00:00 2001 From: Olimpiu Pascariu olimpiu.pasca...@gmail.com Date: Sun, 21 Mar 2010 19:52:31 +0200 Subject: [PATCH 4/4] Staging: cx25821: fix coding style issues in cx25821-i2c.c This is a patch to cx25821-i2c.c file that fixes up warnings and errors found by the checkpatch.pl tool Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com --- drivers/staging/cx25821/cx25821-i2c.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/cx25821/cx25821-i2c.c b/drivers/staging/cx25821/cx25821-i2c.c index f4f2681..f727b85 100644 --- a/drivers/staging/cx25821/cx25821-i2c.c +++ b/drivers/staging/cx25821/cx25821-i2c.c @@ -159,9 +159,9 @@ static int i2c_sendbytes(struct i2c_adapter *i2c_adap, return msg-len; - eio: +eio: retval = -EIO; - err: +err: if (i2c_debug) printk(KERN_ERR ERR: %d\n, retval); return retval; @@ -223,9 +223,9 @@ static int i2c_readbytes(struct i2c_adapter *i2c_adap, } return msg-len; - eio: +eio: retval = -EIO; - err: +err: if (i2c_debug) printk(KERN_ERR ERR: %d\n, retval); return retval; @@ -266,7 +266,7 @@ static int i2c_xfer(struct i2c_adapter *i2c_adap, struct i2c_msg *msgs, int num) } return num; - err: +err: return retval; } @@ -319,7 +319,7 @@ int cx25821_i2c_register(struct cx25821_i2c *bus) bus-i2c_client.adapter = bus-i2c_adap; - //set up the I2c + /* set up the I2c */ bus-i2c_client.addr = (0x88 1); return bus-i2c_rc; -- 1.7.0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] Staging: cx25821: fix coding style issues in cx25821-medusa-video.c
From 24e5efa163c1fa58f694fd8b44dc3488e0cc92d1 Mon Sep 17 00:00:00 2001
From: Olimpiu Pascariu olimpiu.pasca...@gmail.com
Date: Sun, 21 Mar 2010 20:46:26 +0200
Subject: [PATCH 5/5] Staging: cx25821: fix coding style issues in
cx25821-medusa-video.c
This is a patch to cx25821-medusa-video.c file that fixes up warnings and
errors found by the checkpatch.pl tool
Signed-off-by: Olimpiu Pascariu olimpiu.pasca...@gmail.com
---
drivers/staging/cx25821/cx25821-medusa-video.c | 207 ---
1 files changed, 108 insertions(+), 99 deletions(-)
diff --git a/drivers/staging/cx25821/cx25821-medusa-video.c
b/drivers/staging/cx25821/cx25821-medusa-video.c
index d601620..60dd086 100644
--- a/drivers/staging/cx25821/cx25821-medusa-video.c
+++ b/drivers/staging/cx25821/cx25821-medusa-video.c
@@ -24,11 +24,12 @@
#include cx25821-medusa-video.h
#include cx25821-biffuncs.h
-/
-//medusa_enable_bluefield_output()
-//
-// Enable the generation of blue filed output if no video
-//
+/*
+ * medusa_enable_bluefield_output()
+ *
+ * Enable the generation of blue filed output if no video
+ *
+*/
static void medusa_enable_bluefield_output(struct cx25821_dev *dev, int
channel,
int enable)
{
@@ -73,15 +74,15 @@ static void medusa_enable_bluefield_output(struct
cx25821_dev *dev, int channel,
}
value = cx25821_i2c_read(dev-i2c_bus[0], out_ctrl, tmp);
- value = 0xFF7F;// clear BLUE_FIELD_EN
+ value = 0xFF7F;/* clear BLUE_FIELD_EN */
if (enable)
- value |= 0x0080;// set BLUE_FIELD_EN
+ value |= 0x0080;/* set BLUE_FIELD_EN */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], out_ctrl, value);
value = cx25821_i2c_read(dev-i2c_bus[0], out_ctrl_ns, tmp);
value = 0xFF7F;
if (enable)
- value |= 0x0080;// set BLUE_FIELD_EN
+ value |= 0x0080;/* set BLUE_FIELD_EN */
ret_val = cx25821_i2c_write(dev-i2c_bus[0], out_ctrl_ns, value);
}
@@ -95,17 +96,18 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
mutex_lock(dev-lock);
for (i = 0; i MAX_DECODERS; i++) {
- // set video format NTSC-M
+ /* set video format NTSC-M */
value =
cx25821_i2c_read(dev-i2c_bus[0], MODE_CTRL + (0x200 * i),
tmp);
value = 0xFFF0;
- value |= 0x10001; // enable the fast locking mode bit[16]
+ /* enable the fast locking mode bit[16] */
+ value |= 0x10001;
ret_val =
cx25821_i2c_write(dev-i2c_bus[0], MODE_CTRL + (0x200 * i),
value);
- // resolution NTSC 720x480
+ /* resolution NTSC 720x480 */
value =
cx25821_i2c_read(dev-i2c_bus[0],
HORIZ_TIM_CTRL + (0x200 * i), tmp);
@@ -119,17 +121,17 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_read(dev-i2c_bus[0],
VERT_TIM_CTRL + (0x200 * i), tmp);
value = 0x00C00C00;
- value |= 0x1C1E001A;// vblank_cnt + 2 to get camera ID
+ value |= 0x1C1E001A;/* vblank_cnt + 2 to get camera ID */
ret_val =
cx25821_i2c_write(dev-i2c_bus[0],
VERT_TIM_CTRL + (0x200 * i), value);
- // chroma subcarrier step size
+ /* chroma subcarrier step size */
ret_val =
cx25821_i2c_write(dev-i2c_bus[0],
SC_STEP_SIZE + (0x200 * i), 0x43E0);
- // enable VIP optional active
+ /* enable VIP optional active */
value =
cx25821_i2c_read(dev-i2c_bus[0],
OUT_CTRL_NS + (0x200 * i), tmp);
@@ -139,7 +141,7 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_write(dev-i2c_bus[0],
OUT_CTRL_NS + (0x200 * i), value);
- // enable VIP optional active (VIP_OPT_AL) for direct output.
+ /* enable VIP optional active (VIP_OPT_AL) for direct output. */
value =
cx25821_i2c_read(dev-i2c_bus[0], OUT_CTRL1 + (0x200 * i),
tmp);
@@ -149,19 +151,21 @@ static int medusa_initialize_ntsc(struct cx25821_dev *dev)
cx25821_i2c_write(dev-i2c_bus[0], OUT_CTRL1 + (0x200 * i),
value);
- // clear VPRES_VERT_EN bit, fixes the chroma run away
[PATCH] V4L2: Replace loops for finding max buffers in VIDIOC_REQBUFS callbacks
Due to obvious copy and paste coding a number of video capture drivers which implement a limit on the buffer memory decremented the user supplied buffer count in a while loop until it reaches an acceptable value. This is a silly thing to do when the maximum value can be directly computed. Signed-off-by: Andreas Bombe a...@debian.org --- I tested the looping variants (represented by vivi.c) with large numbers of requested buffers. There was no easily measurable delay on my desktop machine, but still. At least the buffer count isn't 64 bit on any architecture. I think I got them all. These are the files which I grepped as candidates (correct = no loop, unlimited = no limit on buffer count, fixed = in this patch), relative to drivers/media/video: ../common/saa7146_video.c: correct au0828/au0828-video.c: unlimited bt8xx/bttv-driver.c: fixed cx231xx/cx231xx-video.c: unlimited cx23885/cx23885-video.c: fixed cx88/cx88-video.c: fixed davinci/vpfe_capture.c:unlimited davinci/vpif_capture.c:unlimited davinci/vpif_display.c:unlimited em28xx/em28xx-video.c: unlimited mx1_camera.c: fixed mx3_camera.c: correct omap24xxcam.c: fixed pxa_camera.c: fixed s2255drv.c:fixed saa7134/saa7134-core.c:correct sh_mobile_ceu_camera.c:fixed tlg2300/pd-video.c:unlimited vivi.c:fixed zr364xx.c: fixed ../../staging/cx25821/cx25821-video.c: fixed drivers/media/video/bt8xx/bttv-driver.c |4 ++-- drivers/media/video/cx23885/cx23885-video.c |4 ++-- drivers/media/video/cx88/cx88-video.c |4 ++-- drivers/media/video/mx1_camera.c|4 ++-- drivers/media/video/omap24xxcam.c |4 ++-- drivers/media/video/pxa_camera.c|4 ++-- drivers/media/video/s2255drv.c |4 ++-- drivers/media/video/sh_mobile_ceu_camera.c |4 ++-- drivers/media/video/vivi.c |4 ++-- drivers/media/video/zr364xx.c |4 ++-- drivers/staging/cx25821/cx25821-video.c |4 ++-- 11 files changed, 22 insertions(+), 22 deletions(-) diff --git a/drivers/media/video/bt8xx/bttv-driver.c b/drivers/media/video/bt8xx/bttv-driver.c index cb46e8f..79af895 100644 --- a/drivers/media/video/bt8xx/bttv-driver.c +++ b/drivers/media/video/bt8xx/bttv-driver.c @@ -1805,8 +1805,8 @@ buffer_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size) *size = fh-fmt-depth*fh-width*fh-height 3; if (0 == *count) *count = gbuffers; - while (*size * *count gbuffers * gbufsize) - (*count)--; + if (*size * *count gbuffers * gbufsize) + *count = (gbuffers * gbufsize) / *size; return 0; } diff --git a/drivers/media/video/cx23885/cx23885-video.c b/drivers/media/video/cx23885/cx23885-video.c index 2d3ac8b..543b854 100644 --- a/drivers/media/video/cx23885/cx23885-video.c +++ b/drivers/media/video/cx23885/cx23885-video.c @@ -514,8 +514,8 @@ static int buffer_setup(struct videobuf_queue *q, unsigned int *count, *size = fh-fmt-depth*fh-width*fh-height 3; if (0 == *count) *count = 32; - while (*size * *count vid_limit * 1024 * 1024) - (*count)--; + if (*size * *count vid_limit * 1024 * 1024) + *count = (vid_limit * 1024 * 1024) / *size; return 0; } diff --git a/drivers/media/video/cx88/cx88-video.c b/drivers/media/video/cx88/cx88-video.c index 48c450f..9c0ca79 100644 --- a/drivers/media/video/cx88/cx88-video.c +++ b/drivers/media/video/cx88/cx88-video.c @@ -561,8 +561,8 @@ buffer_setup(struct videobuf_queue *q, unsigned int *count, unsigned int *size) *size = fh-fmt-depth*fh-width*fh-height 3; if (0 == *count) *count = 32; - while (*size * *count vid_limit * 1024 * 1024) - (*count)--; + if (*size * *count vid_limit * 1024 * 1024) + *count = (vid_limit * 1024 * 1024) / *size; return 0; } diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c index c167cc3..d07af13 100644 --- a/drivers/media/video/mx1_camera.c +++ b/drivers/media/video/mx1_camera.c @@ -140,8 +140,8 @@ static int mx1_videobuf_setup(struct videobuf_queue *vq, unsigned int *count, if (!*count) *count = 32; - while (*size * *count MAX_VIDEO_MEM * 1024 * 1024) - (*count)--; + if (*size * *count MAX_VIDEO_MEM * 1024 * 1024) + *count = (MAX_VIDEO_MEM * 1024 * 1024) / *size; dev_dbg(icd-dev.parent, count=%d, size=%d\n, *count, *size); diff --git a/drivers/media/video/omap24xxcam.c b/drivers/media/video/omap24xxcam.c index 142c327..c910e86 100644 --- a/drivers/media/video/omap24xxcam.c +++ b/drivers/media/video/omap24xxcam.c @@ -451,8 +451,8 @@ static int omap24xxcam_vbq_setup(struct
[PATCH] V4L/DVB: budget-av: wait longer for frontend to power on
Some devices need much more time than 100ms to power on, leading to a
failure to enable the frontend on the first attempt. Instead we get
[ 38.194200] saa7146: register extension 'budget_av'.
[ 38.253828] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ
17
[ 38.601572] saa7146: found saa7146 @ mem c9c6ac00 (revision 1, irq
17) (0x1894,0x0022).
[ 39.251324] saa7146 (0): dma buffer size 1347584
[ 39.306757] DVB: registering new adapter (KNC1 DVB-C MK3)
[ 39.462785] adapter failed MAC signature check
[ 39.516159] encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
[ 39.892397] KNC1-0: MAC addr = 00:09:d6:6d:94:5c
[ 40.552028] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.580044] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.608026] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.636027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.652026] DVB: TDA10023(-1): tda10023_writereg, writereg error (reg ==
0x00, val == 0x33, ret == -5)
[ 40.664027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.692027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.720027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.748027] saa7146 (0) saa7146_i2c_writeout [irq]: timed out waiting for
end of xfer
[ 40.764025] DVB: TDA10023(-1): tda10023_readreg: readreg error (reg == 0x1a,
ret == -5)
[ 40.764067] budget-av: A frontend driver was not found for device
[1131:7146] subsystem [1894:0022]
Unloading and the reloading the driver will work around this problem. But
it can also be easily fixed by increasing the wait period after powering
on. The optimum value is unclear to me. But I've found the 500 ms is not
enough. 5 s is enough for my card, but might be more than actually needed.
However, as long as we don't handle this failure more gracefully, then the
timeout need to be long enough.
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
---
Hello,
I have recently bought a KNC1 clone, called Mystique CaBiX-C2. This card
would just not work on reboot in my system, giving the errors shown above.
Unloading the module and then loading it again always fixed the problem,
indicating that it was just a startup timing problem.
As you can see, the i2c timeouts are from the frontend attach function,
tda10023_attach():
/* wakeup if in standby */
tda10023_writereg (state, 0x00, 0x33);
/* check if the demod is there */
if ((tda10023_readreg(state, 0x1a) 0xf0) != 0x70) goto error;
cleary showing that it just isn't responding yet at that point.
I first tried increasing the msleep() to 500 ms, but still got the same
error. Increasing it to 5000 ms helped, however, and made my card work
from boot. I have not tried any values inbetween, as each attempt AFAIK
requires a reboot to get the card into the cold state where it will
fail.
dmesg with the patch installed:
[ 37.786955] saa7146: register extension 'budget_av'.
[ 37.846592] budget_av :05:01.0: PCI INT A - GSI 17 (level, low) - IRQ
17
[ 37.933318] saa7146: found saa7146 @ mem c9c70c00 (revision 1, irq
17) (0x1894,0x0022).
[ 38.037851] saa7146 (0): dma buffer size 1347584
[ 38.093224] DVB: registering new adapter (KNC1 DVB-C MK3)
[ 38.194254] adapter failed MAC signature check
[ 38.247527] encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
[ 38.622678] KNC1-0: MAC addr = 00:09:d6:6d:94:5c
[ 43.765897] DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
[ 43.851587] budget-av: ci interface initialised.
Please consider this patch. Or maybe it is possible to wait smarter,
testing actual frontend power status instead of just a blind sleep?
I've also included a CC stable as I've had the same problem with the 2.6.32
and 2.6.33 stable drivers.
Bjørn
drivers/media/dvb/ttpci/budget-av.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ttpci/budget-av.c
b/drivers/media/dvb/ttpci/budget-av.c
index 983672a..b53bd80 100644
--- a/drivers/media/dvb/ttpci/budget-av.c
+++ b/drivers/media/dvb/ttpci/budget-av.c
@@ -1215,7 +1215,7 @@ static void frontend_init(struct budget_av *budget_av)
saa7146_setgpio(saa, 0, SAA7146_GPIO_OUTLO);
/* Wait for PowerON */
- msleep(100);
+ msleep(5000);
/* additional setup necessary for the PLUS cards */
switch (saa-pci-subsystem_device) {
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401
mixing IRQF_DISABLED with IRQF_SHARED just doesn't make sense.
Remove IRQF_DISABLED to avoid random unexpected behaviour.
Ever since I started using the saa7146 driver, I've had occasional
soft lockups. I do not have any real evidence that the saa7146
driver is the cause, but the lockups are gone after removing the
IRQF_DISABLED flag from this driver.
On my system, this driver shares an irq17 with the pata_jmicron
driver:
17: 2115 1060594228448193902 IO-APIC-fasteoi
pata_jmicron, saa7146 (0)
This may be a mitigating factor.
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
---
drivers/media/common/saa7146_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 982f000..038dcc8 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -416,7 +416,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
saa7146_write(dev, MC2, 0xf800);
/* request an interrupt for the saa7146 */
- err = request_irq(pci-irq, interrupt_hw, IRQF_SHARED | IRQF_DISABLED,
+ err = request_irq(pci-irq, interrupt_hw, IRQF_SHARED,
dev-name, dev);
if (err 0) {
ERR((request_irq() failed.\n));
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~endriss/ngene
Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene for the following changeset: 01/01: ngene: Workaround for stuck DiSEqC pin http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 stv090x.c |4 1 file changed, 4 insertions(+) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] drivers/media/video: avoid NULL dereference
From: Julia Lawall ju...@diku.dk
If ov is NULL, it will not be possible to take the lock in the first place,
so move the test up earlier.
The semantic match that finds the problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r exists@
expression E, E1;
identifier f;
statement S1,S3;
iterator iter;
@@
if ((E == NULL ...) || ...)
{
... when != false ((E == NULL ...) || ...)
when != true ((E != NULL ...) || ...)
when != iter(E,...) S1
when != E = E1
(
sizeof(E-f)
|
* E-f
)
... when any
return ...;
}
else S3
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/video/ov511.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
index e0bce8d..2357218 100644
--- a/drivers/media/video/ov511.c
+++ b/drivers/media/video/ov511.c
@@ -5913,14 +5913,12 @@ ov51x_disconnect(struct usb_interface *intf)
PDEBUG(3, );
+ if (!ov)
+ return;
+
mutex_lock(ov-lock);
usb_set_intfdata (intf, NULL);
- if (!ov) {
- mutex_unlock(ov-lock);
- return;
- }
-
/* Free device number */
ov511_devused = ~(1 ov-nr);
--
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] V4L/DVB: saa7146: IRQF_DISABLED causes only trouble
On Sun, 2010-03-21 at 21:08 +0100, Bjørn Mork wrote:
As discussed many times, e.g. in http://lkml.org/lkml/2007/7/26/401
mixing IRQF_DISABLED with IRQF_SHARED just doesn't make sense.
Remove IRQF_DISABLED to avoid random unexpected behaviour.
Ever since I started using the saa7146 driver, I've had occasional
soft lockups. I do not have any real evidence that the saa7146
driver is the cause, but the lockups are gone after removing the
IRQF_DISABLED flag from this driver.
On my system, this driver shares an irq17 with the pata_jmicron
driver:
17: 2115 1060594228448193902 IO-APIC-fasteoi
pata_jmicron, saa7146 (0)
This may be a mitigating factor.
Signed-off-by: Bjørn Mork bj...@mork.no
Cc: sta...@kernel.org
And here are some more recent discussions:
http://lkml.org/lkml/2009/11/30/215
http://lkml.org/lkml/2009/3/2/33
http://lkml.org/lkml/2009/3/2/225
http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06319.html
http://www.mail-archive.com/ivtv-de...@ivtvdriver.org/msg06362.html
And the ones on the LKML seem prettry inconclusive to me.
If the saa7146 driver was registered second, then this change should
have no effect on your system.
If the saa7146 driver was registered first, then this can cause the
saa7146 driver's interrupt handler to be interrupted. I doubt the
saa7146 driver is prepared for this contingency.
I doubt that this is the proper fix for your problem.
Does the soft lockup put an Oops or BUG message in dmesg
or /var/log/messages?
What precisely do you mean by soft lockup?
Regards,
Andy
---
drivers/media/common/saa7146_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/saa7146_core.c
b/drivers/media/common/saa7146_core.c
index 982f000..038dcc8 100644
--- a/drivers/media/common/saa7146_core.c
+++ b/drivers/media/common/saa7146_core.c
@@ -416,7 +416,7 @@ static int saa7146_init_one(struct pci_dev *pci, const
struct pci_device_id *ent
saa7146_write(dev, MC2, 0xf800);
/* request an interrupt for the saa7146 */
- err = request_irq(pci-irq, interrupt_hw, IRQF_SHARED | IRQF_DISABLED,
+ err = request_irq(pci-irq, interrupt_hw, IRQF_SHARED,
dev-name, dev);
if (err 0) {
ERR((request_irq() failed.\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
Re: RFC: Phase 1: Proposal to convert V4L1 drivers
On Saturday 20 March 2010 09:58:49 Hans Verkuil wrote: These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. However, all four should be easy to convert to v4l2, even without hardware. Volunteers? I've converted these four drivers to V4L2. See my tree: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-v4l1 It's obviously untested and it needs a closer review, but the bulk of the work is done. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Add AverTV Studio 509UA
Hi,
Am Samstag, den 20.03.2010, 16:08 +0200 schrieb Евгений Бацман:
2010/3/20 hermann pitton hermann-pit...@arcor.de:
Hi, Евгений,
is there any reason, why you set the charge pump bit to low and slow
tuning on a non FM tuner?
Cheers,
Hermann
Am Freitag, den 19.03.2010, 20:32 +0200 schrieb Евгений Бацман:
A add tv tuner AverTV Studio 509UA but radio now not
work(tuner_tea5764hn not in kernel)
diff -r a/linux/drivers/media/common/tuners/tuner-types.c
--- a/linux/drivers/media/common/tuners/tuner-types.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/common/tuners/tuner-types.c 2010-03-19
14:25:24.0 +0200
@@ -1353,6 +1353,30 @@
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_ranges),
},
};
+/* TUNER_PHILIPS_FQ1216ME_MK5 - Philips PAL */
+
+static struct tuner_range tuner_fq1216me_mk5_pal_ranges[] = {
+ { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
+ { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
+ { 16 * 999.99, 0x8e, 0x04, },
+};
+
+static struct tuner_params tuner_fq1216me_mk5_params[] = {
+ {
+ .type = TUNER_PARAM_TYPE_PAL,
+ .ranges = tuner_fq1216me_mk5_pal_ranges,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_pal_ranges),
+ .cb_first_if_lower_freq = 1,
+ .has_tda9887 = 1,
+ .port1_active = 1,
+ .port2_active = 1,
+ .port2_invert_for_secam_lc = 1,
+ .default_top_mid = -2,
+ .default_top_secam_low = -2,
+ .default_top_secam_mid = -2,
+ .default_top_secam_high = -2,
+ },
+};
/* -
*/
@@ -1827,6 +1851,11 @@
.params = tuner_sony_btf_pxn01z_params,
.count = ARRAY_SIZE(tuner_sony_btf_pxn01z_params),
},
+ [TUNER_PHILIPS_FQ1216ME_MK5] = { /* Philips PAL */
+ .name = Philips PAL/SECAM multi (FQ1216ME MK5),
+ .params = tuner_fq1216me_mk5_params,
+ .count = ARRAY_SIZE(tuner_fq1216me_mk5_params),
+ },
};
EXPORT_SYMBOL(tuners);
diff -r a/linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-03-19
16:34:17.0 +0200
@@ -5411,7 +5411,44 @@
.gpio = 0x389c00,
} },
},
-
+ [SAA7134_BOARD_AVERMEDIA_STUDIO_509UA] = {
+ /* Evgen Batsman evgenbats...@gmail.com */
+ .name = Avermedia AVerTV Studio 509UA,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_FQ1216ME_MK5,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .gpiomask = 0x03,
+ .inputs = { {
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ .gpio = 0x00,
+ }, {
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ .gpio = 0x00,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ .gpio = 0x00,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = LINE2,
+ .gpio = 0x01,
+ },
+ .mute = {
+ .name = name_mute,
+ .amux = LINE1,
+ .gpio = 0x00,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -6567,6 +6604,12 @@
.subvendor= 0x107d,
.subdevice= 0x6655,
.driver_data = SAA7134_BOARD_LEADTEK_WINFAST_DTV1000S,
+ },{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0xa14b,
+ .driver_data = SAA7134_BOARD_AVERMEDIA_STUDIO_509UA,
}, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
diff -r a/linux/drivers/media/video/saa7134/saa7134.h
--- a/linux/drivers/media/video/saa7134/saa7134.h 2010-03-17
20:38:10.0 +0200
+++ b/linux/drivers/media/video/saa7134/saa7134.h 2010-03-19
Re: Add AverTV Studio 509UA
I think best would be to create two patches. 1/2 adds the new tuner. (tuner-types.c/tuner.h/tveeprom.c) 2/2 adds the new Avermedia card. Else it looks fine. To add some for the record here for those eventually later on it. We have seen over so many years now, that hundreds of new can tuners did appear and, IIRC, we got them all with any combination of previous chips. The filters, mainly the SAW filters did make a difference to the original products they follow all in what ever combination concerning quality. However, a main annoyance was, that lots of such clones did appear and some did start to use extra radio tuners on cheap silicon on separate addresses, hard to track, since hidden under some welded shielding. This was with all such clones all over Asia and the extra silicon radio tuner was always Philips/NXP in the beginning. What is new now, I think, and first seen, is that the last can tuner flagship MK5 series has a FQ non radio variant on a AverMedia using some extra silicon from Philips/NXP/Trident _themselves_ to make some extra profit against a FM MK5 they have. I would call this a management disaster, but my education might be outdated. Cheers, Hermann -- 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: [REPORT] Brainstorm meeting on V4L2 memory handling
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Saturday, March 13, 2010 7:26 PM To: linux-media@vger.kernel.org Subject: [REPORT] Brainstorm meeting on V4L2 memory handling Introduction A meeting was held from March 10-12 at the Tandberg offices in Lysaker, Norway, between developers from Nokia, Samsung, Intel and Tandberg to informally discuss any V4L2 memory handling issues. This was in preparation of a v4l-dvb mini-summit that will hopefully happen in early May in Norway (I plan to have more definitive information available next week). The main purpose was to gain a better understanding of the problems that SoC developers face when dealing with video4linux and in particular the way it handles the video buffers and the streaming API. Location: Tandberg office, Lysaker, Norway March 10-12, 2010 Attendees: Sakari Ailus (Nokia) Morten Hestnes (Tandberg) Pawel Osciak (Samsung) Laurent Pinchart (Nokia) Marek Szyprowski (Samsung) Hans Verkuil (Tandberg) Xiaolin Zhang (Intel) Summary of the meeting -- 1) Memory-to-memory devices Original thread with the proposal from Samsung: http://www.mail-archive.com/linux-samsung-...@vger.kernel.org/msg00391.html [Hiremath, Vaibhav] Pawel, I wanted to start prototyping Resizer and Previewer driver to this framework, before starting just wanted to make sure that I start with latest and greatest. Is V2 post still holds latest? Did you do any changes after that? Also, have you validated this with actual hardware module? If not then I think I can now start on this and add resizer driver to it. Thanks, Vaibhav Depending on the hardware/driver there can be two methods of doing this: a) Separate capture and output video nodes. This already works, but has the limitation that only one capture and one output file handle can be streaming, just as is the case right now with capture and output nodes. b) Provide a single video node that can do both capture and output. This is what the Samsung patch provides. Here the videobuf queues are placed in the file handle struct. This allows multiplexing (must be possible to add priority queue support later, but use fifo for now). STREAMON must be called for both capture and output queue before the hardware starts processing. Such nodes will set both capture and output capabilities. Drivers will have to store the hardware configuration (e.g. capture/output formats) in the file handle struct as well, since this is now completely local to the file handle. 2) videobuf framework and the V4L2 streaming API The videobuf framework and the streaming API received a lot of attention during this meeting. Many shortcomings and bugs were found. We even discussed the idea whether a new videobuf framework should be created from scratch, but this was abandoned. The general opinion was that while there are many, many problems with videobuf, they are also relatively easy to fix. We identified the following issues in the streaming API and videobuf: a) REQBUFS with count == 0 Currently both the spec and drivers handle this inconsistently. Our proposal is this (and RFC will be posted in the near future): - Returns -EBUSY if the device is still streaming or if buffers are still mapped. - Remove the implicit STREAMOFF behavior from the spec. - Must return an error if the memory mode is not supported. - Must release all buffers otherwise. - On return the count field in the struct remains 0. b) DQBUF handling of buffer errors If a DMA error occurs while capturing a buffer the buffer status is set to VIDEOBUF_ERROR. However, in the current implementation VIDIOC_DQBUF will return -EIO and the v4l2_buffer struct will not be copied back to userspace, so while the buffer is dequeued internally, the userspace application has no idea which buffer that was. From the point of view of the application this buffer has been effectively lost. Proposed fix: - Never return an error if the buffer has been dequeued, otherwise that buffer will be lost to the application. - Need a new error flag to tell the application that the buffer had an error status. c) videobuf framework Many bugs and confusing constructs were identified. Note that proposed name changes are only that: proposals. When the actual implementation is made the name may turn out to be completely different from what is suggested here. - Fix poll behavior for output: POLLIN|POLLRDNORM is set for output devices instead of POLLOUT|POLLWRNORM as is specified in the spec. This must be fixed for mem-to-mem devices. - Run checkpatch.pl over all videobuf sources + headers and post cleanup patches. - Propose to remove the magic fields in the ops. Seems to be absolutely no reason for those. All the magic
