hauppauge hvr 1400
hello any news about getting analog working with this car ? regards -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC Support?
U. Artie Eoff wrote: > I recently purchased a ASUS My Cinema-PHC3-100/NAQ/FM/AV/RC ATSC tv tuner > card. I've done some searching to see what kind of support is available for > using it under Linux. There is nothing out there that mentions it will work > or how to get it to work. And it does not appear that my Fedora OS detects > it installed. Could someone start me off with some steps on getting it > configured (i.e. drivers, detecting, loading, configuring, etc.). I > consider myself a somewhat advanced user of Linux, but have never done any > direct work with tuner cards or general low-level hardware configuration > under Linux. So, don't hesitate to explain in technical terms if it is > easier. > suscipio lackius -- a technical term, derived from Coyote and Road Runner Latin, which literally translates into "support lacking" or, from a contemporary perspective, "not supported". Sorry. Hopefully the humour eased the pain. > Anyway, here is the product link for my card: > http://www.asus.com/products.aspx?l1=18&l2=83&l3=794 > ...and product image: > http://www.asus.com/prog_content/middle_enlargement.aspx?model=2524 > >From your provided link, it is apparent that this is another variation of the ViXS Puretv reference design(s). Up to this point, in PCI flavour, I had only seen a half height card design. Examples: - Vista View Saber DA-1N1-I (http://www.vistaview.tv/saber-da-1n1-i.html) - Samsung Combo-210 (http://www.geeks.com/details.asp?invtid=COMBO-210-BULK&cat=VID) - ViXS PureTV-U 48A3 ( http://www.linuxtv.org/wiki/index.php/ViXS_PureTV-U_48A3) As I've seen a couple of other PureTV-U model numbers listed (without actually having seen the cards), it is likely that your full height PCI card is the equivalent of one of them. I would go a step further and call your card pretty much a PCI hybrid of the Samsung type PCIe design; have a look at: - Vista View Saber DA-1N1-E (http://www.vistaview.tv/content/view/51/116/) - Samsung Combo-210E (http://tekgems.com/Products/et-46138-vid-combo-210e-bulk.htm) Note that with the Vista View PCIe card, it looks like the LG demod is on the front face. (In the half height PCI design, the LG demod is on the back side of the card). In the Samsung PCIe card, there is a much smaller chip in the spot where the LG demod resides on the Vista View PCIe version. Similarly, your card also appears to copy the Samsung layout/componentrywith the minor exceptions related to the difference in interface I suggest contacting ViXS and inquire as to whether they intend to provide Linux support for their chip; there is some evidence that suggests that they may very well be interested (http://www.vixs.com/sections/careers/job_software_driver_engineer.htm). Other then that, I suspect that the other components used by the card already have driver support, or are presently being worked upon (i.e. saa7136) in conjunction for other projects. Once those individual items are all supported, device level support would certainly be feasible to obtain. -- 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] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
On Fri, 27 Feb 2009 19:49:56 +0100 (CET) "Hans Verkuil" wrote: > (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: > > linux-2.6.16.61-i686: ERRORS > linux-2.6.17.14-i686: ERRORS > linux-2.6.18.8-i686: ERRORS > linux-2.6.19.5-i686: ERRORS > linux-2.6.20.21-i686: ERRORS > linux-2.6.21.7-i686: ERRORS > linux-2.6.22.19-i686: ERRORS > linux-2.6.23.12-i686: ERRORS > linux-2.6.24.7-i686: ERRORS > linux-2.6.25.11-i686: ERRORS > linux-2.6.26-i686: ERRORS > linux-2.6.27-i686: ERRORS > linux-2.6.28-i686: ERRORS > linux-2.6.29-rc5-i686: ERRORS Wow! Lots of errors! Ok, I've removed tvmixer and marked the minimal version for firedtv. This should fix the issues. 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: [linux-dvb] GDI Black Gold [14c7:0108] cx88 based DVB-T card
Hi Tim,
Am Freitag, den 27.02.2009, 11:28 + schrieb Tim Small:
> Hello,
>
> I'm interested in getting this card working under Linux as well, it's
> labelled GDI2500PCTV on the back, and has a Conexant CX23881 visible on
> the front, with a Philips "TU1216/1 H P" RF box... Looks like there may
> be some more ICs under the metal box, but I'd have to desolder it to
> check what they were (which I can do if necessary).
>
> According to the preliminary datasheet which I found, the TU1216
> contains a TDA 10046 Channel Decoder, and a TDA6651 Mixer/Oscillator.
>
> There seems to be TU1216 support in both v4l/saa7134-dvb.c and
> v4l/budget-av.c (code cut-n-paste by the look of it), but I can't see a
> way to select this tuner with the cx88xx module (e.g. CARDLIST.tuner),
> unless it's called something different, or is compatible with another
> Philips tuner.
since there is no analog TV tuning support you use TUNER_ABSENT in
cx88-cards.c like SAA7134_BOARD_VIDEOMATE_DVBT_200 and
SAA7134_BOARD_PHILIPS_TOUGH do in saa7134-cards.c accordingly.
> So... I'm game for trying to get this working, and have a bit of kernel
> programming experience, but is there anything else I'm likely to need to
> know before I set out on this?
You then need to implement the functions they call in saa7134-dvb.c
accordingly to cx88-dvb.c and find out if the tuner address is 0x60 or
0x61.
case SAA7134_BOARD_PHILIPS_TOUGH:
fe0->dvb.frontend = dvb_attach(tda10046_attach,
&philips_tu1216_60_config,
&dev->i2c_adap);
if (fe0->dvb.frontend) {
fe0->dvb.frontend->ops.tuner_ops.init =
philips_tu1216_init;
fe0->dvb.frontend->ops.tuner_ops.set_params =
philips_tda6651_pll_set;
}
For testing, on a first look, you need to introduce the tda10046
including firmware upload #include "tda1004x.h" and at least adapt these
functions to cx88-dvb.
/* ==
* tda1004x based DVB-T cards, helper functions
*/
static int philips_tda1004x_request_firmware(struct dvb_frontend *fe,
const struct firmware **fw, char
*name)
{
struct saa7134_dev *dev = fe->dvb->priv;
return request_firmware(fw, name, &dev->pci->dev);
}
/* --
* these tuners are tu1216, td1316(a)
*/
static int philips_tda6651_pll_set(struct dvb_frontend *fe, struct
dvb_frontend_parameters *params)
{
struct saa7134_dev *dev = fe->dvb->priv;
struct tda1004x_state *state = fe->demodulator_priv;
u8 addr = state->config->tuner_address;
u8 tuner_buf[4];
struct i2c_msg tuner_msg = {.addr = addr,.flags = 0,.buf =
tuner_buf,.len =
sizeof(tuner_buf) };
int tuner_frequency = 0;
u8 band, cp, filter;
/* determine charge pump */
tuner_frequency = params->frequency + 36166000;
if (tuner_frequency < 8700)
return -EINVAL;
else if (tuner_frequency < 13000)
cp = 3;
else if (tuner_frequency < 16000)
cp = 5;
else if (tuner_frequency < 2)
cp = 6;
else if (tuner_frequency < 29000)
cp = 3;
else if (tuner_frequency < 42000)
cp = 5;
else if (tuner_frequency < 48000)
cp = 6;
else if (tuner_frequency < 62000)
cp = 3;
else if (tuner_frequency < 83000)
cp = 5;
else if (tuner_frequency < 89500)
cp = 7;
else
return -EINVAL;
/* determine band */
if (params->frequency < 4900)
return -EINVAL;
else if (params->frequency < 16100)
band = 1;
else if (params->frequency < 44400)
band = 2;
else if (params->frequency < 86100)
band = 4;
else
return -EINVAL;
/* setup PLL filter */
switch (params->u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
filter = 0;
break;
case BANDWIDTH_7_MHZ:
filter = 0;
break;
case BANDWIDTH_8_MHZ:
filter = 1;
break;
default:
return -EINVAL;
}
/* calculate divisor
* ((36166000+((100/6)/2)) + Finput)/(100/6)
*/
tuner_frequency = (((params->frequency / 1000) * 6) + 217496) / 1000;
/* setup tuner buffer */
tuner_buf[0] = (tuner_frequency >> 8) & 0x7f;
tuner_buf[1] = tuner_frequency & 0xff;
tuner_buf[2] = 0xca;
tuner_buf[3] = (cp << 5) | (filter <<
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
Hans Verkuil a écrit : > On Thursday 26 February 2009 20:28:06 Mauro Carvalho Chehab wrote: >> On Sat, 21 Feb 2009 22:17:10 +0100 >> >> Hans Verkuil wrote: >>> Hi Mauro, >>> >>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision >>> for the following: >>> >>> - v4l2-common: add v4l2_i2c_subdev_addr() >>> - usbvision: convert to v4l2_device/v4l2_subdev. >> Thierry/Dwaine, >> >> Could you please check if everything is ok with usbvision after those >> patches? > > Just for the record, I did test it on my pinnacle. Sorry, I should have > mentioned it. But it's of course always good to have more testing done. > It is OK; already merged but here is my ack for this patch: Acked-by: Thierry Merle Cheers, Thierry -- 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] Fwd: HVR2250 Status - Where am I?
Devin Heitmueller wrote: On Fri, Feb 27, 2009 at 1:38 PM, John Drescher wrote: So now (with my donation) we have him working at $1/hour assuming that it takes only 100 hours.. Well, this assumes that it would only take 100 hours, of which given the complexity of the device, it will probably take more than twice that (since it's a PCI device and the estimates I gave are for USB devices). If nothing else, it offers some insight as to how valuable the work of people like Steven is (he has written a whole bunch of different drivers). It also demonstrates one reason there are so few developers willing to do this sort of work. Getting a developer to donate a couple of evening's worth of time is pretty easy. Getting them to make a commitment of every day for the next two to three months is quite harder. It takes a massive amount of time from all of the core developers to keep the v4l-dvb tree up to date and to add new functionality. Adding a new style of board to an existing driver can take a couple of hours with testing. It's bread a butter maintenance task. However, adding a brand new bridge driver to the kernel can take 6 months just for the first release, and is then slowly improved over the next 12-24 months. It's a large task. - 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
Re: [PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
On 27 февраля 2009, "Igor M. Liplianin" wrote: > On Fri, 27 Feb 2009, Igor M. Liplianin wrote: > > 01/02: dm1105: not demuxing from interrupt context. > > http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6 > >faf0753950b > > I'm not sure if you considered this, but the default work queue is > multi-threaded with a kernel thread for each CPU. This means that if the > IRQ handler calls schedule_work() while your work function is running then > you can get a second copy running of your work function running at the same > time. It doesn't look like your work function uses atomit_t or locking, so > I'm guessing it's not safe to run concurrently. > > For the pluto2 patch, I created a single threaded work queue. This avoids > the concurrency problem and it's not like the demuxer can run in parallel > anyway. Having your own work queue also means that you don't have to worry > about latency from whatever other tasks might be in the default work queue. > > Also consider that the work function is queued mutliple times before it > runs, it will only run once. I.e. queuing a work func that's already in > the queue does nothing (one the function starts to run, it's no longer in > the queue and can be added again before it's finished). The pluto2 patch I > posted didn't take this into account, but I've since fixed it. I'll return to this :) But it complicates things more and more :( -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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] Fwd: HVR2250 Status - Where am I?
On Fri, Feb 27, 2009 at 1:38 PM, John Drescher wrote: > So now (with my donation) we have him working at $1/hour assuming that > it takes only 100 hours.. Well, this assumes that it would only take 100 hours, of which given the complexity of the device, it will probably take more than twice that (since it's a PCI device and the estimates I gave are for USB devices). If nothing else, it offers some insight as to how valuable the work of people like Steven is (he has written a whole bunch of different drivers). It also demonstrates one reason there are so few developers willing to do this sort of work. Getting a developer to donate a couple of evening's worth of time is pretty easy. Getting them to make a commitment of every day for the next two to three months is quite harder. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] ERRORS: 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:Fri Feb 27 19:00:15 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10772:eae32c526e78 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-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29-rc5-i686: ERRORS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29-rc5-mips: ERRORS linux-2.6.27-powerpc64: ERRORS linux-2.6.28-powerpc64: ERRORS linux-2.6.29-rc5-powerpc64: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29-rc5-x86_64: ERRORS fw/apps: WARNINGS spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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: [linux-dvb] Fwd: HVR2250 Status - Where am I?
On Fri, Feb 27, 2009 at 1:34 PM, Devin Heitmueller wrote: > On Fri, Feb 27, 2009 at 1:27 PM, Andrew Barbaccia >> Sorry, maybe I phrased my request as a solution which is not what I >> intended. I was unaware of your agreements with NXP. I see you added how >> much money has been donated to your post. That's more than enough of a >> status indicator for me. >> Possibly could you roughly estimate how much more work is required and >> present it in the same manner? >> I want to you know that I do support this project and have just contributed >> - both as a thank you for your prior work and willingness to help the >> community in addition to the HVR-2250 support. > > Andrew, > > I cannot speak to the saa7164, but to give you an order of magnitude, > I spent over a month working on the saa7136 support, working every > night and weekend for 4-6 hours. The analog support I did for the > au0828/au8522 took about 100 hours. > > So, while not necessarily an apples-to-apples comparison, these > drivers tend to take tens or sometimes hundreds of hours of > development. They are definitely a non-trivial amount of work to do. > > Bear in mind that the saa7164 is a much more complicated chip than the > saa7136. > So now (with my donation) we have him working at $1/hour assuming that it takes only 100 hours.. John -- 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] Fwd: HVR2250 Status - Where am I?
On Fri, Feb 27, 2009 at 1:27 PM, Andrew Barbaccia > Sorry, maybe I phrased my request as a solution which is not what I > intended. I was unaware of your agreements with NXP. I see you added how > much money has been donated to your post. That's more than enough of a > status indicator for me. > Possibly could you roughly estimate how much more work is required and > present it in the same manner? > I want to you know that I do support this project and have just contributed > - both as a thank you for your prior work and willingness to help the > community in addition to the HVR-2250 support. Andrew, I cannot speak to the saa7164, but to give you an order of magnitude, I spent over a month working on the saa7136 support, working every night and weekend for 4-6 hours. The analog support I did for the au0828/au8522 took about 100 hours. So, while not necessarily an apples-to-apples comparison, these drivers tend to take tens or sometimes hundreds of hours of development. They are definitely a non-trivial amount of work to do. Bear in mind that the saa7164 is a much more complicated chip than the saa7136. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] Fwd: HVR2250 Status - Where am I?
John Drescher wrote: Any way to get a running total on your blog? I'm not against donating for hardware support but I would like to see the total (and it increase after I donate) and also the code tree published so others can contribute and track changes. I don't have anything that sophisticated to be honest. If that bothers you then I understand and respect your decision not to support the project. I can't publish any source code until the driver is largely complete, that's not my call, that's the arrangement with NXP. PS. Thanks for all your hard work on all the drivers - not just this one. It's greatly appreciated by the MythTV community among others and myself. I had specifically decided NOT to look at any HVR-2250 web stats for a week. I ran the numbers today and this is where I am: http://www.steventoth.net/blog/hvr-2250/ Well I just made that 5. Being a software developer myself, I know this will not go far but hopefully more people will see find the page and help out. Thanks John. Also BTW the other message was from Andrew Barbaccia who replied to me instead of the list so I just forwarded it.. Ahh, fair enough. Thanks again, 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
Re: [linux-dvb] Fwd: HVR2250 Status - Where am I?
> Any way to get a running total on your blog? >> >> I'm not against donating for hardware support but I would like to see >> the total (and it increase after I donate) and also the code tree >> published so others can contribute and track changes. > > I don't have anything that sophisticated to be honest. If that bothers you > then > I understand and respect your decision not to support the project. > > I can't publish any source code until the driver is largely complete, that's > not > my call, that's the arrangement with NXP. > > >> PS. Thanks for all your hard work on all the drivers - not just this >> one. It's greatly appreciated by the MythTV community among others and >> myself. > > I had specifically decided NOT to look at any HVR-2250 web stats for a week. I > ran the numbers today and this is where I am: > > http://www.steventoth.net/blog/hvr-2250/ > Well I just made that 5. Being a software developer myself, I know this will not go far but hopefully more people will see find the page and help out. Also BTW the other message was from Andrew Barbaccia who replied to me instead of the list so I just forwarded it.. John -- 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] Fwd: HVR2250 Status - Where am I?
John Drescher wrote: Any way to get a running total on your blog? I'm not against donating for hardware support but I would like to see the total (and it increase after I donate) and also the code tree published so others can contribute and track changes. I don't have anything that sophisticated to be honest. If that bothers you then I understand and respect your decision not to support the project. I can't publish any source code until the driver is largely complete, that's not my call, that's the arrangement with NXP. PS. Thanks for all your hard work on all the drivers - not just this one. It's greatly appreciated by the MythTV community among others and myself. I had specifically decided NOT to look at any HVR-2250 web stats for a week. I ran the numbers today and this is where I am: http://www.steventoth.net/blog/hvr-2250/ -- 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: Conversion of vino driver for SGI to not use the legacy decoder API
Hi there, On Fri, 27 Feb 2009 12:37:14 -0300 Mauro Carvalho Chehab wrote: > On Fri, 27 Feb 2009 10:50:57 -0300 > Douglas Schilling Landgraf wrote: > > > > Douglas, > > > > > > As you've done several radio conversions to V4L2 API, maybe you > > > can also handle this one. > > > > yes. > > Hmm... too late, I've just converted it ;) My Internet connection > dropped and I was without email access, so... Well, it is done. ooops, no problem. I was not so far away in my conversion branch. > I'll commit the changesets right now. Could you please help reviewing > it? I'll also forward it to -alsa people. Sure, reviewed. IMO, it's ok. Cheers, Douglas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] V4L: Int if: v4l2_int_device_try_attach_all requires mutex
From: Sakari Ailus
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-int-device.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-int-device.c
b/drivers/media/video/v4l2-int-device.c
index a935bae..eb8dc84 100644
--- a/drivers/media/video/v4l2-int-device.c
+++ b/drivers/media/video/v4l2-int-device.c
@@ -32,7 +32,7 @@
static DEFINE_MUTEX(mutex);
static LIST_HEAD(int_list);
-void v4l2_int_device_try_attach_all(void)
+static void __v4l2_int_device_try_attach_all(void)
{
struct v4l2_int_device *m, *s;
@@ -66,6 +66,14 @@ void v4l2_int_device_try_attach_all(void)
}
}
}
+
+void v4l2_int_device_try_attach_all(void)
+{
+ mutex_lock(&mutex);
+ __v4l2_int_device_try_attach_all();
+ mutex_unlock(&mutex);
+}
+
EXPORT_SYMBOL_GPL(v4l2_int_device_try_attach_all);
static int ioctl_sort_cmp(const void *a, const void *b)
@@ -89,7 +97,7 @@ int v4l2_int_device_register(struct v4l2_int_device *d)
&ioctl_sort_cmp, NULL);
mutex_lock(&mutex);
list_add(&d->head, &int_list);
- v4l2_int_device_try_attach_all();
+ __v4l2_int_device_try_attach_all();
mutex_unlock(&mutex);
return 0;
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] V4L: Int if: Add vidioc_int_querycap
From: Sakari Ailus
Signed-off-by: Sakari Ailus
---
include/media/v4l2-int-device.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 81f4863..2830ae1 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -173,7 +173,8 @@ enum v4l2_int_ioctl_num {
* "Proper" V4L ioctls, as in struct video_device.
*
*/
- vidioc_int_enum_fmt_cap_num = 1,
+ vidioc_int_querycap_num = 1,
+ vidioc_int_enum_fmt_cap_num,
vidioc_int_g_fmt_cap_num,
vidioc_int_s_fmt_cap_num,
vidioc_int_try_fmt_cap_num,
@@ -278,6 +279,7 @@ enum v4l2_int_ioctl_num {
return desc;\
}
+V4L2_INT_WRAPPER_1(querycap, struct v4l2_capability, *);
V4L2_INT_WRAPPER_1(enum_fmt_cap, struct v4l2_fmtdesc, *);
V4L2_INT_WRAPPER_1(g_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(s_fmt_cap, struct v4l2_format, *);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] V4L: int device: add support for VIDIOC_QUERYMENU
From: Sakari Ailus
Signed-off-by: Tuukka Toivonen
---
include/media/v4l2-int-device.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index 5d254c4..81f4863 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -178,6 +178,7 @@ enum v4l2_int_ioctl_num {
vidioc_int_s_fmt_cap_num,
vidioc_int_try_fmt_cap_num,
vidioc_int_queryctrl_num,
+ vidioc_int_querymenu_num,
vidioc_int_g_ctrl_num,
vidioc_int_s_ctrl_num,
vidioc_int_cropcap_num,
@@ -282,6 +283,7 @@ V4L2_INT_WRAPPER_1(g_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(s_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(try_fmt_cap, struct v4l2_format, *);
V4L2_INT_WRAPPER_1(queryctrl, struct v4l2_queryctrl, *);
+V4L2_INT_WRAPPER_1(querymenu, struct v4l2_querymenu, *);
V4L2_INT_WRAPPER_1(g_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(s_ctrl, struct v4l2_control, *);
V4L2_INT_WRAPPER_1(cropcap, struct v4l2_cropcap, *);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] V4L: Int if: Dummy slave
From: Sakari Ailus
This patch implements a dummy slave that has no functionality. Helps
managing slaves in the OMAP 3 camera driver; no need to check for NULL
pointers.
Signed-off-by: Sakari Ailus
---
drivers/media/video/v4l2-int-device.c | 19 +++
include/media/v4l2-int-device.h |2 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-int-device.c
b/drivers/media/video/v4l2-int-device.c
index eb8dc84..483ee2e 100644
--- a/drivers/media/video/v4l2-int-device.c
+++ b/drivers/media/video/v4l2-int-device.c
@@ -67,6 +67,25 @@ static void __v4l2_int_device_try_attach_all(void)
}
}
+static struct v4l2_int_slave dummy_slave = {
+ /* Dummy pointer to avoid underflow in find_ioctl. */
+ .ioctls = (void *)sizeof(struct v4l2_int_ioctl_desc),
+ .num_ioctls = 0,
+};
+
+static struct v4l2_int_device dummy = {
+ .type = v4l2_int_type_slave,
+ .u = {
+ .slave = &dummy_slave,
+ },
+};
+
+struct v4l2_int_device *v4l2_int_device_dummy()
+{
+ return &dummy;
+}
+EXPORT_SYMBOL_GPL(v4l2_int_device_dummy);
+
void v4l2_int_device_try_attach_all(void)
{
mutex_lock(&mutex);
diff --git a/include/media/v4l2-int-device.h b/include/media/v4l2-int-device.h
index fbf5855..5d254c4 100644
--- a/include/media/v4l2-int-device.h
+++ b/include/media/v4l2-int-device.h
@@ -84,6 +84,8 @@ struct v4l2_int_device {
void *priv;
};
+struct v4l2_int_device *v4l2_int_device_dummy(void);
+
void v4l2_int_device_try_attach_all(void);
int v4l2_int_device_register(struct v4l2_int_device *d);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] V4L patches for OMAP 3 camera and ISP drivers
Hello, Here's a small set of V4L int device patches to support the OMAP 3 camera. These patches are on top of linux-omap but can be applied to v4l-dvb, too. I'll post the corresponding OMAP 3 camera and ISP driver patches in near future. Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
On Fri, 27 Feb 2009 02:14:14 -0500 Michael Krufky wrote: > Mauro, > > Changeset 85a2b117175e creates the following build warning: > > WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsusb.ko] undefined! > WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsdvb.ko] undefined! > > Please pull the fix from: > > http://linuxtv.org/hg/~mkrufky/sms1xxx > > for the following: > > - Backed out changeset 85a2b117175e > - siano: prevent duplicate variable declaration Those patches should be folded, otherwise, they'll break bisect. I'll cherry-pick and fold both. 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: W.: v4l-dvb won't compile with new version
On Fri, 27 Feb 2009 14:41:20 +0100 Hans Verkuil wrote: > On Friday 27 February 2009 14:22:15 scholl...@arcor.de wrote: > > Hi there, > > > > this I get when trying to compile latest mercurial .tar.gz: > > > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In function > > 'tvmixer_ioctl': > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: error: storage > > size of 'va' isn't known > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: > > 'VIDIOCGAUDIO' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: (Each > > undeclared identifier is reported only once > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: for > > each function it appears in.) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:129: error: > > 'VIDEO_AUDIO_BASS' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:131: error: > > 'VIDEO_AUDIO_TREBLE' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:142: error: > > 'VIDEO_AUDIO_MUTE' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:143: error: > > 'VIDIOCSAUDIO' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:147: warning: type > > defaults to 'int' in declaration of '_min1' > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: type > > defaults to 'int' in declaration of '_min1' > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: > > comparison of distinct pointer types lacks a cast > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: warning: unused > > variable 'va' /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In > > function 'tvmixer_clients': > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: error: storage > > size of 'va' isn't known > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:286: error: > > 'VIDIOCGAUDIO' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:288: error: > > 'VIDEO_AUDIO_VOLUME' undeclared (first use in this function) > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: warning: > > unused variable 'va' make[3]: *** > > [/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.o] Error 1 make[2]: > > *** [_module_/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l] Error 2 > > make[2]: Leaving directory `/usr/src/linux-2.6.29-desktop-0.rc6.1.1mnb' > > make[1]: *** [default] Fehler 2 > > make[1]: Leaving directory `/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l' > > make: *** [all] Fehler 2 > > > > Any hints please? > > Run 'make menuconfig' and disable this driver (should be in 'Audio devices > for multimedia'). It's pointless for 2.6.29 anyway. > > Mauro, I suggest we drop this driver altogether from our tree. The > SOUND_TVMIXER config was removed from kernel 2.6.23 onwards (and the actual > source from 2.6.25 onwards), it uses oss instead of alsa, assumes v4l1 i2c > modules and it's never going to work with the new i2c API. > > I actually thought it was removed already... Yes, we should remove it from our tree. I'll write the patch removing the legacy OSS drivers from our tree. 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: Conversion of vino driver for SGI to not use the legacy decoder API
On Fri, 27 Feb 2009 10:50:57 -0300 Douglas Schilling Landgraf wrote: > > Douglas, > > > > As you've done several radio conversions to V4L2 API, maybe you can > > also handle this one. > > yes. Hmm... too late, I've just converted it ;) My Internet connection dropped and I was without email access, so... Well, it is done. I'll commit the changesets right now. Could you please help reviewing it? I'll also forward it to -alsa people. 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: Conversion of vino driver for SGI to not use the legacy decoder API
Hi Hans,
On Fri, 27 Feb 2009 13:12:10 +0100, Hans Verkuil wrote:
> Jean, if you are interested in doing this, then use my v4l-dvb-vino2 tree as
> the starting point. It would be nice to get it all done in one go.
Here you go. The patch below adds the i2c-algo-sgi code to vino. Then
we can delete i2c-algo-sgi altogether, but as this driver isn't part of
the v4l-dvb tree, this has to go through another route (likely my i2c
tree.)
==
Merge i2c-algo-sgi into its only user, vino. This is a very simple
copy-and-paste approach, although a number of further cleanups are
possible.
Signed-off-by: Jean Delvare
---
Note: totally untested!
linux/drivers/media/video/Kconfig |1
linux/drivers/media/video/vino.c | 169 ++---
2 files changed, 156 insertions(+), 14 deletions(-)
--- v4l-dvb-vino2.orig/linux/drivers/media/video/Kconfig2009-02-27
13:21:39.0 +0100
+++ v4l-dvb-vino2/linux/drivers/media/video/Kconfig 2009-02-27
13:46:55.0 +0100
@@ -582,7 +582,6 @@ config VIDEO_SAA5249
config VIDEO_VINO
tristate "SGI Vino Video For Linux (EXPERIMENTAL)"
depends on I2C && SGI_IP22 && EXPERIMENTAL && VIDEO_V4L2
- select I2C_ALGO_SGI
select VIDEO_SAA7191 if VIDEO_HELPER_CHIPS_AUTO
help
Say Y here to build in support for the Vino video input system found
--- v4l-dvb-vino2.orig/linux/drivers/media/video/vino.c 2009-02-27
13:21:40.0 +0100
+++ v4l-dvb-vino2/linux/drivers/media/video/vino.c 2009-02-27
14:56:52.0 +0100
@@ -33,7 +33,6 @@
#include
#include
-#include
#include
#include
@@ -141,6 +140,20 @@ MODULE_LICENSE("GPL");
#define VINO_DATA_NORM_COUNT 4
+/* I2C controller flags */
+#define SGI_I2C_FORCE_IDLE (0 << 0)
+#define SGI_I2C_NOT_IDLE (1 << 0)
+#define SGI_I2C_WRITE (0 << 1)
+#define SGI_I2C_READ (1 << 1)
+#define SGI_I2C_RELEASE_BUS(0 << 2)
+#define SGI_I2C_HOLD_BUS (1 << 2)
+#define SGI_I2C_XFER_DONE (0 << 4)
+#define SGI_I2C_XFER_BUSY (1 << 4)
+#define SGI_I2C_ACK(0 << 5)
+#define SGI_I2C_NACK (1 << 5)
+#define SGI_I2C_BUS_OK (0 << 7)
+#define SGI_I2C_BUS_ERR(1 << 7)
+
/* Internal data structure definitions */
struct vino_input {
@@ -640,6 +653,17 @@ struct v4l2_queryctrl vino_saa7191_v4l2_
/* VINO I2C bus functions */
+struct i2c_algo_sgi_data {
+ void *data; /* private data for lowlevel routines */
+ unsigned (*getctrl)(void *data);
+ void (*setctrl)(void *data, unsigned val);
+ unsigned (*rdata)(void *data);
+ void (*wdata)(void *data, unsigned val);
+
+ int xfer_timeout;
+ int ack_timeout;
+};
+
unsigned i2c_vino_getctrl(void *data)
{
return vino->i2c_control;
@@ -670,6 +694,134 @@ static struct i2c_algo_sgi_data i2c_sgi_
.ack_timeout = 1000,
};
+static int wait_xfer_done(struct i2c_algo_sgi_data *adap)
+{
+ int i;
+
+ for (i = 0; i < adap->xfer_timeout; i++) {
+ if ((adap->getctrl(adap->data) & SGI_I2C_XFER_BUSY) == 0)
+ return 0;
+ udelay(1);
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int wait_ack(struct i2c_algo_sgi_data *adap)
+{
+ int i;
+
+ if (wait_xfer_done(adap))
+ return -ETIMEDOUT;
+ for (i = 0; i < adap->ack_timeout; i++) {
+ if ((adap->getctrl(adap->data) & SGI_I2C_NACK) == 0)
+ return 0;
+ udelay(1);
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int force_idle(struct i2c_algo_sgi_data *adap)
+{
+ int i;
+
+ adap->setctrl(adap->data, SGI_I2C_FORCE_IDLE);
+ for (i = 0; i < adap->xfer_timeout; i++) {
+ if ((adap->getctrl(adap->data) & SGI_I2C_NOT_IDLE) == 0)
+ goto out;
+ udelay(1);
+ }
+ return -ETIMEDOUT;
+out:
+ if (adap->getctrl(adap->data) & SGI_I2C_BUS_ERR)
+ return -EIO;
+ return 0;
+}
+
+static int do_address(struct i2c_algo_sgi_data *adap, unsigned int addr,
+ int rd)
+{
+ if (rd)
+ adap->setctrl(adap->data, SGI_I2C_NOT_IDLE);
+ /* Check if bus is idle, eventually force it to do so */
+ if (adap->getctrl(adap->data) & SGI_I2C_NOT_IDLE)
+ if (force_idle(adap))
+ return -EIO;
+ /* Write out the i2c chip address and specify operation */
+ adap->setctrl(adap->data,
+ SGI_I2C_HOLD_BUS | SGI_I2C_WRITE | SGI_I2C_NOT_IDLE);
+ if (rd)
+ addr |= 1;
+ adap->wdata(adap->data, addr);
+ if (wait_ack(adap))
+ return -EIO;
+ return 0;
+}
+
+static int i2c_read(struct i2c_algo_sgi_data *adap, unsigned char *buf,
+ unsigned int
Re: Conversion of vino driver for SGI to not use the legacy decoder API
Hello there, On Fri, 27 Feb 2009 08:22:16 -0300 Mauro Carvalho Chehab wrote: > On Fri, 27 Feb 2009 10:09:47 +0100 > Jean Delvare wrote: > > > Hi Hans, > > > > On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote: > > > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote: > > > > After the conversion of Zoran driver to V4L2, now almost all > > > > drivers are using the new API. However, there are is one > > > > remaining driver using the video_decoder.h API (based on V4L1 > > > > API) for message exchange between the bridge driver and the i2c > > > > sensor: the vino driver. > > > > > > > > This driver adds support for the Indy webcam and for a capture > > > > hardware on SGI. Does someone have those hardware? If so, are > > > > you interested on helping to convert those drivers to fully use > > > > V4L2 API? > > > > > > > > The SGI driver is located at: > > > > drivers/media/video/vino.c > > > > > > > > Due to vino, those two drivers are also using the old API: > > > > drivers/media/video/indycam.c > > > > drivers/media/video/saa7191.c > > > > > > > > It shouldn't be hard to convert those files to use the proper > > > > APIs, but AFAIK none of the current active developers has any > > > > hardware for testing it. > > > > > > The conversion has already been done in my v4l-dvb-vino tree. > > Great! Do you have any other tree converting drivers from V4L1 to > V4L2 API? Btw, we should update the dependencies for the converted > drivers. They are still dependent of V4L1: > > config VIDEO_BT819 > tristate "BT819A VideoStream decoder" > depends on VIDEO_V4L1 && I2C > > I'll do such update probably later today. I want to have an overall > picture on what's still left. > > > > I'm trying to > > > convince the original vino author to boot up his Indy and test > > > it, but he is not very interested in doing that. I'll ask him a > > > few more times, but we may have to just merge my code untested. > > > Or perhaps just drop it. > > Well, let's merge the code. Maybe someone at the ML could have an > Indy and can test it. > > I think that the risk of breaking vino is not big, since this > conversion is more like a variable renaming. Also, after applying > those changes at linux-next, more people can test its code. Maybe we > can add some printk's asking for testers to contact us at LMML. > > I would love to finally remove another V4L1 header (video_decoder.h). > > > > Jean, I remember you mentioning that you wouldn't mind if the > > > i2c-algo-sgi code could be dropped which is only used by vino. > > > How important is that to you? Perhaps we are flogging a dead > > > horse here and we should just let this driver die. > > > > My rant was based on the fact that i2c-algo-sgi is totally > > SGI-specific while i2c-algo-* modules are supposed to be generic > > abstractions that can be reused by a variety of hardware. So > > i2c-algo-sgi should really be merged into > > drivers/media/video/vino.c. But as it takes a SGI system to > > build-test such a change, and I don't have one, I am reluctant to > > do it. If we can find a tester for your V4L2 conversion then maybe > > the same tester will be able to test my own changes. > > > > But i2c-algo-sgi isn't a big problem per se, it doesn't block > > further evolutions or anything like that, so if we can't find a > > tester and it has to stay for a few more years, this really isn't a > > problem for me. > > If the merger of i2c-algo-sgi is as not something complex, then we > can try to merge and apply at vino. Otherwise, we can just keep as-is. > > PS.: probably you haven't noticed, but tea575x-tuner.c is still V4L1 > (one of your patches changed the header improperly, breaking sound > build). > > Douglas, > > As you've done several radio conversions to V4L2 API, maybe you can > also handle this one. yes. Cheers, Douglas -- 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: W.: v4l-dvb won't compile with new version
On Friday 27 February 2009 14:22:15 scholl...@arcor.de wrote: > Hi there, > > this I get when trying to compile latest mercurial .tar.gz: > > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In function > 'tvmixer_ioctl': > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: error: storage > size of 'va' isn't known > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: > 'VIDIOCGAUDIO' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: (Each > undeclared identifier is reported only once > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: for > each function it appears in.) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:129: error: > 'VIDEO_AUDIO_BASS' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:131: error: > 'VIDEO_AUDIO_TREBLE' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:142: error: > 'VIDEO_AUDIO_MUTE' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:143: error: > 'VIDIOCSAUDIO' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:147: warning: type > defaults to 'int' in declaration of '_min1' > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: type > defaults to 'int' in declaration of '_min1' > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: > comparison of distinct pointer types lacks a cast > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: warning: unused > variable 'va' /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In > function 'tvmixer_clients': > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: error: storage > size of 'va' isn't known > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:286: error: > 'VIDIOCGAUDIO' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:288: error: > 'VIDEO_AUDIO_VOLUME' undeclared (first use in this function) > /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: warning: > unused variable 'va' make[3]: *** > [/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.o] Error 1 make[2]: > *** [_module_/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.6.29-desktop-0.rc6.1.1mnb' > make[1]: *** [default] Fehler 2 > make[1]: Leaving directory `/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l' > make: *** [all] Fehler 2 > > Any hints please? Run 'make menuconfig' and disable this driver (should be in 'Audio devices for multimedia'). It's pointless for 2.6.29 anyway. Mauro, I suggest we drop this driver altogether from our tree. The SOUND_TVMIXER config was removed from kernel 2.6.23 onwards (and the actual source from 2.6.25 onwards), it uses oss instead of alsa, assumes v4l1 i2c modules and it's never going to work with the new i2c API. I actually thought it was removed already... Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Status of the go7007 driver
Hi Mauro, Just FYI, I also have a tree that merges the go7007 driver from the staging area into v4l-dvb: http://linuxtv.org/hg/~hverkuil/v4l-dvb-go7007/ This driver uses i2c modules and is not converted to v4l2_subdev. Since it is a staging driver I have also no plans right now to do that conversion, although I might revisit it in the future since I do have a go7007 device to test with. If you are interested in getting it merged anyway, then I can make a pull request for it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
W.: v4l-dvb won't compile with new version
Hi there, this I get when trying to compile latest mercurial .tar.gz: /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In function 'tvmixer_ioctl': /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: error: storage size of 'va' isn't known /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: 'VIDIOCGAUDIO' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: (Each undeclared identifier is reported only once /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:114: error: for each function it appears in.) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:129: error: 'VIDEO_AUDIO_BASS' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:131: error: 'VIDEO_AUDIO_TREBLE' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:142: error: 'VIDEO_AUDIO_MUTE' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:143: error: 'VIDIOCSAUDIO' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:147: warning: type defaults to 'int' in declaration of '_min1' /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: type defaults to 'int' in declaration of '_min1' /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:149: warning: comparison of distinct pointer types lacks a cast /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:78: warning: unused variable 'va' /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c: In function 'tvmixer_clients': /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: error: storage size of 'va' isn't known /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:286: error: 'VIDIOCGAUDIO' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:288: error: 'VIDEO_AUDIO_VOLUME' undeclared (first use in this function) /home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.c:254: warning: unused variable 'va' make[3]: *** [/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l/tvmixer.o] Error 1 make[2]: *** [_module_/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.29-desktop-0.rc6.1.1mnb' make[1]: *** [default] Fehler 2 make[1]: Leaving directory `/home/stefan/Linux/v4l-dvb-60389ff5e931/v4l' make: *** [all] Fehler 2 Any hints please? -- 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: Conversion of vino driver for SGI to not use the legacy decoder API
On Friday 27 February 2009 12:53:28 Hans Verkuil wrote: > On Friday 27 February 2009 12:22:16 Mauro Carvalho Chehab wrote: > > Well, let's merge the code. Maybe someone at the ML could have an Indy > > and can test it. > > > > I think that the risk of breaking vino is not big, since this > > conversion is more like a variable renaming. Also, after applying those > > changes at linux-next, more people can test its code. Maybe we can add > > some printk's asking for testers to contact us at LMML. > > > > I would love to finally remove another V4L1 header (video_decoder.h). > > OK, I'll send the pull request. This will be delayed until early next week. I think I may have forgotten to push some final changes to my vino tree but I won't have access to that PC until Sunday. > > > > Jean, I remember you mentioning that you wouldn't mind if the > > > > i2c-algo-sgi code could be dropped which is only used by vino. How > > > > important is that to you? Perhaps we are flogging a dead horse here > > > > and we should just let this driver die. > > > > > > My rant was based on the fact that i2c-algo-sgi is totally > > > SGI-specific while i2c-algo-* modules are supposed to be generic > > > abstractions that can be reused by a variety of hardware. So > > > i2c-algo-sgi should really be merged into drivers/media/video/vino.c. > > > But as it takes a SGI system to build-test such a change, and I don't > > > have one, I am reluctant to do it. If we can find a tester for your > > > V4L2 conversion then maybe the same tester will be able to test my > > > own changes. > > > > > > But i2c-algo-sgi isn't a big problem per se, it doesn't block further > > > evolutions or anything like that, so if we can't find a tester and it > > > has to stay for a few more years, this really isn't a problem for me. > > > > If the merger of i2c-algo-sgi is as not something complex, then we can > > try to merge and apply at vino. Otherwise, we can just keep as-is. Jean, if you are interested in doing this, then use my v4l-dvb-vino2 tree as the starting point. It would be nice to get it all done in one go. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] GDI Black Gold [14c7:0108] cx88 based DVB-T card
Hello, I'm interested in getting this card working under Linux as well, it's labelled GDI2500PCTV on the back, and has a Conexant CX23881 visible on the front, with a Philips "TU1216/1 H P" RF box... Looks like there may be some more ICs under the metal box, but I'd have to desolder it to check what they were (which I can do if necessary). According to the preliminary datasheet which I found, the TU1216 contains a TDA 10046 Channel Decoder, and a TDA6651 Mixer/Oscillator. There seems to be TU1216 support in both v4l/saa7134-dvb.c and v4l/budget-av.c (code cut-n-paste by the look of it), but I can't see a way to select this tuner with the cx88xx module (e.g. CARDLIST.tuner), unless it's called something different, or is compatible with another Philips tuner. So... I'm game for trying to get this working, and have a bit of kernel programming experience, but is there anything else I'm likely to need to know before I set out on this? Cheers! Tim. Richard Runds wrote: > Hi, > > Have a GDI Black Gold card with subsystem 14c7:0108 and I cannot make it > work. Does anyone on the list have a working config for this card and/or know > how to make this card work? > > I'm getting so far as video1 and vbi1 is created, but I don't have any > entries in /dev/dvb/. > > cat /dev/video1 > test.mpg produces a video typical of a tv picture without > signal (ant-war)... :) > > > config > > > /etc/modprobe.conf: > > alias char-major-81-1 cx88-dvb > options cx88xx card=2 i2c_scan=1 > > lspci -v: > > 02:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and > Audio Decoder (rev 05) > Subsystem: Modular Technology Holdings Ltd GDI Black Gold > Flags: bus master, medium devsel, latency 64, IRQ 23 > Memory at f500 (32-bit, non-prefetchable) [size=16M] > Capabilities: [44] Vital Product Data > Capabilities: [4c] Power Management version 2 > > 02:09.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio > Decoder [MPEG Port] (rev 05) > Subsystem: Modular Technology Holdings Ltd Unknown device 0108 > Flags: bus master, medium devsel, latency 64, IRQ 5 > Memory at f600 (32-bit, non-prefetchable) [size=16M] > Capabilities: [4c] Power Management version 2 > > dmesg: > > CORE cx88[0]: subsystem: 14c7:0108, board: GDI Black Gold [card=2,insmod > option] > TV tuner -1 at 0x1fe, Radio tuner -1 at 0x1fe > cx88[0]: Test OK > cx88[0]: i2c scan: found device @ 0x10 [???] > cx88[0]: i2c scan: found device @ 0xa0 [eeprom] > cx88[0]: GDI: tuner=unknown > cx88[0]/2: cx2388x 8802 Driver Manager > ACPI: PCI Interrupt :02:09.0[A] -> GSI 21 (level, low) -> IRQ 23 > CORE cx88[0]: subsystem: 14c7:0108, board: GDI Black Gold [card=2,insmod > option] > TV tuner -1 at 0x1fe, Radio tuner -1 at 0x1fe > cx88[0]: Test OK > cx88[0]: i2c scan: found device @ 0x10 [???] > cx88[0]: i2c scan: found device @ 0xa0 [eeprom] > cx88[0]: GDI: tuner=unknown > cx88[0]/0: found at :02:09.0, rev: 5, irq: 23, latency: 64, mmio: > 0xf500 > cx88[0]/0: registered device video1 [v4l2] > cx88[0]/0: registered device vbi1 > > > > Thanks, > > //riru > > > > > ___ > Yahoo! Answers - Got a question? Someone out there knows the answer. Try it > now. > http://uk.answers.yahoo.com/ > > > ___ > linux-dvb mailing list > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- 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: Conversion of vino driver for SGI to not use the legacy decoder API
On Friday 27 February 2009 12:22:16 Mauro Carvalho Chehab wrote: > On Fri, 27 Feb 2009 10:09:47 +0100 > > Jean Delvare wrote: > > Hi Hans, > > > > On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote: > > > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote: > > > > After the conversion of Zoran driver to V4L2, now almost all > > > > drivers are using the new API. However, there are is one remaining > > > > driver using the video_decoder.h API (based on V4L1 API) for > > > > message exchange between the bridge driver and the i2c sensor: the > > > > vino driver. > > > > > > > > This driver adds support for the Indy webcam and for a capture > > > > hardware on SGI. Does someone have those hardware? If so, are you > > > > interested on helping to convert those drivers to fully use V4L2 > > > > API? > > > > > > > > The SGI driver is located at: > > > > drivers/media/video/vino.c > > > > > > > > Due to vino, those two drivers are also using the old API: > > > > drivers/media/video/indycam.c > > > > drivers/media/video/saa7191.c > > > > > > > > It shouldn't be hard to convert those files to use the proper APIs, > > > > but AFAIK none of the current active developers has any hardware > > > > for testing it. > > > > > > The conversion has already been done in my v4l-dvb-vino tree. > > Great! Do you have any other tree converting drivers from V4L1 to V4L2 > API? Btw, we should update the dependencies for the converted drivers. > They are still dependent of V4L1: Oops, forgot about those. > config VIDEO_BT819 > tristate "BT819A VideoStream decoder" > depends on VIDEO_V4L1 && I2C > > I'll do such update probably later today. I want to have an overall > picture on what's still left. I'm keeping a document with the state of all the drivers here: http://www.xs4all.nl/%7Ehverkuil/drivers.txt Basically it tells me which drivers are v4l1/2, use video_ioctl2, use v4l2_device and which use v4l2_subdev (this column is empty when the driver doesn't use modules at all). The final column tells me who can test this hardware. At the bottom is a similar list of i2c modules. I have also converted the cafe_ccic driver and I'm waiting for feedback from Jonathan Corbet whether it works or not. The following drivers haven't been converted yet to v4l2_device/subdev: em28xx (Douglas Landgraf said he'd tackle that one), pvrusb2 (Mike Isely is doing that one), cx88 (unassigned), bttv (I want to look at that one), cx23885 (also for me), and w9968cf. The last one is much more difficult since it is v4l1. I do have hardware to test this, but no experience porting from v4l1 to v4l2 or with gspca (the alternative conversion path that I can take). In all honesty, I was planning to just do a quick-and-dirty conversion to v4l2_subdev, while keeping the v4l1 API. I doubt I will have time to do anything more. It allows Jean to make his i2c cleanups and we can do a proper conversion to v4l2 later. My status document also contains a list of the remaining v4l1 drivers: arv, bw-qcam, c-qcam, cpia_pp: these four are ancient and we should consider dropping these altogether. The first seems to be tied to very specific hardware (we should contact the author first before making any decision on that one), the others are for parallel port webcams. cpia_usb: ancient, but USB and I got my hands on one, so that might be interesting to see if it can be converted. ov511: I got hardware for that one as well pms: Amazingly, I got hardware for this one as well. Totally useless ISA video capture card, but it actually works and as a fun project I want to upgrade that one. se401: I don't believe I have hardware for this one (I'm scouring ebay these days for old stuff, but I don't think I found hardware for this driver). stradis: can't find any hardware at all. We might want to contact the author first, though, since these are (semi-?)professional devices. stv680: got hardware for this usbvideo: ditto w9966: can't find any hardware for this one. w9968cf: have hardware as described above. Actually, if anyone else is interested in converting some of these drivers to v4l2 or gspca, I'd be happy to send him the hardware. It's too much work for one person, really. The reason for me collecting all this information and hardware is that I think that for 2.6.31 we should set our goal to abolish these last v4l1 drivers. In parallel to that we should convert the other drivers to v4l2_device and video_ioctl2 which gives a great foundation for the future. > > > I'm trying to > > > convince the original vino author to boot up his Indy and test it, > > > but he is not very interested in doing that. I'll ask him a few more > > > times, but we may have to just merge my code untested. Or perhaps > > > just drop it. > > Well, let's merge the code. Maybe someone at the ML could have an Indy > and can test it. > > I think that the risk of breaking vino is not big, since this conversion > is m
Re: Conversion of vino driver for SGI to not use the legacy decoder API
On Fri, 27 Feb 2009 10:09:47 +0100 Jean Delvare wrote: > Hi Hans, > > On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote: > > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote: > > > After the conversion of Zoran driver to V4L2, now almost all drivers are > > > using the new API. However, there are is one remaining driver using the > > > video_decoder.h API (based on V4L1 API) for message exchange between the > > > bridge driver and the i2c sensor: the vino driver. > > > > > > This driver adds support for the Indy webcam and for a capture hardware > > > on SGI. Does someone have those hardware? If so, are you interested on > > > helping to convert those drivers to fully use V4L2 API? > > > > > > The SGI driver is located at: > > > drivers/media/video/vino.c > > > > > > Due to vino, those two drivers are also using the old API: > > > drivers/media/video/indycam.c > > > drivers/media/video/saa7191.c > > > > > > It shouldn't be hard to convert those files to use the proper APIs, but > > > AFAIK none of the current active developers has any hardware for testing > > > it. > > > > The conversion has already been done in my v4l-dvb-vino tree. Great! Do you have any other tree converting drivers from V4L1 to V4L2 API? Btw, we should update the dependencies for the converted drivers. They are still dependent of V4L1: config VIDEO_BT819 tristate "BT819A VideoStream decoder" depends on VIDEO_V4L1 && I2C I'll do such update probably later today. I want to have an overall picture on what's still left. > > I'm trying to > > convince the original vino author to boot up his Indy and test it, but he > > is not very interested in doing that. I'll ask him a few more times, but we > > may have to just merge my code untested. Or perhaps just drop it. Well, let's merge the code. Maybe someone at the ML could have an Indy and can test it. I think that the risk of breaking vino is not big, since this conversion is more like a variable renaming. Also, after applying those changes at linux-next, more people can test its code. Maybe we can add some printk's asking for testers to contact us at LMML. I would love to finally remove another V4L1 header (video_decoder.h). > > Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi > > code could be dropped which is only used by vino. How important is that to > > you? Perhaps we are flogging a dead horse here and we should just let this > > driver die. > > My rant was based on the fact that i2c-algo-sgi is totally SGI-specific > while i2c-algo-* modules are supposed to be generic abstractions that > can be reused by a variety of hardware. So i2c-algo-sgi should really be > merged into drivers/media/video/vino.c. But as it takes a SGI system to > build-test such a change, and I don't have one, I am reluctant to do > it. If we can find a tester for your V4L2 conversion then maybe the > same tester will be able to test my own changes. > > But i2c-algo-sgi isn't a big problem per se, it doesn't block further > evolutions or anything like that, so if we can't find a tester and it > has to stay for a few more years, this really isn't a problem for me. If the merger of i2c-algo-sgi is as not something complex, then we can try to merge and apply at vino. Otherwise, we can just keep as-is. PS.: probably you haven't noticed, but tea575x-tuner.c is still V4L1 (one of your patches changed the header improperly, breaking sound build). Douglas, As you've done several radio conversions to V4L2 API, maybe you can also handle this one. 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: Conversion of vino driver for SGI to not use the legacy decoder API
Hi Hans, On Fri, 27 Feb 2009 08:19:17 +0100, Hans Verkuil wrote: > On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote: > > After the conversion of Zoran driver to V4L2, now almost all drivers are > > using the new API. However, there are is one remaining driver using the > > video_decoder.h API (based on V4L1 API) for message exchange between the > > bridge driver and the i2c sensor: the vino driver. > > > > This driver adds support for the Indy webcam and for a capture hardware > > on SGI. Does someone have those hardware? If so, are you interested on > > helping to convert those drivers to fully use V4L2 API? > > > > The SGI driver is located at: > > drivers/media/video/vino.c > > > > Due to vino, those two drivers are also using the old API: > > drivers/media/video/indycam.c > > drivers/media/video/saa7191.c > > > > It shouldn't be hard to convert those files to use the proper APIs, but > > AFAIK none of the current active developers has any hardware for testing > > it. > > The conversion has already been done in my v4l-dvb-vino tree. I'm trying to > convince the original vino author to boot up his Indy and test it, but he > is not very interested in doing that. I'll ask him a few more times, but we > may have to just merge my code untested. Or perhaps just drop it. > > Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi > code could be dropped which is only used by vino. How important is that to > you? Perhaps we are flogging a dead horse here and we should just let this > driver die. My rant was based on the fact that i2c-algo-sgi is totally SGI-specific while i2c-algo-* modules are supposed to be generic abstractions that can be reused by a variety of hardware. So i2c-algo-sgi should really be merged into drivers/media/video/vino.c. But as it takes a SGI system to build-test such a change, and I don't have one, I am reluctant to do it. If we can find a tester for your V4L2 conversion then maybe the same tester will be able to test my own changes. But i2c-algo-sgi isn't a big problem per se, it doesn't block further evolutions or anything like that, so if we can't find a tester and it has to stay for a few more years, this really isn't a problem for me. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DViCO FusionHDTV driver/firmware problem
Hello! I am using DViCO FusionHDTV DVB-T Dual Express with latest drivers and kernel 2.6.27-7. After system reboot or combination rmmod/modprobe cx23885 getstream(or any another application) working with card do his job well. Once it terminated(by Ctrl+C) or even simply stopped(when job is finished, e.g. scan) I cant make any DVB related tools work. In /var/log/messages i have lots of messages like this: Feb 27 19:31:01 iptv-dvbt kernel: [39261.670228] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90), id . Feb 27 19:31:01 iptv-dvbt kernel: [39261.685084] xc2028 0-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . Feb 27 19:31:01 iptv-dvbt kernel: [39261.980032] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3), id . Feb 27 19:31:03 iptv-dvbt kernel: [39263.250229] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90), id . Feb 27 19:31:03 iptv-dvbt kernel: [39263.265086] xc2028 0-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id . I have xc3028-v27.fw placed in /lib/firmware. After rmmod/modprobe I can perform new try. Maybe someone here has same problem in the past(and more important successfully solved it:))? Thansk, Serg Gulko -- 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: [git pull] DVB + ieee1394: firedtv driver
Ingo Molnar wrote: * Linus Torvalds wrote: Two choices that I can see: - do the ieee1394_init() as a fs_initcall(), earlier - move drivers/ieee1394 linking up to before drivers/media but I suspect that drivers/media wants to be early, in order to do the _media_ layer initialization early. The former seems the better choice to me. Changing the linking order would just break the next time around. Does this work? yes, i just tested it and your patch fixes the crash: mercury:~> uname -a Linux mercury 2.6.29-rc6-tip-02011-gb62a1ed-dirty #250 SMP Thu Feb 26 19:00:54 CET 2009 i686 athlon i386 GNU/Linux mercury:~> uptime 19:02:51 up 0 min, 1 user, load average: 3.97, 1.10, 0.37 Tested-by: Ingo Molnar Thanks guys. I'm very sorry that this basic issue escaped my attention. It's the first time that a 1394 driver lives outside drivers/ieee1394/Makefile. (Also shows that even very long exposure in linux-next does not catch runtime issues like this one.) Stefan Richter -- 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
