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

[Johannes Stezenbach <js@convergence.de>]

Holger Waechtler wrote:
> Andrew de Quincey wrote:
> >On Wednesday 28 January 2004 16:21, Holger Waechtler wrote:
> >
> >>Andrew de Quincey wrote:
> >>
> >>>Hi, this patch is an example of how the changes to support
> >>>request_firmware might be done. I've only made the neccessary changes to
> >>>certain example devices. It probably won't compile.
> >>>
> >>>Please let me know what you think.
> >>
> >>Hmmm - what exactly is the meaning of this device struct - it's not
> >>attached to a device but to the adapter which has no matching device
> >>node, not? Am I misunderstanding something?

It represents a piece of hardware in the device tree. It's also
the basis for the sysfs implementation, and hence necessary for
the firmware loader.

I thought Andrew wants to (mis-) use the struct device * from
the PCI adapter to let it do the firmware loading for I2C
connected devices. Which is fine for now, but might be rejected
on lkml if they notice...

One problem: If you need two firmwares for one adapter, can
you avoid race conditions?

> >Its the linux device structure as defined in linux/device.h..... it made 
> >sense to me to attach it to the adapter because the adapter is the thing 
> >physically plugged into a bus on the machine, not the DVB-devices which 
> >are things attached to the adapter.
> 
> 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). 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.


BTW: Recommended reading: http://lwn.net/Articles/driver-porting/


just my 2¢
johannes


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