Help wanted patching saa7164 driver to work with Compro E900F

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello all,

I've been working on patching the saa7164 driver to work with the
Compro Videomate Vista E900F. This is a PCI-e tuner card that seems to
be almost identical to the Hauppauge HVR-2200, many versions of which
are supported. I've had some success but there are a few problems
which I'm not sure how to approach and I would appreciate any
help/advice. The most important point is number 2 under things that
are confusing.

CARD DETAILS:
 - Dual hybrid DVB-T/analogue TV tuner
 - hardware analogue source encoders
 - Various analogue video inputs
 - IR remote input
 - pci ID: 185b:e900
 - Main IC: phillips saa7164 rev2
 - Tuners: 2x NXP tda18271
 - DVB-T Demodulators: 2x NXP tda10048

WHAT I'VE DONE
My approach has been to modify the driver to make the kernel output
resemble the sample shown for the HVR-2200 here:
http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-2200#Sample_kernel_output
I patched saa7164-cards.c and saa7164.h to include the details of the
card (see https://gist.github.com/anonymous/8801027), and added the
card to the first case in saa7164_dvb_register() in saa7164-dvb.c (the
case covering the Hauppauge DVB-T cards). This results in the card
being recognised, the tuner/digital demodulator chips being detected,
and the DVB frontend devices being registered correctly. Kernel log of
this process is here: https://gist.github.com/anonymous/8799960. The
output of w_scan is here: https://gist.github.com/anonymous/8800001.
w_scan correctly finds frequencies on which there is a signal in my
area but seems to fail to get any data from those transmissions like
channel names etc. Kernel logs collected during that run of w_scan are
here: https://gist.github.com/anonymous/8800084. The behaviour is the
same on both adapters.

MISCELLANEOUS OBSERVATIONS/ACTIONS:
 - the card's firmware is different to any of the hauppauge firmwares.
The earlier two rev2 firmwares on Steven Toth's site boot correctly
and behave similarly to the stock firmware under linux but result in
the card failing to work at all under windows. The rev3 firmwares and
the newer/larger rev2 firmwares fail to boot. The firmware in the
windows driver has a different header structure to that in the
hauppauge firmware files, but I haven't bothered tackling that problem
yet since the firmware persists even through a full power cycle. I've
just been using the Compro firmware as flashed by the windows driver.
 - My best guess is that the two GPIO pins connected to the tda10048
demodulator reset pin are the same as on the HVR-2200. When I disabled
setting these pins on initialisation, the demodulators were not
correctly detected after a reboot, and strobing these pins as is done
for the HVR-2200 fixed the problem.

THINGS THAT ARE CONFUSING TO ME AND SEEM TO BE WRONG:
1. RF calibration for the tda18271 occurs only on the second of the
two tuners. When tda18271c2_rf_cal_init() is called from within
tda18271_attach(...) in tda18271-fe.c, cfg->rf_cal_on_startup is 0 for
the first chip and 1 for the second. I don't know why this is the
case, but I'm currently assuming its not a serious problem.
2. firmware is not loaded onto either of the tda10048's.
tda10048_init() seems to never be called. I don't understand how it is
meant to be called and why it isn't being called. Does the firmware on
this chip not persist through a reboot or reset, and would this
explain why w_scan is unable to see the channels on the frequencies?
What is the expected series of events that results in tda10048_init
being called to initialise the demodulator? At the moment I feel like
this is likely the biggest problem.
3. The firmware seems to object the the get firmware debug status
command sent from saa7164_api_set_debug() with a 0x9 status code
(SAA_ERR_BAD_PARAMETER), but not to the set debug status command, so I
don't see that this matters. I can see messages in the log starting
with FWMSG like what saa7164_api_collect_debug() would print, so it
seems that the firmware debugging is working in any case.
4. The output of saa7164_api_dump_subdevs() (see kernel log:
https://gist.github.com/anonymous/8799960) indicates that there is an
EEPROM with unitID 0x02. I have configured the card with this unitID
but the firmware returns 0x09 (SAA_ERR_BAD_PARAMETER) and the eeprom
is not read. I don't know why this is the case, and I am curious as to
why the particular read addresses are used in
saa7164_api_read_eeprom() in saa7164-api.c. ("u8 reg[] = { 0x0f, 0x00
};"). Might the correct address vary between cards? If so, how would I
got about finding the correct address? Am I correct in thinking that
the failure to read the EEPROM will not affect digital reception?
(btw, I also tried using all other unitIDs 0-0xff and none resulted in
a successful eeprom read)
5. Some of the configurations of hvr-2200 cards do not include analog
demodulators. I assume one must be present and configured in the card
struct to enable analog reception, and that the driver currently only
supports it for some cards for some reason?

As I said any help or guidance would be greatly appreciated. I'm not
experienced in kernel/driver development so it's quite possible I've
overlooked something important.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux