[linux-dvb] Re: CX88 i2c issue w/ DVB tuners

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 12.09.2004 14:03, Holger Waechtler wrote:
> Michael Hunold wrote:
> > On 11.09.2004 19:36, Andrew de Quincey wrote:
> we don't talk about dvb_i2c but about removing the braindead autoprobing 
> infrastructure based on the i2c_client crap and replace it by simple 
> direct calls from the card driver.
Sorry, I didn't realize that.

> Basically the frontend ioctl and registration call moves to the card 
> driver and this one then directly calls a i2c_transfer() function (no 
> matter if a card-specific or the i2c-kernel one) with the card's adap 
> pointer.
>
> See 
> http://www.linuxtv.org:81/mailinglists/linux-dvb/2004/09-2004/msg00216.html 
> for a reference.
Your idea sounds nice. When we don't register the i2c client, no 
autoprobing will be done. We can access any i2c device nevertheless, 
because we still register the i2c_adapter.

Hm, but other non-dvb i2c-clients still can try to probe the exported 
i2c bus. This can of course be prohibited by only allowing known clients.

> > Some frontends need firmware. With kernel i2c, firmware uploading is 
> > easily done through firmware_class interface without much hassle.
> > This was impossible with dvb i2c, because there was no device file 
> > when the frontend was not fully registered and with no device file, no 
> > firmware upload.
> wrong, each frontend device has an attached sysfs device node.
Sure, but only after the frontend device has been recognized and 
registered. So there need to be two stages: recognized, but unconfigured 
(and thus no frontend device) and up-and-running.

> But it does not matters anyway since we were not talking about the 
> dvb_i2c code.
>
> The firmware argument for i2c is just void, we had trivial firmware 
> loaders implemented before and if we would rely on i2c for firmware 
> loading at all we would have a serious problem for demuxes and MPEG 
> decoders: I don't know any which has an i2c interface.
I hope you don't mean the direct-calls-to-vfs-approach for firmware 
loading. This simply doesn't work, because there might be no filesystems 
 at the time the frontend is recogized.

(I admit the same problem exists with firmware_class, but I have some 
patches that add a persistent storage for firmware_class where binary 
firmwares can be compiled into the kernel, so they are available at 
early boot.)

Please have a look at tda1004x.c for reference for i2c. It's one call to 
request_firmware() there which takes care of the firmware loading. When 
the device is recognized and attached to the i2c bus, the hotplug 
firmware loading can be done via the i2c device node (probably with 
hotplug) and afterwards the frontend instance is attached.

Firmware uploading for demuxes and MPEG decoders is a different story 
though, but can be achieved through the struct device member of the pci 
subsystem for example.

In the end, I fail to see the point where we should kill the whole i2c 
infrastructure just because we want to prevent autoprobing.

The subsystem gives us hotplug firmware loading for free and the device 
access works ok, too.

> > When i2c adapters and i2c clients all have a .class entry, it will be 
> > possible to isolate dvb completely, ie. no more probes from other i2c 
> > drivers from other subsystems.
> But you still rely on a bloated subsystem and don't have any support for 
> non-i2c chipsets.
>
> Both approaches are not acceptable in embedded environments.
Sorry, I don't understand that argument. We are talking about frontends 
right?

IMO i2c frontends should be accessed through kernel i2c. Non-i2c 
frontends can be accessed in whatever a way they are supposed to be 
accessed.

Both types of frontends register to dvb_register_frontend() and are 
accessed through the dvb frontend code. In that part of the code, i2c 
isn't present anymore after I cleaned that up a while ago.

In embedded environments, you are free to not use kernel i2c, even if 
the frontend is i2c based. Simply put all the frontend/i2c stuff inside 
the frontend driver and it's ok.

(Please note that this has not been possible with the code a few months 
ago. There, dvb frontend was tightly coupled to dvb i2c, so no non-i2c 
frontend could have been used with that code)

> > I wouldn't care when kernel i2c would be crappy code inside (which I 
> > thing it isn't)
> :) (it is - really: I've rarely seen anything broken-by-concept like 
> this. And I've rarely seen anybody fighting like a pitbull for such a 
> stupid concept.)
>
> Remember: i2c is a trivial protocol: two wires only and ususally 
> controlled by 3-8 registers on the host controller. Really nothing to 
> write tens of thousands of lines of code around it.
For the sake of reusability of the drivers (mostly thermal sensor I 
think) you need some kind of driver abstraction. (struct i2c_driver)

For representing an instance of that driver, you need struct i2c_client.

You need an abstraction of the underlying bus, struct i2c_adapter.

It's cool to have bit-banging abstracted, so you need struct i2c_algorithm.

For bringing something over to a client, you need i2c_msg.

For supporting stripped-down versions of i2c like smbus, you need some 
kind of message send/receive translation stuff.

That is all that's inside i2c.h and I don't know how this can be any 
more basic.

I admit that there should have been some more infrastructure to honour 
the aspect that i2c chipsets can be used in very different setups and so 
there should have been some stuff for passing intial configuration 
setups around.

I agree that we can argue about the stupid autoprobing stuff and perhaps 
there should be a way to disable it all along and let pci drivers 
instead give hints about useful connections.

> > -- that's other people's playground, as long as I can use it.
> That's exactly our problem. It does not works reliably in our usecase, 
> just grep for i2c and firmware-related problems in your linux-dvb inbox 
> before and after the big kernel-i2c move. The number of bug-reports, 
> problems discussions how to solve them and proposals for 'workarounds' 
> raised by a factor ways larger than ten.
That's simply not true. Transition periods always create problems, sure. 
In our case, the problem probably was that this change wasn't announced 
and non-developers didn't notice it at all. So they were updated their 
tree and suddenly their setup stopped working because the firmware 
wasn't read automatically anymore.

I don't know why you think it doesn't work reliably. For the setup of 
cards I have ready it works well, with multiple different cards with 
different frontends in one system.

And in the end, the main linux people and vendors will be happy when the 
dvb subsystems fits more nicely into the kernel, because special 
handling for the things we are currently talking about (i2c, firmware) 
will be done the way it's supposed to in the kernel.

Please have a look at my other mail to Andrew for my suggestions how to 
solve the current problems.

CU
Michael.