Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ivtv: devel

[TEST] Please test my ivtv-i2c tree!

 

 

ivtv devel RSS feed   Index | Next | Previous | View Threaded


hverkuil at xs4all

Nov 13, 2007, 9:28 AM

Post #1 of 14 (9796 views)
Permalink
[TEST] Please test my ivtv-i2c tree!

Hi all,

A long standing problem with ivtv (and v4l drivers in general) is that
sometimes i2c devices are misidentified. So the driver thinks that at a
certain i2c address a tuner is connected, when in reality it is a audio
muxer or whatever. The root cause was a problem in the i2c subsystem of
the kernel which made it very hard to tell the i2c subsystem what to
expect at which address.

A new way of handling the i2c bus was added in kernel 2.6.22. However,
in order to actually make use of this (and so finally fix this issue
once and for all) all i2c drivers that are used by ivtv had to be
converted first and only then could ivtv itself be changed. Since ivtv
uses some 15 different i2c devices (each board uses a subset of 1-4/5
devices) this was a substantial amount of work. And it's also a record:
no other driver has to support that many i2c devices.

I've finally converted all the i2c drivers (they are now part of the
v4l-dvb repository) and have finished converting ivtv itself. But
before I ask the v4l-dvb maintainer to pull my ivtv changes I want
people to test it first. If I've made a mistake here, then devices
suddenly won't work anymore, so it's rather important that I let people
test first. Especially for non-standard boards like Japanese variants
and other non-Hauppauge cards.

It is also important that I know I haven't broken support for older
pre-2.6.22 kernels, so if you have an older kernel then please still
test it!

So please help me out by downloading my ivtv-i2c tree here:
http://linuxtv.org/hg/~hverkuil/ivtv-i2c/archive/tip.tar.bz2

Unpack, run 'make' and 'make install' and see if everything still works
after loading the ivtv driver. Just in case, you might want to make a
copy of /lib/modules/2.6.XXX first. You never know :-)

Whether it works or not, please post (or mail) the ivtv initialization
messages from the kernel log so that I know which devices are tested.

If nothing breaks, then I can merge the code in the v4l-dvb repository
and it will get into 2.6.25.

I've CC-ed Trev in the hope that he can test the adaptec cards and
tadachi in the hope that he can test (or let other people test) the
various Asian boards.

Also several people had conflicts between a DVB card and the ivtv
driver: these conflicts should now be solved as well.

Thanks,

Hans

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


sander.sweers at gmail

Nov 13, 2007, 1:20 PM

Post #2 of 14 (9568 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

On di, 2007-11-13 at 18:28 +0100, Hans Verkuil wrote:
>
> So please help me out by downloading my ivtv-i2c tree here:
> http://linuxtv.org/hg/~hverkuil/ivtv-i2c/archive/tip.tar.bz2

I pulled from you branch instead of downloading.

> Whether it works or not, please post (or mail) the ivtv initialization
> messages from the kernel log so that I know which devices are tested.

All seems to work fine so far but if anything comes up during recording
I'll let you know.

Greets
Sander

