[linux-dvb] Re: [PATCHES] Frontend kernel i2c conversion.

[Kenneth Aafløy <lists@kenneth.aafloy.net>]

> On Sun, Jul 18, 2004 at 01:04:02AM +0200, Kenneth Aafløy wrote:
> > On Sunday 18 July 2004 00:09, Ralph Metzler wrote:
> > > No, I also considered this before implementing the FE_(UN)REGISTER
> > > stuff but adapters with more than one I2C bus/frontend will not work
> > > like this. It also makes the frontend driver and dvbdev depend on I2C
> > > driver structs even if you are not using I2C.
> >
> > Hmm, there is no drivers in CVS which has more than one I2C bus, is
> > there?

On Sunday 18 July 2004 01:59, Ralph Metzler wrote:
> No, but I know of at least one driver/hardware with more than one I2C bus.

On Monday 19 July 2004 00:15, Johannes Stezenbach wrote:
> It is very common for STB chips to have more than one I2C controller --
> which doesn't mean that all I2C buses are used to connect DVB frontends,
> but it is not unexpected for a dual-FE box to have each FE on its own I2C
> bus.

Ok, so there is hardware with both multiple I2C buses and frontends, nice to 
know. What I wonder about now, is how are these implemented multiple frontend 
drivers implemented? Would this x extra frontend be registered together with 
the same adapter or will there be multiple adapters, each attached to their 
frontend?

> > > Hmm, actually, forget about the last paragraph. There are even more
> > > problems, e.g. with the order of module loading, if the dvb_adapter
> > > is registered after the I2C bus (like with the bt878 cards).
> >
> > I've split up the dvb_register_frontend in this version, because like
> > you, I realized that the previous patch would not even work. This new
> > version works as expected wether or not the dvb adapter has been
> > registered when the i2c bus is up and running. I have had no opportunity
> > to test the bttv driver, but it should work with the converted frontend
> > now.

On Sunday 18 July 2004 01:59, Ralph Metzler wrote:
> This now definitely only works with one frontend.
>
> You will also have to lock frontend registering against adapter
> registering now to remove the new possible race conditions.

On Monday 19 July 2004 00:15, Johannes Stezenbach wrote:
> Something's wrong with your patchset. In dvb-bt8xx.c you *added*
> the client_register() functions (unused), while you removed them
> everywhere else. Also, IIRC the skystar2 I2C stuff is a bit special
> and will fail for general use (that's why the funny checks in
> master_xfer() are there).

I was a bit quick on the trigger here. I originally started looking at how to 
make the bt driver do the i2c client command stuff, then realized that it 
would require changes to the core bttv driver. Just forgot to remove those 
thats all.

About the skystar2 driver, I just ripped out what I assumed was legacy i2c bus 
functions without checking/testing, so that broke, since the skystar2 uses 
the old master_xfer/legacy i2c bus to do the work for the kernel i2c bus. 
It's not like this was intended for inclusion into CVS right away, but more 
like a suggestion on how it might be solved so I was a bit sloppy here.

On Sunday 18 July 2004 01:59, Ralph Metzler wrote:
> What happens if the bt878 DVB driver is removed and not bttv? Is the
> frontend device removed in this case?

The frontend i2c client will still be attached to the bttv i2c adapter, and 
the frontend thread will probably crash because of dangling dvb_adapter 
pointers. I didn't look at how the order of destruction *really* is here, 
it's just an assumption.

> Sorry, but to get all this done properly in the way you want to do it
> (i.e. without the kernel i2c registration callback) you will basically
> have to reimplement the whole dvb_i2c layer again ...

And that is unacceptable, is it not? Because the goal here is to remove that 
layer completly, or have I missed something.

Kenneth