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

[Johannes Stezenbach <js@linuxtv.org>]

Holger Waechtler wrote:
> Michael Hunold wrote:
> >IMHO using kernel i2c is the right thing to do.
> >
> >Not all i2c adapters have dedicated i2c hardware; bt8xx and cx88 need to 
> >use bitbanging, which is fully implemented in kernel i2c. With dvb i2c, 
> >the communication functions must be duplicated.
> 
> 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.

Autoprobing isn't braindead.

Braindead is that chip vendors omit the device id registers one
needs to do autoprobing _right_. (It's Philips' fault that they
didn't include device ids in the I2C spec.)

Anyway, now that we have some cases where autoprobing doesn't seem
to work we need a different method. But I'd guess we could try harder
in the probe method, e.g. try to reset the demod and then read a
register which has a known value after reset. It's not clean to
write to the chip before you know what chip it really is, but
maybe worth a try.

> 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.

If we omit I2C driver registration we lose the ability to do
request_firmware(), which was one of the reasons to use kernel
I2C in the first place.

> >Some frontends need firmware. With kernel i2c, firmware uploading is 
> >easily done through firmware_class interface without much hassle.
> 
> Thanks to Marko Kothala we have a sysfs/udev interface for every DVB 
> subdevice. See dvbdev.c.

Which doesn't work for firmware uploads, because it doesn't know
nothing about I2C. Even if you could sensibly do request_firmware()
you don't have access to the I2C bus where you want to write the
firmware to.

> 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.

No one claimed that one needs I2C to do firmware downloads.

The old syscalls-in-kernel firmware loaders are legacy crap.
Linux is OSS, but you still have to play by the rules given
by the main kernel maintainers. If Linux demands that we use
request_firmware() instead of sys_open()/sys_read(), then so
be it. If you want to argue against that, then please do it
on lkml and not here.

> 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.

A lot of embedded stuff uses kernel I2C quite happily. I would
even reckon that nearly no one writes their own I2C stuff just
to save a few K.

> >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.)

It may have been written for sensors/SMBUS stuff and not for DVB, but
IMHO the code is by far not as bad as you make it sound.

> 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.
> 
> 
> >-- 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.

The kernel I2C stuff is simple enough to fix so it works for DVB, and
last time Michael posted a patch for it they were quite happy to include it.
The bug reports on linux-dvb are only caused by in incomplete
transition from old to new frontend code, and a mismatch between the
stuff in the kernel and in CVS.


Have a nice day,
Johannes