Linux video capture interface: v2.00
ivtv: Start initialization, version 1.1.0
ivtv0: Initializing card #0
ivtv0: Autodetected Hauppauge card (cx23416 based)
ACPI: PCI Interrupt 0000:04:05.0[A] -> GSI 20 (level, low) -> IRQ 20
tveeprom 1-0050: The eeprom says no radio is present, but the tuner type
tveeprom 1-0050: indicates otherwise. I will assume that radio is
present.
tveeprom 1-0050: Hauppauge model 26039, rev F0A5, serial# 8837856
tveeprom 1-0050: tuner model is TCL MPE05-2 (idx 105, type 38)
tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K)
(eeprom 0x74)
tveeprom 1-0050: audio processor is CX25842 (idx 36)
tveeprom 1-0050: decoder processor is CX25842 (idx 29)
tveeprom 1-0050: has radio, has IR receiver, has IR transmitter
ivtv0: Autodetected Hauppauge WinTV PVR-150
ivtv0: Reopen i2c bus for IR-blaster support
saa7146: register extension 'budget_ci dvb'.
cx25840 1-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0)
tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner)
tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
tuner-simple 1-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME
MK3))
ivtv0: Registered device video0 for encoder MPG (4096 kB)
ivtv0: Registered device video32 for encoder YUV (2048 kB)
ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
ivtv0: Registered device video24 for encoder PCM (320 kB)
ivtv0: Registered device radio0 for encoder radio
ivtv0: Initialized card #0: Hauppauge WinTV PVR-150
ivtv: End initialization
ACPI: PCI Interrupt 0000:04:06.0[A] -> GSI 21 (level, low) -> IRQ 21
saa7146: found saa7146 @ mem ffffc20000032c00 (revision 1, irq 21)
(0x13c2,0x1010).
saa7146 (0): dma buffer size 192512
DVB: registering new adapter (TT-Budget-C-CI PCI)
adapter has MAC addr = 00:d0:5c:67:c3:3c
input: Budget-CI dvb ir receiver saa7146 (0)
as /devices/pci0000:00/0000:00:06.0/0000:04:06.0/input/input3
budget_ci: CI interface initialised
DVB: registering frontend 0 (ST STV0297 DVB-C)...
lirc_dev: IR Remote Control driver registered, major 61
lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
lirc_dev: lirc_register_plugin: sample_rate: 10
ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)



_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


hverkuil at xs4all

Nov 13, 2007, 2:13 PM

Post #3 of 14 (9548 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

On Tuesday 13 November 2007 22:20:33 Sander Sweers wrote:
> On di, 2007-11-13 at 18:28 +0100, Hans Verkuil wrote:
> > So please help me out by downloading my ivtv-i2c tree here:
> > http://linuxtv.org/hg/~hverkuil/ivtv-i2c/archive/tip.tar.bz2
>
> I pulled from you branch instead of downloading.
>
> > Whether it works or not, please post (or mail) the ivtv
> > initialization messages from the kernel log so that I know which
> > devices are tested.
>
> All seems to work fine so far but if anything comes up during
> recording I'll let you know.

Well, it either works or not, so this isn't a duration test luckily.

But can you give me the kernel version you are using?

Thanks,

Hans

>
> Greets
> Sander
>
> Linux video capture interface: v2.00
> ivtv: Start initialization, version 1.1.0
> ivtv0: Initializing card #0
> ivtv0: Autodetected Hauppauge card (cx23416 based)
> ACPI: PCI Interrupt 0000:04:05.0[A] -> GSI 20 (level, low) -> IRQ 20
> tveeprom 1-0050: The eeprom says no radio is present, but the tuner
> type tveeprom 1-0050: indicates otherwise. I will assume that radio
> is present.
> tveeprom 1-0050: Hauppauge model 26039, rev F0A5, serial# 8837856
> tveeprom 1-0050: tuner model is TCL MPE05-2 (idx 105, type 38)
> tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K)
> (eeprom 0x74)
> tveeprom 1-0050: audio processor is CX25842 (idx 36)
> tveeprom 1-0050: decoder processor is CX25842 (idx 29)
> tveeprom 1-0050: has radio, has IR receiver, has IR transmitter
> ivtv0: Autodetected Hauppauge WinTV PVR-150
> ivtv0: Reopen i2c bus for IR-blaster support
> saa7146: register extension 'budget_ci dvb'.
> cx25840 1-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0)
> tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0)
> tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner)
> tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
> tuner-simple 1-0061: type set to 38 (Philips PAL/SECAM multi
> (FM1216ME MK3))
> ivtv0: Registered device video0 for encoder MPG (4096 kB)
> ivtv0: Registered device video32 for encoder YUV (2048 kB)
> ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> ivtv0: Registered device video24 for encoder PCM (320 kB)
> ivtv0: Registered device radio0 for encoder radio
> ivtv0: Initialized card #0: Hauppauge WinTV PVR-150
> ivtv: End initialization
> ACPI: PCI Interrupt 0000:04:06.0[A] -> GSI 21 (level, low) -> IRQ 21
> saa7146: found saa7146 @ mem ffffc20000032c00 (revision 1, irq 21)
> (0x13c2,0x1010).
> saa7146 (0): dma buffer size 192512
> DVB: registering new adapter (TT-Budget-C-CI PCI)
> adapter has MAC addr = 00:d0:5c:67:c3:3c
> input: Budget-CI dvb ir receiver saa7146 (0)
> as /devices/pci0000:00/0000:00:06.0/0000:04:06.0/input/input3
> budget_ci: CI interface initialised
> DVB: registering frontend 0 (ST STV0297 DVB-C)...
> lirc_dev: IR Remote Control driver registered, major 61
> lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
> lirc_dev: lirc_register_plugin: sample_rate: 10
> ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> ivtv0: Encoder revision: 0x02060039
> cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
>
>
>
> _______________________________________________
> ivtv-devel mailing list
> ivtv-devel [at] ivtvdriver
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel



