Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
On 10/14/2010 11:41 AM, Devin Heitmueller wrote: On Thu, Oct 14, 2010 at 4:33 AM, Antti Palosaari wrote: I haven't examined this yet enough, but for the background information I can say I have one device which needs this. There is tuner behind demodulator, but instead of normal I2C-gate switch, it is rather much likely repeater. All tuner commands are send to the demod which then writes those to the tuner. DD = demod I2C addr TT = tuner I2C addr Bn = payload data traditional I2C send to the tuner: TT>> B0 B1 B2 ... demod as repeater send to the tuner: DD>> TT B0 B1 B2 ... You can accomplish this by having the demod create an i2c adapter instance, which generates i2c commands to the bridge. Then when instantiating the tuner subdev, pass a pointer to the demod's i2c adapter instead of the i2c adapter provided by the bridge. No changes required to the core framework. Thank you Devin. I didn't realized that earlier. It worked just fine. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
On Thu, Oct 14, 2010 at 4:33 AM, Antti Palosaari wrote: > I haven't examined this yet enough, but for the background information I can > say I have one device which needs this. There is tuner behind demodulator, > but instead of normal I2C-gate switch, it is rather much likely repeater. > All tuner commands are send to the demod which then writes those to the > tuner. > > DD = demod I2C addr > TT = tuner I2C addr > Bn = payload data > > traditional I2C send to the tuner: > TT >> B0 B1 B2 ... > > demod as repeater send to the tuner: > DD >> TT B0 B1 B2 ... You can accomplish this by having the demod create an i2c adapter instance, which generates i2c commands to the bridge. Then when instantiating the tuner subdev, pass a pointer to the demod's i2c adapter instead of the i2c adapter provided by the bridge. No changes required to the core framework. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
On 10/06/2010 03:40 PM, Mauro Carvalho Chehab wrote:
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,
};
I haven't examined this yet enough, but for the background information I
can say I have one device which needs this. There is tuner behind
demodulator, but instead of normal I2C-gate switch, it is rather much
likely repeater. All tuner commands are send to the demod which then
writes those to the tuner.
DD = demod I2C addr
TT = tuner I2C addr
Bn = payload data
traditional I2C send to the tuner:
TT >> B0 B1 B2 ...
demod as repeater send to the tuner:
DD >> TT B0 B1 B2 ...
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
Hi Mauro
> Em 07-10-2010 10:00, Dmitri Belimov escreveu:
> > 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.
>
> Yeah, we may need to add encoders here, and other stuff like IR and
> CA modules.
>
> an approach like that is easy to extend, as new issues that may
> require resource reservation is added.
Are you wrote this feature already? I'll try it on my boards.
Some description need :)
> Cheers,
> Mauro
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to maj
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
Em 07-10-2010 10:00, Dmitri Belimov escreveu:
> 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.
Yeah, we may need to add encoders here, and other stuff like IR and CA modules.
an approach like that is easy to extend, as new issues that may require
resource reservation is added.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
