Hi,

I've switched over the bttv + cx88 drivers to use the tveeprom
module as well to get the config info for the Hauppauge TV cards.
Because of that I'll push that module to the 2.6 mainline kernel soon
(with my next batch of v4l patches, most likely for 2.6.11 early next
year).

I've also cleaned up the module.  All compatibility stuff for old
kernels is gone.  The module doesn't register itself as i2c driver any
more, it just provides some helper functions which can simply be called
directly by the tv card drivers instead of going the indirect route
using i2c_driver->command().  See the tveeprom.h appended below for the
interface, check a fresh video4linux snapshot tarball from
http://dl.bytesex.org/cvs-snapshots/ for the other bits.

The reason to do it this way is that i2c_driver stuff only makes it much
more complicated than it needs to be.  Also the existing code wouldn't
handle cx88-driven cards correctly.  The cx2388x chips use the first 8
bytes of the eeprom for PCI config stuff (PCI Subsystem ID and some
other things).  The Hauppauge config info on these cards (analog) looks
is almost identical to the other (bttv/iviv) ones, the only difference
is that it is shifted by 8 bytes.  When calling the decoding function
directly handing this is trivial, when using the indirect route tveeprom
would need to figure somehow whenever it should shift by 8 bytes or not.

Comments?

Suggestions on how to handle the merge and ivtv adaption?

In the long run I'd like to see all three drivers use the same tveeprom
module (the one in mainline obviously), but I'd also would like to avoid
any hassle created by two incompatible tveeprom modules.  If ivtv adapts
the new interface quickly it probably isn't a big issue as it will take
some time until the tveeprom shows up in a mainline kernel.  Otherwise
we'll should figure some sane way to handle it.  Put it into mainline
with a different name maybe?

  Gerd

======================= [ tveeprom.h ] =======================
struct tveeprom {
        u32 has_radio;

        u32 tuner_type;
        u32 tuner_formats;

        u32 digitizer;
        u32 digitizer_formats;

        u32 audio_processor;
        /* a_p_fmts? */

        u32 model;
        u32 revision;
        u32 serial_number;
        char rev_str[5];
};

void tveeprom_hauppauge_analog(struct tveeprom *tvee,
                               unsigned char *eeprom_data);

int tveeprom_read(struct i2c_client *c, unsigned char *eedata, int len);
int tveeprom_dump(unsigned char *eedata, int len);


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
ivtv-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/ivtv-devel

Reply via email to