_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mark.paulus at verizonbusiness

Nov 13, 2007, 2:21 PM

Post #4 of 14 (9563 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree! [In reply to]

Hans Verkuil wrote:
> Hi all,
>
> A long standing problem with ivtv (and v4l drivers in general) is that
> sometimes i2c devices are misidentified. So the driver thinks that at a
> certain i2c address a tuner is connected, when in reality it is a audio
> muxer or whatever. The root cause was a problem in the i2c subsystem of
> the kernel which made it very hard to tell the i2c subsystem what to
> expect at which address.
>
> A new way of handling the i2c bus was added in kernel 2.6.22. However,
> in order to actually make use of this (and so finally fix this issue
> once and for all) all i2c drivers that are used by ivtv had to be
> converted first and only then could ivtv itself be changed. Since ivtv
> uses some 15 different i2c devices (each board uses a subset of 1-4/5
> devices) this was a substantial amount of work. And it's also a record:
> no other driver has to support that many i2c devices.
>
> I've finally converted all the i2c drivers (they are now part of the
> v4l-dvb repository) and have finished converting ivtv itself. But
> before I ask the v4l-dvb maintainer to pull my ivtv changes I want
> people to test it first. If I've made a mistake here, then devices
> suddenly won't work anymore, so it's rather important that I let people
> test first. Especially for non-standard boards like Japanese variants
> and other non-Hauppauge cards.
>
> It is also important that I know I haven't broken support for older
> pre-2.6.22 kernels, so if you have an older kernel then please still
> test it!
>

Hmmm.

Won't compile on my debian etch stock kernel:

# make
creating symbolic links...
Kernel build directory is /lib/modules/2.6.18-5-k7/build
make -C /lib/modules/2.6.18-5-k7/build SUBDIRS=/usr/src/ivtv/ivtv-i2c-7b56d82d91
bb/v4l modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.18-5-k7'
CC [M] /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.o
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:126: error: unknown field 'dev_attrs' specified in initializer
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:126: warning: initialization from incompatible pointer type
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: error: unknown field 'dev_release' specified in initializer
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning: missing braces around initializer
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning: (near initialization for 'video_class.subsys')
/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning: initialization from incompatible pointer type
make[2]: *** [/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.o] Error 1
make[1]: *** [_module_/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-5-k7'
make: *** [default] Error 2
Attachments: mark_paulus.vcf (0.29 KB)


sander.sweers at gmail

Nov 13, 2007, 2:25 PM

Post #5 of 14 (9545 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

On di, 2007-11-13 at 23:13 +0100, Hans Verkuil wrote:
> Well, it either works or not, so this isn't a duration test luckily.

Then it works :)

> But can you give me the kernel version you are using?

Oops..

mythtv v4l-dvb # uname -a
Linux mythtv 2.6.23-gentoo-r1 #1 Sun Nov 4 19:41:06 CET 2007 x86_64 AMD
Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux

Greets
Sander


_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


hverkuil at xs4all

Nov 13, 2007, 2:42 PM

Post #6 of 14 (9576 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree! [In reply to]

