Mauro:
Thanks a lot ! This explanation is what I referred to as a roadmap, as I
see not all current devices use this decoupling.
Andy, John, Barnaby:
By now, I'd like to split up some tasks.
Have you been able to install the branch that Mauro has set up ?
And have you been able to use the stick ?
Please confirm so; I haven't heard from you in a while.
I think we hace three basic tasks:
1) writing a script that takes care of coding style issuse
2) figuring out how to split up the code to use tuner.ko
3) Using drivers/media/common/ir-keymaps for IR codes and implement
switching (see my mails with Chialing).
Any volunteers for these tasks ?
Mauro Carvalho Chehab wrote:
> On Mon, 17 Mar 2008 20:36:12 +0100
> Jan Hoogenraad <jan-conceptronic@xxxxxxxx> wrote:
>
>> Mauro:
>>
>> Most of the mail understood.
>>
>> Can you put us into contact with the people who did the decoupling to
>> the tuner for for example, with saa711x ?
>> We could re-use some of their work, and learn from them.
>
> Several developers ;)
>
> First of all, there are two different behaviors, userspace and kernelspace
> API's being one for analog and another for digital. This is due to historic
> reasons.
>
> The decoupling is via I2C interface. Basically, each i2c driver is independent.
> Kernel Documentation/i2c explains the usage of I2C.
>
> In the case of tuner and saa711x, those are two independent drivers, used
> (mostly) by analog mode.
>
> tuner.ko module contains tuner-core.c. There are several other tuner drivers
> that can be bound to tuner.ko or to a frontend driver.
>
> On i2c normal way for analog TV, composite/svideo and FM, it probes I2C bus for
> the presence of I2C devices by sending a read message with 0 bytes. If some
> answer is given, this means that an I2C device is present there. When something
> is detected, an attach callback is called. For example, attach_inform(), on
> cx88-i2c. The attach_inform() then configures that device, if needed.
>
> A newer method for probing is starting to be implemented, on ivtv driver.
>
> Both tuner and saa711x implements a "command" interface. The command is meant
> to receive requests for tuning and other things, like changing video
> standard. All I2C devices listen to the I2C command. So, when you change a
> video standard, tuner may set the proper IF, while saa711x can send the proper
> initialization codes for that video standard.
>
> In order to better support hybrid devices, tuner now is implemented on separate files.
> tuner.ko is just the core, meant to be use by analog/svideo/composite or radio mode.
>
> The tuner, itself, can work with both V4L and DVB API's. This is warranted by
> the usage of callbacks.
>
> For digital TV, there are several callbacks. In the case of a tuner, for
> example xc2028, the driver fills an structure with the callbacks:
>
> static const struct dvb_tuner_ops xc2028_dvb_tuner_ops = {
> .info = {
> .name = "Xceive XC3028",
> .frequency_min = 42000000,
> .frequency_max = 864000000,
> .frequency_step = 50000,
> },
>
> .set_config = xc2028_set_config,
> .set_analog_params = xc2028_set_analog_freq,
> .release = xc2028_dvb_release,
> .get_frequency = xc2028_get_frequency,
> .get_rf_strength = xc2028_signal,
> .set_params = xc2028_set_params,
> .sleep = xc2028_sleep,
>
> #if 0
> int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
> int (*get_status)(struct dvb_frontend *fe, u32 *status);
> #endif
> };
>
> The above struct contains both callbacks for analog and digital.
>
> dvb core will call the proper callbacks when needed. For example, set_params
> select the proper DVB mode, and tune to an specific frequency.
>
> There are similar callbacks also for DVB frontend (a frontend is a tuner plus
> a demod - and, for DVB-S, the LNBf control interface).
>
>> A similar thing goes for the IR devices.
>> Currently, these sticks are shipped with 3 different IR devices, with
>> different (and sometimes conflicting) IR codes.
>
> IR scan tables can be inside drivers/media/common/ir-keymaps. The hanlding for
> gpio RC5 is provided at ir-common.ko.
>
> For I2C, there's a special module for handling this (ir_i2c_kbd). This is also
> a generic module. The attach callback is used to setup the specific parameters
> for each IR.
>
>> I see that there are two different mechanisms used in the drivers.
>>
>> The cxusb.c driver shows how to switch based on the USB ID of the stick.
>>
>> The hauppage driver, with ir-kbd-i2c.c and ir-keymaps.c shosw how to
>> switch based on module parameters (mechanism similar to the debug=1).
>
> The usage of module parameters should be used only when other mechanisms aren't
> possible. The preferred way is to detect board characteristics via reading the
> board eeprom, if available. Hauppauge detection is very good, for most things,
> due to tveeprom.ko. There's a parser there to read their info inside the eeprom.
>
> This saves a lot of space inside kernel to handle all differences between the boards.
>
> If this is not possible, the next option is to use USB ID or PCI ID. However,
> sometimes, unfortunately, a cheap board doesn't have an unique PCI ID. So, the
> only way is to provide module options.
>
>> Can you tell me if there is a roadmap for this (e.g. decoupling the
>> mapping from the stick ID and putting the rc_query subroutines together) ?
>
> What do you mean?
>
>> In the next patch, I'll add a file
>> /linux/Documentation/dvb/README.rtl2831
>> with some data I got from Realtek.
>
> Good.
>
> Cheers,
> Mauro
>
>
--
Jan Hoogenraad
Hoogenraad Interface Services
Postbus 2717
3500 GS Utrecht
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
