[PATCH v2] Enabling of the Winfast TV2000 XP Global TV capture card remote control
This patch is for supporting the remote control of the Winfast TV2000 XP Global TV capture card. A case statement was added in order to initialize the GPIO data structures as well as a case statement for handling the keys correctly when pressed. Thanks to Hermann for all his help Regards Pieter van Schaik diff -r ac3865b16886 linux/drivers/media/video/cx88/cx88-input.c --- a/linux/drivers/media/video/cx88/cx88-input.c Mon Apr 20 08:47:22 2009 -0300 +++ b/linux/drivers/media/video/cx88/cx88-input.c Mon Apr 20 15:25:19 2009 +0200 @@ -92,6 +92,7 @@ gpio=(gpio & 0x7fd) + (auxgpio & 0xef); break; case CX88_BOARD_WINFAST_DTV1000: + case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL: gpio = (gpio & 0x6ff) | ((cx_read(MO_GP1_IO) << 8) & 0x900); auxgpio = gpio; break; @@ -243,6 +244,7 @@ break; case CX88_BOARD_WINFAST2000XP_EXPERT: case CX88_BOARD_WINFAST_DTV1000: + case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL: ir_codes = ir_codes_winfast; ir->gpio_addr = MO_GP0_IO; ir->mask_keycode = 0x8f8;
Re: [PATCH 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Jean, I had actually written out a longer, detailed, point-by-point reply earlier today, but before I could finish it I got interrupted with a crisis. And then another. And that's kind of how my day went. Now I'm finally back to this, but I have another e-mail debacle to immediately deal with (thank you pobox.com, not!) so I'm tossing that unfinished lengthy reply. I think I can sum this whole thing up very simply. Here's what I think should be happening: 1a. Your existing IR changeset, minus the pvrusb2 changes, should be merged. 1b. In parallel with (1a) I modify my pvrusb2 changeset to use the right module name and I adjust the driver option name to match. 2. My pvrusb2 changeset, with changes from (1b) is merged. 3. Andy's proposed change for ir_kbd_i2c to support additional IR devices is investigated and probably merged. 4. I test the changed ir_kbd_i2c against additional pvrusb2 devices known not to work previously with ir_kbd_i2c. If they work, then I will create a pvrusb2 patch to load ir_video in those cases as well as the cases already set up (which still won't cover all possible pvrusb2-driven devices). I think this satisfies the remaining issues, except that from between steps 1 and 2 ir_kbd_i2c won't work with the pvrusb2 driver. But you know, I'm OK with that. I expect (2) to happen within a few days after (1) so the impact should be minimal. It certainly won't escape into the kernel tree that way. In addition, my impression from the community of pvrusb2 users is that the preferred IR strategy is lirc anyway, and it's a foregone conclusion that they are all going to be, uh, impacted once your compatibility parts are gone from i2c. From where I'm sitting the "gap" from (1) to (2) is trivial compared to that impending mess - realize I'm not complaining since after all (a) it really falls to the lirc developers to fix that, (b) you do need to get your changes in, and (c) there's little I can do for lirc there except to keep it working as long as possible with the pvrusb2 driver. I'm just pointing out that I'm OK with the step 1 -> 2 gap for the pvrusb2 driver because it's small and will be nothing compared to what's about to happen with lirc. If you still don't like any of that, well, then I give up. In that case, then merge your changes with the pvrusb2 changes included. I won't ack them, but I'll just deal with it later. Because while your changes might keep ir_kbd_i2c going, they will also immediately break the more-useful and apparently more-used lirc (by always binding ir_kbd_i2c even in cases in the pvrusb2 driver where it's known that it can't even work but lirc would have) which as far as I'm concerned is far worse than the step 1 - 2 gap above. But it's just another gap and I'll push another pvrusb2 changeset on top to clean it up. So just do whatever you think is best right now, if you disagree with the sequence above. Now I will go off and deal with the steamer that pobox.com has just handed me :-( -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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] FM1216ME_MK3 some changes
If it should be unnoticed yet. > > > > I thought the FM1216ME MK3 was an analog only tuner. I guess I don't > > know DVB-T or cable in Europe well enough. > > that is for sure, analog only. > > Dmitry is preparing something for the MK5 too and the FMD1216ME/I MK3 > hybrid. Hmm, I wonder if Hans and Jarod do have something to improve for > the MK4 too and the others. > > As said, I don't care for changes within the freq. gap and accept > everything working better there ;) For some sort of completeness, we have quite some cardbus devices too, originally hacked by Hans J. Koch, you might not recognize as MK3 stuff. They come as ancient ALPS stuff. 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: [PATCH] FM1216ME_MK3 some changes
Hi,
Am Donnerstag, den 23.04.2009, 21:43 -0400 schrieb Andy Walls:
> Hi Dmitri,
>
> Thank you for you responses.
>
> Just a few more comments...
>
> On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
> > Hi Andy
> >
> > > Dmitri,
> > >
> > >
> > > On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
> > > > Hi All
> > > >
> > > > 1. Change middle band. In the end of the middle band the
> > > > sensitivity of receiver not good. If we switch to higher band,
> > > > sensitivity more better. Hardware trick.
> > >
>
> > Several years a go your customers write some messages about bad quality of
> > TV
> > if frequency of TV is the end of band. It can be low band or middle. Our
> > hardware engeneer make some tests with hardware TV generator and our TV
> > tuners.
> >
> > If we set default frequency range for low and middle band, quality of TV
> > signal
> > on 159MHz and 442 MHz is bad. When we make our changes with moving end of
> > bands
> > the quality of TV much better. And our system programmer for OS Windows use
> > changed
> > bands for drivers. Customers be happy.
>
> OK. A properly run experiment wins over theory every time. :)
>
>
>
> > You can test it if in your placement available TV programm on 159MHz or
> > 442MHz. This trick
> > can be usefull for other tuners.
>
> If you look at tveeprom.c, a number of other tuners are using that tuner
> definition:
>
> $ grep FM1216ME_MK3 tveeprom.c
> { TUNER_PHILIPS_FM1216ME_MK3, "Philips FQ1216ME MK3"},
> { TUNER_PHILIPS_FM1216ME_MK3, "Philips FM1216 ME MK3"},
> { TUNER_PHILIPS_FM1216ME_MK3, "LG S001D MK3"},
> { TUNER_PHILIPS_FM1216ME_MK3, "LG S701D MK3"},
> { TUNER_PHILIPS_FM1216ME_MK3, "Philips FQ1216LME MK3"},
> { TUNER_PHILIPS_FM1216ME_MK3, "TCL MFPE05 2"},
> { TUNER_PHILIPS_FM1216ME_MK3, "TCL MPE05-2"},
> { TUNER_PHILIPS_FM1216ME_MK3, "Philips FM1216ME MK5"},
>
> If your change makes things bad for the other tuners, we'll probably
> have to create an alternate entry for the other tuners instead of using
> the FM1216ME_MK3 defintion. I suspect most of them are clones of the
> FM1216ME MK3 however, so it probably won't matter.
>
> > > > 3. Set charge pump bit
> > >
> > > This will improve the time to initially tune to a frequency, but will
> > > likely add some noise as the PLL continues to maintain lock on the
> > > signal. If there is no way to turn off the CP after the lock bit is
> > > set in the tuner, it's probably better to leave it off for lower
> > > noise and just live with slower tuning.
> >
> > We discuss with our windows system programmer about it. He sad that
> > in analog TV mode noise from PLL don't give any problem.
>
> I would be concerned about phase noise affecting the colors or any FM
> sound carriers. If the noise isn't noticably affecting colors to the
> human eye (do color bars look OK?), or sound to the human ear, then OK.
>
>
> > But in digital TV mode
> > noise from PLL decreased BER.
>
> I thought the FM1216ME MK3 was an analog only tuner. I guess I don't
> know DVB-T or cable in Europe well enough.
that is for sure, analog only.
Dmitry is preparing something for the MK5 too and the FMD1216ME/I MK3
hybrid. Hmm, I wonder if Hans and Jarod do have something to improve for
the MK4 too and the others.
As said, I don't care for changes within the freq. gap and accept
everything working better there ;)
>
> > > Leaving the CP bit set should be especially noticable ad FM noise when
> > > set to tune to FM radio stations. From the FM1236ME_MK3 datasheet:
> > > "It is recommended to set CP=0 in the FM mode at all times."
> > > But the VHF low band control byte is also used when setting FM radio
> > > (AFAICT with a quick look at the code.)
> >
> > Yes. You are right. We can swith CP off in FM mode.
>
> OK. Thank you.
>
> > With my best regards, Dmitry.
>
>
> Regards,
> Andy
>
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: [PATCH] uvc: Add Microsoft VX 500 webcam
Hello Laurent, On Mon, 20 Apr 2009 20:07:31 +0200 Laurent Pinchart wrote: > Hi Douglas, > > On Wednesday 15 April 2009 15:48:08 Douglas Schilling Landgraf wrote: > > Hello Laurent, > > > > On Wed, 15 Apr 2009 11:46:52 +0200 > > > > Laurent Pinchart wrote: > > > Hi Douglas, > > > > > > On Wednesday 15 April 2009 09:03:45 Douglas Schilling Landgraf > > > wrote: > > > > Hello Laurent, > > > > > > > > Attached patch for the following: > > > > > > > > Added Microsoft VX 500 webcam to uvc driver. > > > > > > > > Signed-off-by: Douglas Schilling Landgraf > > > > > > Could you please send me the output of > > > > > > lsusb -v -d 045e:074a > > > > > > using usbutils 0.72 or newer (0.73+ preferred) ? > > > > usbutils-0.73-2 > > > > > Have you tried the latest driver ? > > > > Yes > > > > > The MINMAX quirk isn't required > > > anymore for most cameras (although the two supported Microsoft > > > webcams still need it, so I doubt it will work as-is). > > > > Indeed, attached new patch. > > The new patch shouldn't be needed at all, as it doesn't declare any > quirk. The camera should work out of the box using the latest driver. It doesn't work to me. :-( > Best regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~awalls/cx18-perf
On Wed, 2009-04-15 at 20:08 -0400, Andy Walls wrote: > Mauro, > > Please pull from: > > http://linuxtv.org/hg/~awalls/cx18-perf > > for the following: > > cx18: Increment version due to significant buffer handling changes > cx18: Simplify the work handler for outgoing mailbox commands > cx18: Convert per stream mutex locks to per queue spin locks > cx18: Set up to wait for a one-shot response before sending a firmware cmd > cx18: Add a work queue for deferring empty buffer handoffs to the firmware > cx18: Rename the work queue to "in_work_queue" > > These are a series of patches to improve latency of incoming capture > buffer handling from the time of firmware notification of DMA done, to > the applications reading the data, by removing all possible sleeps in > that processing. The sleeps, that can happen when trying to send empty > buffers back to the firmware, now happen in an "out_work_handler" set of > workqueue threads. > > Regards, > Andy Mauro, Please don not pull these changes yet. A user has reported a problem that concerns me. Until I fully investigate, I'd prefer this changeset not go forward. If it is already pulled, I let you know of any additional changes required as soon as possible. Thank you. 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
Re: [PATCH] FM1216ME_MK3 some changes
Hi Dmitri,
Thank you for you responses.
Just a few more comments...
On Thu, 2009-04-23 at 20:36 +1000, Dmitri Belimov wrote:
> Hi Andy
>
> > Dmitri,
> >
> >
> > On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
> > > Hi All
> > >
> > > 1. Change middle band. In the end of the middle band the
> > > sensitivity of receiver not good. If we switch to higher band,
> > > sensitivity more better. Hardware trick.
> >
> Several years a go your customers write some messages about bad quality of TV
> if frequency of TV is the end of band. It can be low band or middle. Our
> hardware engeneer make some tests with hardware TV generator and our TV
> tuners.
>
> If we set default frequency range for low and middle band, quality of TV
> signal
> on 159MHz and 442 MHz is bad. When we make our changes with moving end of
> bands
> the quality of TV much better. And our system programmer for OS Windows use
> changed
> bands for drivers. Customers be happy.
OK. A properly run experiment wins over theory every time. :)
> You can test it if in your placement available TV programm on 159MHz or
> 442MHz. This trick
> can be usefull for other tuners.
If you look at tveeprom.c, a number of other tuners are using that tuner
definition:
$ grep FM1216ME_MK3 tveeprom.c
{ TUNER_PHILIPS_FM1216ME_MK3, "Philips FQ1216ME MK3"},
{ TUNER_PHILIPS_FM1216ME_MK3, "Philips FM1216 ME MK3"},
{ TUNER_PHILIPS_FM1216ME_MK3, "LG S001D MK3"},
{ TUNER_PHILIPS_FM1216ME_MK3, "LG S701D MK3"},
{ TUNER_PHILIPS_FM1216ME_MK3, "Philips FQ1216LME MK3"},
{ TUNER_PHILIPS_FM1216ME_MK3, "TCL MFPE05 2"},
{ TUNER_PHILIPS_FM1216ME_MK3, "TCL MPE05-2"},
{ TUNER_PHILIPS_FM1216ME_MK3, "Philips FM1216ME MK5"},
If your change makes things bad for the other tuners, we'll probably
have to create an alternate entry for the other tuners instead of using
the FM1216ME_MK3 defintion. I suspect most of them are clones of the
FM1216ME MK3 however, so it probably won't matter.
> > > 3. Set charge pump bit
> >
> > This will improve the time to initially tune to a frequency, but will
> > likely add some noise as the PLL continues to maintain lock on the
> > signal. If there is no way to turn off the CP after the lock bit is
> > set in the tuner, it's probably better to leave it off for lower
> > noise and just live with slower tuning.
>
> We discuss with our windows system programmer about it. He sad that
> in analog TV mode noise from PLL don't give any problem.
I would be concerned about phase noise affecting the colors or any FM
sound carriers. If the noise isn't noticably affecting colors to the
human eye (do color bars look OK?), or sound to the human ear, then OK.
> But in digital TV mode
> noise from PLL decreased BER.
I thought the FM1216ME MK3 was an analog only tuner. I guess I don't
know DVB-T or cable in Europe well enough.
> > Leaving the CP bit set should be especially noticable ad FM noise when
> > set to tune to FM radio stations. From the FM1236ME_MK3 datasheet:
> > "It is recommended to set CP=0 in the FM mode at all times."
> > But the VHF low band control byte is also used when setting FM radio
> > (AFAICT with a quick look at the code.)
>
> Yes. You are right. We can swith CP off in FM mode.
OK. Thank you.
> With my best regards, Dmitry.
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
Re: recommendation for hd atsc usb device?
On Thu, 2009-04-23 at 11:49 -0400, b3782...@columbus.rr.com wrote: > Neal Becker wrote: > > > My ATSC reception is marginal. > > Are there any recommendations for devices that give better ATSC performance > > (I > > think the main issue in my location is multipath) > > Yes! > > Get a highly directional antenna. > A big honkin' UHF Yagi[1] should do the trick. > Better yet, mount it high (like on a chimney). > Better yet, use an antenna rotor[2]. > > [1] http://en.wikipedia.org/wiki/Yagi_antenna > E.g. http://www.radioshack.com/product/index.jsp?productId=2417011 > [2] http://en.wikipedia.org/wiki/Antenna_rotor Well, be advised that when the US DTV transition is complete, some stations will have moved back to VHF allocations. You'll need more than a UHF antenna. As far as improving signal goes: http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality And Winegard sells some good antenna amplifiers. Just remember, too much amplification can overdrive the front end of tuners and the intermodulation products that result will be equivalent to a rise in noise. Also, FM radio stations that are very strong in your antenna beam will show up as a herring-bone pattern (and thus noise) on analog TV stations on channels in the high-VHF and UHF bands. It's best to install your antenna and antenna amp and ajdust the FM trap while analog stations still are broadcasting so you can see gradual visual effects due to over-amplification on analog stations and correct them. -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
Re: Kernel 2.6.29 breaks DVB-T ASUSTeK Tiger LNA Hybrid Capture Device
Hi David and all interested, [snip] > > Sorry for interrupt. > Would your saa7134 i2c problem is due to the i2c quirk? > I have problem on the saa7134 i2c quirk that I have to totally disable > it on my work-in-progress card. > Just a little suggestion that trying disable the i2c quirk like this change > set: > http://linuxtv.org/hg/~mkrufky/dmbth/rev/781ffa6c43d3 > > David. I cross post this in for the record. Commenting the i2c quirk does not help at all on these card, as already assumed. And I also can't see any pattern yet, which should cause this from within v4l-dvb. At least, but who has hardware to test on all cases, the i2c quirk Gerd needed for the first saa7134 DVB card ever, the Pinnacle 300i, seems not to be needed for a few other cards I could test on only for now with saa7134 and saa7131e. So, Jean likely is right, that we should have it the other way round and this might help you and Mike with a decision still to make. Since 2.6.28 did work for those cards and 2.6.30-rc2-git4 seems to work within limited usability in my user environment, it seems to be something in between and might not even be the same. 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
TT S2 1600 status
Hi all, Support for the TT S2-1600 has been updated. Please do test. The 903 demodulator officially supports 45MSPS, with an unofficial max up to 63MSPS with 8PSK DVB-S2. (standard DVB-S2 demodulators support upto 30MSPS) Support is found on the v4l-dvb hg tree on jusst.de Testers, Feedback welcome. Regards, Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
Mauro Carvalho Chehab wrote: > On Thu, 23 Apr 2009 17:05:45 +0200 > Erik Andrén wrote: > > >> Hi, I'm truly sorry for creating this mess. I wasn't aware of that the >> previously pulled changesets still were registred after a pull. > > No problem. > >> I'm all for submitting pull requests to you Mauro. >> Just to avoid these kind of situations in the future please review this >> process. >> >> 1. Perform various commits to my local v4l-dvb tree >> 2. Pull the main tree >> 3. Resolve any conflicts > > Be care with the conflicts: if you fix non-trivial conflicts at the merge > commit, this will be lost when I'll generate the -git patch (since merge > patches aren't exported). On those cases, the better is to clone main tree, > and > apply patch per patch on it (./hgimport script helps with this), fixing the > conflict on the affected patch. > >> 4. Push my local tree >> 5. Send mail asking for a pull > > Ok. >> Do I need to do anything further or could I just repeat this process >> in the future? > > The above process, noticing my comment is enough. >> Best regards, >> Erik > Ok, so the next step is to clone your main v4l-dvb tree, apply the new patches and submit a pull request directly to you, or have Jean-Francois already pulled them? Best regards, Erik > > > > 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
patch: s2255drv: code cleanup
From: Dean Anderson
Removal of unused structure items. Response values defined. Driver revision
printk.
Signed-off-by: Dean Anderson
--- v4l-dvb-ebb7b82f2b48/linux/drivers/media/video/s2255drv.c.orig
2009-04-23 11:37:28.0 -0700
+++ v4l-dvb-ebb7b82f2b48/linux/drivers/media/video/s2255drv.c 2009-04-23
11:54:24.0 -0700
@@ -78,6 +78,8 @@
#define MAX_CHANNELS 4
#define S2255_MARKER_FRAME 0x2255DA4AL
#define S2255_MARKER_RESPONSE 0x2255ACACL
+#define S2255_RESPONSE_SETMODE 0x01
+#define S2255_RESPONSE_FW 0x10
#define S2255_USB_XFER_SIZE(16 * 1024)
#define MAX_CHANNELS 4
#define MAX_PIPE_BUFFERS 1
@@ -179,9 +181,6 @@ struct s2255_bufferi {
struct s2255_dmaqueue {
struct list_headactive;
- /* thread for acquisition */
- struct task_struct *kthread;
- int frame;
struct s2255_dev*dev;
int channel;
};
@@ -211,16 +210,11 @@ struct s2255_pipeinfo {
u32 max_transfer_size;
u32 cur_transfer_size;
u8 *transfer_buffer;
- u32 transfer_flags;;
u32 state;
- u32 prev_state;
- u32 urb_size;
void *stream_urb;
void *dev; /* back pointer to s2255_dev struct*/
u32 err_count;
- u32 buf_index;
u32 idx;
- u32 priority_set;
};
struct s2255_fmt; /*forward declaration */
@@ -240,8 +234,6 @@ struct s2255_dev {
struct list_heads2255_devlist;
struct timer_list timer;
struct s2255_fw *fw_data;
- int board_num;
- int is_open;
struct s2255_pipeinfo pipes[MAX_PIPE_BUFFERS];
struct s2255_bufferibuffer[MAX_CHANNELS];
struct s2255_mode mode[MAX_CHANNELS];
@@ -298,9 +290,10 @@ struct s2255_fh {
int resources[MAX_CHANNELS];
};
-#define CUR_USB_FWVER 774 /* current cypress EEPROM firmware version */
+/* current cypress EEPROM firmware version */
+#define S2255_CUR_USB_FWVER((3 << 8) | 6)
#define S2255_MAJOR_VERSION1
-#define S2255_MINOR_VERSION13
+#define S2255_MINOR_VERSION14
#define S2255_RELEASE 0
#define S2255_VERSION KERNEL_VERSION(S2255_MAJOR_VERSION, \
S2255_MINOR_VERSION, \
@@ -1819,7 +1812,6 @@ static int s2255_probe_v4l(struct s2255_
INIT_LIST_HEAD(&dev->vidq[i].active);
dev->vidq[i].dev = dev;
dev->vidq[i].channel = i;
- dev->vidq[i].kthread = NULL;
/* register 4 video devices */
dev->vdev[i] = video_device_alloc();
memcpy(dev->vdev[i], &template, sizeof(struct video_device));
@@ -1840,7 +1832,9 @@ static int s2255_probe_v4l(struct s2255_
return ret;
}
}
- printk(KERN_INFO "Sensoray 2255 V4L driver\n");
+ printk(KERN_INFO "Sensoray 2255 V4L driver Revision: %d.%d\n",
+ S2255_MAJOR_VERSION,
+ S2255_MINOR_VERSION);
return ret;
}
@@ -1930,14 +1924,14 @@ static int save_frame(struct s2255_dev *
if (!(cc >= 0 && cc < MAX_CHANNELS))
break;
switch (pdword[2]) {
- case 0x01:
+ case S2255_RESPONSE_SETMODE:
/* check if channel valid */
/* set mode ready */
dev->setmode_ready[cc] = 1;
wake_up(&dev->wait_setmode[cc]);
dprintk(5, "setmode ready %d\n", cc);
break;
- case 0x10:
+ case S2255_RESPONSE_FW:
dev->chn_ready |= (1 << cc);
if ((dev->chn_ready & 0x0f) != 0x0f)
@@ -2173,10 +2167,15 @@ static int s2255_board_init(struct s2255
/* query the firmware */
fw_ver = s2255_get_fx2fw(dev);
- printk(KERN_INFO "2255 usb firmware version %d \n", fw_ver);
- if (fw_ver < CUR_USB_FWVER)
+ printk(KERN_INFO "2255 usb firmware version %d.%d\n",
+ (fw_ver >> 8) & 0xff,
+ fw_ver & 0xff);
+
+ if (fw_ver < S2255_CUR_USB_FWVER)
dev_err(&dev->udev->dev,
- "usb firmware not up to date %d\n", fw_ver);
+ "usb firmware not up to date %d.%d\n",
+ (fw_ver >> 8) & 0xff,
+ fw_ver & 0xff);
for (j = 0; j < MAX_CHANNELS; j++) {
dev->b_acquire[j] = 0;
@@ -2284,8 +2283,7 @@ static int s2255_start_readpipe(struct s
[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 Apr 23 19:00:04 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11576:ebb7b82f2b48 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-rc3-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-rc3-armv5-omap2: ERRORS linux-2.6.22.19-i686: WARNINGS 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: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-rc3-i686: ERRORS 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-rc3-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29.1-mips: OK linux-2.6.30-rc3-mips: ERRORS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-rc3-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS 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-rc3-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc3): 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: WARNINGS 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: WARNINGS 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: [PULL] http://linuxtv.org/hg/~eandren/gspca/
On Thu, 23 Apr 2009 17:05:45 +0200 Erik Andrén wrote: > Hi, I'm truly sorry for creating this mess. I wasn't aware of that the > previously pulled changesets still were registred after a pull. No problem. > I'm all for submitting pull requests to you Mauro. > Just to avoid these kind of situations in the future please review this > process. > > 1. Perform various commits to my local v4l-dvb tree > 2. Pull the main tree > 3. Resolve any conflicts Be care with the conflicts: if you fix non-trivial conflicts at the merge commit, this will be lost when I'll generate the -git patch (since merge patches aren't exported). On those cases, the better is to clone main tree, and apply patch per patch on it (./hgimport script helps with this), fixing the conflict on the affected patch. > 4. Push my local tree > 5. Send mail asking for a pull Ok. > > Do I need to do anything further or could I just repeat this process > in the future? The above process, noticing my comment is enough. > > Best regards, > Erik Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
2009/4/23 Mauro Carvalho Chehab : > On Thu, 23 Apr 2009 15:21:41 +0200 > Jean-Francois Moine wrote: > >> On Thu, 23 Apr 2009 09:42:07 -0300 >> Mauro Carvalho Chehab wrote: >> > On Mon, 20 Apr 2009 21:21:53 +0200 >> > Erik Andrén wrote: >> > > Hi Jean-Francois. >> > > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more >> > > 2.6.30+ related changeset. >> > > >> > > If Mauro has imposed some kind of changeset limit on you that forces >> > > you to issue a pull request to Mauro each time you have pulled from >> > > my repository then we might have a process issue which probably we >> > > should discuss. >> > > If you think it's too much work to issue these kinds of extra >> > > requests then I can submit pull requests directly to Mauro, as my >> > > code only touches the m5602 part of the gspca driver and any patch >> > > touching the gspca core would first be posted to the list for >> > > review. >> > >> > Wow! 196 patches! >> > >> > Instead of submitting such large pull requests, you should had, >> > instead, submit more frequent smaller pull requests. I'll handle it >> > directly, but you should be warned that eventually some of those >> > patches will require changes. On that case, I'll point you the >> > troubles I may found on the offending patch, and I'll wait for your >> > fixes or comments about it. Only then I'll proceed (since it has some >> > chances that you'll need to touch on other patches of this large >> > series if such case happens). >> > >> > > That said I'm currently trying to push a backlog of changesets which >> > > thankfully soon is done. The driver is currently in quite a stable >> > > state and I'm not doing any active work on it for the moment, IOW >> > > the steady stream of frequent pull requests will soon end. >> >> Hi Mauro, >> >> Well, as I told him many times, the best for Erik should be to ask you >> directly to pull his changesets, but we started in an other way. > > Ok. Probably he sending patches that don't touch on gspca core would improve > the process. > >> Actually, I have two repositories: 'v4l-dvb' which is under the main >> v4l-dvb, and 'gspca' which is desynchronized and is used for tests. >> Erik's repository is under this last one. > > Ok, that explains why it hits 196 patches here. > >> When I get pull requests from >> him, I do 'hg export' from his repository and 'hg import' to my test >> repository. Then I do again export and import from my test to my main >> for a pull request to you. Eventually, when I get a new pull request >> from Erik, 'hg incoming' from Erik to my test repository gives me again >> the previous changesets. So, I have to check them and apply only the >> new changesets. Is there any method to avoid such a problem? > > Unfortunately, hg has some troubles when you have a more distributed model > like > what we have with gspca. > > Hg now have the rebase extension that could eventually help to exceed its > limitations, but my experiences with this went into more troubles than > solutions. > > IMO, the better would be if he uses the main v4l-dvb as the basis for his > sub-tree. This works for most of the patches. This will not work for the few > ones that touches on gspca core files, but this is probably the exception. > > So, if you decide to go to this approach, you'll have to submit him patches > that touches on his files, and he'll have to submit you the patches that > touches on core. > > Yet, you'll have troubles if I reject one patch from the tree. > Hi, I'm truly sorry for creating this mess. I wasn't aware of that the previously pulled changesets still were registred after a pull. I'm all for submitting pull requests to you Mauro. Just to avoid these kind of situations in the future please review this process. 1. Perform various commits to my local v4l-dvb tree 2. Pull the main tree 3. Resolve any conflicts 4. Push my local tree 5. Send mail asking for a pull Do I need to do anything further or could I just repeat this process in the future? Best regards, Erik -- 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 usb-pwc-do-not-pass-stack-allocated-buffers-to-usb-core.patch added to gregkh-2.6 tree
On Wed, Apr 22, 2009 at 08:20:50PM -0300, Mauro Carvalho Chehab wrote: > On Wed, 22 Apr 2009 14:00:24 -0700 > wrote: > > > > > This is a note to let you know that I've just added the patch titled > > > > Subject: USB: pwc : do not pass stack allocated buffers to USB core. > > > > to my gregkh-2.6 tree. Its filename is > > > > usb-pwc-do-not-pass-stack-allocated-buffers-to-usb-core.patch > > > > This tree can be found at > > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ > > > > > > From mfuz...@gmail.com Wed Apr 22 13:31:46 2009 > > From: Martin Fuzzey > > Date: Tue, 21 Apr 2009 21:48:09 +0200 > > Subject: USB: pwc : do not pass stack allocated buffers to USB core. > > To: Greg KH , > > Message-ID: <20090421194808.8272.8437.st...@mfuzzey-laptop> > > > > > > This is causes problems on platforms that have alignment requirements > > for DMA transfers. > > > > Signed-off-by: Martin Fuzzey > > Signed-off-by: Greg Kroah-Hartman > > Acked-by: Mauro Carvalho Chehab Thanks, I've added it to the patch and will send it off in my next round of updates. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
On Thu, 23 Apr 2009 10:19:48 -0300 Mauro Carvalho Chehab wrote: > > > > changeset: 11571:c3ae07c7c476 > > > > gspca - tp6800: New subdriver with webcam 06a2:0003. > > + .sizeimage = 320 * 240 + 590, > > Hmm... this looks weird! Why do you need to add 590 bytes here? Yes, there are problems in this driver, but it is working! Anders, may you change the 'sizeimage's to: .sizeimage = 320 * 240 * 3 / 8 + 590, and .sizeimage = 640 * 480 * 3 / 8 + 590, Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
On Thu, 23 Apr 2009 15:21:41 +0200 Jean-Francois Moine wrote: > On Thu, 23 Apr 2009 09:42:07 -0300 > Mauro Carvalho Chehab wrote: > > On Mon, 20 Apr 2009 21:21:53 +0200 > > Erik Andrén wrote: > > > Hi Jean-Francois. > > > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more > > > 2.6.30+ related changeset. > > > > > > If Mauro has imposed some kind of changeset limit on you that forces > > > you to issue a pull request to Mauro each time you have pulled from > > > my repository then we might have a process issue which probably we > > > should discuss. > > > If you think it's too much work to issue these kinds of extra > > > requests then I can submit pull requests directly to Mauro, as my > > > code only touches the m5602 part of the gspca driver and any patch > > > touching the gspca core would first be posted to the list for > > > review. > > > > Wow! 196 patches! > > > > Instead of submitting such large pull requests, you should had, > > instead, submit more frequent smaller pull requests. I'll handle it > > directly, but you should be warned that eventually some of those > > patches will require changes. On that case, I'll point you the > > troubles I may found on the offending patch, and I'll wait for your > > fixes or comments about it. Only then I'll proceed (since it has some > > chances that you'll need to touch on other patches of this large > > series if such case happens). > > > > > That said I'm currently trying to push a backlog of changesets which > > > thankfully soon is done. The driver is currently in quite a stable > > > state and I'm not doing any active work on it for the moment, IOW > > > the steady stream of frequent pull requests will soon end. > > Hi Mauro, > > Well, as I told him many times, the best for Erik should be to ask you > directly to pull his changesets, but we started in an other way. Ok. Probably he sending patches that don't touch on gspca core would improve the process. > Actually, I have two repositories: 'v4l-dvb' which is under the main > v4l-dvb, and 'gspca' which is desynchronized and is used for tests. > Erik's repository is under this last one. Ok, that explains why it hits 196 patches here. > When I get pull requests from > him, I do 'hg export' from his repository and 'hg import' to my test > repository. Then I do again export and import from my test to my main > for a pull request to you. Eventually, when I get a new pull request > from Erik, 'hg incoming' from Erik to my test repository gives me again > the previous changesets. So, I have to check them and apply only the > new changesets. Is there any method to avoid such a problem? Unfortunately, hg has some troubles when you have a more distributed model like what we have with gspca. Hg now have the rebase extension that could eventually help to exceed its limitations, but my experiences with this went into more troubles than solutions. IMO, the better would be if he uses the main v4l-dvb as the basis for his sub-tree. This works for most of the patches. This will not work for the few ones that touches on gspca core files, but this is probably the exception. So, if you decide to go to this approach, you'll have to submit him patches that touches on his files, and he'll have to submit you the patches that touches on core. Yet, you'll have troubles if I reject one patch from the tree. With git, the workflow would probably be much more easier, since you can create several branches on your tree, and patch migration/rebasing between the branches is very easy. You can even undo several git operations, since it has a history tracking what happened, in terms or merging. > About this pull request, 'hg incoming' gives me only 56 changesets, but > I think that 30 ones were alrady applied... Probably due to some "rebase" did by one of you. Since his work is against your tree, I have no other option but waiting until you cleanup the mess and send me a pull request. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
On Thu, 23 Apr 2009 09:42:07 -0300 Mauro Carvalho Chehab wrote: > On Mon, 20 Apr 2009 21:21:53 +0200 > Erik Andrén wrote: > > Hi Jean-Francois. > > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more > > 2.6.30+ related changeset. > > > > If Mauro has imposed some kind of changeset limit on you that forces > > you to issue a pull request to Mauro each time you have pulled from > > my repository then we might have a process issue which probably we > > should discuss. > > If you think it's too much work to issue these kinds of extra > > requests then I can submit pull requests directly to Mauro, as my > > code only touches the m5602 part of the gspca driver and any patch > > touching the gspca core would first be posted to the list for > > review. > > Wow! 196 patches! > > Instead of submitting such large pull requests, you should had, > instead, submit more frequent smaller pull requests. I'll handle it > directly, but you should be warned that eventually some of those > patches will require changes. On that case, I'll point you the > troubles I may found on the offending patch, and I'll wait for your > fixes or comments about it. Only then I'll proceed (since it has some > chances that you'll need to touch on other patches of this large > series if such case happens). > > > That said I'm currently trying to push a backlog of changesets which > > thankfully soon is done. The driver is currently in quite a stable > > state and I'm not doing any active work on it for the moment, IOW > > the steady stream of frequent pull requests will soon end. Hi Mauro, Well, as I told him many times, the best for Erik should be to ask you directly to pull his changesets, but we started in an other way. Actually, I have two repositories: 'v4l-dvb' which is under the main v4l-dvb, and 'gspca' which is desynchronized and is used for tests. Erik's repository is under this last one. When I get pull requests from him, I do 'hg export' from his repository and 'hg import' to my test repository. Then I do again export and import from my test to my main for a pull request to you. Eventually, when I get a new pull request from Erik, 'hg incoming' from Erik to my test repository gives me again the previous changesets. So, I have to check them and apply only the new changesets. Is there any method to avoid such a problem? About this pull request, 'hg incoming' gives me only 56 changesets, but I think that 30 ones were alrady applied... Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
On Thu, 23 Apr 2009 14:43:37 +0200 Jean-Francois Moine wrote: > On Thu, 23 Apr 2009 09:43:28 -0300 > Mauro Carvalho Chehab wrote: > > > On Tue, 21 Apr 2009 09:29:39 +0200 > > Jean-Francois Moine wrote: > > > > > Hi Mauro, > > > > > > Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ > > > for: > > > > > > changeset: 11570:ccddae0f5d8f > > > gspca - zc3xx: Bad debug level in i2c_read. > > > > > > changeset: 11571:c3ae07c7c476 > > > gspca - tp6800: New subdriver with webcam 06a2:0003. + .sizeimage = 320 * 240 + 590, Hmm... this looks weird! Why do you need to add 590 bytes here? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
On Mon, 20 Apr 2009 21:21:53 +0200 Erik Andrén wrote: > Hi Jean-Francois. > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more > 2.6.30+ related changeset. > I suspect that there are something wrong on your tree: # HG changeset patch # User Jean-Francois Moine # Date 1233943966 -3600 # Node ID 832fa26df44387e729f3e793c2cf7329d9bb0faf # Parent 46e1d0a87f80d261d13eda63916bc256b3e35f57 gspca - sq905: New subdriver. gspca - sq905: New subdriver. From: Adam Baker Add initial support for cameras based on the SQ Technologies SQ-905 chipset (USB ID 2770:9120) to V4L2 using the gspca infrastructure. Currently only supports one resolution and doesn't attempt to inform libv4l what image flipping options are needed. Priority: normal This patch is already on my tree, but with a different MD5: changeset: 10639:81b7156aa12d user:Jean-Francois Moine date:Fri Feb 06 19:12:46 2009 +0100 files: linux/drivers/media/video/gspca/Kconfig linux/drivers/media/video/gspca/Makefile linux/drivers/media/video/gspca/sq905.c description: gspca - sq905: New subdriver. From: Adam Baker Add initial support for cameras based on the SQ Technologies SQ-905 chipset (USB ID 2770:9120) to V4L2 using the gspca infrastructure. Currently only supports one resolution and doesn't attempt to inform libv4l what image flipping options are needed. Priority: normal Please re-base your tree against mine and add the newer patches only. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
On Thu, 23 Apr 2009 09:43:28 -0300 Mauro Carvalho Chehab wrote: > On Tue, 21 Apr 2009 09:29:39 +0200 > Jean-Francois Moine wrote: > > > Hi Mauro, > > > > Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ > > for: > > > > changeset: 11570:ccddae0f5d8f > > gspca - zc3xx: Bad debug level in i2c_read. > > > > changeset: 11571:c3ae07c7c476 > > gspca - tp6800: New subdriver with webcam 06a2:0003. > > > > changeset: 11572:b7b10bc9ad67 > > tag: tip > > gspca - main: Version change. > > > > Cheers. > > > Hmm... your tree seems to be empty. Had I already pulled from it? > > Cheers, > Mauro Oops, I forgot to do the push! Here it is. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
On Tue, 21 Apr 2009 09:29:39 +0200 Jean-Francois Moine wrote: > Hi Mauro, > > Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ > for: > > changeset: 11570:ccddae0f5d8f > gspca - zc3xx: Bad debug level in i2c_read. > > changeset: 11571:c3ae07c7c476 > gspca - tp6800: New subdriver with webcam 06a2:0003. > > changeset: 11572:b7b10bc9ad67 > tag: tip > gspca - main: Version change. > > Cheers. > Hmm... your tree seems to be empty. Had I already pulled from it? Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~eandren/gspca/
On Mon, 20 Apr 2009 21:21:53 +0200 Erik Andrén wrote: > Hi Jean-Francois. > Please pull http://linuxtv.org/hg/~eandren/gspca/ for some more > 2.6.30+ related changeset. > > If Mauro has imposed some kind of changeset limit on you that forces > you to issue a pull request to Mauro each time you have pulled from > my repository then we might have a process issue which probably we > should discuss. > If you think it's too much work to issue these kinds of extra > requests then I can submit pull requests directly to Mauro, as my > code only touches the m5602 part of the gspca driver and any patch > touching the gspca core would first be posted to the list for review. Wow! 196 patches! Instead of submitting such large pull requests, you should had, instead, submit more frequent smaller pull requests. I'll handle it directly, but you should be warned that eventually some of those patches will require changes. On that case, I'll point you the troubles I may found on the offending patch, and I'll wait for your fixes or comments about it. Only then I'll proceed (since it has some chances that you'll need to touch on other patches of this large series if such case happens). > That said I'm currently trying to push a backlog of changesets which > thankfully soon is done. The driver is currently in quite a stable > state and I'm not doing any active work on it for the moment, IOW > the steady stream of frequent pull requests will soon end. > > Best regards, > Erik Andrén Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
On Sun, 19 Apr 2009 12:46:00 +0200 Hans Verkuil wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the > following: > > - v4l: TI THS7303 video amplifier driver code > - Analog Devices ADV7343 video encoder driver > - v4l: improve consistency of the config menu. > > These new drivers for the davinci platform have been reviewed and OKed > almost a month ago, so it's time to get these merged. Especially since the > davinci display driver is also almost ready. Please, never copy a subscribers only list on pull requests. It is very annoying to receive such emails: From: davinci-linux-open-source-boun...@linux.davincidsp.com To: mche...@infradead.org Subject: Your message to Davinci-linux-open-source awaits moderator approval Date: Thu, 23 Apr 2009 06:35:25 -0500 Sender: davinci-linux-open-source-boun...@linux.davincidsp.com Your mail to 'Davinci-linux-open-source' with the subject Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://linux.davincidsp.com/mailman/confirm/davinci-linux-open-source/cb8519a88f202b29b91bd0944d04b2ef2e67c239 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci
On Sun, 19 Apr 2009 12:46:00 +0200
Hans Verkuil wrote:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-davinci for the
> following:
>
> - v4l: TI THS7303 video amplifier driver code
+static int ths7303_setvalue(struct v4l2_subdev *sd, v4l2_std_id std)
+{
+ int err = 0;
+ u8 val;
+ struct i2c_client *client;
+
+ client = v4l2_get_subdevdata(sd);
+
+ if ((std & V4L2_STD_NTSC) || (std & V4L2_STD_PAL)) {
+ val = 0x02;
+ v4l2_dbg(1, debug, sd, "setting value for SDTV format\n");
+ } else {
+ val = 0x00;
+ v4l2_dbg(1, debug, sd, "disabling all channels\n");
+ }
+
Hmm... Are you sure that the above check is ok? The standards you're allowing
are: PAL/BGDKHI and NTSC (except for NTSC/443). So, standards like PAL/N,
PAL/N', PAL/60, PAL/M will stay away.
If what you want is all standards but SECAM, then the correct syntax would be
something like:
if (std & (V4L2_STD_ALL & ~V4L2_STD_SECAM))
> - Analog Devices ADV7343 video encoder driver
+#define SD_STD_NTSC(0x00)
+#define SD_STD_PAL_BDGHI (0x01)
+#define SD_STD_PAL_M (0x02)
+#define SD_STD_PAL_N (0x03)
Hmm... from the comments at the beginning of the .c file, it seems that the
hardware supports all standards but SECAM. The above register definitions also
specifies PAL/M and PAL/M as supported standards.
However, by looking at the std_into table:
+static const struct adv7343_std_info
+ adv7343_composite_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0xCB, 0x8A, 0x09, 0x2A, V4L2_STD_PAL,
+ },
+};
+
+static const struct adv7343_std_info
+ adv7343_component_std_info[] = {
+ {
+ SD_STD_NTSC, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_NTSC,
+ },
+ {
+ SD_STD_PAL_BDGHI, 0x1F, 0x7C, 0xF0, 0x21, V4L2_STD_PAL,
+ },
+};
Hmm.. on the last table, you are using a FSC = 3,579,545.45 Hz for both PAL and
NTSC? This seems wrong to my eyes.
Also, both tables have several supported standards missed.
Instead of specifying the FSC as 4 u8 values, obfuscating its value, it would
be much more valuable to write it as a u32 and explaining how to obtain the
value.
Unfortunately, according with the datasheet [1], those values are specified in
function of the 27MHz reference clock, and not in Hz, so the data is somewhat
obfuscated.
The datasheet says that this is calculated by:
number of subcarrier periods per video line
FSC(reg) = --- x 2^32
number of 27MHz clk cycles per video line
And rounded to the nearest value.
Since both factors are divided by the same constant (video line), this is the
same as defining FSC(reg) as given by this formula:
2^32
FSC(reg) = FSC (Hz) * -
2700 (Hz)
By using the above formula, we have:
StandardFSC (Hz) * 2^32/2700 = FSC(reg)
PAL/M 3,575,611.00 * 159.0728628 = 568,782,678.08
PAL/Nc 3,582,056.00 * 159.0728628 = 569,807,902.68
NTSC3,579,545.45 * 159.0728628 = 569,408,542.31
PAL/NBGDKHI 4,433,618.75 * 159.0728628 = 705,268,427.19
With the above, we can fill the missing entries at the table.
Ah, if you want, you can also add PAL/60 and NTSC/443 to the above table, since
both also use the same 4.42 MHz FSC.
NTSC 4.43 should be as simple as just using 4.43 MHz for FSC.
I'm not sure what would be the proper SD register for PAL/60, and the datasheet
doesn't mention (although it says it is supported). I guess it will work
properly with the same value as PAL/M, since, AFAIK, the only difference
between PAL/60 and PAL/M is the FSC.
So, the complete STD for all supported standards seems to be:
struct adv7343_std_info {
u32 standard_reg;
u32 fsc_regs;
v4l2_std_id stdid;
};
/*
* 2^32
* FSC(reg) = FSC (HZ) *
*2700
*/
adv7343_std_info[] = {
{
/* FSC(Hz) = 3,579,545.45 Hz */
SD_STD_NTSC, 569408542, V4L2_STD_NTSC,
}, {
/* FSC(Hz) = 3,575,611.00 Hz */
SD_STD_PAL_M, 568782678, V4L2_STD_PAL_M,
}, {
/* FSC(Hz) = 3,582,056.00 */
SD_STD_PAL_N, 569807903, V4L2_STD_PAL_Nc,
}, {
/* FSC(Hz) = 4,433,618.75 Hz */
SD_STD_PAL_N, 705268427, V4L2_STD_PAL_N,
}, {
/* FSC(Hz) = 4,433,618.75 Hz */
SD_STD_PAL_BDGHI, 705268427, V4L2_STD_PAL,
}, {
/* FSC(Hz) = 4,433,618.75 Hz */
SD_STD_NTSC, 705268427, V4L2_STD_NTSC443,
}, {
/* FSC(Hz) = 4,433,618.75 Hz */
SD_STD_PAL_M, 705268427, V4L2_STD_PAL6
Re: [PATCH] FM1216ME_MK3 some changes
Hi Andy
> Dmitri,
>
>
> On Wed, 2009-04-22 at 17:48 +1000, Dmitri Belimov wrote:
> > Hi All
> >
> > 1. Change middle band. In the end of the middle band the
> > sensitivity of receiver not good. If we switch to higher band,
> > sensitivity more better. Hardware trick.
>
> This concerns me slightly as it does not match the datasheet (hence
> the design objectives) of the FM1236ME_MK3.
Yes, I know.
> How are you measuring sensitivity? Do you know if it really is the
> middle-band preselector filter (and PLL and Mixer) or is it a problem
> with the input signal? How do you know it is not manufacturing
> variations in the preselector filters with the particular tuner
> assembly you are testing?
Several years a go your customers write some messages about bad quality of TV
if frequency of TV is the end of band. It can be low band or middle. Our
hardware engeneer make some tests with hardware TV generator and our TV tuners.
If we set default frequency range for low and middle band, quality of TV signal
on 159MHz and 442 MHz is bad. When we make our changes with moving end of bands
the quality of TV much better. And our system programmer for OS Windows use
changed
bands for drivers. Customers be happy.
You can test it if in your placement available TV programm on 159MHz or 442MHz.
This trick
can be usefull for other tuners.
> Also, as an alternative to using a different frequency for the
> bandswitch, have you considered setting the Auxillary Byte in the
> tuner chip (Infineon TUA6030?) to use external AGC and experimented
> with changing the tuner AGC take-over point (TOP) in the TDA9887?
>
> By maximizing the gain in the tuner chip, but avoiding clipping, with
> the proper TOP setting, you minimize the contributions by the rest of
> the receive chain to the overall receiver Noise Figure:
>
> http://en.wikipedia.org/wiki/Friis_formulas_for_noise
>
> This may be a way to improve receiver sensitivity that does not
> conflict with the data sheet specification.
>
>
>
>
> > 2. Set correct highest freq of the higher band.
>
> :)
>
> This bothers me too; all the tuners in tuner-types.c have it set too
> high (999.0 MHz). I think I rememeber at time when all the
> tuner_range definitions had a real value there.
>
> It would be nice to have a real value there for all the tuners. The
> function tuner-simple.c:simple_config_lookup() would then prevent
> attempts to tune to an unsupported frequnecy.
>
>
>
> > 3. Set charge pump bit
>
> This will improve the time to initially tune to a frequency, but will
> likely add some noise as the PLL continues to maintain lock on the
> signal. If there is no way to turn off the CP after the lock bit is
> set in the tuner, it's probably better to leave it off for lower
> noise and just live with slower tuning.
We discuss with our windows system programmer about it. He sad that
in analog TV mode noise from PLL don't give any problem. But in digital TV mode
noise from PLL decreased BER.
> Leaving the CP bit set should be especially noticable ad FM noise when
> set to tune to FM radio stations. From the FM1236ME_MK3 datasheet:
> "It is recommended to set CP=0 in the FM mode at all times."
> But the VHF low band control byte is also used when setting FM radio
> (AFAICT with a quick look at the code.)
Yes. You are right. We can swith CP off in FM mode.
With my best regards, Dmitry.
>
> Regards,
> Andy
>
> > diff -r 43dbc8ebb5a2 linux/drivers/media/common/tuners/tuner-types.c
> > --- a/linux/drivers/media/common/tuners/tuner-types.c Tue
> > Jan 27 23:47:50 2009 -0200 +++
> > b/linux/drivers/media/common/tuners/tuner-types.c Tue Apr 21
> > 09:44:38 2009 +1000 @@ -557,9 +557,9 @@ /*
> > TUNER_PHILIPS_FM1216ME_MK3 - Philips PAL */
> > static struct tuner_range tuner_fm1216me_mk3_pal_ranges[] = {
> > - { 16 * 158.00 /*MHz*/, 0x8e, 0x01, },
> > - { 16 * 442.00 /*MHz*/, 0x8e, 0x02, },
> > - { 16 * 999.99, 0x8e, 0x04, },
> > + { 16 * 158.00 /*MHz*/, 0xc6, 0x01, },
> > + { 16 * 441.00 /*MHz*/, 0xc6, 0x02, },
> > + { 16 * 864.00, 0xc6, 0x04, },
> > };
> >
> >
> >
> > Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
> >
> >
> > With my best regards, Dmitry.
> > --
> > video4linux-list mailing list
> > Unsubscribe
> > mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/video4linux-list
>
--
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
About using VIDIOC_REQBUFS
Hello Hans, Is it an ordinary way to use twice reqbuf without closing and re-opening between them? I mean like this, 1. Open device 2. VIDIOC_REQBUFS 3. VIDIOC_STREAMON 4. VIDIOC_STREAMOFF 5. VIDIOC_REQBUFS 6. VIDIOC_STREAMON I suppose there should be a strict order for this. That order seems to be wrong but necessary when we do capturing a JPEG data which size (not resolution) is bigger than the preview data size. (Assuming that user is using mmap) Please let me know the right way for that kind of case. Just close and re-open with big enough size for JPEG? or mmap with big enough size in the first place? Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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 2/6] ir-kbd-i2c: Switch to the new-style device binding model
Hi Mike, Sorry for the late answer. On Sat, 18 Apr 2009 08:53:35 -0500 (CDT), Mike Isely wrote: > On Sat, 18 Apr 2009, Jean Delvare wrote: > > On Sat, 18 Apr 2009 11:25:19 +0200, Jean Delvare wrote: > > > Hmm, I thought that our latest discussions had (at least partly) > > > obsoleted your patches. Remember that we want to always instantiate > > > ir_video I2C devices even when ir-kbd-i2c can't driver them, otherwise > > > lirc won't be able to bind to the devices in question as soon as the > > > legacy binding model is gone. So the conditionals in your second patch > > > (which is all that makes it differ from mine) are no longer desirable. > > Jean: > > The differences between my patch(es) and yours are: > > 1. My patch only attempts to bind the driver if the hardware actually > supports it. That's not clear to me. I seem to understand that your patch instantiates the ir_video device if and only if the ir-kbd-i2c driver supports it. This is not what we want to do. We want to create the ir_video device if an IR receiver exists, even if ir-kbd-i2c doesn't support it. The reason is that ir-kbd-i2c could be extended to support the IR receiver in question in the future, and that alternative drivers (lirc_i2c comes to mind) could also be used. I also don't understand why you use i2c_new_probed_device() rather than i2c_new_device() if you already know for sure that the IR receiver device is present? > 2. My patch selects the right I2C address for the case(s) where it makes > sense to bind. This is a good thing, although your implementation isn't exactly what I would expect. The address list should depend on the value of hdw->ir_scheme_active. At the moment you support only 2 schemes and they happen to use the same I2C address, but I presume this will change in the future. > 3. My patch provides a module option to completely disable binding. I agree this can be useful, as discussed earlier, although I still object to the name you chose (disable_autoload_ir_kbd). This module option is only remotely related to the i2c binding model change. > You are probably thinking about (3) but you forgot that I had also taken > care of (1). Difference (1) is why I don't want your patch. If your > patch gets merged I will have to partially redo my patch to make (1) > work again. This is correct. But if your second patch is merged before my own changes, then IR support will be broken for all pvrusb2 users, unless they temporarily load the driver with disable_autoload_ir_kbd=1. But they will have to remove the parameter as soon as my own patches are merged. This approach doesn't strike me as the best user experience. If my patches are merged first and yours go second (which I admit means you'll have to adjust your patches a bit) then everything will keep working for the user. This is the reason why I was proposing this order. > When I had issued my pull request to Mauro (which he didn't pull), there > were actually 2 patches. The first one dealt with (1) and the second > dealt with (2) and (3), while taking advantage of (1). Had Mauro pulled > those patches at that time then you could have made further changes on > top without losing (1). But since he didn't, it's best just to leave > the pvrusb2 driver alone and I'll make the needed additional change(s) > there after your stuff is merged. I can't "leave the pvrusb2 driver alone", unless you consider it acceptable that your users lose IR support between my patches and yours. When ir-kbd-i2c is converted to the new-style i2c binding, all bridge drivers must be updated too. > > > I'll work on lirc patches today or tomorrow, so that lirc doesn't break > > > when my patches hit mainline. > > > > Speaking of this: do you know all the I2C addresses that can host IR > > devices on pvrusb2 cards? I understand that the only address supported > > by ir-kbd-i2c is 0x18, but I also need to know the addresses supported > > by lirc_i2c and possibly lirc_zilog, if you happen to know this. > > Right now I only care about 0x18 (for 29xxx and early 24xxx devices). I've seen this, but this isn't my question. If lirc_i2c supports other IR devices that are present on pvrusb2 devices, we must declare them as well so that we don't break lirc_i2c. So, once again: do you know all the I2C addresses where pvrusb2 cards can have IR devices? > I noticed the thread where Andy got IR reception to work with ir-kbd-i2c > using 0x71 (lirc_zilog type) and I suspect that same set of ir-kbd-i2c > changes will probably work with the pvrusb2 driver for MCE 24xxx and > HVR-1900/HVR-1950 devices. But I figured once Andy's stuff gets into > ir-kbd-i2c I'd simply test for this and if it worked I would make the > appropriate adjustments in the pvrusb2 driver to enable ir-kbd-i2c > binding in those cases as well (an easy change). However even with that > change, there are other pvrusb2-driven devices that cannot support > ir-kbd-i2c. I'm worried that this means doing several c
PID discontinuity problems on TT C-2300
Hi, I tried to get help from the MythTV community to no avail. Maybe it's a hardware/driver/dvb subsystem problem, I have no idea. I see two symptoms, some recordings are generated empty, i.e. Myth thinks it has recorded something, but there is no video file created. Sometimes, recordings just stop in the middle. This is the only case where I get a useful log entry *at all*. But it doesn't say anything more than: 2009-04-22 23:03:07.318 DVBRec(1:0): PID 0x215 discontinuity detected with different PIDs. This message is continuously being logged until the end of the scheduled recordings, sometime interrupted by a single: 2009-04-22 23:03:11.220 AddTSPacket: Out of sync!!! Need to wait for next payloa dStart PID: 0x10, continuity counter: 15 (expected 12). Please help me someone, no component of this system is logging *anything* useful, this used to work one day, and I'm running out of ideas and motivation into frustration. Beside several things I also tried running a recent v4l-dvb hg checkout. No change. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- 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