On Tuesday 13 November 2007 23:21:55 Mark Paulus wrote:
> Hans Verkuil wrote:
> > Hi all,
> >
> > A long standing problem with ivtv (and v4l drivers in general) is
> > that sometimes i2c devices are misidentified. So the driver thinks
> > that at a certain i2c address a tuner is connected, when in reality
> > it is a audio muxer or whatever. The root cause was a problem in
> > the i2c subsystem of the kernel which made it very hard to tell the
> > i2c subsystem what to expect at which address.
> >
> > A new way of handling the i2c bus was added in kernel 2.6.22.
> > However, in order to actually make use of this (and so finally fix
> > this issue once and for all) all i2c drivers that are used by ivtv
> > had to be converted first and only then could ivtv itself be
> > changed. Since ivtv uses some 15 different i2c devices (each board
> > uses a subset of 1-4/5 devices) this was a substantial amount of
> > work. And it's also a record: no other driver has to support that
> > many i2c devices.
> >
> > I've finally converted all the i2c drivers (they are now part of
> > the v4l-dvb repository) and have finished converting ivtv itself.
> > But before I ask the v4l-dvb maintainer to pull my ivtv changes I
> > want people to test it first. If I've made a mistake here, then
> > devices suddenly won't work anymore, so it's rather important that
> > I let people test first. Especially for non-standard boards like
> > Japanese variants and other non-Hauppauge cards.
> >
> > It is also important that I know I haven't broken support for older
> > pre-2.6.22 kernels, so if you have an older kernel then please
> > still test it!
>
> Hmmm.
>
> Won't compile on my debian etch stock kernel:

I heard more reports about compatibility problems and I traced it to
some recent videodev changes that break compatibility for kernels <
2.6.19. So in order to test this you need a kernel >- 2.6.19.

I'll also report this compatibility breakage to the v4l mailinglist.

Regards,

Hans

>
> # make
> creating symbolic links...
> Kernel build directory is /lib/modules/2.6.18-5-k7/build
> make -C /lib/modules/2.6.18-5-k7/build
> SUBDIRS=/usr/src/ivtv/ivtv-i2c-7b56d82d91 bb/v4l modules
> make[1]: Entering directory `/usr/src/linux-headers-2.6.18-5-k7'
> CC [M] /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.o
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:126: error:
> unknown field 'dev_attrs' specified in initializer
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:126: warning:
> initialization from incompatible pointer type
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: error:
> unknown field 'dev_release' specified in initializer
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning:
> missing braces around initializer
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning:
> (near initialization for 'video_class.subsys')
> /usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.c:127: warning:
> initialization from incompatible pointer type make[2]: ***
> [/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l/videodev.o] Error 1 make[1]:
> *** [_module_/usr/src/ivtv/ivtv-i2c-7b56d82d91bb/v4l] Error 2
> make[1]: Leaving directory `/usr/src/linux-headers-2.6.18-5-k7' make:
> *** [default] Error 2



_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


srey0123+ivtv at gmail

Nov 14, 2007, 7:36 AM

Post #7 of 14 (9538 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

On Nov 13, 2007, at 4:42 PM, Hans Verkuil wrote:

> I heard more reports about compatibility problems and I traced it to
> some recent videodev changes that break compatibility for kernels <
> 2.6.19. So in order to test this you need a kernel >- 2.6.19.

I looked into this last week and I'm pretty confident this is just a
bogus version test. If you look at the lines near the errors
mentioned, you'll see a check for kernel 2.6.13; however, struct class
didn't gain .dev_attrs, and hadn't renamed .release to .dev_release,
until 2.6.19.

If you change both #if LINUX_VERSION_CODE lines from 13 to 19 you'll
get it to compile (with a warning), but there will be another error
v4l1-compat.c that I'm not entirely sure of how to handle. At least on
my system it chokes on the __pure attribute to palette_to_pixelformat().

The patch I used to get the latest v4l-dvb to compile is appended. It
seems to work for me but I can't guarantee its correctness, YMMV, etc.

--scott

diff -r b9523a14ccea linux/drivers/media/video/v4l1-compat.c
--- a/linux/drivers/media/video/v4l1-compat.c Sun Nov 04 14:34:05 2007
-0200
+++ b/linux/drivers/media/video/v4l1-compat.c Wed Nov 07 00:00:45 2007
-0600
@@ -145,7 +145,7 @@ const static unsigned int palette2pixelf
[VIDEO_PALETTE_YUV422P] = V4L2_PIX_FMT_YUV422P,
};

