Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux