Hi
> Em 06-10-2010 16:52, Dmitri Belimov escreveu:
> > Hi
> >
> > Our TV card Behold X7 has two different RF input. This RF inputs
> > can switch between different RF sources.
> >
> > ANT 1 for analog and digital TV
> > ANT 2 for FM radio
> >
> > The switch controlled by zl10353.
> >
> > How to I can control this switch?
> >
> > I found 2 way
> >
> > 1.
> > Use tuner callback to saa1734. add some params like
> > XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h call tuner
> > callback from xc5000_set_analog_params with new params about
> > switching. In this case inside saa7134 need know about zl10353 and
> > configuration. I don't understand how to do. The structure
> > saa7134_dev hasn't pointer to the structure dvb_frontend. Or use
> > hardcoded i2c_addr and params.
> >
> > 2.
> > Direct call switch the switcher from the tuner code. In this case
> > need know TV card type. I think it is not so good idea.
>
> The issues between FM and TV mode is only a small part of a big
> problem that we're currently facing: drivers that support multiple
> types of streams, like radio, analog TV and digital TV need a way to
> avoid conflicts between different parts of the driver, and between a
> DVB and a V4L call.
>
> The long-term solution seems to implement a tuner/frontend resource
> reservation routine. This will solve other problems as well, like
> having both analog and digital parts of the driver trying to access
> the same resource at the same time.
>
> While implementing both analog and ISDB-T support for a saa7134-based
> board, I got one issue where analog tuner were trying to do RF
> callibration while the DVB demod were initialized. As the access to
> the demod requires one I2C gate setup and the access to the tuner
> requires another setup, both operations failed.
>
> We had similar problems in em28xx and cx231xx. Both were partially
> solved with a lock, but still if the user tries to open both DVB and
> V4L interfaces, it will likely have problems.
>
> So, we really need to implement some type of resource locking that
> will properly setup I2C gates, RF gates, etc, depending on the type
> of resource currently in use.
>
> Basically, the idea would be to implement something like:
>
> enum frontend_resource {
> ANALOG_TV_TUNER,
> DIGITAL_TV_TUNER,
> FM_TUNER,
> ANALOG_DEMOD,
> DIGITAL_DEMOD,
> };
>
> And add a new callback at struct dvb_frontend_ops():
>
> int (*set_resource)(struct dvb_frontend* fe, enum
> frontend_resource, bool reserve);
>
> Those callbacks may replace i2c_gate_ctrl().
>
> With those changes, when a driver needs to access, for example, a
> tuner at a dvb part of the driver, it would do:
>
> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, true);
> /* All i2c transactions and other operations needed at tuner */
> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, false);
>
> In other words, it will basically replace the current occurrences of
> i2c_gate_ctrl(), providing a clearer indication that the I2C change
> needed are to enable the access to the tuner.
>
> The fun begins if other parts of the driver try to do different
> things on resources that may be shared. They can now say that they
> want to access the demod with:
>
> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
>
> So, demods operations will be protected by:
>
> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
> /* All i2c transactions and other operations applied on demod
> */ fe->ops.set_resource(fe, DIGITAL_DEMOD, false);
>
> It is up to driver callback to handle this call. If both
> DIGITAL_DEMOD and DIGITAL_TV_TUNER are at the same i2c bus (e.g.
> there's no i2c gate), and if there's no risk for one I2C access to
> affect the other, the callback can just return 0. Otherwise, it may
> return -EBUSY and let the caller wait for the resource to be freed
> with: wake_up(fe->ops.set_resource(fe, DIGITAL_DEMOD, true) == 0); or
> wake_up_interruptible(fe->ops.set_resource(fe, DIGITAL_DEMOD,
> true) == 0);
>
> This way, when the resource is freed, the digital demod logic may
> happen.
>
> Comments?
What about hardware encoders? May be need switch between some TV and encoders.
Switch input source, output bus and other.
With my best regards, Dmitry.
> Thanks,
> Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