-static unsigned int __pure
+static unsigned int /* __pure */
palette_to_pixelformat(unsigned int palette)
{
if (palette < ARRAY_SIZE(palette2pixelformat))
diff -r b9523a14ccea linux/drivers/media/video/videodev.c
--- a/linux/drivers/media/video/videodev.c Sun Nov 04 14:34:05 2007
-0200
+++ b/linux/drivers/media/video/videodev.c Tue Nov 06 19:31:57 2007
-0600
@@ -111,7 +111,7 @@ static void video_release(struct device
vfd->release(vfd);
}

-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,13)
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19)
static struct device_attribute video_device_attrs[] = {
__ATTR(name, S_IRUGO, show_name, NULL),
__ATTR_NULL
@@ -120,7 +120,7 @@ static struct device_attribute video_dev

static struct class video_class = {
.name = VIDEO_NAME,
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
.release = video_release,
#else
.dev_attrs = video_device_attrs,


_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mark.paulus at verizonbusiness

Nov 14, 2007, 8:34 AM

Post #8 of 14 (9539 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

Scott Reynolds wrote:
> On Nov 13, 2007, at 4:42 PM, Hans Verkuil wrote:
>
>> I heard more reports about compatibility problems and I traced it to
>> some recent videodev changes that break compatibility for kernels <
>> 2.6.19. So in order to test this you need a kernel >- 2.6.19.
>
> I looked into this last week and I'm pretty confident this is just a
> bogus version test. If you look at the lines near the errors
> mentioned, you'll see a check for kernel 2.6.13; however, struct class
> didn't gain .dev_attrs, and hadn't renamed .release to .dev_release,
> until 2.6.19.
>
> If you change both #if LINUX_VERSION_CODE lines from 13 to 19 you'll
> get it to compile (with a warning), but there will be another error
> v4l1-compat.c that I'm not entirely sure of how to handle. At least on
> my system it chokes on the __pure attribute to palette_to_pixelformat().
>
> The patch I used to get the latest v4l-dvb to compile is appended. It
> seems to work for me but I can't guarantee its correctness, YMMV, etc.
>
> --scott
>
> diff -r b9523a14ccea linux/drivers/media/video/v4l1-compat.c
> --- a/linux/drivers/media/video/v4l1-compat.c Sun Nov 04 14:34:05 2007
> -0200
> +++ b/linux/drivers/media/video/v4l1-compat.c Wed Nov 07 00:00:45 2007
> -0600
> @@ -145,7 +145,7 @@ const static unsigned int palette2pixelf
> [VIDEO_PALETTE_YUV422P] = V4L2_PIX_FMT_YUV422P,
> };
>
> -static unsigned int __pure
> +static unsigned int /* __pure */
> palette_to_pixelformat(unsigned int palette)
> {
> if (palette < ARRAY_SIZE(palette2pixelformat))
> diff -r b9523a14ccea linux/drivers/media/video/videodev.c
> --- a/linux/drivers/media/video/videodev.c Sun Nov 04 14:34:05 2007
> -0200
> +++ b/linux/drivers/media/video/videodev.c Tue Nov 06 19:31:57 2007
> -0600
> @@ -111,7 +111,7 @@ static void video_release(struct device
> vfd->release(vfd);
> }
>
> -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,13)
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19)
> static struct device_attribute video_device_attrs[] = {
> __ATTR(name, S_IRUGO, show_name, NULL),
> __ATTR_NULL
> @@ -120,7 +120,7 @@ static struct device_attribute video_dev
>
> static struct class video_class = {
> .name = VIDEO_NAME,
> -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
> .release = video_release,
> #else
> .dev_attrs = video_device_attrs,
>

I used this patch and managed to get the modules to compile and load
on my 2.6.18 debian/etch kernel. However, I have a question. Will
these modules now load in a deterministic manner? For instance,
on this box I have a PVR-150, a air2PC card, an Avermedia A180,
and a DVICO pcHDTV RT5 lite. My issue is that in myth, I need to
assign the proper /dev/device to the proper capture device.

To get around that with previous versions, I had some custom rules in
hotplug/udev that would create custom aliases, such as /dev/ivtv0,
/dev/bttv_vid0. However, this release has broken the mechanism that
created my /dev/ivtv0, so mythtv isn't happy.

Will all devices load and create /dev/video* in the same order all the time,
or is it still up in the air as to which device will create which
/dev/video*, based upon who's faster today????

This is a long outstanding issue with udev/hotplug, but someone needs to
fix it, if they can figure out how.
Attachments: dmesg.out (6.08 KB)
  mark_paulus.vcf (0.29 KB)


mark.paulus at verizonbusiness

Nov 14, 2007, 9:59 AM

Post #9 of 14 (9519 views)
Permalink
Re: [ivtv-users] [TEST] Please test my ivtv-i2c tree! [In reply to]

Mark Paulus wrote:
>
> I used this patch and managed to get the modules to compile and load
> on my 2.6.18 debian/etch kernel. However, I have a question. Will
> these modules now load in a deterministic manner? For instance,
> on this box I have a PVR-150, a air2PC card, an Avermedia A180, and a
> DVICO pcHDTV RT5 lite. My issue is that in myth, I need to assign the
> proper /dev/device to the proper capture device.
>
> To get around that with previous versions, I had some custom rules in
> hotplug/udev that would create custom aliases, such as /dev/ivtv0,
> /dev/bttv_vid0. However, this release has broken the mechanism that
> created my /dev/ivtv0, so mythtv isn't happy.
>
> Will all devices load and create /dev/video* in the same order all the
> time,
> or is it still up in the air as to which device will create which
> /dev/video*, based upon who's faster today????
>
> This is a long outstanding issue with udev/hotplug, but someone needs to
> fix it, if they can figure out how.

Ok, I fixed up my udev script, and now I have my /dev/ivtv0 device again.
So, using your tree, everything seems to be working on my 2.6.18 box,
with the small patchset provided by Scott Reynolds. The appropriate
dmesg messages were attached to my previous email. So, outside
of a couple of small glitches, these drivers seem to be backwards
compatible.
Attachments: mark_paulus.vcf (0.29 KB)


mark.paulus at verizonbusiness

Nov 15, 2007, 7:43 AM

Post #10 of 14 (9508 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree - Problem with SAA7134 device [In reply to]

Hans Verkuil wrote:
> Hi all,
>
> A long standing problem with ivtv (and v4l drivers in general) is that
> sometimes i2c devices are misidentified. So the driver thinks that at a
> certain i2c address a tuner is connected, when in reality it is a audio
> muxer or whatever. The root cause was a problem in the i2c subsystem of
> the kernel which made it very hard to tell the i2c subsystem what to
> expect at which address.
>
> A new way of handling the i2c bus was added in kernel 2.6.22. However,
> in order to actually make use of this (and so finally fix this issue
> once and for all) all i2c drivers that are used by ivtv had to be
> converted first and only then could ivtv itself be changed. Since ivtv
> uses some 15 different i2c devices (each board uses a subset of 1-4/5
> devices) this was a substantial amount of work. And it's also a record:
> no other driver has to support that many i2c devices.
>
> I've finally converted all the i2c drivers (they are now part of the
> v4l-dvb repository) and have finished converting ivtv itself. But
> before I ask the v4l-dvb maintainer to pull my ivtv changes I want
> people to test it first. If I've made a mistake here, then devices
> suddenly won't work anymore, so it's rather important that I let people
> test first. Especially for non-standard boards like Japanese variants
> and other non-Hauppauge cards.
>
> It is also important that I know I haven't broken support for older
> pre-2.6.22 kernels, so if you have an older kernel then please still
> test it!
>
> So please help me out by downloading my ivtv-i2c tree here:
> http://linuxtv.org/hg/~hverkuil/ivtv-i2c/archive/tip.tar.bz2
>
> Unpack, run 'make' and 'make install' and see if everything still works
> after loading the ivtv driver. Just in case, you might want to make a
> copy of /lib/modules/2.6.XXX first. You never know :-)
>
> Whether it works or not, please post (or mail) the ivtv initialization
> messages from the kernel log so that I know which devices are tested.
>
> If nothing breaks, then I can merge the code in the v4l-dvb repository
> and it will get into 2.6.25.
>
> I've CC-ed Trev in the hope that he can test the adaptec cards and
> tadachi in the hope that he can test (or let other people test) the
> various Asian boards.
>
> Also several people had conflicts between a DVB card and the ivtv
> driver: these conflicts should now be solved as well.


