[linux-dvb] Re: Example modifications to support request_firmware

[Holger Waechtler <holger@convergence.de>]

Johannes Stezenbach wrote:
> Holger Waechtler wrote:
>
> > As I read the device.h API it requires you to define a subsystem class - 
> > in our case either 'i2c' or 'dvb'. 'i2c' would add again a dependency to 
> > the kernel-i2c core, defining our own device class 'dvb' would cause 
> > serious problems when backporting the code to 2.4.
> >
> > But the latter is probably the better interpretation of the API 
> > intention and on the long term the only way I see to cleanly load 
> > firmwares into MPEG decoders or DSPs in STBs without PCI or USB or i2c 
> > bus (or any other bus with a predefined subsystem class in the 2.6 sense)
>
> The i2c bus and devices in the DVB driver will have to be registered
> with the Linux device infrastructure if we ever want to have working
> power management (e.g. a STB with *real* standby).
?!?

Can you please elaborate this in detail? The power management in 2.6 is 
not related to i2c, you probably mean that we need to implement the DVB 
device handling based on device.h - then we also get the required 
suspend/resume hooks.

And keep in mind that i2c is a european-only proprietary bus that forces 
chip vendors to pay license fees to Philips, alternative 1-wire, 8bit 
parallel, 3-wire and SPI busses are used in DVB and ATSC hardware, too - 
some revisions on the TT rev1.2 DVB-T cards even had the PLL connected 
via 3-wire bus -


> I believe that
> this is more work than sorting out the problems with the current
> kernel I2C implementation, and using that instead of our own.
you are aware of the fact that demodulators, and synthesizer/PLLs/tuner 
chips produced e.g. by Motorola, Broadcom and others don't have an i2c 
interface at all?

Misusing the kernel-i2c API for them is kind of a rapture since the 
i2c-core is tightly bound to the i2c algorithms/protocol. In our DVB 
infrastructure we don't include any protocol code, a simple 'sed -e 
"s/dvb_i2c/dvb_uC/g"' would make our infrastructure reusable by SPI, 
1-wire, i2c, 8bit parallel and all other microcontroller bus systems ( - 
for the kernel i2c code you probably need a little more efforts;).


> BTW: Recommended reading: http://lwn.net/Articles/driver-porting/
They suggest porting the code to the device class/kobject infrastructure 
- I'm sure this is unavoidable on the long term, but doing it now would 
castrate the 2.4 compability we still need until realtime and embedded 
kernels for 2.6 are ready, stable and widely used.

Holger



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.