[pvrusb2] AVerMedia HC80 AVerTV Hybrid ExpressCard/54 support?
Mike Isely
isely at isely.net
Tue Apr 13 19:41:06 CDT 2010
On Mon, 12 Apr 2010, Bill Paxton wrote:
> Hi Mike and list,
>
> > But obviously the devil is in the details.
>
> ;^)
>
> > The first and biggest step is to ensure that the FX2 runs properly,
> > and for that it requires firmware. The FX2 can load firmware by
> > itself from a connected I2C ROM or it can be downloaded from the
> > host.
>
> I'm using a 64-bit 2.6.33.2 stable vanilla kernel, all the
> capture/frontend/tuner modules are enabled, and also things I thought
> might help (ie. CONFIG_USB_C67X00_HCD=Y, I can't imagine it needs host
> controller mode, I'm just "preparing".) I've pulled v4l-dvb from their
> Hg repository, and am working with pvrusb2-mci-20100221.tar.bz2. As
> suggested, I added new device elements to the pvr2_device_table and
> pvr2_device_desc structures. I cloned the simplest entry and modified
> that.
You don't need to do anything special with the USB host controller to
operate your device. It just needs to be loaded and working same as for
any other connected USB device (mouse, keyboard, portable hard drive,
flash key, etc).
The rest of this sounds good.
>
> I'm wading much deeper than my skill level, but I am trying to
> comprehend it. With regards to the analog tuner, the Xceive 2038 has
> both it's own module & firmware in v4l__experimental, and in the
> kernel inclusion of ivtv's tuner.h as tuner #71. Also since I don't
> know any better, I've made new entries for ROUTING_SCHEME,
> DIGITAL_SCHEME, LED_SCHEME, and IR_SCHEME for the HC80 in
> prbusb2-devattr.h...
You're doing fine so far.
Those *_SCHEME definitions are in fact important and you've guessed
correctly that they will probably need to be enhanced. There will also
be corresponding code changes elsewhere in the driver for each of these.
The "schemes" are:
"ROUTING" - This defines the wiring between the digitizer chip's inputs
and the physical inputs on the device. For example, "input 1" to the
digitizer on one vendor's device might be composite but on another
vendor's device it might instead be your "s-video" input. Some vendors
don't implement all the input combinations either, so you need to define
and implement a scheme that corresponds correctly to how the vendor has
done this. It is in fact this piece that usually requires the most
guesswork.
"DIGITAL" - This defines the mechanism for controlling of digital
streaming (as opposed to old analog capture). While the analog side of
most of these devices all pretty closely follow a common reference
design (and thus don't vary much), the digital side so far in the two
cases I've encountered operate a lot differently. If your device is yet
different we'll have to figure this out too.
"LED" - This one can be punted in the short term. Some devices include
an LED that can be turned on under software control. The pvrusb2 driver
tries to turn on such an LED only while streaming is underway. However
there really is no 'standard' among the device types for how the LED is
controlled, and unfortunately there are numerous choices.
"IR" - This defines some configuration about the IR receiver, if any, on
the device. This one is relatively simple to set up. It can also be
completely ignored until you're ready to get IR reception working - if
even there's an IR receiver present. Given that this is an Expresscard
device I don't really see where an IR receiver might reside so there's
probably no receiver anyway.
(BTW, do you have a URL that points to the vendor's product page for
this device?)
Question: Is this device purely a tuner or does it have additional
analog inputs? For example are there composite or s-video inputs
available? Is so, then it is possible to break down the porting effort
somewhat: You don't need the tuner itself operating correctly when using
one of those inputs. The composite and/or s-video inputs enter the
video pipeline downstream of the tuner, so this gives us a way to
separately debug the rest of the video pipeline independent of the
tuner. Then later attention can be focused on the tuner itself, knowing
then that everything else is working correctly.
>
> ----
> /* AVerMedia HC80 AVerTV Hybrid ExpressCard/54 */
>
> static const struct pvr2_device_client_desc pvr2_cli_hc80[] = {
> { .module_id = PVR2_CLIENT_ID_CX25840 },
> { .module_id = PVR2_CLIENT_ID_TUNER },
> // { .module_id = PVR2_CLIENT_ID_TUNER_XC2028 },
> // { .module_id = PVR2_CLIENT_ID_WM8739 },
> { .module_id = PVR2_CLIENT_ID_DEMOD },
> };
Those ID's are arbitrary constants in the driver used purely to tell the
devices apart. You will need to define any new constant first before
they are used (suggest you use 'grep' to see how/where they are used).
>
> static const struct pvr2_device_desc pvr2_device_hc80 = {
> .description = "AVerMedia HC80 AVerTV Hybrid USB tuner",
> .shortname = "hc80",
> .client_table.lst = pvr2_cli_hc80,
> .client_table.cnt = ARRAY_SIZE(pvr2_cli_hc80),
> .default_tuner_type = TUNER_XC2028,
> .flag_has_analogtuner = !0,
> .flag_has_fmradio = !0,
> .flag_has_composite = !0,
> .flag_has_cx25840 = !0,
> .flag_has_svideo = !0,
> .flag_digital_requires_cx23416 = !0,
> .signal_routing_scheme = PVR2_ROUTING_SCHEME_HC80,
> .digital_control_scheme = PVR2_DIGITAL_SCHEME_HC80,
> .led_scheme = PVR2_LED_SCHEME_HC80,
> .ir_scheme = PVR2_IR_SCHEME_HC80,
> .default_std_mask = V4L2_STD_NTSC_M,
> };
> <--snip-->
> { USB_DEVICE(0x07ca, 0x0c80),
> .driver_info = (kernel_ulong_t)&pvr2_device_hc80},
For each new scheme you add, there will likely be code that must be
written as well. A really quick way to spot how this works is just to
use grep on the driver source - just search for the scheme names
themselves. The search will be easy because those names are
deliberately set up to be unique.
> ----
>
> It compiles and installs and I get:
>
> ---
> [root at lappy]# modprobe pvrusb2 debug=1 tuner=71 ; tail /var/log/messages
>
> pvrusb2: Hardware description: AVerMedia HC80 AVerTV Hybrid USB tuner
> usbcore: registered new interface driver pvrusb2
> pvrusb2: 20100221 (from www.isely.net):Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> pvrusb2: Debug mask is 31 (0x1f)
> cx25840 2-0044: Unable to detect h/w, assuming cx23887
> cx25840 2-0044: cx23887 A/V decoder found @ 0x88 (pvrusb2_a)
> pvrusb2: Attached sub-driver cx25840
That's a likely problem; looks like the cx25840 isn't working soon
enough. There might need to be a something that must be done first to
turn it on.
> pvrusb2: Module ID 4 (tuner) for device AVerMedia HC80 AVerTV Hybrid USB tuner failed to load. Possible missing sub-device kernel module or initialization failure within module.
> tuner 2-0043: chip found @ 0x86 (pvrusb2_a)
> tda9887 2-0043: creating new instance
> tda9887 2-0043: tda988[5/6/7] found
> tda9887 2-0043: i2c i/o error: rc == -5 (should be 4)
> pvrusb2: Attached sub-driver tuner
This is another detection failure :-(
> pvrusb2: Device being rendered inoperable
> pvrusb2: ***WARNING*** pvrusb2 driver initialization failed due to the
> failure of one or more sub-device kernel modules.
> pvrusb2: You need to resolve the failing condition before this driver
> can function. There should be some earlier messages giving more
> information about the problem.
And this all happened as a result of the failures above. Part of the
driver's initialization sequence is to pull in sub-device drivers from
v4l-dvb corresponding to the expected hardware (those PVR2_CLIENT_ID_*
items). If one of those sub-drivers fail, then the pvrusb2 driver will
abort its initialization and you'll see the text above.
There is a module option can you give to the pvrusb2 driver (i2cscan=1)
to cause it to scan the I2C bus within the device. Try that, then look
at your dmesg output and you should see a list of the I2C ids that were
found. This will probably give some more insight about what to do
regarding the above errors.
>
> [root at lappy]# lsmod
>
> Module Size Used by
> tda9887 9545 1
> tda8290 10728 0
> tuner 18177 1
> cx25840 26761 1
> pvrusb2 137202 0
> dvb_core 88897 1 pvrusb2
> cx2341x 11086 1 pvrusb2
> v4l2_common 16247 5 wm8739,tuner,cx25840,pvrusb2,cx2341x
> videodev 35699 5 wm8739,tuner,cx25840,pvrusb2,v4l2_common
> v4l1_compat 12658 2 pvrusb2,videodev
> v4l2_compat_ioctl32 10021 1 videodev
> tveeprom 12918 1 pvrusb2
>
> ----
>
> However, it at least does try and talk thru USB. "chip found @ 0x86"
> whether or not it's correct sounds like it was able to query
> something. And loading the module turns on the card's in-use LED, too.
> Would you consider that an indicator that the FX2 gets bootstrapped
> from that EEPROM? Also, if I modprobe wm8739 & tuner_xc2028 from
> v4l-dvb, they load, but do nothing. (and defining them as .module_id
> list items in pvrusb2 generates undef'd compile errors, go figure.)
If you can show for a fact that the driver can reach the device's I2C
bus, then the FX2 is definitely bootstrapped and working already.
Assuming the FX2 wasn't already bootstrapped from a previous run using
Windows then yes, you have definitely proven that the FX2 firmware is
already there.
I'm not totally convinced yet that the I2C bus is working. But that
i2cscan=1 experiment would probably prove the case.
>
> As always, thanks so much for reading, and if there's any way you can
> help me along I'd greatly appreciate it.
Hopefully the above will let you make some more progress.
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2
mailing list