I was playing with the new drivers last night, and noticed an oddity on my
Avermedia A180 card (SAA7134 based, used for QAM256). I was having issues
getting a LOCK on one frequency. So, I booted back to the old modules,
and got a LOCK right away as expected.

The dmesg output should be the same as what I posted originally. I have
added the dmesg output from the boot that allows the card to work as
expected.

What I did was create a copy of my /lib/modules/`uname -r`.orig. Then I
installed your experimental drivers, and rebooted. I have a link in
/lib/modules, so I can rapidly switch module base and reboot, to see
the results of modules.

In addition, I have attached the output from the azap sessions.
Attachments: signallock.good (1.60 KB)
  signal.dmesg.good (21.2 KB)
  signallock.bad (1.84 KB)
  mark_paulus.vcf (0.29 KB)


md001 at gmx

Nov 15, 2007, 2:19 PM

Post #11 of 14 (9508 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree! [In reply to]

seems to work :-)
but I noticed this in the log, which was not present with an earlier driver:

i2c-adapter i2c-2: SMBus Quick command not supported, can't probe for chips

and this is missing:
tuner 3-0061: chip found @ 0xc2 (ivtv i2c driver #0)

full ivtv initialization attached (old + new)
Attachments: ivtv-messages.txt (5.65 KB)


hverkuil at xs4all

Nov 24, 2007, 2:01 PM

Post #12 of 14 (9330 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree - Problem with SAA7134 device [In reply to]

On Thursday 15 November 2007 16:43:05 Mark Paulus wrote:
> Hans Verkuil wrote:
> > Hi all,
> >
> > A long standing problem with ivtv (and v4l drivers in general) is
> > that sometimes i2c devices are misidentified. So the driver thinks
> > that at a certain i2c address a tuner is connected, when in reality
> > it is a audio muxer or whatever. The root cause was a problem in
> > the i2c subsystem of the kernel which made it very hard to tell the
> > i2c subsystem what to expect at which address.
> >
> > A new way of handling the i2c bus was added in kernel 2.6.22.
> > However, in order to actually make use of this (and so finally fix
> > this issue once and for all) all i2c drivers that are used by ivtv
> > had to be converted first and only then could ivtv itself be
> > changed. Since ivtv uses some 15 different i2c devices (each board
> > uses a subset of 1-4/5 devices) this was a substantial amount of
> > work. And it's also a record: no other driver has to support that
> > many i2c devices.
> >
> > I've finally converted all the i2c drivers (they are now part of
> > the v4l-dvb repository) and have finished converting ivtv itself.
> > But before I ask the v4l-dvb maintainer to pull my ivtv changes I
> > want people to test it first. If I've made a mistake here, then
> > devices suddenly won't work anymore, so it's rather important that
> > I let people test first. Especially for non-standard boards like
> > Japanese variants and other non-Hauppauge cards.
> >
> > It is also important that I know I haven't broken support for older
> > pre-2.6.22 kernels, so if you have an older kernel then please
> > still test it!
> >
> > So please help me out by downloading my ivtv-i2c tree here:
> > http://linuxtv.org/hg/~hverkuil/ivtv-i2c/archive/tip.tar.bz2
> >
> > Unpack, run 'make' and 'make install' and see if everything still
> > works after loading the ivtv driver. Just in case, you might want
> > to make a copy of /lib/modules/2.6.XXX first. You never know :-)
> >
> > Whether it works or not, please post (or mail) the ivtv
> > initialization messages from the kernel log so that I know which
> > devices are tested.
> >
> > If nothing breaks, then I can merge the code in the v4l-dvb
> > repository and it will get into 2.6.25.
> >
> > I've CC-ed Trev in the hope that he can test the adaptec cards and
> > tadachi in the hope that he can test (or let other people test) the
> > various Asian boards.
> >
> > Also several people had conflicts between a DVB card and the ivtv
> > driver: these conflicts should now be solved as well.
>
> I was playing with the new drivers last night, and noticed an oddity
> on my Avermedia A180 card (SAA7134 based, used for QAM256). I was
> having issues getting a LOCK on one frequency. So, I booted back to
> the old modules, and got a LOCK right away as expected.
>
> The dmesg output should be the same as what I posted originally. I
> have added the dmesg output from the boot that allows the card to
> work as expected.
>
> What I did was create a copy of my /lib/modules/`uname -r`.orig.
> Then I installed your experimental drivers, and rebooted. I have a
> link in /lib/modules, so I can rapidly switch module base and reboot,
> to see the results of modules.
>
> In addition, I have attached the output from the azap sessions.

