Re: [PATCH] firedtv: refine AVC debugging
Henrik Kurelid wrote:
+static int debug_fcp_opcode_flag_set(unsigned int opcode,
+const u8 *data, int length)
+{
+ switch (opcode) {
+ case AVC_OPCODE_VENDOR: break;
+ case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug &
AVC_DEBUG_READ_DESCRIPTOR;
+ case AVC_OPCODE_DSIT: return avc_debug &
AVC_DEBUG_DSIT;
+ case AVC_OPCODE_DSD:return avc_debug &
AVC_DEBUG_DSD;
+ default:return 1;
+ }
+
+ if (length < 7 ||
+ data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
+ data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
+ data[5] != SFE_VENDOR_DE_COMPANYID_2)
+ return 1;
+
+ switch (data[6]) {
+ case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug &
AVC_DEBUG_REGISTER_REMOTE_CONTROL;
+ case SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug &
AVC_DEBUG_LNB_CONTROL;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK: return avc_debug &
AVC_DEBUG_TUNE_QPSK;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug &
AVC_DEBUG_TUNE_QPSK2;
+ case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug &
AVC_DEBUG_HOST2CA;
+ case SFE_VENDOR_OPCODE_CA2HOST: return avc_debug &
AVC_DEBUG_CA2HOST;
+ }
+ return 1;
+}
+
static void debug_fcp(const u8 *data, int length)
{
unsigned int subunit_type, subunit_id, op;
const char *prefix = data[0] > 7 ? "FCP <- " : "FCP -> ";
- if (avc_debug & AVC_DEBUG_FCP_SUBACTIONS) {
- subunit_type = data[1] >> 3;
- subunit_id = data[1] & 7;
- op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ subunit_type = data[1] >> 3;
+ subunit_id = data[1] & 7;
+ op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ if (debug_fcp_opcode_flag_set(op, data, length)) {
printk(KERN_INFO "%ssu=%x.%x l=%d: %-8s - %s\n",
[...]
Shouldn't the three return statements in debug_fcp_opcode_flag_set be
'return 0' rather than one?
--
Stefan Richter
-=-==--= -=== =---=
http://arcgraph.de/sr/
--
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] firedtv: refine AVC debugging
Henrik Kurelid wrote: +#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 22) This expression is always true. :-) -- Stefan Richter -=-==--= -=== =---= http://arcgraph.de/sr/ -- 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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Hi Pham Thanh Nam, Thanks for your help, now it works correctly! Cheers, Laszlo On Fri, Jul 17, 2009 at 4:32 AM, Pham Thanh Nam wrote: > change .amux = LINE1 to .amux = TV > Please let us know if it works. -- 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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Hi So, should we add an option for this card? For example: modprobe saa7134 card=57 radioontv Regards -- 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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Hi Pham Thanh Nam,
you are exactly at the point!
Am Freitag, den 17.07.2009, 08:32 +0700 schrieb Pham Thanh Nam:
> I read somewhere that the radio had ever worked for this card but has
> stopped working with newer kernels. I had the same problem when I used
> my card (AverMedia AverTV GO 007 FM Plus) with card=57 before. Radio had
> worked with old kernel versions.
> Try this:
> hg clone http://linuxtv.org/hg/v4l-dvb
> Edit v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c, go to
> entry [SAA7134_BOARD_AVERMEDIA_GO_007_FM], in .radio = { ... },
> change .amux = LINE1 to .amux = TV
> make
> then
> sudo make install
> and reboot.
> I don't know why someone has changed it to LINE1. But if the
> modification works for you, I think we need to modify a bit.
> Please let us know if it works.
The AVerMedia AVerTV GO 007 FM was the first card ever reported working
with the new saa7131e chip, including the previously external tda8290
demodulator built into that chip, by Assaf Gillat.
This did include working radio on LINE* input.
No other later card does have such and all LINE* input for radio was not
working on all other later cards.
However, all later cards did use gpio21 to switch those stuff into radio
mode, having it either high or later also low. (vice versa/swapped)
That single gpio did trigger a cascade of further switches on later
cards, starting with selecting the right antenna input on a further
microscopic switch later in the row and routing the radio IF to the TV
input for decoding "on chip".
This did also include that the radio IF has to go over that
extra/special 7.5MHz ceramic filter on these cards, also present on the
007.
I can tell, that this huge ceramic filter on recent cards is not any
longer easily to identify, there are SMD replacements for it, and with
recent circuits for additional external LNAs, all looks even much more
interesting ;)
Fact is so far, with the previous reports the card should work with
kernels around 2.6.13,14,15.
Since all other later cards did not work for radio that way, Hartmut
introduced decoding from radio IF at amux TV (saa7133/35/31e only) and
that maybe did break this one.
Or the other way round, before he introduced that, it might have been
working. I don't have the specs, but as long nothing else is reported, I
can't exclude that the tda8275 in combination with a tda8290 can deliver
base band radio stereo sound to some pair of stereo LINE input of the
saa7131e.
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: AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
I read somewhere that the radio had ever worked for this card but has
stopped working with newer kernels. I had the same problem when I used
my card (AverMedia AverTV GO 007 FM Plus) with card=57 before. Radio had
worked with old kernel versions.
Try this:
hg clone http://linuxtv.org/hg/v4l-dvb
Edit v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c, go to
entry [SAA7134_BOARD_AVERMEDIA_GO_007_FM], in .radio = { ... },
change .amux = LINE1 to .amux = TV
make
then
sudo make install
and reboot.
I don't know why someone has changed it to LINE1. But if the
modification works for you, I think we need to modify a bit.
Please let us know if it works.
--
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: two instances of tvp514x module required for DM6467. Any suggestion?
On Thu, 2009-07-16 at 10:32 -0500, Karicheri, Muralidharan wrote: > Hi, > > I am working to add support for DM6467 capture driver. This evm has > two tvp5147 chips with different i2c addresses. So will I be able to > call v4l2_i2c_new_subdev_board() twice to have two instances of this > driver running? Yes call it once for each device. Technically there will only be one copy of the driver code in memory, but two distinct instances of data structures on which that code operates. > Murali Karicheri > Software Design Engineer > Texas Instruments Inc. > Germantown, MD 20874 ^^ Another Marylander! :) Regards, Andy -- 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] firedtv: refine AVC debugging
Hi,
Here is another patch for the firedtv driver. This one changes the debug
logging somewhat to make it easier to find issues with the driver since it
is still fairly untested for variants of delivery systems, CAMs and CA systems.
---
firedtv: refine AVC debugging
The current AVC debugging can clog the log down a lot since many applications
tend to check the signal strength very often. This patch enables users to
select which AVC messages to log using a bitmask.
In addition, it also enables the possibility to debug application PMTs sent
to the driver. This will be usable since the CA support is still poorly tested
for lots of CAMs and CA systems.
Signed-off-by: Henrik Kurelid
diff -r 48086ebb22a8 linux/drivers/media/dvb/firewire/firedtv-avc.c
--- a/linux/drivers/media/dvb/firewire/firedtv-avc.cThu Jul 16 16:13:09
2009 +0200
+++ b/linux/drivers/media/dvb/firewire/firedtv-avc.cThu Jul 16 21:54:34
2009 +0200
@@ -89,14 +89,31 @@ struct avc_response_frame {
u8 operand[509];
};
-#define AVC_DEBUG_FCP_SUBACTIONS 1
-#define AVC_DEBUG_FCP_PAYLOADS 2
+#define AVC_DEBUG_READ_DESCRIPTOR 0x0001
+#define AVC_DEBUG_DSIT 0x0002
+#define AVC_DEBUG_DSD 0x0004
+#define AVC_DEBUG_REGISTER_REMOTE_CONTROL 0x0008
+#define AVC_DEBUG_LNB_CONTROL 0x0010
+#define AVC_DEBUG_TUNE_QPSK0x0020
+#define AVC_DEBUG_TUNE_QPSK2 0x0040
+#define AVC_DEBUG_HOST2CA 0x0080
+#define AVC_DEBUG_CA2HOST 0x0100
+#define AVC_DEBUG_APPLICATION_PMT 0x4000
+#define AVC_DEBUG_FCP_PAYLOADS 0x8000
static int avc_debug;
module_param_named(debug, avc_debug, int, 0644);
-MODULE_PARM_DESC(debug, "Verbose logging (default = 0"
- ", FCP subactions = " __stringify(AVC_DEBUG_FCP_SUBACTIONS)
- ", FCP payloads = " __stringify(AVC_DEBUG_FCP_PAYLOADS)
+MODULE_PARM_DESC(debug, "Verbose logging bitmask (none (default) = 0"
+ ", FCP subaction(READ DESCRIPTOR) = "
__stringify(AVC_DEBUG_READ_DESCRIPTOR)
+ ", FCP subaction(DSIT) = "
__stringify(AVC_DEBUG_DSIT)
+ ", FCP subaction(REGISTER_REMOTE_CONTROL) = "
__stringify(AVC_DEBUG_REGISTER_REMOTE_CONTROL)
+ ", FCP subaction(LNB CONTROL) = "
__stringify(AVC_DEBUG_LNB_CONTROL)
+ ", FCP subaction(TUNE QPSK) = "
__stringify(AVC_DEBUG_TUNE_QPSK)
+ ", FCP subaction(TUNE QPSK2) = "
__stringify(AVC_DEBUG_TUNE_QPSK2)
+ ", FCP subaction(HOST2CA) = "
__stringify(AVC_DEBUG_HOST2CA)
+ ", FCP subaction(CA2HOST) = "
__stringify(AVC_DEBUG_CA2HOST)
+ ", Application sent PMT = "
__stringify(AVC_DEBUG_APPLICATION_PMT)
+ ", FCP payloads(for selected subactions) = "
__stringify(AVC_DEBUG_FCP_PAYLOADS)
", or all = -1)");
static const char *debug_fcp_ctype(unsigned int ctype)
@@ -142,31 +159,67 @@ static const char *debug_fcp_opcode(unsi
return "Vendor";
}
+static int debug_fcp_opcode_flag_set(unsigned int opcode,
+const u8 *data, int length)
+{
+ switch (opcode) {
+ case AVC_OPCODE_VENDOR: break;
+ case AVC_OPCODE_READ_DESCRIPTOR:return avc_debug &
AVC_DEBUG_READ_DESCRIPTOR;
+ case AVC_OPCODE_DSIT: return avc_debug &
AVC_DEBUG_DSIT;
+ case AVC_OPCODE_DSD:return avc_debug &
AVC_DEBUG_DSD;
+ default:return 1;
+ }
+
+ if (length < 7 ||
+ data[3] != SFE_VENDOR_DE_COMPANYID_0 ||
+ data[4] != SFE_VENDOR_DE_COMPANYID_1 ||
+ data[5] != SFE_VENDOR_DE_COMPANYID_2)
+ return 1;
+
+ switch (data[6]) {
+ case SFE_VENDOR_OPCODE_REGISTER_REMOTE_CONTROL: return avc_debug &
AVC_DEBUG_REGISTER_REMOTE_CONTROL;
+ case SFE_VENDOR_OPCODE_LNB_CONTROL: return avc_debug &
AVC_DEBUG_LNB_CONTROL;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK: return avc_debug &
AVC_DEBUG_TUNE_QPSK;
+ case SFE_VENDOR_OPCODE_TUNE_QPSK2: return avc_debug &
AVC_DEBUG_TUNE_QPSK2;
+ case SFE_VENDOR_OPCODE_HOST2CA: return avc_debug &
AVC_DEBUG_HOST2CA;
+ case SFE_VENDOR_OPCODE_CA2HOST: return avc_debug &
AVC_DEBUG_CA2HOST;
+ }
+ return 1;
+}
+
static void debug_fcp(const u8 *data, int length)
{
unsigned int subunit_type, subunit_id, op;
const char *prefix = data[0] > 7 ? "FCP <- " : "FCP -> ";
- if (avc_debug & AVC_DEBUG_FCP_SUBACTIONS) {
- subunit_type = data[1] >> 3;
- subunit_id = data[1] & 7;
- op = subunit_type == 0x1e || subunit_id == 5 ? ~0 : data[2];
+ subunit_type = data[1] >> 3;
+ subunit_id = data[1]
AVerMedia AVerTV GO 007 FM, no radio sound (with routing enabled)
Hi all, I have problems with my AVerMedia AVerTV GO 007 FM tuner, kernel version 2.6.28. TV and remote are working correctly, but the radio does not have any sound. I already tried the steps described in http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_GO_007_FM but still no success. According to this: "The *latest revision*(PCI ID 1461:f31f) of the Avermedia AVerTV GO 007 FM works "out of the box" in recent kernels" but it's not the case for me. /dev/radio0 is created, but radio is not functional. I can tune to different frequencies, but no change in the sound. The "antenna" icon of gnomeradio does not show any signal. If I try to scan with gnomeradio, it dies. I tried different tuner=xx insmod options, the maximum I could achieve was that gnomeradio finds some stations and the antenna icon shows that there is a signal, but still cannot hear anything. I enabled sound routing (that's how tvtime works correctly), but the radio is not functional yet: #!/bin/sh sox -c 2 -s -r 32000 -t ossdsp /dev/dsp1 -t ossdsp -r 32000 /dev/dsp & gnomeradio --mixer=/dev/mixer:pcm wait gnomeradio t=`pidof sox`; kill $t; amixer -c 0 sset PCM 80%,80% unmute dmesg output: [ 1360.408481] saa7130/34: v4l2 driver version 0.2.15 loaded [ 1360.408582] saa7133[0]: found at :01:06.0, rev: 208, irq: 19, latency: 64, mmio: 0xd800 [ 1360.408593] saa7133[0]: subsystem: 1461:f31f, board: Avermedia AVerTV GO 007 FM [card=57,autodetected] [ 1360.408663] saa7133[0]: board init: gpio is 80185 [ 1360.408793] input: saa7134 IR (Avermedia AVerTV GO as /devices/pci:00/:00:04.0/:01:06.0/input/input7 [ 1360.568037] saa7133[0]: i2c eeprom 00: 61 14 1f f3 ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568054] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568068] saa7133[0]: i2c eeprom 20: ff d2 fe ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568082] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568094] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568107] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568120] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568133] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568146] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568159] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568172] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568185] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568198] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568211] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568224] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.568237] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 1360.608210] tuner 2-004b: chip found @ 0x96 (saa7133[0]) [ 1360.688029] tda829x 2-004b: setting tuner address to 61 [ 1360.752032] tda829x 2-004b: type set to tda8290+75 [ 1365.492142] saa7133[0]: registered device video0 [v4l2] [ 1365.492181] saa7133[0]: registered device vbi0 [ 1365.492218] saa7133[0]: registered device radio0 [ 1365.502229] saa7134 ALSA driver for DMA sound loaded [ 1365.502288] saa7133[0]/alsa: saa7133[0] at 0xd800 irq 19 registered as card -2 On the tuner I see a SAA7131 and a TDA8275 integrated circuit. Please help me get my radio working. Thanks, Laszlo -- 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: Control IOCTLs handling
> >> I don't see any control IDs available for Bayer RGB color space. >> >> In our video hardware, there is a set of Gain values that can be applied >to the Bayer RGB data. We can apply them individually to R, Gr, Gb or B >color components. So I think we need to have 4 more controls defined for >doing white balancing in the Bayer RGB color space that is applicable for >sensors (like MT9T031) and image tuning hardware like the VPFE CCDC& IPIPE. >> >> Define following new controls for these in Bayer RGB color space White >Balance (WB) controls?? >> >> V4L2_CID_BAYER_RED_BALANCE integer Bayer Red balance. >> V4L2_CID_BAYER_BLUE_BALANCE integer Bayer Blue balance. >> V4L2_CID_BAYER_GREEN_R_BALANCE integer Bayer Gr balance. >> V4L2_CID_BAYER_GREEN_B_BALANCE integer Bayer Gb balance. >> >> There is also an offset value defined per color which is like adjusting >the black level in the video image data. It is subtracted from the image >byte. >> What you call this ? Should we define a new control, >V4l2_CID_BAYER_OFFSET ?? >> > >I can't help but wonder if we should export all these as controls. One can >probably export about 90% of the registers of a sensor as controls, >but then why write a driver at all, why not just give the user an >application to set the registers himself them ? > I can agree that we don't expect all registers exported to user space as control. I have consulted with our internal (Texas Instruments) sensor experts. Our customers need to change the Gains mentioned above as part of the Automatic White Balance algorithm which runs in the user space. So these needs to be exported to user space either as a proprietary control or as a standard control. These Gains have maximum, minimum and a default values and looks similar to a control function. So The idea of sending this email was to see if any other hardware has similar functionality. If so, it is worth adding it to the list of standard Control IDs. If not, it can stay as a proprietary control ID, but then we need a way to set proprietary controls. >When it comes to controls, less is more IMHO. > >So the question is can't we give these registers a sensible default setting >and leave it at that? > As I have said, this will not work for AWB algorithm implementation. >And currently the answer to that is yes, there currently are 2 ways to do >whitebalance for sensors >under Linux: >1) The sensor does it in hardware (using per color gains like above) Why not let VPFE image processing modules to do this as well ? >2) libv4l does whitebalancing in software, in this case case a software >gain is used as we can >control that very precisely and libv4l does not know the exact gain >factor (and has no way to find >out) of per color gains exported through controls, so we just apply a >software per color gain, >which we can control exactly. > In my opinion, both hardware and software options should be available to application so that it can choose one over other. >So currently the best thing todo is, either: >a) make the sensor do hardware whitebalance if it can (much prefered), or: Hardware here also should refers to image processing hardware like VPFE. So this calls for adding these control IDs to list of available control IDs. This are required for CCDC as well as IPIPE hardware modules in VPFE to do TI AWB algorithm. >b) set all the per color gains in their default / middle position and >handle >the whitebalancing fully in software. > Our customers would like to use VPFE based AWB algorithm that needs to set Gains in VPFE as well as sensors. So this is a NACK for our hardware. >This applies even more to the per color offset's, I really see little use >in exporting this to the >end-user. > >You should look at controls as knobs the end user may want to tweak, if it >is not something the end-user >could want to / should tweak it should not be a control. > >Regards, > >Hans -- 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] Implement V4L2_CAP_STREAMING for zr364xx driver
Em Quinta-feira 16 Julho 2009, Mauro Carvalho Chehab escreveu:
> Em Wed, 15 Jul 2009 20:54:55 -0300
>
> Lamarque Vieira Souza escreveu:
> > This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
> > converting the driver to use videobuf. This version is synced with
> > v4l-dvb as of 15/Jul/2009.
> >
> > Tested with Creative PC-CAM 880.
> >
> > It basically:
> > . implements V4L2_CAP_STREAMING using videobuf;
> >
> > . re-implements V4L2_CAP_READWRITE using videobuf;
> >
> > . copies cam->udev->product to the card field of the v4l2_capability
> > struct. That gives more information to the users about the webcam;
> >
> > . moves the brightness setting code from before requesting a frame (in
> > read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
> > executed only when the application requests a change in brightness and
> > not before every frame read;
> >
> > . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
> > libv4l do not work.
> >
> > This patch fixes zr364xx for applications such as mplayer,
> > Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
> > with zr364xx chip.
> >
> > Signed-off-by: Lamarque V. Souza
> > ---
> >
> > diff -r c300798213a9 linux/drivers/media/video/zr364xx.c
> > --- a/linux/drivers/media/video/zr364xx.c Sun Jul 05 19:08:55 2009 -0300
> > +++ b/linux/drivers/media/video/zr364xx.c Wed Jul 15 20:50:34 2009 -0300
> > @@ -1,5 +1,5 @@
> > /*
> > - * Zoran 364xx based USB webcam module version 0.72
> > + * Zoran 364xx based USB webcam module version 0.73
> > *
> > * Allows you to use your USB webcam with V4L2 applications
> > * This is still in heavy developpement !
> > @@ -10,6 +10,8 @@
> > * Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c
> > drivers * V4L2 version inspired by meye.c driver
> > *
> > + * Some video buffer code by Lamarque based on s2255drv.c and vivi.c
> > drivers. + *
>
> Maybe the better example for it is em28xx-video, where we firstly used
> videobuf on usb devices.
I will take a look at em28xx-video. I used s2255drv.c and vivi.c
because
their code organization are similar to zr364xx.c, so it was easier to know
what to do.
> > +static void free_buffer(struct videobuf_queue *vq, struct zr364xx_buffer
> > *buf)
> > +{
> > + DBG("%s\n", __func__);
> > +
> > + /*Lamarque: is this really needed? Sometimes this blocks rmmod forever
> > +* after running Skype on an AMD64 system. */
> > + /*videobuf_waiton(&buf->vb, 0, 0);*/
>
> Answering to your note, take a look at em28xx-video implementation:
>
> /* We used to wait for the buffer to finish here, but this didn't
> work because, as we were keeping the state as VIDEOBUF_QUEUED,
> videobuf_queue_cancel marked it as finished for us.
>(Also, it could wedge forever if the hardware was
> misconfigured.)
>
>This should be safe; by the time we get here, the buffer isn't
>queued anymore. If we ever start marking the buffers as
>VIDEOBUF_ACTIVE, it won't be, though.
> */
> spin_lock_irqsave(&dev->slock, flags);
> if (dev->isoc_ctl.buf == buf)
> dev->isoc_ctl.buf = NULL;
> spin_unlock_irqrestore(&dev->slock, flags);
Yes, the comment answers my question. There is no similar code in
zr364xx.c
like the one above. zr364xx_camera does not have a member with zr364xxx_buffer
type (the equivalent type of dev->isoc_ctl.buf).
> > + if (pipe_info->state != 0) {
> > + if (usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL))
> > + dev_err(&cam->udev->dev, "error submitting urb\n");
> > + } else {
> > + DBG("read pipe complete state 0\n");
> > + }
>
> Hmm... for the usb_submit_urb() call that happens during IRQ context
> (while you're receiving stream), you need to use:
> urb->status = usb_submit_urb(pipe_info->stream_urb, GFP_ATOMIC);
>
> otherwise, you may get the errors that Antoine is reporting
Ok, changed to GPF_ATOMIC. Could someone test this for me since I was
not
able to reproduce this problem? The new patch is here
http://bach.metasys.com.br/~lamarque/zr364xx/zr364xx.c-streaming.patch-v4l-
dvb-20090716 . I upload it to avoid bloating the mailing-list with a 40k
patch.
I have computer here with dual core processor but no display. I need to
get a
DVI <-> VGA adaptor to plug my DVI LCD on it, when I get one I am going to
test the changes with SMP enabled.
--
Lamarque V. Souza
http://www.geographicguide.com/brazil.htm
Linux User #57137 - http://counter.li.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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:Thu Jul 16 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12270:d754a2d5a376 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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] Implement V4L2_CAP_STREAMING for zr364xx driver
Mauro,
Thanks. That was what I was thinking, but just want to see what issues I might
face on the way. I am starting the work on DM6467 capture driver and you would
be getting a patch soon for review in the mailing list.
Regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
>-Original Message-
>From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
>Sent: Thursday, July 16, 2009 11:45 AM
>To: Lamarque Vieira Souza
>Cc: Antoine Jacquet; linux-media@vger.kernel.org; video4linux-
>l...@redhat.com
>Subject: Re: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
>
>Em Wed, 15 Jul 2009 20:54:55 -0300
>Lamarque Vieira Souza escreveu:
>
>> This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
>> converting the driver to use videobuf. This version is synced with v4l-
>dvb as
>> of 15/Jul/2009.
>>
>> Tested with Creative PC-CAM 880.
>>
>> It basically:
>> . implements V4L2_CAP_STREAMING using videobuf;
>>
>> . re-implements V4L2_CAP_READWRITE using videobuf;
>>
>> . copies cam->udev->product to the card field of the v4l2_capability
>struct.
>> That gives more information to the users about the webcam;
>>
>> . moves the brightness setting code from before requesting a frame (in
>> read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
>> executed only when the application requests a change in brightness and
>> not before every frame read;
>>
>> . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
>> libv4l do not work.
>>
>> This patch fixes zr364xx for applications such as mplayer,
>> Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
>> with zr364xx chip.
>>
>> Signed-off-by: Lamarque V. Souza
>> ---
>>
>> diff -r c300798213a9 linux/drivers/media/video/zr364xx.c
>> --- a/linux/drivers/media/video/zr364xx.cSun Jul 05 19:08:55 2009 -
>0300
>> +++ b/linux/drivers/media/video/zr364xx.cWed Jul 15 20:50:34 2009 -
>0300
>> @@ -1,5 +1,5 @@
>> /*
>> - * Zoran 364xx based USB webcam module version 0.72
>> + * Zoran 364xx based USB webcam module version 0.73
>> *
>> * Allows you to use your USB webcam with V4L2 applications
>> * This is still in heavy developpement !
>> @@ -10,6 +10,8 @@
>> * Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c
>drivers
>> * V4L2 version inspired by meye.c driver
>> *
>> + * Some video buffer code by Lamarque based on s2255drv.c and vivi.c
>drivers.
>> + *
>
>Maybe the better example for it is em28xx-video, where we firstly used
>videobuf
>on usb devices.
>
>> +static void free_buffer(struct videobuf_queue *vq, struct zr364xx_buffer
>> *buf)
>> +{
>> +DBG("%s\n", __func__);
>> +
>> +/*Lamarque: is this really needed? Sometimes this blocks rmmod
>forever
>> + * after running Skype on an AMD64 system. */
>> +/*videobuf_waiton(&buf->vb, 0, 0);*/
>
>Answering to your note, take a look at em28xx-video implementation:
>
>/* We used to wait for the buffer to finish here, but this didn't
>work
> because, as we were keeping the state as VIDEOBUF_QUEUED,
> videobuf_queue_cancel marked it as finished for us.
> (Also, it could wedge forever if the hardware was
>misconfigured.)
>
> This should be safe; by the time we get here, the buffer isn't
> queued anymore. If we ever start marking the buffers as
> VIDEOBUF_ACTIVE, it won't be, though.
>*/
>spin_lock_irqsave(&dev->slock, flags);
>if (dev->isoc_ctl.buf == buf)
>dev->isoc_ctl.buf = NULL;
>spin_unlock_irqrestore(&dev->slock, flags);
>
>> +if (pipe_info->state != 0) {
>> +if (usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL))
>> +dev_err(&cam->udev->dev, "error submitting urb\n");
>> +} else {
>> +DBG("read pipe complete state 0\n");
>> +}
>
>Hmm... for the usb_submit_urb() call that happens during IRQ context
>(while
>you're receiving stream), you need to use:
>urb->status = usb_submit_urb(pipe_info->stream_urb, GFP_ATOMIC);
>
>otherwise, you may get the errors that Antoine is reporting
>
>
>
>Cheers,
>Mauro
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Force driver to load (tcm825x)
Hello, I am working to get the omap34xxcam with the tcm825x running. Currently I was not successful in forcing the driver to load and register (in absence of a real sensor). I do a probe when the driver starts and uncommented the i2c things. It fails when calling the vidioc_int_g_priv() Function in the device-register function of the "omap34xxcam.c". How do I get it accepting the data ? Is there any documentation to find? Any hint would be perfect. Kind regards /Jesko -- 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: two instances of tvp514x module required for DM6467. Any suggestion?
Em Thu, 16 Jul 2009 10:32:17 -0500 "Karicheri, Muralidharan" escreveu: > Hi, > > I am working to add support for DM6467 capture driver. This evm has two > tvp5147 chips with different i2c addresses. So will I be able to call > v4l2_i2c_new_subdev_board() twice to have two instances of this driver > running? Yes. If there aren't any static vars at tvp514x and you have proper locks there, this should work fine 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] Implement V4L2_CAP_STREAMING for zr364xx driver
Em Wed, 15 Jul 2009 20:54:55 -0300
Lamarque Vieira Souza escreveu:
> This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
> converting the driver to use videobuf. This version is synced with v4l-dvb as
> of 15/Jul/2009.
>
> Tested with Creative PC-CAM 880.
>
> It basically:
> . implements V4L2_CAP_STREAMING using videobuf;
>
> . re-implements V4L2_CAP_READWRITE using videobuf;
>
> . copies cam->udev->product to the card field of the v4l2_capability struct.
> That gives more information to the users about the webcam;
>
> . moves the brightness setting code from before requesting a frame (in
> read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
> executed only when the application requests a change in brightness and
> not before every frame read;
>
> . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
> libv4l do not work.
>
> This patch fixes zr364xx for applications such as mplayer,
> Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
> with zr364xx chip.
>
> Signed-off-by: Lamarque V. Souza
> ---
>
> diff -r c300798213a9 linux/drivers/media/video/zr364xx.c
> --- a/linux/drivers/media/video/zr364xx.c Sun Jul 05 19:08:55 2009 -0300
> +++ b/linux/drivers/media/video/zr364xx.c Wed Jul 15 20:50:34 2009 -0300
> @@ -1,5 +1,5 @@
> /*
> - * Zoran 364xx based USB webcam module version 0.72
> + * Zoran 364xx based USB webcam module version 0.73
> *
> * Allows you to use your USB webcam with V4L2 applications
> * This is still in heavy developpement !
> @@ -10,6 +10,8 @@
> * Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c drivers
> * V4L2 version inspired by meye.c driver
> *
> + * Some video buffer code by Lamarque based on s2255drv.c and vivi.c drivers.
> + *
Maybe the better example for it is em28xx-video, where we firstly used videobuf
on usb devices.
> +static void free_buffer(struct videobuf_queue *vq, struct zr364xx_buffer
> *buf)
> +{
> + DBG("%s\n", __func__);
> +
> + /*Lamarque: is this really needed? Sometimes this blocks rmmod forever
> + * after running Skype on an AMD64 system. */
> + /*videobuf_waiton(&buf->vb, 0, 0);*/
Answering to your note, take a look at em28xx-video implementation:
/* We used to wait for the buffer to finish here, but this didn't work
because, as we were keeping the state as VIDEOBUF_QUEUED,
videobuf_queue_cancel marked it as finished for us.
(Also, it could wedge forever if the hardware was misconfigured.)
This should be safe; by the time we get here, the buffer isn't
queued anymore. If we ever start marking the buffers as
VIDEOBUF_ACTIVE, it won't be, though.
*/
spin_lock_irqsave(&dev->slock, flags);
if (dev->isoc_ctl.buf == buf)
dev->isoc_ctl.buf = NULL;
spin_unlock_irqrestore(&dev->slock, flags);
> + if (pipe_info->state != 0) {
> + if (usb_submit_urb(pipe_info->stream_urb, GFP_KERNEL))
> + dev_err(&cam->udev->dev, "error submitting urb\n");
> + } else {
> + DBG("read pipe complete state 0\n");
> + }
Hmm... for the usb_submit_urb() call that happens during IRQ context (while
you're receiving stream), you need to use:
urb->status = usb_submit_urb(pipe_info->stream_urb, GFP_ATOMIC);
otherwise, you may get the errors that Antoine is reporting
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
two instances of tvp514x module required for DM6467. Any suggestion?
Hi, I am working to add support for DM6467 capture driver. This evm has two tvp5147 chips with different i2c addresses. So will I be able to call v4l2_i2c_new_subdev_board() twice to have two instances of this driver running? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
Em Quinta-feira 16 Julho 2009, Antoine Jacquet escreveu: > Thanks, > > I successfully applied your patch and tested it with mplayer. > However I have the following trace each time I capture a frame: No, I do not have this problem neither in 2.6.28 (vanilla), 2.6.29.3 (vanilla source and v4l-dvb) and 2.6.30.1 (vanilla and v4l-dvb). My notebook is single core, maybe this problem is related to SMP. I will try to test the patch on a dual core processor. > [ 523.477064] BUG: scheduling while atomic: swapper/0/0x1001 > [ 523.477390] Modules linked in: zr364xx videodev v4l1_compat > v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core binfmt_misc ipv6 fuse > ntfs it87 hwmon_vid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event > snd_seq snd_timer snd_seq_device pcspkr snd snd_page_alloc > [ 523.477390] CPU 0: > [ 523.477390] Modules linked in: zr364xx videodev v4l1_compat > v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core binfmt_misc ipv6 fuse > ntfs it87 hwmon_vid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss > snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event > snd_seq snd_timer snd_seq_device pcspkr snd snd_page_alloc > [ 523.477390] Pid: 0, comm: swapper Not tainted 2.6.30.1 #1 Aspire T160 > [ 523.477390] RIP: 0010:[] [] > default_idle+0x54/0x90 > [ 523.477390] RSP: 0018:807e3f38 EFLAGS: 0246 > [ 523.477390] RAX: 807e3fd8 RBX: RCX: > > [ 523.477390] RDX: RSI: 0001 RDI: > 8078d010 > [ 523.477390] RBP: 8020b60e R08: R09: > > [ 523.477390] R10: 000f423d R11: R12: > 88003f87d180 > [ 523.477390] R13: R14: 88003e1e9940 R15: > 88003f87d180 > [ 523.477390] FS: 7f40f871e730() GS:80789000() > knlGS: > [ 523.477390] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > [ 523.477390] CR2: 7f099e8c2008 CR3: 3c16c000 CR4: > 06e0 > [ 523.477390] DR0: DR1: DR2: > > [ 523.477390] DR3: DR6: 0ff0 DR7: > 0400 > [ 523.477390] Call Trace: > [ 523.477390] [] ? notifier_call_chain+0x29/0x4c > [ 523.477390] [] ? cpu_idle+0x23/0x5b > [ 523.477390] [] ? start_kernel+0x2e8/0x2f4 > [ 523.477390] [] ? x86_64_start_kernel+0xe5/0xeb > > I can trigger it each time I read a frame, for example using dd on > /dev/video0. > Did you have the same behavior? > > Regards, > > Antoine > > Lamarque Vieira Souza wrote: > > This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by > > converting the driver to use videobuf. This version is synced with > > v4l-dvb as of 15/Jul/2009. > > > > Tested with Creative PC-CAM 880. > > > > It basically: > > . implements V4L2_CAP_STREAMING using videobuf; > > > > . re-implements V4L2_CAP_READWRITE using videobuf; > > > > . copies cam->udev->product to the card field of the v4l2_capability > > struct. That gives more information to the users about the webcam; > > > > . moves the brightness setting code from before requesting a frame (in > > read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is > > executed only when the application requests a change in brightness and > > not before every frame read; > > > > . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype + > > libv4l do not work. > > > > This patch fixes zr364xx for applications such as mplayer, > > Kopete+libv4l and Skype+libv4l can make use of the webcam that comes > > with zr364xx chip. > > > > Signed-off-by: Lamarque V. Souza > > --- -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
Thanks,
I successfully applied your patch and tested it with mplayer.
However I have the following trace each time I capture a frame:
[ 523.477064] BUG: scheduling while atomic: swapper/0/0x1001
[ 523.477390] Modules linked in: zr364xx videodev v4l1_compat
v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core binfmt_misc ipv6 fuse
ntfs it87 hwmon_vid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_timer snd_seq_device pcspkr snd snd_page_alloc
[ 523.477390] CPU 0:
[ 523.477390] Modules linked in: zr364xx videodev v4l1_compat
v4l2_compat_ioctl32 videobuf_vmalloc videobuf_core binfmt_misc ipv6 fuse
ntfs it87 hwmon_vid snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss
snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi_event
snd_seq snd_timer snd_seq_device pcspkr snd snd_page_alloc
[ 523.477390] Pid: 0, comm: swapper Not tainted 2.6.30.1 #1 Aspire T160
[ 523.477390] RIP: 0010:[] []
default_idle+0x54/0x90
[ 523.477390] RSP: 0018:807e3f38 EFLAGS: 0246
[ 523.477390] RAX: 807e3fd8 RBX: RCX:
[ 523.477390] RDX: RSI: 0001 RDI:
8078d010
[ 523.477390] RBP: 8020b60e R08: R09:
[ 523.477390] R10: 000f423d R11: R12:
88003f87d180
[ 523.477390] R13: R14: 88003e1e9940 R15:
88003f87d180
[ 523.477390] FS: 7f40f871e730() GS:80789000()
knlGS:
[ 523.477390] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
[ 523.477390] CR2: 7f099e8c2008 CR3: 3c16c000 CR4:
06e0
[ 523.477390] DR0: DR1: DR2:
[ 523.477390] DR3: DR6: 0ff0 DR7:
0400
[ 523.477390] Call Trace:
[ 523.477390] [] ? notifier_call_chain+0x29/0x4c
[ 523.477390] [] ? cpu_idle+0x23/0x5b
[ 523.477390] [] ? start_kernel+0x2e8/0x2f4
[ 523.477390] [] ? x86_64_start_kernel+0xe5/0xeb
I can trigger it each time I read a frame, for example using dd on
/dev/video0.
Did you have the same behavior?
Regards,
Antoine
Lamarque Vieira Souza wrote:
This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
converting the driver to use videobuf. This version is synced with v4l-dvb as
of 15/Jul/2009.
Tested with Creative PC-CAM 880.
It basically:
. implements V4L2_CAP_STREAMING using videobuf;
. re-implements V4L2_CAP_READWRITE using videobuf;
. copies cam->udev->product to the card field of the v4l2_capability struct.
That gives more information to the users about the webcam;
. moves the brightness setting code from before requesting a frame (in
read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
executed only when the application requests a change in brightness and
not before every frame read;
. comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
libv4l do not work.
This patch fixes zr364xx for applications such as mplayer,
Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
with zr364xx chip.
Signed-off-by: Lamarque V. Souza
---
diff -r c300798213a9 linux/drivers/media/video/zr364xx.c
--- a/linux/drivers/media/video/zr364xx.c Sun Jul 05 19:08:55 2009 -0300
+++ b/linux/drivers/media/video/zr364xx.c Wed Jul 15 20:50:34 2009 -0300
@@ -1,5 +1,5 @@
/*
- * Zoran 364xx based USB webcam module version 0.72
+ * Zoran 364xx based USB webcam module version 0.73
*
* Allows you to use your USB webcam with V4L2 applications
* This is still in heavy developpement !
@@ -10,6 +10,8 @@
* Heavily inspired by usb-skeleton.c, vicam.c, cpia.c and spca50x.c drivers
* V4L2 version inspired by meye.c driver
*
+ * Some video buffer code by Lamarque based on s2255drv.c and vivi.c drivers.
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -35,25 +37,34 @@
#include
#include
#include
+#include
#include "compat.h"
/* Version Information */
-#define DRIVER_VERSION "v0.72"
+#define DRIVER_VERSION "v0.73"
+#define ZR364_VERSION_CODE KERNEL_VERSION(0, 7, 3)
#define DRIVER_AUTHOR "Antoine Jacquet, http://royale.zerezo.com/";
#define DRIVER_DESC "Zoran 364xx"
/* Camera */
-#define FRAMES 2
+#define FRAMES 1
#define MAX_FRAME_SIZE 10
#define BUFFER_SIZE 0x1000
#define CTRL_TIMEOUT 500
+#define ZR364XX_DEF_BUFS 4
+#define ZR364XX_READ_IDLE 0
+#define ZR364XX_READ_FRAME 1
/* Debug macro */
-#define DBG(x...) if (debug) printk(KERN_INFO KBUILD_MODNAME x)
-
+#define DBG(fmt, args...) \
+ do { \
+ if (debug) { \
+ printk(KERN_INFO KBUILD_MODNAME " " fmt, ##args); \
+ } \
+ }
