Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: CX88 i2c issue w/ DVB tuners
Andrew de Quincey writes:
> On Friday 10 Sep 2004 13:10, Ralph Metzler wrote:
> > Holger Waechtler writes:
> > > Andrew de Quincey wrote:
> > > > Yeah, that sounds good. So effectively the frontend drivers will cease
> > > > to be kernel i2c devices. However, we'll still use the kernel i2c for
> > > > the adapter's i2c buses if need be, so no one can complain we're
> > > > duplicating stuff again. That makes sense - theres no point really in
> > > > making the frontends generic devices usable by non-DVB code.
> > > >
> > > > How will we prevent things like that tda9887 tuner from taking over
> > > > our addresses on the bus accidentally if our bus is marked as ANALOGUE
> > > > and DIGITAL? We should probably claim addresses on the bus that we use
> > > > - but it all depends on what order things are loaded in.
> > >
> > > I would not claim any addresses, why should we? Even registration to the
> > > kernel i2c API is optional (and only introduces delays and the risk of
> > > accidentally attached devices from other subsystems).
> > >
> > > The generic i2c_read/write() implementations in the card drivers should
> > > allow writes to all addresses. If not we should fix them, we're
> > > maintaining them anyway. We also need to ensure they are correctly
> > > locking on the low level because we don't rely on the i2c layer locking
> > > mechanism anymore (but last time I checked most drivers implemented
> > > correct semaphores, so this should not really be a problem).
> > >
> > > If properly done both systems can existence peacefully in coexistence
> > > and concurrent accesses are allowed (like it was the case for the
> > > dvb_i2c_bus code).
>
> Sorry! hit the wrong key before.
>
> > And what exactly are the advantages of having these two systems for
> > similar things again?
> > You will again have a lot of code duplication with only minimal
> > differences depending on the card type and necessary fixes
> > (like the locking) to make it work with existing structures if
> > you happen to need other i2c clients.
>
> yeah, I don't like having multiple i2c implementations hitting the same bus.
> Thats why I would prefer to use the kernel i2c implementation where possible,
> since it handles locking and bitbanging (if necessary) for us.
>
> > Getting rid of wrong attaches is easily done by introducing a
> > client type field as I described before or just by getting an id range
> > reserved in i2c-id.h as it is already done for sensors and V4L2 common
> > components (is the latter used yet?).
>
> We can't have an id per frontend - from what Holger described about the
> binary-only firmwares.
Completely closed drivers could still use their own thin I2C layers or
other means (see below).
I see how what Holger describes would make things a little bit
easier for pure DVB drivers if you want to use existing
i2c clients you get added complexity.
But I can see how one could use such a really thin layer and
alternatively either put a generic i2c kernel client registration
layer above it or use it directly with a DVB driver if the latter
really does not need anything else.
> Isn't a client-type field the same as the clients testing the adapter type
> field to check that it meets what they expect?
Testing the adapter type in the client allows the client to prevent
attaching to non-DVB adapters but the adapter might still get attach
callbacks from unwanted other clients or from DVB frontends it
does not know.
If the client would have a type of DVB demodulator or would be in the id
range of DVB demodulators the adapter also could always attach and
register it as a frontend, even if it does not know this specific one.
Configuration of specific frontend subtypes could still be handled by
SET_TYPE calls or even config table upload calls.
You could also add your own secret GET_TYPE calls where the frontend
tells the adapter what kind it is if you really do not want one
id per frontend for those binary-only drivers.
Ralph
Home |
Main Index |
Thread Index