Hi Mark,

You should probably try to use the latest v4l-dvb master repository and
see if this problem has been fixed already. If not, you should report
it to the video4linux mailinglist. The ivtv-i2c tree also has bleeding
edge versions of other drivers, so bugs are not impossible. But it's
not something ivtv introduced.

Thanks for testing!

Regards,

Hans

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel


mark.paulus at verizonbusiness

Dec 7, 2007, 12:28 PM

Post #13 of 14 (9094 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree - Problem with SAA7134 device [In reply to]

Hans Verkuil wrote:
> On Thursday 15 November 2007 16:43:05 Mark Paulus wrote:
>> I was playing with the new drivers last night, and noticed an oddity
>> on my Avermedia A180 card (SAA7134 based, used for QAM256). I was
>> having issues getting a LOCK on one frequency. So, I booted back to
>> the old modules, and got a LOCK right away as expected.
>>
>> The dmesg output should be the same as what I posted originally. I
>> have added the dmesg output from the boot that allows the card to
>> work as expected.
>>
>> What I did was create a copy of my /lib/modules/`uname -r`.orig.
>> Then I installed your experimental drivers, and rebooted. I have a
>> link in /lib/modules, so I can rapidly switch module base and reboot,
>> to see the results of modules.
>>
>> In addition, I have attached the output from the azap sessions.
>
> Hi Mark,
>
> You should probably try to use the latest v4l-dvb master repository and
> see if this problem has been fixed already. If not, you should report
> it to the video4linux mailinglist. The ivtv-i2c tree also has bleeding
> edge versions of other drivers, so bugs are not impossible. But it's
> not something ivtv introduced.
>
> Thanks for testing!
>
> Regards,
>
> Hans

