[cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Tue Feb 10 08:37:17 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10503:9cb19f080660 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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-rc4-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc4-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc4-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK 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-rc4-i686: WARNINGS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK 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-rc4-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc4-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc4-powerpc64: WARNINGS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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-rc4-x86_64: WARNINGS fw/apps: OK spec: sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc4): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TS sample from freeview, anyone?
Sorry -- I overlooked this earlier... On Fri, 6 Feb 2009, Andrea Venturi wrote: > i'm looking for a full TS sample of a freeview mheg RedButton transmission. How much are you looking for -- in other words, do you need the full service including video that a RedButton service might bring up, or do you just need a sample of, well, Digital Teletext? I'm assuming that you're in Italia (based on your mail headers). Therefore you likely would have problems in receiving television programming via satellite on Astra 2D, although I've had error-free reception with a 60cm dish in Zuerich long before I was aware of the spotbeam. However, the BBC radio services are on a pan-european beam and also (since some months) include a minimal MHEG application that I've been able to receive and view, like the BBCi services on the TV channels -- also available from the BBC (if not ITV too) via satellite/Freesat, and which is likely to be pretty much identical with that received via Freeview... So, unless you've received off-list assistance, this may be a possibility to get something barry bouwsma -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l/tvp514x: try_count reaches 0, not -1
Roel Kluin wrote:
> with while (try_count-- > 0) { ... } try_count reaches 0, not -1.
Sorry but this is bogus, please ignore.
--
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: channels.conf file for danish DVB-C provider AFDK (www.afdk.tv)
On Mon, 9 Feb 2009, Christoph Pfister wrote: > > I sent you the wrong file, it occured to me.. The right one goes here : > Added, thanks :) > > C 38600 6875000 AUTO QAM64 Looking at all the other dvb-c scanfiles, would it not be most likely that the FEC here would be also NONE, like all others, regardless of comparable symbol rate or modulation? I am ignorant about DVB-C practice, and don't have access to the NIT tables of any providers, so I'm happy to be wrong... barry bouwsma -- 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: DAB SFN (was: Re: [linux-dvb] dib0700 "buggy sfn workaround" or equivalent)
Hi Barry, On Tue, 10 Feb 2009, BOUWSMA Barry wrote: Is it in theory possible that this may be the source of some problems I experience receiving DAB radio, using a multi- element directional antenna, regardless of orientation, in a location with reception from at least two and possibly more than four senders within eyesight, or close to that? It's a completely different manufacturer (Siano) and the problem disappears when I simply use a short indoor whip antenna with adequate S/N ratio. I'm not sure how Siano's demodulator is working (not to say, I don't know it at all) for SFNs. Your scenario could also be explained with a too strong signal. When the ADC is saturated the reception is bad. Especially when not using in-can tuners (but silicon ones) you can face the issue easily. But your problem could also be explained by a 100 of different things I don't know. Patrick. -- Mail: patrick.boettc...@desy.de WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ -- 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: Any supported Dual DVB-S cards?
Daniel Pocock wrote: > Steven Ellis wrote: >> Noticed that Pinnacle now do a dual tuner PCI based DVB-S card >> >> http://www.pinnaclesys.com/PublicSite/uk/Products/Consumer+Products/PCTV+Tuners/PCTV+Digital+PVR+(DVB-S_DVB-T)/PCTV+Dual+Sat+Pro+PCI.htm >> >> >> And that development is underway. Has anyone found a dual tuner card >> that works? >> > Is it possible to use multiple USB devices to do the same thing as a > dual tuner card? The problem is I want to house the tuners inside of a media PC case which is harder with USB devices. Also I have spare PCIe slots if there was a dual tuner PCIe unit at a reasonable price. Steve -- 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
Where to find DVB-API v5 (s2api) documentation
Hello list, is there any documentation of the dvb-api v5 (or s2api) available? I've already read the various s2api-threads, but there are still a lot of questions, especially about the delivery-system- and capabilities-stuff. Any starting points for reading about that? Thanks, Carsten -- 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: [linux-dvb] Upcoming DVB-T channel changes for HH (Hamburg)
On Sat, 7 Feb 2009, Christoph Pfister wrote: > Sorry for the late answer, No worries, I've been keeping busy by discovering yet more info. Discovering a site where not only does everyone know more than me and where all the info I could possibly want is there for the taking, but where I feel more unworthy than usual. So, while I still have yet to mangle the machine-generated output, I did observe the following: It seems that the info for Hansestadt Bremen (Radio Bremen) can be merged into that for Niedersachsen, as the presence of an RB multiplex in the latter disturbed me, until I noted that apparently all the (Bundesland) Bremen frequencies are also used in Bremerhaven. So, one less file to maintain. Not only is Hansestadt Hamburg migrating away from the VHF Band III allocation which kicked off this too-long-running thread, but at some yet unspecified time this year (2009), most if not all of the remaining Band III DVB-T transmitters will also relocate. This affects primarily Bayern, but also a few other sites (FFM, Berlin...) I don't know if the frequencies I've read are confirmed, or mere speculation; further, I know no fixed planned dates. But more importantly, I don't know if it's worth it for me to bother to announce known and confirmed changes, or if I should relax and let the official channels publish the info to be massaged into scanfiles. Any residents who might happen to read the info I post are almost certain to have already been made aware of any such changes through other media... My claim that the information for each Bundesland was not likely to change, could be an untruth. I've seen mention of additional frequency changes that were unknown to me, in addition to vacating VHF DVB-T frequencies to make available more DAB/DMB/DVB-T2 multiplexes nationally and regionally. Apparently Bundesland B-W will not only start two more ARD/SWR multiplexes in Bad Mergentheim at a lower power than the other transmitter sites, but will also start a handful of other lower power sort-of-filler sites, apparently not coordinated with ZDF. (May be R-P; my geography is poor). And there should also be some sort of pilot or comparable introduction of a Private MUX in Stuttgart, quite possibly incompatible with existing practice throughout Germany (may be use of MPEG-4 video, or perhaps DVB-T2, or maybe encryption)... > case you need to mark the individual transmitters). Actually I don't > care about the arrangement, as long as there are machine-implementable > rules for the update. Of course, first of all, I need to get off my lazy butt and actually start sorting the info you've compiled into something that will help me get an overview. Say, for Bayern, which, from the Bayerischer Rundfunk perspective, is divided into North (Franken) and South (also with good beer); to which are added a few Privates in scattered areas, partly using the same frequencies, though widely spaced... As a tradeoff, it could possibly be that some Bundesland files could be merged into a super-region -- notably the NDR and mdr regions, though this is pure speculation as I haven't rearranged any files to imbed them in my brain, and is only suggested at by the Bremen/Bremerhaven union. Talk is cheap. > >> They shouldn't be too excessive, > > I meant the number of transmitters, not the size of the file. Ah, fine, fine. As a comparison, I'll offer Helvetia. The last list of DVB-T transmitters in service I bothered to download includes some 25 pages, each with around 20 or so listed sites, for that small land. No way would I consider attempting to list these -- or even those for a particular language region or SFN part thereof, in a scanfile. > > I just updated overnight, and de-Leipzig no longer exists! > > Aieee!@ Good thing I made a backup copy of that directory > > before I updated > > hg has a good memory as well :) At my age, it's hard to unlearn the convenience of such advanced tools as `grep' and `less' on simple foo,v text files (and Attic directories) to trace a file through time. However, you're right -- I do believe that I had problems with `git' on renamed or obsolete files, and subversion appears hopeless for anything but remaining up-to-date offline, though I have enough SOCKS and https problems with that, so that I'm no longer bothered... Like they say, I learn something new every day. Pity that most days it's the same thing I learned on several previous occasions, when not each day the past week... Anyway, let this be a fore-warning that you will be likely to need to update the files for various Laender a few times this year to keep up-to-date -- and that is not to include changes to MUX contents (renaming one ZDF digital channel, or changes in Private Muxen). So I'm off to the Bundesnetzagentur to see if I can get accurate info about upcoming changes and allocations, though I believe this source will be more suitable for planning, than to generate up-to-the-minute scanfiles. barry bouw
Re: TS sample from freeview, anyone?
BOUWSMA Barry wrote: On Fri, 6 Feb 2009, Andrea Venturi wrote: i'm looking for a full TS sample of a freeview mheg RedButton transmission. How much are you looking for -- in other words, do you need the full service including video that a RedButton service might bring up, or do you just need a sample of, well, Digital Teletext? i'd like to have a couple of minute of a full TS from Freeview, to give a quick glance to Red button service. supposed it's a 24Mbps, a couple of minutes should be something like 350MB of dump. I'm assuming that you're in Italia (based on your mail headers). Therefore you likely would have problems in receiving television programming via satellite on Astra 2D, although I've had error-free reception with a 60cm dish in Zuerich long before I was aware of the spotbeam. i know that i could try freesat albeit has a tight footprint, but i just have a fixed dish toward 13 east However, the BBC radio services are on a pan-european beam and also (since some months) include a minimal MHEG application that I've been able to receive and view, like the BBCi services on the TV channels -- also available from the BBC (if not ITV too) via satellite/Freesat, and which is likely to be pretty much identical with that received via Freeview... is there really MHEG over the BBC radio service? do you mean on these BBC "World service" at 13 degree? http://www.lyngsat.com/hotbird.html the transponder TP *50 at freq. 11727V thanx in advance Andrea * So, unless you've received off-list assistance, this may be a possibility to get something barry bouwsma -- 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 v3] v4l/tvp514x: make the module aware of rich people
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> Sent: Thursday, February 05, 2009 11:53 PM
> To: Hiremath, Vaibhav
> Cc: linux-media@vger.kernel.org; mche...@redhat.com; video4linux-
> l...@redhat.com
> Subject: [PATCH v3] v4l/tvp514x: make the module aware of rich
> people
>
> because they might design two of those chips on a single board.
> You never know.
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> Sorry for the delay. While I was preparing v2 I lost the
> tvp514x_slave
> chunk. Now I see a can see a picture error when I plug two codecs
> simultaneity but this could be also a bug in my cam driver.
>
> v3: - addressed review comments
> - move tvp514x_slave into decoder struct it is used per device
> while
> registering / comparing
> v2: Make the content of the registers (brightness, \ldots) per
> decoder
> and not global.
> v1: Initial version
>
> drivers/media/video/tvp514x.c | 104 +++---
> ---
> 1 files changed, 58 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/media/video/tvp514x.c
> b/drivers/media/video/tvp514x.c
> index 8e23aa5..2167284 100644
> --- a/drivers/media/video/tvp514x.c
> +++ b/drivers/media/video/tvp514x.c
> @@ -86,9 +86,12 @@ struct tvp514x_std_info {
> struct v4l2_standard standard;
> };
>
> +static struct tvp514x_reg tvp514x_reg_list_default[0x40];
> /**
> - * struct tvp514x_decoded - TVP5146/47 decoder object
> + * struct tvp514x_decoder - TVP5146/47 decoder object
> * @v4l2_int_device: Slave handle
> + * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
> + * @tvp514x_regs: copy of hw's regs with preset values.
> * @pdata: Board specific
> * @client: I2C client data
> * @id: Entry from I2C table
> @@ -103,7 +106,9 @@ struct tvp514x_std_info {
> * @route: input and output routing at chip level
> */
> struct tvp514x_decoder {
> - struct v4l2_int_device *v4l2_int_device;
> + struct v4l2_int_device v4l2_int_device;
> + struct v4l2_int_slave tvp514x_slave;
> + struct tvp514x_reg
> tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
> const struct tvp514x_platform_data *pdata;
> struct i2c_client *client;
>
> @@ -124,7 +129,7 @@ struct tvp514x_decoder {
> };
>
> /* TVP514x default register values */
> -static struct tvp514x_reg tvp514x_reg_list[] = {
> +static struct tvp514x_reg tvp514x_reg_list_default[] = {
> {TOK_WRITE, REG_INPUT_SEL, 0x05}, /* Composite selected */
> {TOK_WRITE, REG_AFE_GAIN_CTRL, 0x0F},
> {TOK_WRITE, REG_VIDEO_STD, 0x00}, /* Auto mode */
> @@ -422,7 +427,7 @@ static int tvp514x_configure(struct
> tvp514x_decoder *decoder)
>
> /* common register initialization */
> err =
> - tvp514x_write_regs(decoder->client, tvp514x_reg_list);
> + tvp514x_write_regs(decoder->client, decoder-
> >tvp514x_regs);
> if (err)
> return err;
>
> @@ -580,7 +585,7 @@ static int ioctl_s_std(struct v4l2_int_device
> *s, v4l2_std_id *std_id)
> return err;
>
> decoder->current_std = i;
> - tvp514x_reg_list[REG_VIDEO_STD].val = decoder-
> >std_list[i].video_std;
> + decoder->tvp514x_regs[REG_VIDEO_STD].val = decoder-
> >std_list[i].video_std;
[Hiremath, Vaibhav] I am getting an checkpatch warning here, the line is
exceeding 80 columns. Since this is not some complex line which will be having
problems in readability, I would prefer to fix this.
>
> v4l_dbg(1, debug, decoder->client, "Standard set to: %s",
> decoder->std_list[i].standard.name);
> @@ -625,8 +630,8 @@ static int ioctl_s_routing(struct
> v4l2_int_device *s,
> if (err)
> return err;
>
> - tvp514x_reg_list[REG_INPUT_SEL].val = input_sel;
> - tvp514x_reg_list[REG_OUTPUT_FORMATTER1].val = output_sel;
> + decoder->tvp514x_regs[REG_INPUT_SEL].val = input_sel;
> + decoder->tvp514x_regs[REG_OUTPUT_FORMATTER1].val = output_sel;
>
> /* Clear status */
> msleep(LOCK_RETRY_DELAY);
> @@ -779,16 +784,16 @@ ioctl_g_ctrl(struct v4l2_int_device *s, struct
> v4l2_control *ctrl)
>
> switch (ctrl->id) {
> case V4L2_CID_BRIGHTNESS:
> - ctrl->value = tvp514x_reg_list[REG_BRIGHTNESS].val;
> + ctrl->value = decoder->tvp514x_regs[REG_BRIGHTNESS].val;
> break;
> case V4L2_CID_CONTRAST:
> - ctrl->value = tvp514x_reg_list[REG_CONTRAST].val;
> + ctrl->value = decoder->tvp514x_regs[REG_CONTRAST].val;
> break;
> case V4L2_CID_SATURATION:
> - ctrl->value = tvp514x_reg_list[REG_SATURATION].val;
> + ctrl->value = decoder->tvp514x_regs[REG_SATURATION].val;
> break;
> case V4L2_CID_HUE:
> - ctrl->value = tvp514x_reg_list[REG_HUE].val;
> + ctrl->value = decoder->tvp514x_regs[REG_HUE].val;
>
Re: cx8802.ko module not being built with current HG tree
On Thu, 5 Feb 2009 16:59:16 +0100 Eduard Huguet wrote: > Hi, > Maybe I'm wrong, but I think there is something wrong in current > Kconfig file for cx88 drivers. I've been struggling for some hours > trying to find why, after compiling a fresh copy of the LinuxTV HG > drivers, I wasn't unable to modprobe cx88-dvb module, which I need for > HVR-3000. > > The module was not being load because kernel was failing to find > cx8802_get_driver, etc... entry points, which are exported by > cx88-mpeg.c. > > The strange part is that, according to the cx88/Kconfig file this file > should be automatically added as dependency if either CX88_DVB or > CX88_BLACKBIRD were selected, > but for some strange reason it wasn't. > > After a 'make menuconfig' in HG tree the kernel configuration > contained these lines (this was using the default config, without > adding / removing anything): > CONFIG_VIDEO_CX88=m > CONFIG_VIDEO_CX88_ALSA=m > CONFIG_VIDEO_CX88_BLACKBIRD=m > CONFIG_VIDEO_CX88_DVB=m > CONFIG_VIDEO_CX88_MPEG=y > CONFIG_VIDEO_CX88_VP3054=m > > Notice that they are all marked as 'm' excepting > CONFIG_VIDEO_CX88_MPEG, which is marked as 'y'. I don't know if it's > relevant or not, but the fact is that the module was not being > compiled at all. The option was not visible inside menuconfig, by the > way. > > I've done some changes inside Kconfig to make it visible in > menuconfig, and by doing this I've been able to set it to 'm' and > rebuild, which has just worked apparently. > > This Kconfig file was edited in revisions 10190 & 10191, precisely for > reasons related to cx8802 dependencies, so I'm not sure the solution > taken there was the right one. > > Best regards, > Eduard Huguet Eduard, I suspect that this is some bug on the out-of-tree build. In order to test it, I've tried to reproduce what I think you did. So, I ran the following procedures over the devel branch on my -git tree: make allmodconfig (to select everything as 'm') I manually unselect all drivers at the tree, keeping only CX88 and submodules. All CX88 submodules as "M". I've repeated the procedure, this time starting with make allyesconfig. On both cases, I got those configs: CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m My -git tree were updated up to this changeset: commit 67e70baf043cfdcdaf5972bc94be82632071536b Author: Devin Heitmueller Date: Mon Jan 26 03:07:59 2009 -0300 V4L/DVB (10411): s5h1409: Perform s5h1409 soft reset after tuning I tried also reproduce the bug you've mentioned at the v4l-dvb tree, but unfortunately, I couldn't (the .config file is attached). I got exactly the same result as compiling in-kernel. Could you please send us your buggy .config? Cheers, Mauro v4l_config Description: Binary data
Re: channels.conf file for danish DVB-C provider AFDK (www.afdk.tv)
2009/2/10 BOUWSMA Barry : > On Mon, 9 Feb 2009, Christoph Pfister wrote: > >> > I sent you the wrong file, it occured to me.. The right one goes here : >> Added, thanks :) > >> > C 38600 6875000 AUTO QAM64 > > Looking at all the other dvb-c scanfiles, would it not be most > likely that the FEC here would be also NONE, like all others, > regardless of comparable symbol rate or modulation? Yes; I've fixed this while committing. > I am ignorant about DVB-C practice, and don't have access to > the NIT tables of any providers, so I'm happy to be wrong... EN300429 says that no convolutional coding (= inner fec) shall be used for dvb-c, so you aren't wrong :) > barry bouwsma Christoph -- 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: cx8802.ko module not being built with current HG tree
Hi, I don't have yet the buggy config, but the steps I was following when I encounter the problem were the following: · hg clone http://linuxtv.org/hg/v4l-dvb · cd v4l-dvb · make menuconfig (I mostly uncheck here most of the modules, as I really was needing only to compile the support for Nova-T 500 and an HVR-3000. I just leave "as is" (checked as M by default) all the SAA7134 and derived options). · make && make install Best regards, Eduard PS: I suspect that "make allmodconfig" (which I didn't even know it existed...) makes a difference here, because it will mark CX88_MPEG as 'M', if I understand it well. I wasn't using it, so maybe this explains why the option was hiddenly marked as 'Y' instead of 'M'. 2009/2/10 Mauro Carvalho Chehab : > On Thu, 5 Feb 2009 16:59:16 +0100 > Eduard Huguet wrote: > >> Hi, >> Maybe I'm wrong, but I think there is something wrong in current >> Kconfig file for cx88 drivers. I've been struggling for some hours >> trying to find why, after compiling a fresh copy of the LinuxTV HG >> drivers, I wasn't unable to modprobe cx88-dvb module, which I need for >> HVR-3000. >> >> The module was not being load because kernel was failing to find >> cx8802_get_driver, etc... entry points, which are exported by >> cx88-mpeg.c. >> >> The strange part is that, according to the cx88/Kconfig file this file >> should be automatically added as dependency if either CX88_DVB or >> CX88_BLACKBIRD were selected, >> but for some strange reason it wasn't. >> >> After a 'make menuconfig' in HG tree the kernel configuration >> contained these lines (this was using the default config, without >> adding / removing anything): >> CONFIG_VIDEO_CX88=m >> CONFIG_VIDEO_CX88_ALSA=m >> CONFIG_VIDEO_CX88_BLACKBIRD=m >> CONFIG_VIDEO_CX88_DVB=m >> CONFIG_VIDEO_CX88_MPEG=y >> CONFIG_VIDEO_CX88_VP3054=m >> >> Notice that they are all marked as 'm' excepting >> CONFIG_VIDEO_CX88_MPEG, which is marked as 'y'. I don't know if it's >> relevant or not, but the fact is that the module was not being >> compiled at all. The option was not visible inside menuconfig, by the >> way. >> >> I've done some changes inside Kconfig to make it visible in >> menuconfig, and by doing this I've been able to set it to 'm' and >> rebuild, which has just worked apparently. >> >> This Kconfig file was edited in revisions 10190 & 10191, precisely for >> reasons related to cx8802 dependencies, so I'm not sure the solution >> taken there was the right one. >> >> Best regards, >> Eduard Huguet > > Eduard, > > I suspect that this is some bug on the out-of-tree build. In order to test it, > I've tried to reproduce what I think you did. > > So, I ran the following procedures over the devel branch on my -git tree: > > make allmodconfig (to select everything as 'm') > I manually unselect all drivers at the tree, keeping only CX88 and submodules. > All CX88 submodules as "M". > > I've repeated the procedure, this time starting with make allyesconfig. > > On both cases, I got those configs: > > CONFIG_VIDEO_CX88=m > CONFIG_VIDEO_CX88_ALSA=m > CONFIG_VIDEO_CX88_BLACKBIRD=m > CONFIG_VIDEO_CX88_DVB=m > CONFIG_VIDEO_CX88_MPEG=m > CONFIG_VIDEO_CX88_VP3054=m > > My -git tree were updated up to this changeset: > > commit 67e70baf043cfdcdaf5972bc94be82632071536b > Author: Devin Heitmueller > Date: Mon Jan 26 03:07:59 2009 -0300 > >V4L/DVB (10411): s5h1409: Perform s5h1409 soft reset after tuning > > > I tried also reproduce the bug you've mentioned at the v4l-dvb tree, but > unfortunately, I couldn't (the .config file is attached). I got exactly the > same result as compiling in-kernel. > > Could you please send us your buggy .config? > > 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: cx8802.ko module not being built with current HG tree
Hi, Just tried it right now, with these simple steps: · hg clone http://linuxtv.org/hg/v4l-dvb · cd v4l-dvb · make menuconfig & exit from it without touching anything I attach the resulting v4l/.config file generated. As you can see, CX88_MPEG is being marked as 'Y' instead that 'M': $ grep CX88 v4l/.config CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=y CONFIG_VIDEO_CX88_VP3054=m I'm compiling against Ubuntu kernel 2.6.22, which I know it's pretty old. Can this make any difference? Best regards, Eduard PS: by the way, this works fine when using revision 10189, just before CX88 dependencies got altered. 2009/2/10 Mauro Carvalho Chehab : > On Thu, 5 Feb 2009 16:59:16 +0100 > Eduard Huguet wrote: > >> Hi, >> Maybe I'm wrong, but I think there is something wrong in current >> Kconfig file for cx88 drivers. I've been struggling for some hours >> trying to find why, after compiling a fresh copy of the LinuxTV HG >> drivers, I wasn't unable to modprobe cx88-dvb module, which I need for >> HVR-3000. >> >> The module was not being load because kernel was failing to find >> cx8802_get_driver, etc... entry points, which are exported by >> cx88-mpeg.c. >> >> The strange part is that, according to the cx88/Kconfig file this file >> should be automatically added as dependency if either CX88_DVB or >> CX88_BLACKBIRD were selected, >> but for some strange reason it wasn't. >> >> After a 'make menuconfig' in HG tree the kernel configuration >> contained these lines (this was using the default config, without >> adding / removing anything): >> CONFIG_VIDEO_CX88=m >> CONFIG_VIDEO_CX88_ALSA=m >> CONFIG_VIDEO_CX88_BLACKBIRD=m >> CONFIG_VIDEO_CX88_DVB=m >> CONFIG_VIDEO_CX88_MPEG=y >> CONFIG_VIDEO_CX88_VP3054=m >> >> Notice that they are all marked as 'm' excepting >> CONFIG_VIDEO_CX88_MPEG, which is marked as 'y'. I don't know if it's >> relevant or not, but the fact is that the module was not being >> compiled at all. The option was not visible inside menuconfig, by the >> way. >> >> I've done some changes inside Kconfig to make it visible in >> menuconfig, and by doing this I've been able to set it to 'm' and >> rebuild, which has just worked apparently. >> >> This Kconfig file was edited in revisions 10190 & 10191, precisely for >> reasons related to cx8802 dependencies, so I'm not sure the solution >> taken there was the right one. >> >> Best regards, >> Eduard Huguet > > Eduard, > > I suspect that this is some bug on the out-of-tree build. In order to test it, > I've tried to reproduce what I think you did. > > So, I ran the following procedures over the devel branch on my -git tree: > > make allmodconfig (to select everything as 'm') > I manually unselect all drivers at the tree, keeping only CX88 and submodules. > All CX88 submodules as "M". > > I've repeated the procedure, this time starting with make allyesconfig. > > On both cases, I got those configs: > > CONFIG_VIDEO_CX88=m > CONFIG_VIDEO_CX88_ALSA=m > CONFIG_VIDEO_CX88_BLACKBIRD=m > CONFIG_VIDEO_CX88_DVB=m > CONFIG_VIDEO_CX88_MPEG=m > CONFIG_VIDEO_CX88_VP3054=m > > My -git tree were updated up to this changeset: > > commit 67e70baf043cfdcdaf5972bc94be82632071536b > Author: Devin Heitmueller > Date: Mon Jan 26 03:07:59 2009 -0300 > >V4L/DVB (10411): s5h1409: Perform s5h1409 soft reset after tuning > > > I tried also reproduce the bug you've mentioned at the v4l-dvb tree, but > unfortunately, I couldn't (the .config file is attached). I got exactly the > same result as compiling in-kernel. > > Could you please send us your buggy .config? > > Cheers, > Mauro > .config Description: Binary data
Re: KWorld ATSC 115 all static
On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 04:43:15 +0100 > hermann pitton wrote: > >> >> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton: >> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab: >> > > On Tue, 10 Feb 2009 02:31:00 +0100 >> > > hermann pitton wrote: >> >> > > > > >> > > > > BTW, just to remember. >> > > > > >> > > > > Tvtime with signal detection on shows a blue screen without signal. >> > > > > With signal detection off, just good old snow. >> > > >> > > So, the tda9887 or the PLL are configured wrongly. >> > > >> >> Urgh, not to add more confusion here at least. >> >> Good old snow means the analog signal is perfect. >> >> I stopped since long to connect a real signal to it surfing the grounds >> on my stomach, but it is for sure working then and the pll is always >> fine. > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to confirm > that everything is fine on their side. This patch may also fix other similar > troubles on a few devices that seem to need some i2c magic before probing the > tuner. Just tried the latest hg and I can confirm that both an ATSC 110 and 115 work with tvtime and ATSC. Later Jonathan > 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
[cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Tue Feb 10 11:46:10 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10503:9cb19f080660 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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-rc4-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc4-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc4-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK 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-rc4-i686: WARNINGS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK 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-rc4-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc4-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc4-powerpc64: WARNINGS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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-rc4-x86_64: WARNINGS fw/apps: OK spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc4): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 12:57:47 +0100 Eduard Huguet wrote: > Hi, > Just tried it right now, with these simple steps: > > · hg clone http://linuxtv.org/hg/v4l-dvb > · cd v4l-dvb > · make menuconfig & exit from it without touching anything > > I attach the resulting v4l/.config file generated. As you can see, > CX88_MPEG is being marked as 'Y' instead that 'M': > > $ grep CX88 v4l/.config > CONFIG_VIDEO_CX88=m > CONFIG_VIDEO_CX88_ALSA=m > CONFIG_VIDEO_CX88_BLACKBIRD=m > CONFIG_VIDEO_CX88_DVB=m > CONFIG_VIDEO_CX88_MPEG=y > CONFIG_VIDEO_CX88_VP3054=m Weird. I 've applied your changeset and copied it at v4l/.config. Then, a make menuconfig and exit, just to be sure that kernel build would touch on it. Everything worked fine. > I'm compiling against Ubuntu kernel 2.6.22, which I know it's pretty > old. Can this make any difference? I'm using here kernel 2.6.28.2. Maybe this is some bug on the Ubuntu's kernel kbuild, since make *config options at the out-of-tree kernel is a wrapper to the kernel kbuild. Could you please try the same procedure with a newer kernel? There's no need to install the kernel on your machine. All you need to do is something like: wget tar -xvfoj cd linux make init cd ~/v4l-dvb make release DIR= make menuconfig The "make release" will allow you to use the Kbuild of the newer kernel. > > Best regards, > Eduard > > PS: by the way, this works fine when using revision 10189, just > before CX88 dependencies got altered. The problem is that the old Kconfig were causing breakages upstream. 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 1/2] Pad configuration for OMAP3EVM Multi-Media Daughter Card Support
Thanks,
Vaibhav Hiremath
> -Original Message-
> From: Hiremath, Vaibhav
> Sent: Friday, January 30, 2009 12:52 AM
> To: linux-o...@vger.kernel.org
> Cc: linux-media@vger.kernel.org; Hiremath, Vaibhav; Jadav, Brijesh
> R; Shah, Hardik
> Subject: [PATCH 1/2] Pad configuration for OMAP3EVM Multi-Media
> Daughter Card Support
>
> From: Vaibhav Hiremath
>
> On OMAP3EVM Mass Market Daugher Card following GPIO pins are being
> used -
>
> GPIO134 --> Enable/Disable TVP5146 interface
> GPIO54 --> Enable/Disable Expansion Camera interface
> GPIO136 --> Enable/Disable Camera (Sensor) interface
>
> Added entry for the above GPIO's in mux.c and mux.h file
>
> Signed-off-by: Brijesh Jadav
> Signed-off-by: Hardik Shah
> Signed-off-by: Vaibhav Hiremath
> ---
> arch/arm/mach-omap2/mux.c |6 ++
> arch/arm/plat-omap/include/mach/mux.h |5 -
> 2 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 1556688..d226d81 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -471,6 +471,12 @@ MUX_CFG_34XX("AF5_34XX_GPIO142", 0x170,
> OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
> MUX_CFG_34XX("AE5_34XX_GPIO143", 0x172,
> OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
> +MUX_CFG_34XX("AG4_34XX_GPIO134", 0x160,
> + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
> +MUX_CFG_34XX("U8_34XX_GPIO54", 0x0b4,
> + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
> +MUX_CFG_34XX("AE4_34XX_GPIO136", 0x164,
> + OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
>
> };
>
> diff --git a/arch/arm/plat-omap/include/mach/mux.h b/arch/arm/plat-
> omap/include/mach/mux.h
> index 67fddec..ace037f 100644
> --- a/arch/arm/plat-omap/include/mach/mux.h
> +++ b/arch/arm/plat-omap/include/mach/mux.h
> @@ -795,7 +795,10 @@ enum omap34xx_index {
> AF6_34XX_GPIO140_UP,
> AE6_34XX_GPIO141,
> AF5_34XX_GPIO142,
> - AE5_34XX_GPIO143
> + AE5_34XX_GPIO143,
> + AG4_34XX_GPIO134,
> + U8_34XX_GPIO54,
> + AE4_34XX_GPIO136,
> };
>
[Hiremath, Vaibhav] If there are no review comments on this then probably this
patch should go through, since this is independent and being used with
Multi-Media Daughter card support.
> struct omap_mux_cfg {
> --
> 1.5.6
--
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: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card Support
Thanks, Vaibhav Hiremath > -Original Message- > From: Alexey Klimov [mailto:klimov.li...@gmail.com] > Sent: Saturday, January 31, 2009 9:59 PM > To: Hiremath, Vaibhav > Cc: linux-o...@vger.kernel.org; linux-media@vger.kernel.org; Jadav, > Brijesh R; Shah, Hardik > Subject: Re: [REVIEW PATCH 2/2] OMAP3EVM Multi-Media Daughter Card > Support > > Hello, Vaibhav > May i tell few suggestions ? > > On Fri, 2009-01-30 at 00:52 +0530, hvaib...@ti.com wrote: > > From: Vaibhav Hiremath > > > > This is second version of OMAP3EVM Mulit-Media/Mass Market > > Daughter Card support. > > > > Fixes: > > - Cleaned unused header files, struct formating, and unused > > comments. > > - Pad/mux configuration handled in mux.ch > > - mux.ch related changes moved to seperate patch > > - Renamed file board-omap3evm-dc.c to board-omap3evm-dc-v4l.c > > to make more explicit. > > - Added some more meaningful name for Kconfig option > > > > TODO: > > - Camera sensor support (for future development). > > - Driver header file inclusion (dependency on ISP-Camera > patches) > > I am working with Sergio to seperate/move header file to > standard > > location. > > - Still need to fix naming convention for DC > > > > Tested: > > - TVP5146 (BT656) decoder interface on top of > > Sergio's ISP-Camera patches. > > - Loopback application, capturing image through TVP5146 > > and saving it to file per frame. > > - Basic functionality of HSUSB Transceiver USB-83320 > > > > Signed-off-by: Brijesh Jadav > > Signed-off-by: Hardik Shah > > Signed-off-by: Vaibhav Hiremath > > --- > > arch/arm/mach-omap2/Kconfig |8 +- > > arch/arm/mach-omap2/Makefile|1 + > > arch/arm/mach-omap2/board-omap3evm-dc-v4l.c | 348 > +++ > > arch/arm/mach-omap2/board-omap3evm-dc.h | 42 > > 4 files changed, 398 insertions(+), 1 deletions(-) > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc-v4l.c > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-dc.h > > [Hiremath, Vaibhav] This patch is strongly dependent on ISP-Camera patches, and need rebase/refreshment/synchronization with latest code-base from Sergio and Sakari. I believe they are under process of fixing review comments. Since there are only minor review comments received for MMDC patch, I will wait till the time Sergio posts the patches supporting ISP-Camera module. And then I will submit it to the community after refreshing on top of it (with review comment fix). -- 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: KWorld ATSC 115 all static
On Tue, 10 Feb 2009 06:07:51 -0600 Jonathan Isom wrote: > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab > wrote: > > On Tue, 10 Feb 2009 04:43:15 +0100 > > hermann pitton wrote: > > > >> > >> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton: > >> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab: > >> > > On Tue, 10 Feb 2009 02:31:00 +0100 > >> > > hermann pitton wrote: > >> > >> > > > > > >> > > > > BTW, just to remember. > >> > > > > > >> > > > > Tvtime with signal detection on shows a blue screen without signal. > >> > > > > With signal detection off, just good old snow. > >> > > > >> > > So, the tda9887 or the PLL are configured wrongly. > >> > > > >> > >> Urgh, not to add more confusion here at least. > >> > >> Good old snow means the analog signal is perfect. > >> > >> I stopped since long to connect a real signal to it surfing the grounds > >> on my stomach, but it is for sure working then and the pll is always > >> fine. > > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to > > confirm > > that everything is fine on their side. This patch may also fix other similar > > troubles on a few devices that seem to need some i2c magic before probing > > the > > tuner. > > Just tried the latest hg and I can confirm that both an ATSC 110 and > 115 work with tvtime > and ATSC. > Jonathan, You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree (http://linuxtv.org/hg/~mchehab/saa7134)? In the first case, could you please confirm that it works fine also with the saa7134 tree? > Later > > Jonathan > > > 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 > > 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: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 10:09:55 -0200 Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 12:57:47 +0100 > Eduard Huguet wrote: > > > Hi, > > Just tried it right now, with these simple steps: > > > > · hg clone http://linuxtv.org/hg/v4l-dvb > > · cd v4l-dvb > > · make menuconfig & exit from it without touching anything > > > > I attach the resulting v4l/.config file generated. As you can see, > > CX88_MPEG is being marked as 'Y' instead that 'M': > > > > $ grep CX88 v4l/.config > > CONFIG_VIDEO_CX88=m > > CONFIG_VIDEO_CX88_ALSA=m > > CONFIG_VIDEO_CX88_BLACKBIRD=m > > CONFIG_VIDEO_CX88_DVB=m > > CONFIG_VIDEO_CX88_MPEG=y > > CONFIG_VIDEO_CX88_VP3054=m > > Weird. I 've applied your changeset and copied it at v4l/.config. Then, a make > menuconfig and exit, just to be sure that kernel build would touch on it. > Everything worked fine. > > > I'm compiling against Ubuntu kernel 2.6.22, which I know it's pretty > > old. Can this make any difference? > > I'm using here kernel 2.6.28.2. Maybe this is some bug on the Ubuntu's kernel > kbuild, since make *config options at the out-of-tree kernel is a wrapper to > the kernel kbuild. > > Could you please try the same procedure with a newer kernel? There's no need > to > install the kernel on your machine. All you need to do is something like: > > wget > tar -xvfoj > cd linux Hmm.. you'll need to provide some .config to the downloaded kernel. You may do it my running "make allyesconfig" or "make allmodconfig". Another approach would be to run "make oldconfig", but, in the latter case, you would need to answer to several questions (it is probably ok to just press enter to all questions). > make init > > cd ~/v4l-dvb > make release DIR= > make menuconfig > > The "make release" will allow you to use the Kbuild of the newer kernel. > > > > > Best regards, > > Eduard > > > > PS: by the way, this works fine when using revision 10189, just > > before CX88 dependencies got altered. > > The problem is that the old Kconfig were causing breakages upstream. > > Cheers, > Mauro 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: cx8802.ko module not being built with current HG tree
I'll give it a try, thanks. Regards, Eduard 2009/2/10 Mauro Carvalho Chehab : > On Tue, 10 Feb 2009 12:57:47 +0100 > Eduard Huguet wrote: > >> Hi, >> Just tried it right now, with these simple steps: >> >> · hg clone http://linuxtv.org/hg/v4l-dvb >> · cd v4l-dvb >> · make menuconfig & exit from it without touching anything >> >> I attach the resulting v4l/.config file generated. As you can see, >> CX88_MPEG is being marked as 'Y' instead that 'M': >> >> $ grep CX88 v4l/.config >> CONFIG_VIDEO_CX88=m >> CONFIG_VIDEO_CX88_ALSA=m >> CONFIG_VIDEO_CX88_BLACKBIRD=m >> CONFIG_VIDEO_CX88_DVB=m >> CONFIG_VIDEO_CX88_MPEG=y >> CONFIG_VIDEO_CX88_VP3054=m > > Weird. I 've applied your changeset and copied it at v4l/.config. Then, a make > menuconfig and exit, just to be sure that kernel build would touch on it. > Everything worked fine. > >> I'm compiling against Ubuntu kernel 2.6.22, which I know it's pretty >> old. Can this make any difference? > > I'm using here kernel 2.6.28.2. Maybe this is some bug on the Ubuntu's kernel > kbuild, since make *config options at the out-of-tree kernel is a wrapper to > the kernel kbuild. > > Could you please try the same procedure with a newer kernel? There's no need > to > install the kernel on your machine. All you need to do is something like: > > wget > tar -xvfoj > cd linux > make init > > cd ~/v4l-dvb > make release DIR= > make menuconfig > > The "make release" will allow you to use the Kbuild of the newer kernel. > >> >> Best regards, >> Eduard >> >> PS: by the way, this works fine when using revision 10189, just >> before CX88 dependencies got altered. > > The problem is that the old Kconfig were causing breakages upstream. > > 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: KWorld ATSC 115 all static
On Tue, Feb 10, 2009 at 6:27 AM, Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 06:07:51 -0600 > Jonathan Isom wrote: > >> On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab >> wrote: >> > On Tue, 10 Feb 2009 04:43:15 +0100 >> > hermann pitton wrote: >> > >> >> >> >> Am Dienstag, den 10.02.2009, 04:14 +0100 schrieb hermann pitton: >> >> > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab: >> >> > > On Tue, 10 Feb 2009 02:31:00 +0100 >> >> > > hermann pitton wrote: >> >> >> >> > > > > >> >> > > > > BTW, just to remember. >> >> > > > > >> >> > > > > Tvtime with signal detection on shows a blue screen without >> >> > > > > signal. >> >> > > > > With signal detection off, just good old snow. >> >> > > >> >> > > So, the tda9887 or the PLL are configured wrongly. >> >> > > >> >> >> >> Urgh, not to add more confusion here at least. >> >> >> >> Good old snow means the analog signal is perfect. >> >> >> >> I stopped since long to connect a real signal to it surfing the grounds >> >> on my stomach, but it is for sure working then and the pll is always >> >> fine. >> > >> > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to >> > confirm >> > that everything is fine on their side. This patch may also fix other >> > similar >> > troubles on a few devices that seem to need some i2c magic before probing >> > the >> > tuner. >> >> Just tried the latest hg and I can confirm that both an ATSC 110 and >> 115 work with tvtime >> and ATSC. >> > Jonathan, > > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree > (http://linuxtv.org/hg/~mchehab/saa7134)? > > In the first case, could you please confirm that it works fine also with the > saa7134 tree? Hi I can confirm they work with both trees. Later Jonathan >> Later >> >> Jonathan >> >> > 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 >> > > > > > > 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: [cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
Hi all, Note that the spec is now automatically generated as well by the daily build. A link is at the bottom of the report: http://www.xs4all.nl/~hverkuil/spec/v4l2.html Regards, Hans > (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:Tue Feb 10 11:46:10 CET 2009 > path:http://www.linuxtv.org/hg/v4l-dvb > changeset: 10503:9cb19f080660 > gcc version: gcc (GCC) 4.3.1 > hardware:x86_64 > host os: 2.6.26 > > linux-2.6.16.61-armv5: OK > linux-2.6.17.14-armv5: OK > linux-2.6.18.8-armv5: OK > linux-2.6.19.5-armv5: OK > linux-2.6.20.21-armv5: OK > linux-2.6.21.7-armv5: OK > 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-rc4-armv5: OK > linux-2.6.27-armv5-ixp: OK > linux-2.6.28-armv5-ixp: OK > linux-2.6.29-rc4-armv5-ixp: OK > linux-2.6.27-armv5-omap2: OK > linux-2.6.28-armv5-omap2: OK > linux-2.6.29-rc4-armv5-omap2: OK > linux-2.6.16.61-i686: OK > linux-2.6.17.14-i686: OK > linux-2.6.18.8-i686: OK > linux-2.6.19.5-i686: OK > linux-2.6.20.21-i686: OK > linux-2.6.21.7-i686: OK > linux-2.6.22.19-i686: OK > linux-2.6.23.12-i686: OK > 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-rc4-i686: WARNINGS > linux-2.6.16.61-m32r: OK > linux-2.6.17.14-m32r: OK > linux-2.6.18.8-m32r: OK > linux-2.6.19.5-m32r: OK > linux-2.6.20.21-m32r: OK > linux-2.6.21.7-m32r: OK > 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-rc4-m32r: OK > linux-2.6.16.61-mips: OK > linux-2.6.26-mips: OK > linux-2.6.27-mips: OK > linux-2.6.28-mips: OK > linux-2.6.29-rc4-mips: WARNINGS > linux-2.6.27-powerpc64: OK > linux-2.6.28-powerpc64: OK > linux-2.6.29-rc4-powerpc64: WARNINGS > linux-2.6.16.61-x86_64: OK > linux-2.6.17.14-x86_64: OK > linux-2.6.18.8-x86_64: OK > linux-2.6.19.5-x86_64: OK > linux-2.6.20.21-x86_64: OK > linux-2.6.21.7-x86_64: OK > linux-2.6.22.19-x86_64: OK > linux-2.6.23.12-x86_64: OK > 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-rc4-x86_64: WARNINGS > fw/apps: OK > spec: OK > sparse (linux-2.6.28): ERRORS > sparse (linux-2.6.29-rc4): ERRORS > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Tuesday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 > > The V4L2 specification from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/v4l2.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 > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] use the new request_module_nowait() in drivers/media
On Tuesday 10 February 2009 03:04:56 Mauro Carvalho Chehab wrote: > On Sun, 8 Feb 2009 11:00:52 -0800 > Arjan van de Ven wrote: > > From: Arjan van de Ven > > Subject: [PATCH] use the new request_module_nowait() in drivers/media ... > Acked-by: Mauro Carvalho Chehab > > Cheers, > Mauro Thanks Mauro. Since I have the prereq, I've taken this into my tree too. Thanks, Rusty. -- 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: [linux-dvb] mt352 no more working after suspend to disk
On Tuesday 10 February 2009 13:39:09 Alex Betis wrote: > I've tried to configure my system for suspends and here are my > conclusions, maybe it will be helpful: > > Make sure no applications are using drivers that generally make > problems after suspend, that means you have to stop/kill them > before suspending. I use pm-utils script to stop application before > suspend and start applications after that. > Make sure you reload the drivers after resume. pm-utils has a > feature to unload modules before suspend and reload them after > resume automatically, check the SUSPEND_MODULES configuration. That > method works fine for my DVB-S drivers, but don't work for my WiFi > card, so I had to reload the driver after resume in my script. > > Hope it helps. > it's very useful, thanks a lot -- 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: [linux-dvb] mt352 no more working after suspend to disk
On Tuesday 10 February 2009 13:39:09 Alex Betis wrote: > On Tue, Feb 10, 2009 at 12:16 AM, hermann pitton wrote: > > Hi Nico, > > > > Am Montag, den 09.02.2009, 12:33 +0100 schrieb Nico Sabbi: > > > Hi, > > > if I suspend to disk and next resume I have to manually remove > > > and reload my mt352 driver, otherwise it complains of a lot of > > > i2c errors. > > > > > > My kernel is suse's 2.6.27. > > > > > > Is this problem fixed in recent kernels or in hg? > > > > > > Thanks, > > > Nico > > > > don't know on what driver you report it, but since I know you > > also have saa7134 driver devices, nobody claimed so far that dvb > > is suspend/resume safe. > > > > I recently reported that people have to stay aware after resume, > > that even without using any dvb app actually during suspend, > > analog needs to be re-initialized first after that to get the > > tda10046 in a proper state for DVB-T again, at least on hybrid > > devices. Unshared DVB-S tuners and demods do stand this already. > > (medion 8800quad, CTX948, Asus 3in1) > > > > You can suspend to RAM on analog for example with a running > > tvtime and resume, but dma sound on saa7134-alsa is also not > > handled yet. Analog sound works. > > > > That is the status as far I have it. > > Hi Hermann, the only card that gave me problems so was is my Airstar2 PCI card, while my Lifeview Trio worked perfectly after resume -- 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
Clarification for V4L2_FIELD_SEQ_TB in planar modes
Hi, I'm writing a driver for a device that appears to support only planar video modes. For video out I would like to use the auto-repeat functionality of its DMA engine. In interlaced modes this requires a plane of the second field to directly follow the corresponding plane of the first field in memory. I could not find any driver supporting SEQ_TB/SEQ_BT in planar modes, so my question is: Does V4L2_FIELD_SEQ_TB in planar YCbCr modes correspond to Y1 Y2 Cb1 Cb2 Cr1 Cr2 or Y1 Cb1 Cr1 Y2 Cb2 Cr2 ? Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 emlix - your embedded linux partner -- 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: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009, Eduard Huguet wrote: > I don't have yet the buggy config, but the steps I was following > when I encounter the problem were the following: > ? hg clone http://linuxtv.org/hg/v4l-dvb > ? cd v4l-dvb > ? make menuconfig This is what I did too. Just use the menuconfig or xconfig targets. Maybe the kernel kconfig behavior has changed? -- 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] gspca
On Mon, 9 Feb 2009 18:50:15 -0200 Mauro Carvalho Chehab wrote: > On Thu, 5 Feb 2009 10:32:31 +0100 > Jean-Francois Moine wrote: [snip] > > Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ > > for: [snip] > Hmm... it seems that your tree has more changesets than what you've > pointed on your pull request... I got here 15 patches. Right! And there are some more to come! I was waiting for you to do the pull before requesting a new pull... > On the last changesets, I've seen that you're adding a lot of private > controls, like those: > > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 0) > +#define V4L2_CID_CAM_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > > and, on other driver: > > +#define V4L2_CID_INFRARED (V4L2_CID_PRIVATE_BASE + 0) > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > +#define V4L2_CID_JPEG_QUALITY (V4L2_CID_PRIVATE_BASE + 2) > > We should really standardize those controls and prepare some patches > for V4L2 API also, documenting what does that mean. Btw, it as not > clear what's the difference between those "quality" controls... Well, each webcam has a lot of parameters. Some of them enter in the standard controls, some other ones are very specific. This is the case here for the zc3xx subdriver: there is a quality parameter in the bridge which accepts values from 0 to 3. This parameter is automatically set by the ms-win driver according (surely) to the luminosity, and its initial value depends on the sensor. As we have no documentation about this quality, the best for me was to have a specific control (CAM_QUALITY). What difference with the JPEG quality? This last control is used to load the quantization tables into the webcam. The quality is the standard JPEG compression quality (value 0..100 in percent). And the last control? It is not a control of the webcam. It defines the quantization tables which are added to the webcam raw images to create JPEG images readable by any JPEG/MJPEG viewer. So, while their units are the same (compression in percent), the difference between JPEG_QUALITY and IMAGE_QUALITY is that the first one is used for encoding (in the webcam) while the second one is used for decoding (by the v4l library). Indeed, I should have written some documentation, but I think most users will play with these controls before reading anything. About the two last controls (quantization tables in the webcam or added in the raw JPEG images), there is already a jpegcomp ioctl, but I could not understand how it should work. AFAIK, only one driver implements it. Otherwise, one interesting feature of the V4L2 API is the possibility for any application to handle all standard and private device controls via VIDIOC_G/S_CTRL. Usually, control changes are not done automatically by applications, but by the users. Once a user has set the controls to get correct images, he may start any viewer application (but not mplayer which resets some controls to their default!). BTW, it should be useful to have a program which saves the control values on disk at change time, device disconnection or reboot) and reload them at system start or on device connection... 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: [PATCH 3/3] use the new request_module_nowait() in drivers/media
On Wed, 11 Feb 2009 00:02:15 +1030 Rusty Russell wrote: > On Tuesday 10 February 2009 03:04:56 Mauro Carvalho Chehab wrote: > > On Sun, 8 Feb 2009 11:00:52 -0800 > > Arjan van de Ven wrote: > > > From: Arjan van de Ven > > > Subject: [PATCH] use the new request_module_nowait() in drivers/media > ... > > Acked-by: Mauro Carvalho Chehab > > > > Cheers, > > Mauro > > Thanks Mauro. Since I have the prereq, I've taken this into my tree too. OK. 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: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 10:25:26 -0800 (PST) Trent Piepho wrote: > On Tue, 10 Feb 2009, Eduard Huguet wrote: > > I don't have yet the buggy config, but the steps I was following > > when I encounter the problem were the following: > > · hg clone http://linuxtv.org/hg/v4l-dvb > > · cd v4l-dvb > > · make menuconfig > > This is what I did too. Just use the menuconfig or xconfig targets. Maybe > the kernel kconfig behavior has changed? Hmm... I did a test here with RHEL 2.6.18 kernel: $ make menuconfig make -C /home/v4l/master/v4l menuconfig make[1]: Entrando no diretório `/home/v4l/master/v4l' /usr/src/kernels/2.6.18-125.el5-x86_64//scripts/kconfig/mconf ./Kconfig # # configuration written to .config # *** End of Linux kernel configuration. *** Execute 'make' to build the kernel or try 'make help'. $ grep CX88 v4l/.config CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=y CONFIG_VIDEO_CX88_VP3054=m So, I got the buggy .config Another test with 2.6.27: $ make menuconfig make -C /home/v4l/master/v4l menuconfig make[1]: Entrando no diretório `/home/v4l/master/v4l' ./scripts/make_kconfig.pl /usr/src/kernels/v2.6.27.4/ /usr/src/kernels/v2.6.27.4/ Preparing to compile for kernel version 2.6.27 VIDEO_PXA27x: Requires at least kernel 2.6.29 USB_STV06XX: Requires at least kernel 2.6.28 /usr/src/kernels/v2.6.27.4.i5400//scripts/kconfig/mconf ./Kconfig # # configuration written to .config # *** End of Linux kernel configuration. *** Execute 'make' to build the kernel or try 'make help'. make[1]: Saindo do diretório `/home/v4l/master/v4l' [...@pedra master]$ grep CX88 v4l/.config CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_MPEG=m CONFIG_VIDEO_CX88_VP3054=m With 2.6.27, everything is OK. So, it seems that a fix at some kernel between 2.6.22 and 2.6.27 changed (or fixed) the Kconfig behaviour. I suspect that the better fix for this would be to run something like: cat .config|sed s,'=y','=m' For kernels older than 2.6.27. Maybe Hans can give us a hint on what kernel this issue were solved, with his build environment. 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: KWorld ATSC 115 all static
On Tue, 10 Feb 2009 06:48:12 -0600 Jonathan Isom wrote: > > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 > > tree > > (http://linuxtv.org/hg/~mchehab/saa7134)? > > > > In the first case, could you please confirm that it works fine also with > > the saa7134 tree? > > Hi > I can confirm they work with both trees. > > Later Thanks, Jonathan. I'll merge the saa7134 patches then. The method I used previously is better fitted when we know how to enable and disable the i2c gate, but, for ATSC 115, we only know how to open the gate. 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: Driver for this DVB-T tuner?
- Original Nachricht Von: Antti Palosaari An: scholl...@arcor.de Datum: 09.02.2009 22:26 Betreff: Re: Aw: Re: Driver for this DVB-T tuner? > scholl...@arcor.de wrote: > > Wow that was fast! Thanks!!! > > > >> You should use driver from > >> http://linuxtv.org/hg/~anttip/mc44s803/ > > > > I managed to do that. > > > >>> af9013: firmware version:4.65.0 > >> Use 4.95.0 instead. > > > > How do I insert it correctly into the source tree? > > A short hint (to a readme) should help. > > Sorry, didn't understand what you mean. I've downloaded the af9015 firmware version 4.95.0 from here: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/ but simply downloading and installing into /lib/firmware seems to be not enough here (Mandriva 2009.0). > Anyhow, Mauro just committed this driver to the master, you can now use I did so, but firmware 4.95.0 is not included?!? Thanks, Stefan -- 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] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Tue Feb 10 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10503:9cb19f080660 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK 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-rc4-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc4-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc4-armv5-omap2: OK linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK 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-rc4-i686: WARNINGS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK 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-rc4-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc4-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc4-powerpc64: WARNINGS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK 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-rc4-x86_64: WARNINGS fw/apps: OK spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc4): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Driver for this DVB-T tuner?
scholl...@arcor.de wrote: I've downloaded the af9015 firmware version 4.95.0 from here: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/ Thats ok but simply downloading and installing into /lib/firmware seems to be not enough here (Mandriva 2009.0). ?? How did you installed old 4.65.0 firmware? Just replace 4.65.0 firmware file (file name is same) with 4.95.0 is enough. Anyhow, Mauro just committed this driver to the master, you can now use I did so, but firmware 4.95.0 is not included?!? Is not included? Firmware does not come with driver - it should be downloaded and installed separately. What it now prints to the /var/log/messages ? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] v4l/tvp514x: make the module aware of rich people
because they might design two of those chips on a single board.
You never know.
Signed-off-by: Sebastian Andrzej Siewior
---
v4: fix checkpatch issues
v3: - addressed review comments
- move tvp514x_slave into decoder struct it is used per device while
registering / comparing
v2: Make the content of the registers (brightness, \ldots) per decoder
and not global.
v1: Initial version
drivers/media/video/tvp514x.c | 106 +++--
1 files changed, 60 insertions(+), 46 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 8e23aa5..f8944d2 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -86,9 +86,12 @@ struct tvp514x_std_info {
struct v4l2_standard standard;
};
+static struct tvp514x_reg tvp514x_reg_list_default[0x40];
/**
- * struct tvp514x_decoded - TVP5146/47 decoder object
+ * struct tvp514x_decoder - TVP5146/47 decoder object
* @v4l2_int_device: Slave handle
+ * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
* @client: I2C client data
* @id: Entry from I2C table
@@ -103,7 +106,9 @@ struct tvp514x_std_info {
* @route: input and output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device *v4l2_int_device;
+ struct v4l2_int_device v4l2_int_device;
+ struct v4l2_int_slave tvp514x_slave;
+ struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
struct i2c_client *client;
@@ -124,7 +129,7 @@ struct tvp514x_decoder {
};
/* TVP514x default register values */
-static struct tvp514x_reg tvp514x_reg_list[] = {
+static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_WRITE, REG_INPUT_SEL, 0x05}, /* Composite selected */
{TOK_WRITE, REG_AFE_GAIN_CTRL, 0x0F},
{TOK_WRITE, REG_VIDEO_STD, 0x00}, /* Auto mode */
@@ -422,7 +427,7 @@ static int tvp514x_configure(struct tvp514x_decoder
*decoder)
/* common register initialization */
err =
- tvp514x_write_regs(decoder->client, tvp514x_reg_list);
+ tvp514x_write_regs(decoder->client, decoder->tvp514x_regs);
if (err)
return err;
@@ -580,7 +585,8 @@ static int ioctl_s_std(struct v4l2_int_device *s,
v4l2_std_id *std_id)
return err;
decoder->current_std = i;
- tvp514x_reg_list[REG_VIDEO_STD].val = decoder->std_list[i].video_std;
+ decoder->tvp514x_regs[REG_VIDEO_STD].val =
+ decoder->std_list[i].video_std;
v4l_dbg(1, debug, decoder->client, "Standard set to: %s",
decoder->std_list[i].standard.name);
@@ -625,8 +631,8 @@ static int ioctl_s_routing(struct v4l2_int_device *s,
if (err)
return err;
- tvp514x_reg_list[REG_INPUT_SEL].val = input_sel;
- tvp514x_reg_list[REG_OUTPUT_FORMATTER1].val = output_sel;
+ decoder->tvp514x_regs[REG_INPUT_SEL].val = input_sel;
+ decoder->tvp514x_regs[REG_OUTPUT_FORMATTER1].val = output_sel;
/* Clear status */
msleep(LOCK_RETRY_DELAY);
@@ -779,16 +785,16 @@ ioctl_g_ctrl(struct v4l2_int_device *s, struct
v4l2_control *ctrl)
switch (ctrl->id) {
case V4L2_CID_BRIGHTNESS:
- ctrl->value = tvp514x_reg_list[REG_BRIGHTNESS].val;
+ ctrl->value = decoder->tvp514x_regs[REG_BRIGHTNESS].val;
break;
case V4L2_CID_CONTRAST:
- ctrl->value = tvp514x_reg_list[REG_CONTRAST].val;
+ ctrl->value = decoder->tvp514x_regs[REG_CONTRAST].val;
break;
case V4L2_CID_SATURATION:
- ctrl->value = tvp514x_reg_list[REG_SATURATION].val;
+ ctrl->value = decoder->tvp514x_regs[REG_SATURATION].val;
break;
case V4L2_CID_HUE:
- ctrl->value = tvp514x_reg_list[REG_HUE].val;
+ ctrl->value = decoder->tvp514x_regs[REG_HUE].val;
if (ctrl->value == 0x7F)
ctrl->value = 180;
else if (ctrl->value == 0x80)
@@ -798,7 +804,7 @@ ioctl_g_ctrl(struct v4l2_int_device *s, struct v4l2_control
*ctrl)
break;
case V4L2_CID_AUTOGAIN:
- ctrl->value = tvp514x_reg_list[REG_AFE_GAIN_CTRL].val;
+ ctrl->value = decoder->tvp514x_regs[REG_AFE_GAIN_CTRL].val;
if ((ctrl->value & 0x3) == 3)
ctrl->value = 1;
else
@@ -848,7 +854,7 @@ ioctl_s_ctrl(struct v4l2_int_device *s, struct v4l2_control
*ctrl)
value);
if (err)
return err;
- tvp514x_reg_list[REG_BRIGHTNESS].val = value;
+ decoder->tvp514x_regs[REG_BRIGHTNESS].val = value;
bre
Re: Driver for this DVB-T tuner?
- Original Nachricht Von: Antti Palosaari An: scholl...@arcor.de Datum: 09.02.2009 22:26 Betreff: Re: Aw: Re: Driver for this DVB-T tuner? > scholl...@arcor.de wrote: > > Wow that was fast! Thanks!!! > > > >> You should use driver from > >> http://linuxtv.org/hg/~anttip/mc44s803/ > > > > I managed to do that. > > > >>> af9013: firmware version:4.65.0 > >> Use 4.95.0 instead. > > > > How do I insert it correctly into the source tree? > > A short hint (to a readme) should help. > > Sorry, didn't understand what you mean. I've downloaded the af9015 firmware version 4.95.0 from here: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/ but simply downloading and installing into /lib/firmware seems to be not enough here (Mandriva 2009.0). > Anyhow, Mauro just committed this driver to the master, you can now use I did so, but firmware 4.95.0 is not included?!? Thanks, Stefan -- 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: Driver for this DVB-T tuner?
- Original Nachricht Von: Antti Palosaari An: scholl...@arcor.de Datum: 09.02.2009 22:26 Betreff: Re: Aw: Re: Driver for this DVB-T tuner? > scholl...@arcor.de wrote: > > Wow that was fast! Thanks!!! > > > >> You should use driver from > >> http://linuxtv.org/hg/~anttip/mc44s803/ > > > > I managed to do that. > > > >>> af9013: firmware version:4.65.0 > >> Use 4.95.0 instead. > > > > How do I insert it correctly into the source tree? > > A short hint (to a readme) should help. > > Sorry, didn't understand what you mean. I've downloaded the af9015 firmware version 4.95.0 from here: http://www.otit.fi/~crope/v4l-dvb/af9015/af9015_firmware_cutter/firmware_files/4.95.0/ but simply downloading and installing into /lib/firmware seems to be not enough here (Mandriva 2009.0). > Anyhow, Mauro just committed this driver to the master, you can now use I did so, but firmware 4.95.0 is not included?!? Thanks, Stefan -- 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] em28xx: Codign style fixes and a typo correction
On Tue, 10 Feb 2009 20:59:05 +0100 Nicola Soranzo wrote: > Alle lunedì 09 febbraio 2009, hai scritto: > > On Mon, 9 Feb 2009 17:50:44 +0100 > > Nicola Soranzo wrote: > > > Lots of codign style fixes and a typo correction for em28xx. > > > > > > Priority: low > > > > > > Signed-off-by: Nicola Soranzo > > > > > > --- > > > diff -r 71e5a36634ea linux/drivers/media/video/em28xx/em28xx-audio.c > > > --- a/linux/drivers/media/video/em28xx/em28xx-audio.c Mon Feb 02 > > > 10:33:31 > > > 2009 +0100 > > > +++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Mon Feb 09 > > > 12:47:13 > > > 2009 +0100 > > > @@ -264,8 +264,7 @@ > > > } > > > > > > #if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 16) > > > -static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > > > - size_t size) > > > +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > > > size_t size) > > > > Please, prefer, instead, something like: > > +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > > size_t size) > > This part was line wrapped by KMail (I've changed its setting as suggested), > the original was: Ah, ok. > diff -r 9cb19f080660 linux/drivers/media/video/em28xx/em28xx-audio.c > --- a/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 05:26:05 > 2009 -0200 > +++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 20:33:23 > 2009 +0100 > @@ -264,8 +264,7 @@ static int em28xx_cmd(struct em28xx *dev > } > > #if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 16) > -static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > - size_t size) > +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, size_t > size) > #else > static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, > size_t size) > > The function definition is <= 80 characters, so I've put it on one line. Do > you > anyway prefer the second parameter on the other line for consistency? If it fits on 80 columns, IMO, the better is to keep it at the same line. > Thanks for the review, I've fixed all other required changes and I will send > the new version later. Ok, thanks! 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: Driver for this DVB-T tuner?
Antti wrote: > ?? How did you installed old 4.65.0 firmware? Just replace 4.65.0 > firmware file (file name is same) with 4.95.0 is enough. > I'm not fully sure, if I did it at all, it was from an old, unsuccessful attempt. Tryed an "updatedb" as root and the only places where I could find it has the new version. I'm suspecting it comes with standard kernel 2.6.27.10-1 on Mandriva, which I'm using. Should I deactivate 9015 from standard kernel options? Anyhow - is there no default place to store firmware when compiling a kernel or modules? > What it now prints to the /var/log/messages ? This is still as before: Feb 10 20:10:44 localhost kernel: af9013: firmware version:4.65.0 Thanks for your help, Stefan -- 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] em28xx: Codign style fixes and a typo correction
Alle lunedì 09 febbraio 2009, hai scritto: > On Mon, 9 Feb 2009 17:50:44 +0100 > Nicola Soranzo wrote: > > Lots of codign style fixes and a typo correction for em28xx. > > > > Priority: low > > > > Signed-off-by: Nicola Soranzo > > > > --- > > diff -r 71e5a36634ea linux/drivers/media/video/em28xx/em28xx-audio.c > > --- a/linux/drivers/media/video/em28xx/em28xx-audio.c Mon Feb 02 > > 10:33:31 > > 2009 +0100 > > +++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Mon Feb 09 > > 12:47:13 > > 2009 +0100 > > @@ -264,8 +264,7 @@ > > } > > > > #if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 16) > > -static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > > - size_t size) > > +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, > > size_t size) > > Please, prefer, instead, something like: > +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, >size_t size) This part was line wrapped by KMail (I've changed its setting as suggested), the original was: diff -r 9cb19f080660 linux/drivers/media/video/em28xx/em28xx-audio.c --- a/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 05:26:05 2009 -0200 +++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 20:33:23 2009 +0100 @@ -264,8 +264,7 @@ static int em28xx_cmd(struct em28xx *dev } #if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 16) -static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, - size_t size) +static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, size_t size) #else static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) The function definition is <= 80 characters, so I've put it on one line. Do you anyway prefer the second parameter on the other line for consistency? Thanks for the review, I've fixed all other required changes and I will send the new version later. Nicola -- 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] gspca
On Tue, 10 Feb 2009 19:18:03 +0100 Jean-Francois Moine wrote: > On Mon, 9 Feb 2009 18:50:15 -0200 > Mauro Carvalho Chehab wrote: > > > On Thu, 5 Feb 2009 10:32:31 +0100 > > Jean-Francois Moine wrote: > [snip] > > > Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ > > > for: > [snip] > > Hmm... it seems that your tree has more changesets than what you've > > pointed on your pull request... I got here 15 patches. > > Right! And there are some more to come! I was waiting for you to do the > pull before requesting a new pull... Please, don't add newer patches after requesting me to pull, otherwise, I may not pull from it, since the other patches may not be ready yet for pulling. If you want an experimental tree, the better is to create a second tree there. > > We should really standardize those controls and prepare some patches > > for V4L2 API also, documenting what does that mean. Btw, it as not > > clear what's the difference between those "quality" controls... > > Well, each webcam has a lot of parameters. Some of them enter in the > standard controls, some other ones are very specific. > > This is the case here for the zc3xx subdriver: there is a quality > parameter in the bridge which accepts values from 0 to 3. This > parameter is automatically set by the ms-win driver according (surely) > to the luminosity, and its initial value depends on the sensor. As we > have no documentation about this quality, the best for me was to have a > specific control (CAM_QUALITY). Ok, in this specific case, I agree that maybe this could be a private control. Yet, if an userpace app is aware of it, it can have an userspace algorithm to automatically adjust it based on luminosity. > What difference with the JPEG quality? This last control is used to > load the quantization tables into the webcam. The quality is the > standard JPEG compression quality (value 0..100 in percent). > > And the last control? It is not a control of the webcam. It defines > the quantization tables which are added to the webcam raw images to > create JPEG images readable by any JPEG/MJPEG viewer. So, while their > units are the same (compression in percent), the difference between > JPEG_QUALITY and IMAGE_QUALITY is that the first one is used for > encoding (in the webcam) while the second one is used for decoding (by > the v4l library). Both of those quality controls seem standard enough to use a standard. > Indeed, I should have written some documentation, but I think most users > will play with these controls before reading anything. > > About the two last controls (quantization tables in the webcam or added > in the raw JPEG images), there is already a jpegcomp ioctl, but I could > not understand how it should work. AFAIK, only one driver implements it. If the spec is not clear enough, then we should patch the spec and use it, instead of creating yet another control for the same thing. Looking at meye.c code, the V4L2_CID_JPEGQUAL seems to control what you called as IMAGE_QUALITY, e. g. it controls what quantization table will be used. It is also a private control: #define V4L2_CID_JPEGQUAL (V4L2_CID_PRIVATE_BASE + 3) I would do, instead, something like this, at videodev2.h: #define V4L2_CTRL_CLASS_JPEG 0x009a /* Jpeg class controls */ #define V4L2_CID_JPEG_BASE (V4L2_CTRL_CLASS_HPEG | 0x900) #define V4L2_CID_QUALITY(V4L2_CID_CAMERA_CLASS_BASE+17) #define V4L2_JPEG_QUALITY(V4L2_CTRL_CLASS_JPEG_BASE+0) #define V4L2_JPEG_QTABLE (V4L2_CTRL_CLASS_JPEG_BASE+1) Adding V4L2_JPEG_QTABLE to all cases where the legacy V4L2_CID_JPEGQUAL were used. > Otherwise, one interesting feature of the V4L2 API is the possibility > for any application to handle all standard and private device controls > via VIDIOC_G/S_CTRL. Usually, control changes are not done > automatically by applications, but by the users. True, but certain applications (like multimedia conference and surveillance software) may want to adjust the codec quality according with the amount of bandwidth to be used. By using a standard way, they can automatically handle such controls, and even adjusting the quality based on the luminosity of the environment. > Once a user has set > the controls to get correct images, he may start any viewer application > (but not mplayer which resets some controls to their default!). > > BTW, it should be useful to have a program which saves the control > values on disk at change time, device disconnection or reboot) and > reload them at system start or on device connection... This has pros and cons. tvtime does this for analog TV. That's a nice feature on most cases, but, when a command changes its scale, or their default values, then we have a trouble, since the saved control may produce a black image for example (we just have this issue recently with a cut-and-paste error that happened on V4L subdev). Cheers, Mauro -- To
Re: cx8802.ko module not being built with current HG tree
On Tuesday 10 February 2009 19:47:40 Mauro Carvalho Chehab wrote:
> On Tue, 10 Feb 2009 10:25:26 -0800 (PST)
>
> Trent Piepho wrote:
> > On Tue, 10 Feb 2009, Eduard Huguet wrote:
> > > I don't have yet the buggy config, but the steps I was following
> > > when I encounter the problem were the following:
> > > · hg clone http://linuxtv.org/hg/v4l-dvb
> > > · cd v4l-dvb
> > > · make menuconfig
> >
> > This is what I did too. Just use the menuconfig or xconfig targets.
> > Maybe the kernel kconfig behavior has changed?
>
> Hmm... I did a test here with RHEL 2.6.18 kernel:
>
> $ make menuconfig
> make -C /home/v4l/master/v4l menuconfig
> make[1]: Entrando no diretório `/home/v4l/master/v4l'
> /usr/src/kernels/2.6.18-125.el5-x86_64//scripts/kconfig/mconf ./Kconfig
> #
> # configuration written to .config
> #
>
>
> *** End of Linux kernel configuration.
> *** Execute 'make' to build the kernel or try 'make help'.
>
> $ grep CX88 v4l/.config
> CONFIG_VIDEO_CX88=m
> CONFIG_VIDEO_CX88_ALSA=m
> CONFIG_VIDEO_CX88_BLACKBIRD=m
> CONFIG_VIDEO_CX88_DVB=m
> CONFIG_VIDEO_CX88_MPEG=y
> CONFIG_VIDEO_CX88_VP3054=m
>
> So, I got the buggy .config
>
> Another test with 2.6.27:
>
> $ make menuconfig
> make -C /home/v4l/master/v4l menuconfig
> make[1]: Entrando no diretório `/home/v4l/master/v4l'
> ./scripts/make_kconfig.pl /usr/src/kernels/v2.6.27.4/
> /usr/src/kernels/v2.6.27.4/ Preparing to compile for kernel version
> 2.6.27
> VIDEO_PXA27x: Requires at least kernel 2.6.29
> USB_STV06XX: Requires at least kernel 2.6.28
> /usr/src/kernels/v2.6.27.4.i5400//scripts/kconfig/mconf ./Kconfig
> #
> # configuration written to .config
> #
>
>
> *** End of Linux kernel configuration.
> *** Execute 'make' to build the kernel or try 'make help'.
>
> make[1]: Saindo do diretório `/home/v4l/master/v4l'
> [...@pedra master]$ grep CX88 v4l/.config
> CONFIG_VIDEO_CX88=m
> CONFIG_VIDEO_CX88_ALSA=m
> CONFIG_VIDEO_CX88_BLACKBIRD=m
> CONFIG_VIDEO_CX88_DVB=m
> CONFIG_VIDEO_CX88_MPEG=m
> CONFIG_VIDEO_CX88_VP3054=m
>
> With 2.6.27, everything is OK.
>
> So, it seems that a fix at some kernel between 2.6.22 and 2.6.27 changed
> (or fixed) the Kconfig behaviour.
>
> I suspect that the better fix for this would be to run something like:
>
> cat .config|sed s,'=y','=m'
>
> For kernels older than 2.6.27.
>
> Maybe Hans can give us a hint on what kernel this issue were solved, with
> his build environment.
2.6.21 is wrong, 2.6.22 is right. Cause: dependency on VIDEOBUF_DMA_SG,
which has a dependency on CONFIG_HAS_DMA, which was apparently introduced
in 2.6.22 and didn't exist in 2.6.21.
This is fixed by the attached diff.
Signed-off-by: Hans Verkuil
BTW, all the scripts I use to setup and run the build environment are
available here: http://www.xs4all.nl/%7Ehverkuil/logs/scripts.tar.bz2
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
diff -r 9cb19f080660 v4l/scripts/make_kconfig.pl
--- a/v4l/scripts/make_kconfig.pl Tue Feb 10 05:26:05 2009 -0200
+++ b/v4l/scripts/make_kconfig.pl Tue Feb 10 21:28:50 2009 +0100
@@ -537,6 +537,11 @@
$kernopts{HAS_IOMEM} = 2;
}
+# Kernel < 2.6.22 is missing the HAS_DMA option
+if (!defined $kernopts{HAS_DMA} && cmp_ver($kernver, '2.6.22') < 0) {
+$kernopts{HAS_DMA} = 2;
+}
+
# Kernel < 2.6.23 is missing the VIRT_TO_BUS option
if (!defined $kernopts{VIRT_TO_BUS} && cmp_ver($kernver, '2.6.23') < 0) {
# VIRT_TO_BUS -> !PPC64
Re: Driver for this DVB-T tuner?
scholl...@arcor.de wrote: Feb 10 20:10:44 localhost kernel: af9013: firmware version:4.65.0 Still old firmware. What md5sum says? [r...@localhost ~]# md5sum /lib/firmware/dvb-usb-af9015.fw dccbc92c9168cc629a88b34ee67ede7b /lib/firmware/dvb-usb-af9015.fw Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 21:31:59 +0100 Hans Verkuil wrote: > On Tuesday 10 February 2009 19:47:40 Mauro Carvalho Chehab wrote: > > On Tue, 10 Feb 2009 10:25:26 -0800 (PST) > > > > Trent Piepho wrote: > > > On Tue, 10 Feb 2009, Eduard Huguet wrote: > > > > I don't have yet the buggy config, but the steps I was following > > > > when I encounter the problem were the following: > > > > · hg clone http://linuxtv.org/hg/v4l-dvb > > > > · cd v4l-dvb > > > > · make menuconfig > > > > > > This is what I did too. Just use the menuconfig or xconfig targets. > > > Maybe the kernel kconfig behavior has changed? > > > > Hmm... I did a test here with RHEL 2.6.18 kernel: > > > > $ make menuconfig > > make -C /home/v4l/master/v4l menuconfig > > make[1]: Entrando no diretório `/home/v4l/master/v4l' > > /usr/src/kernels/2.6.18-125.el5-x86_64//scripts/kconfig/mconf ./Kconfig > > # > > # configuration written to .config > > # > > > > > > *** End of Linux kernel configuration. > > *** Execute 'make' to build the kernel or try 'make help'. > > > > $ grep CX88 v4l/.config > > CONFIG_VIDEO_CX88=m > > CONFIG_VIDEO_CX88_ALSA=m > > CONFIG_VIDEO_CX88_BLACKBIRD=m > > CONFIG_VIDEO_CX88_DVB=m > > CONFIG_VIDEO_CX88_MPEG=y > > CONFIG_VIDEO_CX88_VP3054=m > > > > So, I got the buggy .config > > > > Another test with 2.6.27: > > > > $ make menuconfig > > make -C /home/v4l/master/v4l menuconfig > > make[1]: Entrando no diretório `/home/v4l/master/v4l' > > ./scripts/make_kconfig.pl /usr/src/kernels/v2.6.27.4/ > > /usr/src/kernels/v2.6.27.4/ Preparing to compile for kernel version > > 2.6.27 > > VIDEO_PXA27x: Requires at least kernel 2.6.29 > > USB_STV06XX: Requires at least kernel 2.6.28 > > /usr/src/kernels/v2.6.27.4.i5400//scripts/kconfig/mconf ./Kconfig > > # > > # configuration written to .config > > # > > > > > > *** End of Linux kernel configuration. > > *** Execute 'make' to build the kernel or try 'make help'. > > > > make[1]: Saindo do diretório `/home/v4l/master/v4l' > > [...@pedra master]$ grep CX88 v4l/.config > > CONFIG_VIDEO_CX88=m > > CONFIG_VIDEO_CX88_ALSA=m > > CONFIG_VIDEO_CX88_BLACKBIRD=m > > CONFIG_VIDEO_CX88_DVB=m > > CONFIG_VIDEO_CX88_MPEG=m > > CONFIG_VIDEO_CX88_VP3054=m > > > > With 2.6.27, everything is OK. > > > > So, it seems that a fix at some kernel between 2.6.22 and 2.6.27 changed > > (or fixed) the Kconfig behaviour. > > > > I suspect that the better fix for this would be to run something like: > > > > cat .config|sed s,'=y','=m' > > > > For kernels older than 2.6.27. > > > > Maybe Hans can give us a hint on what kernel this issue were solved, with > > his build environment. > > 2.6.21 is wrong, 2.6.22 is right. Cause: dependency on VIDEOBUF_DMA_SG, > which has a dependency on CONFIG_HAS_DMA, which was apparently introduced > in 2.6.22 and didn't exist in 2.6.21. > > This is fixed by the attached diff. No, it didn't fix. I'm still getting this issue with 2.6.18. Btw, on RHEL5 2.6.18 kernel, HAS_DMA does exist: $ grep CONFIG_HAS_DMA /usr/src/kernels/2.6.18-125.el5-x86_64/.config CONFIG_HAS_DMA=y Also, the original reporter were for an Ubuntu kernel 2.6.22. > > Signed-off-by: Hans Verkuil > > BTW, all the scripts I use to setup and run the build environment are > available here: http://www.xs4all.nl/%7Ehverkuil/logs/scripts.tar.bz2 > > Regards, > > Hans > 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] gspca
On Tuesday 10 February 2009 19:18:03 Jean-Francois Moine wrote: > On Mon, 9 Feb 2009 18:50:15 -0200 > > Mauro Carvalho Chehab wrote: > > On Thu, 5 Feb 2009 10:32:31 +0100 > > Jean-Francois Moine wrote: > > [snip] > > > > Please pull from http://linuxtv.org/hg/~jfrancois/gspca/ > > > for: > > [snip] > > > Hmm... it seems that your tree has more changesets than what you've > > pointed on your pull request... I got here 15 patches. > > Right! And there are some more to come! I was waiting for you to do the > pull before requesting a new pull... > > > On the last changesets, I've seen that you're adding a lot of private > > controls, like those: > > > > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 0) > > +#define V4L2_CID_CAM_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > > > > and, on other driver: > > > > +#define V4L2_CID_INFRARED (V4L2_CID_PRIVATE_BASE + 0) > > +#define V4L2_CID_IMAGE_QUALITY (V4L2_CID_PRIVATE_BASE + 1) > > +#define V4L2_CID_JPEG_QUALITY (V4L2_CID_PRIVATE_BASE + 2) > > > > We should really standardize those controls and prepare some patches > > for V4L2 API also, documenting what does that mean. Btw, it as not > > clear what's the difference between those "quality" controls... Argh! Don't use PRIVATE_BASE except as a duplicate for older apps! Add class-private controls as was done with the MPEG controls. I wrote a good overview of how to add private controls and the current status of that here: http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg07999.html I suggest that you add proper camera controls to videodev2.h from base V4L2_CTRL_CLASS_CAMERA | 0x1000, document them in the spec and use PRIVATE_BASE IDs internally as a backup for old apps. Currently I am working to convert all drivers to use the new v4l2 framework. Once that it finished I can start to do all sorts of fancy stuff including improving handling of controls. You might want to consider converting gspca to use v4l2_device as well to be prepared for that. It doesn't do much right know (unless the driver needs i2c modules), but it will become much more important in the future. > Well, each webcam has a lot of parameters. Some of them enter in the > standard controls, some other ones are very specific. > > This is the case here for the zc3xx subdriver: there is a quality > parameter in the bridge which accepts values from 0 to 3. This > parameter is automatically set by the ms-win driver according (surely) > to the luminosity, and its initial value depends on the sensor. As we > have no documentation about this quality, the best for me was to have a > specific control (CAM_QUALITY). > > What difference with the JPEG quality? This last control is used to > load the quantization tables into the webcam. The quality is the > standard JPEG compression quality (value 0..100 in percent). > > And the last control? It is not a control of the webcam. It defines > the quantization tables which are added to the webcam raw images to > create JPEG images readable by any JPEG/MJPEG viewer. So, while their > units are the same (compression in percent), the difference between > JPEG_QUALITY and IMAGE_QUALITY is that the first one is used for > encoding (in the webcam) while the second one is used for decoding (by > the v4l library). JPEG_QUALITY looks to me to be perfect as a general camera or user control. IMAGE_QUALITY I don't get. Do you mean that the v4l library will use this control? For what? > Indeed, I should have written some documentation, but I think most users > will play with these controls before reading anything. They *must* be documented in the spec. There are other private controls in existing drivers that are completely undocumented and nobody knows what they do. Let's prevent that for new private controls. > About the two last controls (quantization tables in the webcam or added > in the raw JPEG images), there is already a jpegcomp ioctl, but I could > not understand how it should work. AFAIK, only one driver implements it. I'm working on the zoran driver anyway. I'll see if I can find out some decent documentation and add it to the spec (another case of people adding to the API without documenting it!). To be honest, I am afraid that they basically added a zoran-private ioctl to the public V4L2 API and it probably is useless outside that single driver. Regards, Hans > Otherwise, one interesting feature of the V4L2 API is the possibility > for any application to handle all standard and private device controls > via VIDIOC_G/S_CTRL. Usually, control changes are not done > automatically by applications, but by the users. Once a user has set > the controls to get correct images, he may start any viewer application > (but not mplayer which resets some controls to their default!). > > BTW, it should be useful to have a program which saves the control > values on disk at change time, device disconnection or reboot) and > reload them at system start or on device connection..
Re: [linux-dvb] EC168
Tanguy Pruvot wrote: #define CMD_EC168_RAM 0x00 //RW- Read/Write RAM (Firmware go to addr 0-0x1EFF) #define CMD_EC168_GETSTATUS 0x01 //R-- ex: dfu_ctrl_get(device,0x01,0x,0x01A0,buffer,0x1A); #define CMD_EC168_STREAM0x03 //R-X ex: dfu_ctrl(device,0x03,0/0x20,0xFF00); //disable/enable streaming #define CMD_EC168_SET_POWER 0x04 //--X ex: dfu_ctrl(device,0x04,0/1,0x0008); //disable/enable LED //indexes seen: 206,208,8,9,A,B #define CMD_EC168_UNKNOWN 0x10 //--X ??? #define CMD_EC168_READ_BUF 0x20 //R-- ex: dfu_ctrl_get(device,0x20,0x,0x01A0,buffer,0x1A); #define CMD_EC168_WRITE_BUF 0x21 //-W- #define CMD_EC168_SET 0x30 //--X ex: dfu_ctrl(device, 0x30, 0x0709, 0x1A); Are you still hacking that device? I tried to order Intel CE6230 device but got EC168 (SinoVideo 3420A-2). I take one USB-sniff and here are commands as I think: 00 firmware download 01 ? config 03 demodulator 04 ? GPIO (LED) 10 streaming control 20 I2C read 21 I2C write 30 HID table download Looks like EC168 has EC100 demodulator integrated. And programming this demodulator seems to be rather easy, not very many bytes... regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx8802.ko module not being built with current HG tree
On Tuesday 10 February 2009 21:41:47 Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 21:31:59 +0100 > > Hans Verkuil wrote: > > On Tuesday 10 February 2009 19:47:40 Mauro Carvalho Chehab wrote: > > > On Tue, 10 Feb 2009 10:25:26 -0800 (PST) > > > > > > Trent Piepho wrote: > > > > On Tue, 10 Feb 2009, Eduard Huguet wrote: > > > > > I don't have yet the buggy config, but the steps I was > > > > > following when I encounter the problem were the following: > > > > > · hg clone http://linuxtv.org/hg/v4l-dvb > > > > > · cd v4l-dvb > > > > > · make menuconfig > > > > > > > > This is what I did too. Just use the menuconfig or xconfig > > > > targets. Maybe the kernel kconfig behavior has changed? > > > > > > Hmm... I did a test here with RHEL 2.6.18 kernel: > > > > > > $ make menuconfig > > > make -C /home/v4l/master/v4l menuconfig > > > make[1]: Entrando no diretório `/home/v4l/master/v4l' > > > /usr/src/kernels/2.6.18-125.el5-x86_64//scripts/kconfig/mconf > > > ./Kconfig # > > > # configuration written to .config > > > # > > > > > > > > > *** End of Linux kernel configuration. > > > *** Execute 'make' to build the kernel or try 'make help'. > > > > > > $ grep CX88 v4l/.config > > > CONFIG_VIDEO_CX88=m > > > CONFIG_VIDEO_CX88_ALSA=m > > > CONFIG_VIDEO_CX88_BLACKBIRD=m > > > CONFIG_VIDEO_CX88_DVB=m > > > CONFIG_VIDEO_CX88_MPEG=y > > > CONFIG_VIDEO_CX88_VP3054=m > > > > > > So, I got the buggy .config > > > > > > Another test with 2.6.27: > > > > > > $ make menuconfig > > > make -C /home/v4l/master/v4l menuconfig > > > make[1]: Entrando no diretório `/home/v4l/master/v4l' > > > ./scripts/make_kconfig.pl /usr/src/kernels/v2.6.27.4/ > > > /usr/src/kernels/v2.6.27.4/ Preparing to compile for kernel version > > > 2.6.27 > > > VIDEO_PXA27x: Requires at least kernel 2.6.29 > > > USB_STV06XX: Requires at least kernel 2.6.28 > > > /usr/src/kernels/v2.6.27.4.i5400//scripts/kconfig/mconf ./Kconfig > > > # > > > # configuration written to .config > > > # > > > > > > > > > *** End of Linux kernel configuration. > > > *** Execute 'make' to build the kernel or try 'make help'. > > > > > > make[1]: Saindo do diretório `/home/v4l/master/v4l' > > > [...@pedra master]$ grep CX88 v4l/.config > > > CONFIG_VIDEO_CX88=m > > > CONFIG_VIDEO_CX88_ALSA=m > > > CONFIG_VIDEO_CX88_BLACKBIRD=m > > > CONFIG_VIDEO_CX88_DVB=m > > > CONFIG_VIDEO_CX88_MPEG=m > > > CONFIG_VIDEO_CX88_VP3054=m > > > > > > With 2.6.27, everything is OK. > > > > > > So, it seems that a fix at some kernel between 2.6.22 and 2.6.27 > > > changed (or fixed) the Kconfig behaviour. > > > > > > I suspect that the better fix for this would be to run something > > > like: > > > > > > cat .config|sed s,'=y','=m' > > > > > > For kernels older than 2.6.27. > > > > > > Maybe Hans can give us a hint on what kernel this issue were solved, > > > with his build environment. > > > > 2.6.21 is wrong, 2.6.22 is right. Cause: dependency on VIDEOBUF_DMA_SG, > > which has a dependency on CONFIG_HAS_DMA, which was apparently > > introduced in 2.6.22 and didn't exist in 2.6.21. > > > > This is fixed by the attached diff. > > No, it didn't fix. I'm still getting this issue with 2.6.18. > > Btw, on RHEL5 2.6.18 kernel, HAS_DMA does exist: > > $ grep CONFIG_HAS_DMA /usr/src/kernels/2.6.18-125.el5-x86_64/.config > CONFIG_HAS_DMA=y Oops, this fixes a different bug. It is still a bug fix, though, since it prevents CX88 from being build at all on any vanilla kernels < 2.6.22. Can you apply it? > Also, the original reporter were for an Ubuntu kernel 2.6.22. I did some more testing and the bug disappears in kernel 2.6.25. Also, if I just run 'make', then the .config file it produces is fine. I wonder if it isn't a bug in menuconfig itself. Regards, Hans > > > Signed-off-by: Hans Verkuil > > > > BTW, all the scripts I use to setup and run the build environment are > > available here: http://www.xs4all.nl/%7Ehverkuil/logs/scripts.tar.bz2 > > > > Regards, > > > > Hans > > Cheers, > Mauro -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add Elgato EyeTV DTT to dibcom driver
This patch introduces support for DVB-T for the following dibcom based card:
Elgato EyeTV DTT (USB-ID: 0fd9:0021)
Signed-off-by: Klaus Flittner
diff -r 9cb19f080660 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Tue Feb 10 05:26:05
2009 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Tue Feb 10 22:21:16
2009 +0100
@@ -1419,6 +1419,7 @@
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_EXPRESS) },
{ USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2) },
+ { USB_DEVICE(USB_VID_ELGATO,USB_PID_ELGATO_EYETV_DTT) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1618,7 +1619,7 @@
},
},
- .num_device_descs = 9,
+ .num_device_descs = 10,
.devices = {
{ "DiBcom STK7070P reference design",
{ &dib0700_usb_id_table[15], NULL },
@@ -1654,6 +1655,10 @@
},
{ "Terratec Cinergy T USB XXS",
{ &dib0700_usb_id_table[33], NULL },
+ { NULL },
+ },
+ { "Elgato EyeTV DTT",
+ { &dib0700_usb_id_table[44], NULL },
{ NULL },
},
},
diff -r 9cb19f080660 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Tue Feb 10 05:26:05
2009 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Tue Feb 10 22:21:16
2009 +0100
@@ -27,6 +27,7 @@
#define USB_VID_DIBCOM 0x10b8
#define USB_VID_DPOSH 0x1498
#define USB_VID_DVICO 0x0fe9
+#define USB_VID_ELGATO 0x0fd9
#define USB_VID_EMPIA 0xeb1a
#define USB_VID_GENPIX 0x09c0
#define USB_VID_GRANDTEC 0x5032
@@ -237,5 +238,6 @@
#define USB_PID_XTENSIONS_XD_380 0x0381
#define USB_PID_TELESTAR_STARSTICK_2 0x8000
#define USB_PID_MSI_DIGI_VOX_MINI_III 0x8807
+#define USB_PID_ELGATO_EYETV_DTT 0x0021
#endif
diff -r 9cb19f080660 linux/drivers/media/dvb/dvb-usb/dvb-usb.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb.h Tue Feb 10 05:26:05 2009 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb.h Tue Feb 10 22:21:16 2009 +0100
@@ -224,7 +224,7 @@
int generic_bulk_ctrl_endpoint;
int num_device_descs;
- struct dvb_usb_device_description devices[9];
+ struct dvb_usb_device_description devices[10];
};
/**
--
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 v2] em28xx: Coding style fixes and a typo correction
Lots of coding style fixes and a typo correction for em28xx.
Priority: low
Signed-off-by: Nicola Soranzo
---
v2: Addressed review comments from Mauro Carvalho Chehab
diff -r 9cb19f080660 linux/drivers/media/video/em28xx/em28xx-audio.c
--- a/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 05:26:05
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-audio.c Tue Feb 10 20:33:23
2009 +0100
@@ -264,8 +264,7 @@ static int em28xx_cmd(struct em28xx *dev
}
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 16)
-static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs,
- size_t size)
+static int snd_pcm_alloc_vmalloc_buffer(snd_pcm_substream_t *subs, size_t size)
#else
static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs,
size_t size)
@@ -277,7 +276,7 @@ static int snd_pcm_alloc_vmalloc_buffer(
struct snd_pcm_runtime *runtime = subs->runtime;
#endif
- dprintk("Alocating vbuffer\n");
+ dprintk("Allocating vbuffer\n");
if (runtime->dma_area) {
if (runtime->dma_bytes > size)
return 0;
@@ -454,8 +453,8 @@ static int snd_em28xx_capture_trigger(st
{
struct em28xx *dev = snd_pcm_substream_chip(substream);
- dprintk("Should %s capture\n", (cmd == SNDRV_PCM_TRIGGER_START)?
- "start": "stop");
+ dprintk("Should %s capture\n", (cmd == SNDRV_PCM_TRIGGER_START) ?
+ "start" : "stop");
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
em28xx_cmd(dev, EM28XX_CAPTURE_STREAM_EN, 1);
@@ -476,8 +475,7 @@ static snd_pcm_uframes_t snd_em28xx_capt
*substream)
#endif
{
- unsigned long flags;
-
+ unsigned long flags;
struct em28xx *dev;
snd_pcm_uframes_t hwptr_done;
diff -r 9cb19f080660 linux/drivers/media/video/em28xx/em28xx-cards.c
--- a/linux/drivers/media/video/em28xx/em28xx-cards.c Tue Feb 10 05:26:05
2009 -0200
+++ b/linux/drivers/media/video/em28xx/em28xx-cards.c Tue Feb 10 20:33:23
2009 +0100
@@ -257,7 +257,7 @@ struct em28xx_board em28xx_boards[] = {
.name = "Hauppauge WinTV USB 2",
.tuner_type = TUNER_PHILIPS_FM1236_MK3,
.tda9887_conf = TDA9887_PRESENT |
- TDA9887_PORT1_ACTIVE|
+ TDA9887_PORT1_ACTIVE |
TDA9887_PORT2_ACTIVE,
.decoder = EM28XX_TVP5150,
.has_msp34xx = 1,
@@ -534,7 +534,7 @@ struct em28xx_board em28xx_boards[] = {
},
[EM2861_BOARD_YAKUMO_MOVIE_MIXER] = {
.name = "Yakumo MovieMixer",
- .tuner_type = TUNER_ABSENT, /* Capture only device */
+ .tuner_type= TUNER_ABSENT, /* Capture only device */
.decoder = EM28XX_TVP5150,
.input = { {
.type = EM28XX_VMUX_TELEVISION,
@@ -902,11 +902,11 @@ struct em28xx_board em28xx_boards[] = {
} },
},
[EM2800_BOARD_GRABBEEX_USB2800] = {
- .name = "eMPIA Technology, Inc. GrabBeeX+ Video
Encoder",
- .is_em2800= 1,
- .decoder = EM28XX_SAA711X,
- .tuner_type = TUNER_ABSENT, /* capture only board */
- .input= { {
+ .name = "eMPIA Technology, Inc. GrabBeeX+ Video Encoder",
+ .is_em2800 = 1,
+ .decoder= EM28XX_SAA711X,
+ .tuner_type = TUNER_ABSENT, /* capture only board */
+ .input = { {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
@@ -1282,7 +1282,9 @@ struct em28xx_board em28xx_boards[] = {
.has_dvb = 1,
.dvb_gpio = kworld_330u_digital,
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
- .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
EM28XX_I2C_EEPROM_ON_BOARD | EM28XX_I2C_EEPROM_KEY_VALID,
+ .i2c_speed= EM28XX_I2C_CLK_WAIT_ENABLE |
+ EM28XX_I2C_EEPROM_ON_BOARD |
+ EM28XX_I2C_EEPROM_KEY_VALID,
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
@@ -1321,7 +1323,7 @@ struct em28xx_board em28xx_boards[] = {
const unsigned int em28xx_bcount = ARRAY_SIZE(em28xx_boards);
/* table of devices that work with this driver */
-struct usb_device_id em28xx_id_table [] = {
+struct usb_device_id em28xx_id_table[] = {
{ USB_DEVICE(0xeb1a, 0x2750),
Re: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 22:21:39 +0100
Hans Verkuil wrote:
> > $ grep CONFIG_HAS_DMA /usr/src/kernels/2.6.18-125.el5-x86_64/.config
> > CONFIG_HAS_DMA=y
>
> Oops, this fixes a different bug. It is still a bug fix, though, since it
> prevents CX88 from being build at all on any vanilla kernels < 2.6.22. Can
> you apply it?
Applied, thanks.
> > Also, the original reporter were for an Ubuntu kernel 2.6.22.
>
> I did some more testing and the bug disappears in kernel 2.6.25. Also, if I
> just run 'make', then the .config file it produces is fine. I wonder if it
> isn't a bug in menuconfig itself.
It seems to be a bug at the Kbuild, fixed on Feb, 2008, on this changeset:
commit 587c90616a5b44e6ccfac38e64d4fecee51d588c (attached).
As explained, after the patch description, the value for the Kconfig var, after
the patch, uses this formula:
(value && dependency) || select
where value is the default value.
Since CONFIG_CX88_MPEG is defined as:
config VIDEO_CX88_MPEG
tristate
depends on VIDEO_CX88_DVB || VIDEO_CX88_BLACKBIRD
default y
And there there's no select, the value of CONFIG_CX88_MPEG is determined by:
('y' && dependency)
The most complex case is when we have CX88 defined as:
CX88 = 'y'
if both CX88_DVB and CX88_BLACKBIRD are defined as 'm' (or one of them is 'n'
and the other is 'm'), then CX88_MPEG is defined as:
CX88_MPEG = 'm'
If one of CX88_DVB or CX88_BLACKBIRD is defined as 'y'; then we have:
CX88_MPEG = 'y'
If both are 'n', we have:
CX88_MPEG = 'n'
So, it seems that, after commit 587c90616a5b44e6ccfac38e64d4fecee51d588c,
everything is working as expected. We just need to provide a hack at the
out-of-tree build system for kernels that don't have this commit applied.
Cheers,
Mauro
commit 587c90616a5b44e6ccfac38e64d4fecee51d588c
Author: Roman Zippel
Date: Mon Feb 11 21:13:47 2008 +0100
kconfig: fix select in combination with default
> The attached .config (with current -git) results in a compile
> error since it contains:
>
> CONFIG_X86=y
> # CONFIG_EMBEDDED is not set
> CONFIG_SERIO=m
> CONFIG_SERIO_I8042=y
>
> Looking at drivers/input/serio/Kconfig I simply don't get how this
> can happen.
You've hit the rather subtle rules of select vs default. What happened is
that SERIO is selected to m, but SERIO_I8042 isn't selected so the default
of y is used instead.
We already had the problem in the past that select and default don't work
well together, so this patch cleans this up and makes the rule hopefully
more straightforward. Basically now the value is calculated like this:
(value && dependency) || select
where the value is the user choice (if available and the symbol is
visible) or default.
In this case it means SERIO and SERIO_I8042 are both set to y due to their
default and if SERIO didn't had the default, then the SERIO_I8042 value
would be limited to m due to the dependency.
I tested this patch with more 1 random configs and above case is the
only the difference that showed up, so I hope there is nothing that
depended on the old more complex and subtle rules.
Signed-off-by: Roman Zippel
Tested-by: Adrian Bunk
Signed-off-by: Sam Ravnborg
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 3929e5b..4a03191 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -298,22 +298,30 @@ void sym_calc_value(struct symbol *sym)
if (sym_is_choice_value(sym) && sym->visible == yes) {
prop = sym_get_choice_prop(sym);
newval.tri = (prop_get_symbol(prop)->curr.val == sym) ?
yes : no;
- } else if (EXPR_OR(sym->visible, sym->rev_dep.tri) != no) {
- sym->flags |= SYMBOL_WRITE;
- if (sym_has_value(sym))
- newval.tri = sym->def[S_DEF_USER].tri;
- else if (!sym_is_choice(sym)) {
- prop = sym_get_default_prop(sym);
- if (prop)
- newval.tri =
expr_calc_value(prop->expr);
+ } else {
+ if (sym->visible != no) {
+ /* if the symbol is visible use the user value
+* if available, otherwise try the default value
+*/
+ sym->flags |= SYMBOL_WRITE;
+ if (sym_has_value(sym)) {
+ newval.tri =
EXPR_AND(sym->def[S_DEF_USER].tri,
+ sym->visible);
+ goto calc_newval;
+ }
}
- newval.tr
Re: Any supported Dual DVB-S cards?
Hi Steve! Am Dienstag, den 10.02.2009, 23:20 +1300 schrieb Steven Ellis: > Daniel Pocock wrote: > > Steven Ellis wrote: > >> Noticed that Pinnacle now do a dual tuner PCI based DVB-S card > >> > >> http://www.pinnaclesys.com/PublicSite/uk/Products/Consumer+Products/PCTV+Tuners/PCTV+Digital+PVR+(DVB-S_DVB-T)/PCTV+Dual+Sat+Pro+PCI.htm > >> > >> > >> And that development is underway. Has anyone found a dual tuner card > >> that works? > >> > > Is it possible to use multiple USB devices to do the same thing as a > > dual tuner card? > The problem is I want to house the tuners inside of a media PC case > which is harder with USB devices. > > Also I have spare PCIe slots if there was a dual tuner PCIe unit at a > reasonable price. > > Steve > Same here :) Just for completeness, we support a device on saa7134 with dual DVB-S tuners and demods and also with dual DVB-T/analog hybrid tuners and DVB-T demods and external video inputs. (4 streams at once are always possible) It is card=96 Medion8800 Quad(ro), better called Creatix CTX944 (www.creatix.de). It has also two saa7131e, which causes that it needs at least a blue multi busmaster capable PCI slot, often found on MSI mobos. Within a green one it also offers a soft modem ... Everything works, except the second DVB-S tuner needs the first one active too at the same time, this is caused by the shared dual isl6405 LNB controller, which has only i2c access from the first PCI bridge. Long story short, that second LNB supply should be initialized at 13 Volts, the buffers sent are correct, but stays always at 18 Volts. This is the same for recent Philips/NXP/m$ drivers and ours for my observations. OTOH, also tuner RF loopthrough from the first DVB-S tuner to the second is enabled, which allows also 13 Volts transponder reception on the second. There is some small signal quality loss then, which is not the case for routing the DVB-T RF through to the second tda9875ac1 for DVB-T. I know Aldi/Medion is/are selling in Australia since years and we had feed back for the early cardbus devices from there, but don't know about NZ. If it should happen that you have such a blue PCI slot and are still curious enough, I guess I can get one down to you from second hand markets. If you still have at least two normal PCI slots free and are thinking about a linux media machine for distribution currently, two LifeView Trio or better two Asus 3in1 might do it, but are still rather expensive. I can't tell if you can get some supported Creatix CTX948 triple out of them for better conditions, but maybe worth at try. 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: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009, Mauro Carvalho Chehab wrote:
> > I did some more testing and the bug disappears in kernel 2.6.25. Also, if I
> > just run 'make', then the .config file it produces is fine. I wonder if it
> > isn't a bug in menuconfig itself.
>
> It seems to be a bug at the Kbuild, fixed on Feb, 2008, on this changeset:
> commit 587c90616a5b44e6ccfac38e64d4fecee51d588c (attached).
>
> As explained, after the patch description, the value for the Kconfig var,
> after
> the patch, uses this formula:
>
> (value && dependency) || select
It's odd that the patch is for "fix select in combination with default",
yet there is no select used for CX88_DVB. I think what you've done with
CX88_MPEG is something that nothing else in has used before, which made use
of the behavior introduced by this patch in a new way.
> And there there's no select, the value of CONFIG_CX88_MPEG is determined by:
> ('y' && dependency)
>
> The most complex case is when we have CX88 defined as:
> CX88 = 'y'
>
> if both CX88_DVB and CX88_BLACKBIRD are defined as 'm' (or one of them is 'n'
> and the other is 'm'), then CX88_MPEG is defined as:
> CX88_MPEG = 'm'
>
> If one of CX88_DVB or CX88_BLACKBIRD is defined as 'y'; then we have:
> CX88_MPEG = 'y'
>
> If both are 'n', we have:
> CX88_MPEG = 'n'
>
> So, it seems that, after commit 587c90616a5b44e6ccfac38e64d4fecee51d588c,
> everything is working as expected. We just need to provide a hack at the
> out-of-tree build system for kernels that don't have this commit applied.
I still think using select is better. What Roman Zippel was talking about
was the mess with select and the tuner drivers. I agree that's a mess and
there are better ways to do it without using select. But the MPEG module
is like a library used by just DVB and BLACKBIRD. It seems like the ideal
case for using select.
--
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: KWorld ATSC 115 all static
Hi, Am Dienstag, den 10.02.2009, 04:19 -0200 schrieb Mauro Carvalho Chehab: > On Tue, 10 Feb 2009 04:14:03 +0100 > hermann pitton wrote: > > > > > Am Dienstag, den 10.02.2009, 00:35 -0200 schrieb Mauro Carvalho Chehab: > > > On Tue, 10 Feb 2009 02:31:00 +0100 > > > hermann pitton wrote: > > > > > > > > > Mauro, I know you are waiting for CityK, but I can report so far > > > > > > that I > > > > > > never did see that black screen going away by adjusting the > > > > > > controls and > > > > > > never had that black screen. > > > > > > > > > > > > Tvtime and xawtv were always working under my conditions so far. > > > > > > Good to know. > > > > > > > > > The very old troubles, like tda9887 not present after boot on my > > > > > > md7134 > > > > > > devices with FMD1216ME MK3 hybrid, and the even unrelated issue > > > > > > with the > > > > > > tda10046 not properly controlled anymore after suspend/resume, > > > > > > are unchanged on your current saa7134 attempt, but also no new > > > > > > issues > > > > > > visible so far. > > > > > > Ok, let's go by parts: > > > > > > 1) We need to know the sequence that enables tda9887 on md7134/fmd1216me, > > > in > > > order to fix it. If someone has fmd1216me, please write me in priv or > > > help us > > > to fix the code for it. > > > > > > 2) I bet that the issue with tda10046 is related to firmware loading. I > > > made > > > some tests with a TV @nyware cardbus device that has a tda10046 + > > > tda8290/tda8975. > > > > > > What happens is that this device supports two type of firmware loads. The > > > first > > > one requires an i2c eeprom with the firmware inside. The driver just > > > writes > > > 0x04 at register 0x07 and waits for some time. The hardware does the > > > firmware load. > > > > > > On the second mode, firmware bytes are transferred from the driver into > > > the tda10046 memory. > > > > > > At the tests I made here, on both modes, the i2c bus can't have any other > > > traffic during the firmware load. Otherwise, an invalid firmware will be > > > loaded > > > and tda10046 will hangup. > > > > > > I've started to implement some locks at saa7134 driver (on my saa7134 > > > experimental tree), but it is not finished yet. I didn't touch at the > > > sleep code yet. > > > > > > > > > > > > > > > > > > > BTW, just to remember. > > > > > > > > > > Tvtime with signal detection on shows a blue screen without signal. > > > > > With signal detection off, just good old snow. > > > > > > So, the tda9887 or the PLL are configured wrongly. > > > > > > > > The tda8275/75a shows a black screen without having lock, not even > > > > > snow, > > > > > if it should be related. > > > > > > > > Sorry, to add one more about "black" screens :) > > > > > > > > Without the tda9887 loaded, the FMD1216ME MK3 hybrid also shows a black > > > > screen, but it is slightly different from the fully black screen of the > > > > tda8275, which is in fact an overlay like the blue screen on tvtime. It > > > > has some white points visible and on some channels even _very_ decent > > > > ghosting of TV. > > > > > > Probably, tda9887 is configured for STD/M, instead of STD/BG. Fixing > > > tda9887 > > > will also fix this issue. > > > > > > > The status of the tda9885/6/7 on the TUV1236D is still not clear to me, > > > > until I see debug enabled on it for switching TV standards and just > > > > nothing ever changes. > > > > > > Sorry but I didn't understand what you're meaning with your > > > TUV1236D-based device. > > > > Just for that one for now, I'll try on the other subjects later. > > > > I don't have any TUV1236D based device, but CityK and maybe Michael on > > the Kworld _ATSC_ ! 110/15. > > > > >From the photo provided by CityK, there is clearly a 24pin Philips > > device within the IF section of this tuner, which I guess is a tda9885 > > NTSC only and nothing else. > > > > As mentioned before, they can be strapped on one pin to be NTSC > > (System-M) only without needing _any_ i2c programming according to the > > data sheets. > > > > With the reports so far, after years, either the tda9887 module is just > > fake loaded, even that fails, or nothing ever happens, or something > > happens on i2c we don't have clear. > > > > So I would like to see if there is ever valid i2c traffic to that > > tda988x device on that tuner or never... > > Maybe we don't need any extra programming for tda9885, but it won't hurt to > reprogram it to the right state. Mauro, for the record, it is about chapter 8.16 on page 13 in the current tda9885/6 datasheet and the voltage delay in that case on page 14. It is the same for tda9887. http://www.nxp.com/#/pip/pip=[pip=TDA9885_TDA9886_3]|pp=[t=pip,i=TDA9885_TDA9886_3] Here is a link to the early discussions by Curt and CityK. http://lists.zerezo.com/video4linux/msg09088.html This has also the link to the high resolution photograph of the open tuner. We see a video IF and sound IF SAW filter and can
Re: [linux-dvb] mt352 no more working after suspend to disk
Am Dienstag, den 10.02.2009, 15:11 +0100 schrieb Nico Sabbi: > On Tuesday 10 February 2009 13:39:09 Alex Betis wrote: > > On Tue, Feb 10, 2009 at 12:16 AM, hermann pitton > wrote: > > > Hi Nico, > > > > > > Am Montag, den 09.02.2009, 12:33 +0100 schrieb Nico Sabbi: > > > > Hi, > > > > if I suspend to disk and next resume I have to manually remove > > > > and reload my mt352 driver, otherwise it complains of a lot of > > > > i2c errors. > > > > > > > > My kernel is suse's 2.6.27. > > > > > > > > Is this problem fixed in recent kernels or in hg? > > > > > > > > Thanks, > > > > Nico > > > > > > don't know on what driver you report it, but since I know you > > > also have saa7134 driver devices, nobody claimed so far that dvb > > > is suspend/resume safe. > > > > > > I recently reported that people have to stay aware after resume, > > > that even without using any dvb app actually during suspend, > > > analog needs to be re-initialized first after that to get the > > > tda10046 in a proper state for DVB-T again, at least on hybrid > > > devices. Unshared DVB-S tuners and demods do stand this already. > > > (medion 8800quad, CTX948, Asus 3in1) > > > > > > You can suspend to RAM on analog for example with a running > > > tvtime and resume, but dma sound on saa7134-alsa is also not > > > handled yet. Analog sound works. > > > > > > That is the status as far I have it. > > > > > Hi Hermann, > the only card that gave me problems so was is my Airstar2 PCI card, > while my Lifeview Trio worked perfectly after resume Nico, Alex, thanks. Fine so far then without a running DVB-S app. That we don't get trouble with those maybe building high end linux media machines currently, status for me for the other reception methods is as announced above :) 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: KWorld ATSC 115 all static
On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote: > On Tue, 10 Feb 2009 06:07:51 -0600 > Jonathan Isom wrote: > > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to > > > confirm > > > that everything is fine on their side. This patch may also fix other > > > similar > > > troubles on a few devices that seem to need some i2c magic before probing > > > the > > > tuner. > > > > Just tried the latest hg and I can confirm that both an ATSC 110 and > > 115 work with tvtime > > and ATSC. > > > Jonathan, > > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 tree > (http://linuxtv.org/hg/~mchehab/saa7134)? > > In the first case, could you please confirm that it works fine also with the > saa7134 tree? I tried both trees with my ATSC 115. The v4l-dvb did not work. tvtime showed only a blue screen, presumably due to lack of a signal. The last commit in the tree was as follows: changeset: 10503:9cb19f080660 tag: tip parent: 10495:d76f0c9b75fd parent: 10502:b1d0225eeec4 user:Mauro Carvalho Chehab date:Tue Feb 10 05:26:05 2009 -0200 summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146 The saa7134 worked. MythTV eventually worked too, but I had to do the "unload/reload modules and run tvtime" procedure I reported earlier when I tried Hans' kworld tree. David -- David Engel da...@istwok.net -- 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: [REVIEW PATCH 11/14] OMAP34XXCAM: Add driver
Hello.
+static int omap34xxcam_open(struct inode *inode, struct file *file)
+{
+ if (atomic_inc_return(&vdev->users) == 1) {
+ isp_get();
+ if (omap34xxcam_slave_power_set(vdev, V4L2_POWER_ON,
+ OMAP34XXCAM_SLAVE_POWER_ALL))
+ goto out_slave_power_set_standby;
+ omap34xxcam_slave_power_set(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_SENSOR);
+ omap34xxcam_slave_power_suggest(
+ vdev, V4L2_POWER_STANDBY,
+ OMAP34XXCAM_SLAVE_POWER_LENS);
+ }
I'm wondering whether this V4L2_POWER_STANDBY operation for sensor
device is really necessary.
Because if that makes sensor device in standby mode, we do S_FMT and
bunch of V4L2 APIs while the camera module is in standby mode.
In most cases of "sensor + ISP" SOC camera modules, I2C command is not
working while the camera module is in standby mode.
Following the camera interface source code, sensor goes down to
standby mode until VIDIOC_STREAMON is called.
If this power up timing depends on sensor device, then I think we need
a conditional power on sequence.
As you defined slave devices as SENSOR, LENS, FLASH, then how about
making a new slave category like "ISP" for "sensor+ISP" SOC modules?
Then we could make slave devices with conditional cases.
Cheers.
Regards,
Nate
--
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: KWorld ATSC 115 all static
Hi, Am Dienstag, den 10.02.2009, 21:50 -0600 schrieb David Engel: > On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote: > > On Tue, 10 Feb 2009 06:07:51 -0600 > > Jonathan Isom wrote: > > > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab > > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to > > > > confirm > > > > that everything is fine on their side. This patch may also fix other > > > > similar > > > > troubles on a few devices that seem to need some i2c magic before > > > > probing the > > > > tuner. > > > > > > Just tried the latest hg and I can confirm that both an ATSC 110 and > > > 115 work with tvtime > > > and ATSC. > > > > > Jonathan, > > > > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 > > tree > > (http://linuxtv.org/hg/~mchehab/saa7134)? > > > > In the first case, could you please confirm that it works fine also with > > the saa7134 tree? > > I tried both trees with my ATSC 115. > > The v4l-dvb did not work. tvtime showed only a blue screen, > presumably due to lack of a signal. The last commit in the tree was > as follows: > > changeset: 10503:9cb19f080660 > tag: tip > parent: 10495:d76f0c9b75fd > parent: 10502:b1d0225eeec4 > user:Mauro Carvalho Chehab > date:Tue Feb 10 05:26:05 2009 -0200 > summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146 > > The saa7134 worked. MythTV eventually worked too, but I had to do the > "unload/reload modules and run tvtime" procedure I reported earlier > when I tried Hans' kworld tree. > > David guess that is why CityK reported already on that always with a _cold_ boot too, as discussed. Forget about mythtv on such testing. You likely will never catch a rabbit this way, but it is fine for to count them all after ... 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: KWorld ATSC 115 all static
On Tue, 10 Feb 2009 21:50:16 -0600 David Engel wrote: > On Tue, Feb 10, 2009 at 10:27:32AM -0200, Mauro Carvalho Chehab wrote: > > On Tue, 10 Feb 2009 06:07:51 -0600 > > Jonathan Isom wrote: > > > On Tue, Feb 10, 2009 at 12:15 AM, Mauro Carvalho Chehab > > > > Ah, ok. So, now, we just need CityK (or someone else with ATSC 115) to > > > > confirm > > > > that everything is fine on their side. This patch may also fix other > > > > similar > > > > troubles on a few devices that seem to need some i2c magic before > > > > probing the > > > > tuner. > > > > > > Just tried the latest hg and I can confirm that both an ATSC 110 and > > > 115 work with tvtime > > > and ATSC. > > > > > Jonathan, > > > > You tried the latest tree at http://linuxtv.org/hg/v4l-dvb or my saa7134 > > tree > > (http://linuxtv.org/hg/~mchehab/saa7134)? > > > > In the first case, could you please confirm that it works fine also with > > the saa7134 tree? > > I tried both trees with my ATSC 115. > > The v4l-dvb did not work. tvtime showed only a blue screen, > presumably due to lack of a signal. The last commit in the tree was > as follows: > > changeset: 10503:9cb19f080660 > tag: tip > parent: 10495:d76f0c9b75fd > parent: 10502:b1d0225eeec4 > user:Mauro Carvalho Chehab > date:Tue Feb 10 05:26:05 2009 -0200 > summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-saa7146 > > The saa7134 worked. Ok. I've merged from saa7134 tree. This is the patch that changed the open gate for ATSC115 (and other saa7134 devices whose i2c gate open sequences are known): changeset: 10507:ec84c420abdd user:Mauro Carvalho Chehab date:Sun Feb 08 10:33:15 2009 -0200 summary: saa7134: Fix analog mode on devices that need to open an i2c gate > MythTV eventually worked too, but I had to do the > "unload/reload modules and run tvtime" procedure I reported earlier > when I tried Hans' kworld tree. Maybe this is a race condition I have here with tda1004x. With tda1004x, the i2c bus shouldn't be used by any other device during the firmware transfers, otherwise the firmware load will fail, and tda1004x goes into an unstable state. With this device, it even affects all subsequent i2c acesses. The only alternative to recover tda1004x is to reboot the card (e. g. with my cardbus device, I have to physically remove it and re-insert). What happens is that some softwares (including udev) open the device, and send some VIDIOC_G_TUNER in order to check some tuner characteristics. However, this command generates some i2c transfers, to retrieve signal strength. If this happens while the firmware is being loaded, the bug occurs. In order to fix, a careful review of all locks on the driver is needed. We will likely need to change the demod interface for the boards that have this trouble, in order to be aware of when a firmware transfer started. This lock review is currently on my TODO list. To be sure that this is the case, could you please add this on your /etc/modprobe (or at a file inside /etc/modprobe.d): options nxt200x debug=1 options tuner-simple debug=1 options tuner debug=1 options dvb-core frontend_debug=1 And test again, sending us the produced logs when the device works and when it breaks. I guess we'll discover some tuner dmesg's in the middle of the firmware load sequence. As a reference, this is the logs for the race condition with tda1004x: DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: found firmware revision ff -- invalid tda1004x: trying to boot from eeprom tda829x 1-004b: tda8290 is locked, AGC: 241 tda829x 1-004b: adjust gain, step 1. Agc: 241, ADC stat: 108, lock: 128 tda829x 1-004b: setting tda829x to system B tda827x: setting tda827x to system B tda827x: AGC2 gain is: 1 tda829x 1-004b: tda8290 not locked, no signal? tda829x 1-004b: tda8290 not locked, no signal? tda829x 1-004b: tda8290 not locked, no signal? tda829x 1-004b: adjust gain, step 1. Agc: 236, ADC stat: 0, lock: 0 tda829x 1-004b: adjust gain, step 2. Agc: 128, lock: 0 tda829x 1-004b: adjust gain, step 3. Agc: 128 tda829x 1-004b: setting tda829x to system B tda829x 1-004b: setting tda829x to system B tda1004x: found firmware revision ff -- invalid The firmware load stops at the last message. Notice that, during the firmware transfer, the tuner status were checked. This generated a breakage at the i2c transfer. Maybe we'll need a sort of locking between tuner and demod i2c access to avoid such troubles. 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: cx8802.ko module not being built with current HG tree
On Tue, 10 Feb 2009 17:20:52 -0800 (PST)
Trent Piepho wrote:
> On Tue, 10 Feb 2009, Mauro Carvalho Chehab wrote:
> > > I did some more testing and the bug disappears in kernel 2.6.25. Also, if
> > > I
> > > just run 'make', then the .config file it produces is fine. I wonder if it
> > > isn't a bug in menuconfig itself.
> >
> > It seems to be a bug at the Kbuild, fixed on Feb, 2008, on this changeset:
> > commit 587c90616a5b44e6ccfac38e64d4fecee51d588c (attached).
> >
> > As explained, after the patch description, the value for the Kconfig var,
> > after
> > the patch, uses this formula:
> >
> > (value && dependency) || select
>
> It's odd that the patch is for "fix select in combination with default",
> yet there is no select used for CX88_DVB.
If you look at the patch code, it fixed the handling for non-visible Kconfig
vars.
> I think what you've done with CX88_MPEG is something that nothing else in has
> used before, which made use
> of the behavior introduced by this patch in a new way.
>
> > And there there's no select, the value of CONFIG_CX88_MPEG is determined by:
> > ('y' && dependency)
> >
> > The most complex case is when we have CX88 defined as:
> > CX88 = 'y'
> >
> > if both CX88_DVB and CX88_BLACKBIRD are defined as 'm' (or one of them is
> > 'n'
> > and the other is 'm'), then CX88_MPEG is defined as:
> > CX88_MPEG = 'm'
> >
> > If one of CX88_DVB or CX88_BLACKBIRD is defined as 'y'; then we have:
> > CX88_MPEG = 'y'
> >
> > If both are 'n', we have:
> > CX88_MPEG = 'n'
> >
> > So, it seems that, after commit 587c90616a5b44e6ccfac38e64d4fecee51d588c,
> > everything is working as expected. We just need to provide a hack at the
> > out-of-tree build system for kernels that don't have this commit applied.
>
> I still think using select is better. What Roman Zippel was talking about
> was the mess with select and the tuner drivers. I agree that's a mess and
> there are better ways to do it without using select. But the MPEG module
> is like a library used by just DVB and BLACKBIRD. It seems like the ideal
> case for using select.
I can't foresee any case where this logic would fail in the future.
Let's suppose that some newer dependencies would be needed. If those
dependencies will be properly added at DVB and/or at BLACKBIRD, this logic will
still work. There's no possible case where CX88_MPEG would need a dependency
that aren't needed by either DVB and/or BLACKBIRD. Also, by using depends on,
instead of select, will warrant that CX88_MPEG will have the proper 'y' or 'm'
value, depending on the dependencies of CX88_DVB and CX88_BLACKBIRD.
It seems that this is exactly what Roman expected to be fixed by changing from
"select" to "depends on" with tuners.
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