I have been playing with this box some more, and I think the issue I
reported about not getting a good FE_LOCK is a different problem.
I have 2 different DVB cards (Avermedia A180 & pcHDTV RT5 Lite), and
I think what is happening is that they are getting put in to
/dev/dvb/adapter[n] randomly by udev, based upon who-knows-what. The
pcHDTV doesn't seem to tune quite as well as the Avermedia card, so
depending upon which card I hit, that could determine the results I see.
(We REALLY!!! need some better udev rules for loading and fixing video
card identifiers.)
Attachments: mark_paulus.vcf (0.29 KB)


spamtree at comcast

Dec 16, 2007, 3:48 PM

Post #14 of 14 (8938 views)
Permalink
Re: [TEST] Please test my ivtv-i2c tree - Problem with SAA7134 device [In reply to]

I have been having this problem with the latest development snapshots.
Really started with kernel 2.6.22 and the ivtv driver in the kernel.

Currently using kernel - 2.6.23.11
v4l-dvd - updated 12/16/2007 to lastest master repository. This
version also contains the ivtvfb module.

mythtv - latest svn update from today 12/16/2007.

I have started having the following errors.

i2c-adapter i2c-3: sendbytes: error - bailout.
msp3400 3-0040: I/O error #0 (read 0x10/0x200)
i2c-adapter i2c-3: sendbytes: error - bailout.
msp3400 3-0040: I/O error #0 (read 0x10/0x200)
i2c-adapter i2c-3: sendbytes: error - bailout.
msp3400 3-0040: I/O error #0 (read 0x10/0x200)
i2c-adapter i2c-2: sendbytes: error - bailout.
msp3400 2-0040: I/O error #0 (read 0x10/0x200)
i2c-adapter i2c-3: sendbytes: error - bailout.
msp3400 3-0040: I/O error #0 (read 0x10/0x200)

When this error occurs I lose the sound on the recording, and wife
gets mad ;-)

It is strange because this error does not happen all the time, and the
next recording usually is okay.

I did a search of the mailing list, and one user upgrade
to the lastest v4l-dvb to resolve this problem. However, no luck here.
Anything else I can try? Thanks for any help on this matter.

Alan

_______________________________________________
ivtv-devel mailing list
ivtv-devel [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

ivtv devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.