Commit Message
Hi All
This is my next patch.
Changes:
1. By default charge pump is ON
2. For radio mode charge pump set to OFF
3. Set correct AGC value in radio mode
4. Add control gain of AGC.
5. New function simple_get_tv_gain and simple_set_tv_gain for read/write gain of AGC.
6. Add some code for control gain from saa7134 part. By default this control is OFF 7. When TV card can
manipulate this control, enable it.
Main changes is control value of AGC TOP in .initdata = tua603x_agc112 array. Use this value for set AGC TOP after set freq of TV.
I don't understand how to correct call new function for read/write value of AGC TOP.
What you think about it??
With my best regards, Dmitry.
Comments
On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> Hi All
>
> This is my next patch.
>
> Changes:
> 1. By default charge pump is ON
> 2. For radio mode charge pump set to OFF
> 3. Set correct AGC value in radio mode
> 4. Add control gain of AGC.
> 5. New function simple_get_tv_gain and simple_set_tv_gain for read/write gain of AGC.
> 6. Add some code for control gain from saa7134 part. By default this control is OFF 7. When TV card can
> manipulate this control, enable it.
>
> Main changes is control value of AGC TOP in .initdata = tua603x_agc112 array. Use this value for set AGC TOP after set freq of TV.
>
> I don't understand how to correct call new function for read/write value of AGC TOP.
>
> What you think about it??
>
[patch snipped]
>
>
> With my best regards, Dmitry.
Dmitry,
The direct usage of .initdata and .sleepdata is probably unnecessary
here -- If you trace how the tuner-simple driver works, you'll find
that simply having these fields defined will cause these bytes to be
written at the appropriate moment.
However, for the actual sake of setting this gain value, I'm not sure
that initdata / sleep data is the right place for it either. (I know
that I recommended something like this at first, but at the time I
didn't realize that there is a range of six acceptable values for this
field)
What I would still like to understand is: Who will be changing this
value? I see that you've added a control to the saa7134 driver -- is
this to be manipulated from userspace? Under what conditions will
somebody want to change this value? How will users know that they
need to alter this gain value?
Apologies for the late response.
Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 14 Sep 2009 08:55:22 -0400
Michael Krufky <mkrufky@kernellabs.com> wrote:
> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
> wrote:
> > Hi All
> >
> > This is my next patch.
> >
> > Changes:
> > 1. By default charge pump is ON
> > 2. For radio mode charge pump set to OFF
> > 3. Set correct AGC value in radio mode
> > 4. Add control gain of AGC.
> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
> > read/write gain of AGC. 6. Add some code for control gain from
> > saa7134 part. By default this control is OFF 7. When TV card can
> > manipulate this control, enable it.
> >
> > Main changes is control value of AGC TOP in .initdata =
> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
> > of TV.
> >
> > I don't understand how to correct call new function for read/write
> > value of AGC TOP.
> >
> > What you think about it??
> >
>
> [patch snipped]
>
> >
> >
> > With my best regards, Dmitry.
>
> Dmitry,
>
> The direct usage of .initdata and .sleepdata is probably unnecessary
> here -- If you trace how the tuner-simple driver works, you'll find
> that simply having these fields defined will cause these bytes to be
> written at the appropriate moment.
>
> However, for the actual sake of setting this gain value, I'm not sure
> that initdata / sleep data is the right place for it either. (I know
> that I recommended something like this at first, but at the time I
> didn't realize that there is a range of six acceptable values for this
> field)
>
> What I would still like to understand is: Who will be changing this
> value? I see that you've added a control to the saa7134 driver -- is
> this to be manipulated from userspace?
Yes
> Under what conditions will somebody want to change this value?
for SECAM with strong signal we have wide white crap on the screen.
Need reduce value of AGC TOP.
For weak signal need increase value of AGC TOP
Ajust value of AGC TOP can get more better image quality.
> How will users know that they need to alter this gain value?
By default use value from .initdata
v4l2-ctl can modify this value or via some plugins for TV wach programm.
End-user programm for watch TV IMHO now is very poor.
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> On Mon, 14 Sep 2009 08:55:22 -0400
> Michael Krufky <mkrufky@kernellabs.com> wrote:
>
>> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
>> wrote:
>> > Hi All
>> >
>> > This is my next patch.
>> >
>> > Changes:
>> > 1. By default charge pump is ON
>> > 2. For radio mode charge pump set to OFF
>> > 3. Set correct AGC value in radio mode
>> > 4. Add control gain of AGC.
>> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
>> > read/write gain of AGC. 6. Add some code for control gain from
>> > saa7134 part. By default this control is OFF 7. When TV card can
>> > manipulate this control, enable it.
>> >
>> > Main changes is control value of AGC TOP in .initdata =
>> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
>> > of TV.
>> >
>> > I don't understand how to correct call new function for read/write
>> > value of AGC TOP.
>> >
>> > What you think about it??
>> >
>>
>> [patch snipped]
>>
>> >
>> >
>> > With my best regards, Dmitry.
>>
>> Dmitry,
>>
>> The direct usage of .initdata and .sleepdata is probably unnecessary
>> here -- If you trace how the tuner-simple driver works, you'll find
>> that simply having these fields defined will cause these bytes to be
>> written at the appropriate moment.
>>
>> However, for the actual sake of setting this gain value, I'm not sure
>> that initdata / sleep data is the right place for it either. (I know
>> that I recommended something like this at first, but at the time I
>> didn't realize that there is a range of six acceptable values for this
>> field)
>>
>> What I would still like to understand is: Who will be changing this
>> value? I see that you've added a control to the saa7134 driver -- is
>> this to be manipulated from userspace?
>
> Yes
>
>> Under what conditions will somebody want to change this value?
>
> for SECAM with strong signal we have wide white crap on the screen.
> Need reduce value of AGC TOP.
>
> For weak signal need increase value of AGC TOP
> Ajust value of AGC TOP can get more better image quality.
>
>> How will users know that they need to alter this gain value?
>
> By default use value from .initdata
> v4l2-ctl can modify this value or via some plugins for TV wach programm.
>
> End-user programm for watch TV IMHO now is very poor.
>
> With my best regards, Dmitry.
>
I have to admit that I am not familiar enough with SECAM myself to see
this kind of trouble. For NTSC and PAL, tvtime is a great application
-- the only shortcoming that bothers me about tvtime is lack of audio
support. One must rely on a separate mechanism to hear audio, whether
it's a patch cable from the tv tuner to the sound board, or a separate
application decoding DMA audio. ...but that is not what this email
thread is about.
As far as simple tuning and analog television viewing goes, tvtime
rocks. Is it really that difficult for SECAM users?
In summary, you are telling us that we need to add userspace controls
to handle gain control, for tuning SECAM. I am going to have to ask
for help on this topic from those cc'd on this email. (Adding Hans
Verkuil, as I value his opinion for controls and dealing with video
standards in high regard)
Personally, I don't quite understand why we would need to add such
controls NOW, while we've supported this video standard for years
already. I am not arguing against this in any way, but I dont feel
like I'm qualified to accept this addition without hearing the
opinions of others first.
Can somebody help to shed some light?
Cheers,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky:
> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> > On Mon, 14 Sep 2009 08:55:22 -0400
> > Michael Krufky <mkrufky@kernellabs.com> wrote:
> >
> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
> >> wrote:
> >> > Hi All
> >> >
> >> > This is my next patch.
> >> >
> >> > Changes:
> >> > 1. By default charge pump is ON
> >> > 2. For radio mode charge pump set to OFF
> >> > 3. Set correct AGC value in radio mode
> >> > 4. Add control gain of AGC.
> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
> >> > read/write gain of AGC. 6. Add some code for control gain from
> >> > saa7134 part. By default this control is OFF 7. When TV card can
> >> > manipulate this control, enable it.
> >> >
> >> > Main changes is control value of AGC TOP in .initdata =
> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
> >> > of TV.
> >> >
> >> > I don't understand how to correct call new function for read/write
> >> > value of AGC TOP.
> >> >
> >> > What you think about it??
> >> >
> >>
> >> [patch snipped]
> >>
> >> >
> >> >
> >> > With my best regards, Dmitry.
> >>
> >> Dmitry,
> >>
> >> The direct usage of .initdata and .sleepdata is probably unnecessary
> >> here -- If you trace how the tuner-simple driver works, you'll find
> >> that simply having these fields defined will cause these bytes to be
> >> written at the appropriate moment.
> >>
> >> However, for the actual sake of setting this gain value, I'm not sure
> >> that initdata / sleep data is the right place for it either. (I know
> >> that I recommended something like this at first, but at the time I
> >> didn't realize that there is a range of six acceptable values for this
> >> field)
> >>
> >> What I would still like to understand is: Who will be changing this
> >> value? I see that you've added a control to the saa7134 driver -- is
> >> this to be manipulated from userspace?
> >
> > Yes
> >
> >> Under what conditions will somebody want to change this value?
> >
> > for SECAM with strong signal we have wide white crap on the screen.
> > Need reduce value of AGC TOP.
> >
> > For weak signal need increase value of AGC TOP
> > Ajust value of AGC TOP can get more better image quality.
> >
> >> How will users know that they need to alter this gain value?
> >
> > By default use value from .initdata
> > v4l2-ctl can modify this value or via some plugins for TV wach programm.
> >
> > End-user programm for watch TV IMHO now is very poor.
> >
> > With my best regards, Dmitry.
> >
>
> I have to admit that I am not familiar enough with SECAM myself to see
> this kind of trouble. For NTSC and PAL, tvtime is a great application
> -- the only shortcoming that bothers me about tvtime is lack of audio
> support. One must rely on a separate mechanism to hear audio, whether
> it's a patch cable from the tv tuner to the sound board, or a separate
> application decoding DMA audio. ...but that is not what this email
> thread is about.
>
> As far as simple tuning and analog television viewing goes, tvtime
> rocks. Is it really that difficult for SECAM users?
>
> In summary, you are telling us that we need to add userspace controls
> to handle gain control, for tuning SECAM. I am going to have to ask
> for help on this topic from those cc'd on this email. (Adding Hans
> Verkuil, as I value his opinion for controls and dealing with video
> standards in high regard)
>
> Personally, I don't quite understand why we would need to add such
> controls NOW, while we've supported this video standard for years
> already. I am not arguing against this in any way, but I dont feel
> like I'm qualified to accept this addition without hearing the
> opinions of others first.
>
> Can somebody help to shed some light?
>
> Cheers,
>
> Mike
Mike,
i did discuss this with Dmitri a lot on the list previously.
I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in
China, to convince him not to do that for the original Philips tuners.
Andy was also pretty active on it, thanks for your help.
However, it is for now only about that TCL MK3, using different filters
than the original Philips stuff, and their labs have clear results, that
they can improve SECAM-DK this way for their users.
Cheers,
Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton
<hermann-pitton@arcor.de> wrote:
>
> Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky:
>> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
>> > On Mon, 14 Sep 2009 08:55:22 -0400
>> > Michael Krufky <mkrufky@kernellabs.com> wrote:
>> >
>> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
>> >> wrote:
>> >> > Hi All
>> >> >
>> >> > This is my next patch.
>> >> >
>> >> > Changes:
>> >> > 1. By default charge pump is ON
>> >> > 2. For radio mode charge pump set to OFF
>> >> > 3. Set correct AGC value in radio mode
>> >> > 4. Add control gain of AGC.
>> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
>> >> > read/write gain of AGC. 6. Add some code for control gain from
>> >> > saa7134 part. By default this control is OFF 7. When TV card can
>> >> > manipulate this control, enable it.
>> >> >
>> >> > Main changes is control value of AGC TOP in .initdata =
>> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
>> >> > of TV.
>> >> >
>> >> > I don't understand how to correct call new function for read/write
>> >> > value of AGC TOP.
>> >> >
>> >> > What you think about it??
>> >> >
>> >>
>> >> [patch snipped]
>> >>
>> >> >
>> >> >
>> >> > With my best regards, Dmitry.
>> >>
>> >> Dmitry,
>> >>
>> >> The direct usage of .initdata and .sleepdata is probably unnecessary
>> >> here -- If you trace how the tuner-simple driver works, you'll find
>> >> that simply having these fields defined will cause these bytes to be
>> >> written at the appropriate moment.
>> >>
>> >> However, for the actual sake of setting this gain value, I'm not sure
>> >> that initdata / sleep data is the right place for it either. (I know
>> >> that I recommended something like this at first, but at the time I
>> >> didn't realize that there is a range of six acceptable values for this
>> >> field)
>> >>
>> >> What I would still like to understand is: Who will be changing this
>> >> value? I see that you've added a control to the saa7134 driver -- is
>> >> this to be manipulated from userspace?
>> >
>> > Yes
>> >
>> >> Under what conditions will somebody want to change this value?
>> >
>> > for SECAM with strong signal we have wide white crap on the screen.
>> > Need reduce value of AGC TOP.
>> >
>> > For weak signal need increase value of AGC TOP
>> > Ajust value of AGC TOP can get more better image quality.
>> >
>> >> How will users know that they need to alter this gain value?
>> >
>> > By default use value from .initdata
>> > v4l2-ctl can modify this value or via some plugins for TV wach programm.
>> >
>> > End-user programm for watch TV IMHO now is very poor.
>> >
>> > With my best regards, Dmitry.
>> >
>>
>> I have to admit that I am not familiar enough with SECAM myself to see
>> this kind of trouble. For NTSC and PAL, tvtime is a great application
>> -- the only shortcoming that bothers me about tvtime is lack of audio
>> support. One must rely on a separate mechanism to hear audio, whether
>> it's a patch cable from the tv tuner to the sound board, or a separate
>> application decoding DMA audio. ...but that is not what this email
>> thread is about.
>>
>> As far as simple tuning and analog television viewing goes, tvtime
>> rocks. Is it really that difficult for SECAM users?
>>
>> In summary, you are telling us that we need to add userspace controls
>> to handle gain control, for tuning SECAM. I am going to have to ask
>> for help on this topic from those cc'd on this email. (Adding Hans
>> Verkuil, as I value his opinion for controls and dealing with video
>> standards in high regard)
>>
>> Personally, I don't quite understand why we would need to add such
>> controls NOW, while we've supported this video standard for years
>> already. I am not arguing against this in any way, but I dont feel
>> like I'm qualified to accept this addition without hearing the
>> opinions of others first.
>>
>> Can somebody help to shed some light?
>>
>> Cheers,
>>
>> Mike
>
> Mike,
>
> i did discuss this with Dmitri a lot on the list previously.
>
> I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in
> China, to convince him not to do that for the original Philips tuners.
>
> Andy was also pretty active on it, thanks for your help.
>
> However, it is for now only about that TCL MK3, using different filters
> than the original Philips stuff, and their labs have clear results, that
> they can improve SECAM-DK this way for their users.
Thanks for the comment, Hermann.
Do you think there is any way that we can automate this without having
to expose an additional user control?
If you believe that it's necessary, I am fine with adding this, but I
will need Mauro to agree on it as well -- that's why I'm asking for
some argument points.
Some questions that he might ask -- why do we need this in the saa7134
driver but not the other drivers? Is this specific to this TCL MK3
only? Could doing this help to improve SECAM support for users of
other tuners?
Cheers,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
Am Dienstag, den 15.09.2009, 00:55 -0400 schrieb Michael Krufky:
> On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton
> <hermann-pitton@arcor.de> wrote:
> >
> > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky:
> >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> >> > On Mon, 14 Sep 2009 08:55:22 -0400
> >> > Michael Krufky <mkrufky@kernellabs.com> wrote:
> >> >
> >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
> >> >> wrote:
> >> >> > Hi All
> >> >> >
> >> >> > This is my next patch.
> >> >> >
> >> >> > Changes:
> >> >> > 1. By default charge pump is ON
> >> >> > 2. For radio mode charge pump set to OFF
> >> >> > 3. Set correct AGC value in radio mode
> >> >> > 4. Add control gain of AGC.
> >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
> >> >> > read/write gain of AGC. 6. Add some code for control gain from
> >> >> > saa7134 part. By default this control is OFF 7. When TV card can
> >> >> > manipulate this control, enable it.
> >> >> >
> >> >> > Main changes is control value of AGC TOP in .initdata =
> >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
> >> >> > of TV.
> >> >> >
> >> >> > I don't understand how to correct call new function for read/write
> >> >> > value of AGC TOP.
> >> >> >
> >> >> > What you think about it??
> >> >> >
> >> >>
> >> >> [patch snipped]
> >> >>
> >> >> >
> >> >> >
> >> >> > With my best regards, Dmitry.
> >> >>
> >> >> Dmitry,
> >> >>
> >> >> The direct usage of .initdata and .sleepdata is probably unnecessary
> >> >> here -- If you trace how the tuner-simple driver works, you'll find
> >> >> that simply having these fields defined will cause these bytes to be
> >> >> written at the appropriate moment.
> >> >>
> >> >> However, for the actual sake of setting this gain value, I'm not sure
> >> >> that initdata / sleep data is the right place for it either. (I know
> >> >> that I recommended something like this at first, but at the time I
> >> >> didn't realize that there is a range of six acceptable values for this
> >> >> field)
> >> >>
> >> >> What I would still like to understand is: Who will be changing this
> >> >> value? I see that you've added a control to the saa7134 driver -- is
> >> >> this to be manipulated from userspace?
> >> >
> >> > Yes
> >> >
> >> >> Under what conditions will somebody want to change this value?
> >> >
> >> > for SECAM with strong signal we have wide white crap on the screen.
> >> > Need reduce value of AGC TOP.
> >> >
> >> > For weak signal need increase value of AGC TOP
> >> > Ajust value of AGC TOP can get more better image quality.
> >> >
> >> >> How will users know that they need to alter this gain value?
> >> >
> >> > By default use value from .initdata
> >> > v4l2-ctl can modify this value or via some plugins for TV wach programm.
> >> >
> >> > End-user programm for watch TV IMHO now is very poor.
> >> >
> >> > With my best regards, Dmitry.
> >> >
> >>
> >> I have to admit that I am not familiar enough with SECAM myself to see
> >> this kind of trouble. For NTSC and PAL, tvtime is a great application
> >> -- the only shortcoming that bothers me about tvtime is lack of audio
> >> support. One must rely on a separate mechanism to hear audio, whether
> >> it's a patch cable from the tv tuner to the sound board, or a separate
> >> application decoding DMA audio. ...but that is not what this email
> >> thread is about.
> >>
> >> As far as simple tuning and analog television viewing goes, tvtime
> >> rocks. Is it really that difficult for SECAM users?
> >>
> >> In summary, you are telling us that we need to add userspace controls
> >> to handle gain control, for tuning SECAM. I am going to have to ask
> >> for help on this topic from those cc'd on this email. (Adding Hans
> >> Verkuil, as I value his opinion for controls and dealing with video
> >> standards in high regard)
> >>
> >> Personally, I don't quite understand why we would need to add such
> >> controls NOW, while we've supported this video standard for years
> >> already. I am not arguing against this in any way, but I dont feel
> >> like I'm qualified to accept this addition without hearing the
> >> opinions of others first.
> >>
> >> Can somebody help to shed some light?
> >>
> >> Cheers,
> >>
> >> Mike
> >
> > Mike,
> >
> > i did discuss this with Dmitri a lot on the list previously.
> >
> > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in
> > China, to convince him not to do that for the original Philips tuners.
> >
> > Andy was also pretty active on it, thanks for your help.
> >
> > However, it is for now only about that TCL MK3, using different filters
> > than the original Philips stuff, and their labs have clear results, that
> > they can improve SECAM-DK this way for their users.
>
> Thanks for the comment, Hermann.
>
> Do you think there is any way that we can automate this without having
> to expose an additional user control?
>
> If you believe that it's necessary, I am fine with adding this, but I
> will need Mauro to agree on it as well -- that's why I'm asking for
> some argument points.
We can automate this. Just ignore Chinese tuners ...
Don't forget, Hauppauge is still leading on that.
Likely we support hundreds already, since main chips are the same and
they have to fight on the discrets to get some cent out per device.
> Some questions that he might ask -- why do we need this in the saa7134
> driver but not the other drivers? Is this specific to this TCL MK3
> only? Could doing this help to improve SECAM support for users of
> other tuners?
I don't fear Mauro's questions ;), but those not aware off, including
me.
Simple answer. I'm not on any SECAM-DK and can't tell _at all_.
Cheers,
Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote:
> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> > On Mon, 14 Sep 2009 08:55:22 -0400
> > Michael Krufky <mkrufky@kernellabs.com> wrote:
> >
> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
> >> wrote:
> >> > Hi All
> >> >
> >> > This is my next patch.
> >> >
> >> > Changes:
> >> > 1. By default charge pump is ON
> >> > 2. For radio mode charge pump set to OFF
> >> > 3. Set correct AGC value in radio mode
> >> > 4. Add control gain of AGC.
> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
> >> > read/write gain of AGC. 6. Add some code for control gain from
> >> > saa7134 part. By default this control is OFF 7. When TV card can
> >> > manipulate this control, enable it.
> >> >
> >> > Main changes is control value of AGC TOP in .initdata =
> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
> >> > of TV.
> >> >
> >> > I don't understand how to correct call new function for read/write
> >> > value of AGC TOP.
> >> >
> >> > What you think about it??
> >> >
> >>
> >> [patch snipped]
> >>
> >> >
> >> >
> >> > With my best regards, Dmitry.
> >>
> >> Dmitry,
> >>
> >> The direct usage of .initdata and .sleepdata is probably unnecessary
> >> here -- If you trace how the tuner-simple driver works, you'll find
> >> that simply having these fields defined will cause these bytes to be
> >> written at the appropriate moment.
> >>
> >> However, for the actual sake of setting this gain value, I'm not sure
> >> that initdata / sleep data is the right place for it either. (I know
> >> that I recommended something like this at first, but at the time I
> >> didn't realize that there is a range of six acceptable values for this
> >> field)
> >>
> >> What I would still like to understand is: Who will be changing this
> >> value? I see that you've added a control to the saa7134 driver -- is
> >> this to be manipulated from userspace?
> >
> > Yes
> >
> >> Under what conditions will somebody want to change this value?
> >
> > for SECAM with strong signal we have wide white crap on the screen.
> > Need reduce value of AGC TOP.
> >
> > For weak signal need increase value of AGC TOP
> > Ajust value of AGC TOP can get more better image quality.
> >
> >> How will users know that they need to alter this gain value?
> >
> > By default use value from .initdata
> > v4l2-ctl can modify this value or via some plugins for TV wach programm.
> >
> > End-user programm for watch TV IMHO now is very poor.
> >
> > With my best regards, Dmitry.
> >
>
> I have to admit that I am not familiar enough with SECAM myself to see
> this kind of trouble. For NTSC and PAL, tvtime is a great application
> -- the only shortcoming that bothers me about tvtime is lack of audio
> support. One must rely on a separate mechanism to hear audio, whether
> it's a patch cable from the tv tuner to the sound board, or a separate
> application decoding DMA audio. ...but that is not what this email
> thread is about.
>
> As far as simple tuning and analog television viewing goes, tvtime
> rocks. Is it really that difficult for SECAM users?
>
> In summary, you are telling us that we need to add userspace controls
> to handle gain control, for tuning SECAM. I am going to have to ask
> for help on this topic from those cc'd on this email. (Adding Hans
> Verkuil, as I value his opinion for controls and dealing with video
> standards in high regard)
>
> Personally, I don't quite understand why we would need to add such
> controls NOW, while we've supported this video standard for years
> already. I am not arguing against this in any way, but I dont feel
> like I'm qualified to accept this addition without hearing the
> opinions of others first.
>
> Can somebody help to shed some light?
It's the first time I've heard about SECAM and AGC-TOP problems. I do know
that the TOP value is standard-dependent, although the datasheets recommend
different SECAM-L values only. So I can imagine that in some cases you would
like to adjust the TOP value a bit.
The problem is that end-users will have no idea what to do with a control like
that. It falls into the category of 'advanced controls' that might be nice to
add but is only for very advanced users or applications.
The proposed media controller actually gives you a way of implementing that
as tuner-specific controls that do not show up in the regular /dev/videoX
control list. I have no problems adding an AGC-TOP control as a tuner-specific
control, but adding it as a generic control is a bad idea IMHO.
Regards,
Hans
On Tue, 2009-09-15 at 08:26 +0200, Hans Verkuil wrote:
> On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote:
> > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> > Personally, I don't quite understand why we would need to add such
> > controls NOW, while we've supported this video standard for years
> > already. I am not arguing against this in any way, but I dont feel
> > like I'm qualified to accept this addition without hearing the
> > opinions of others first.
> >
> > Can somebody help to shed some light?
>
> It's the first time I've heard about SECAM and AGC-TOP problems. I do know
> that the TOP value is standard-dependent, although the datasheets recommend
> different SECAM-L values only. So I can imagine that in some cases you would
> like to adjust the TOP value a bit.
>
> The problem is that end-users will have no idea what to do with a control like
> that. It falls into the category of 'advanced controls' that might be nice to
> add but is only for very advanced users or applications.
The AGC Take Over Point (TOP) is the signal level at which the 2nd stage
of the amplifier chain (after the IF filter) takes over gain control
from the 1st stage in the amplifier chain. The idea is to maximize
overall noise figure by boosting small signals as needed, but avoiding
hittng amplifer non-linearities that generate intermodulation products
(i.e. spectral "splatter").
The TOP setting depends on the TV standard *and* the attenuation through
the IF filter. I'm fairly sure, it is something that one probably
should not change to a value different from the manufacturer's
recommendation for a particular TV standard, unless you are dealing with
input signals in a very controlled, known range aor you have taken
measurments inside the tuner and precisely know the loss through the IF
filter. If the user doesn't understand how the AGC-TOP setting will
affect his overall system noise figure, for all inoming signal
strengths, then the user shouldn't change it. (IMO)
> The proposed media controller actually gives you a way of implementing that
> as tuner-specific controls that do not show up in the regular /dev/videoX
> control list. I have no problems adding an AGC-TOP control as a tuner-specific
> control, but adding it as a generic control is a bad idea IMHO.
If needed, it should be an advanced control or, dare I say, a tunable
via sysfs. Setting the TOP wrong will simply degrade reception for the
the general case of an unknown incoming signal level.
The tuner-sumple code has initialization values for TOP. Also there are
some module options for the user to fix TOP to a value, IIRC. Both are
rather inflexible for someone who does want to manipulate the TOP in an
environment where the incoming RF signal levels are controlled.
Regards,
Andy
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-09-15 at 00:55 -0400, Michael Krufky wrote:
> On Tue, Sep 15, 2009 at 12:43 AM, hermann pitton
> <hermann-pitton@arcor.de> wrote:
> >
> > Am Dienstag, den 15.09.2009, 00:18 -0400 schrieb Michael Krufky:
> >> On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com> wrote:
> >> > On Mon, 14 Sep 2009 08:55:22 -0400
> >> > Michael Krufky <mkrufky@kernellabs.com> wrote:
> >> >
> >> >> On Thu, Sep 10, 2009 at 1:25 AM, Dmitri Belimov <d.belimov@gmail.com>
> >> >> wrote:
> >> >> > Hi All
> >> >> >
> >> >> > This is my next patch.
> >> >> >
> >> >> > Changes:
> >> >> > 1. By default charge pump is ON
> >> >> > 2. For radio mode charge pump set to OFF
> >> >> > 3. Set correct AGC value in radio mode
> >> >> > 4. Add control gain of AGC.
> >> >> > 5. New function simple_get_tv_gain and simple_set_tv_gain for
> >> >> > read/write gain of AGC. 6. Add some code for control gain from
> >> >> > saa7134 part. By default this control is OFF 7. When TV card can
> >> >> > manipulate this control, enable it.
> >> >> >
> >> >> > Main changes is control value of AGC TOP in .initdata =
> >> >> > tua603x_agc112 array. Use this value for set AGC TOP after set freq
> >> >> > of TV.
> >> >> >
> >> >> > I don't understand how to correct call new function for read/write
> >> >> > value of AGC TOP.
> >> >> >
> >> >> > What you think about it??
> >> >> >
> >> >>
> >> >> [patch snipped]
> >> >>
> >> >> >
> >> >> >
> >> >> > With my best regards, Dmitry.
> >> >>
> >> >> Dmitry,
> >> >>
> >> >> The direct usage of .initdata and .sleepdata is probably unnecessary
> >> >> here -- If you trace how the tuner-simple driver works, you'll find
> >> >> that simply having these fields defined will cause these bytes to be
> >> >> written at the appropriate moment.
> >> >>
> >> >> However, for the actual sake of setting this gain value, I'm not sure
> >> >> that initdata / sleep data is the right place for it either. (I know
> >> >> that I recommended something like this at first, but at the time I
> >> >> didn't realize that there is a range of six acceptable values for this
> >> >> field)
> >> >>
> >> >> What I would still like to understand is: Who will be changing this
> >> >> value? I see that you've added a control to the saa7134 driver -- is
> >> >> this to be manipulated from userspace?
> >> >
> >> > Yes
> >> >
> >> >> Under what conditions will somebody want to change this value?
> >> >
> >> > for SECAM with strong signal we have wide white crap on the screen.
> >> > Need reduce value of AGC TOP.
> >> >
> >> > For weak signal need increase value of AGC TOP
> >> > Ajust value of AGC TOP can get more better image quality.
> >> >
> >> >> How will users know that they need to alter this gain value?
> >> >
> >> > By default use value from .initdata
> >> > v4l2-ctl can modify this value or via some plugins for TV wach programm.
> >> >
> >> > End-user programm for watch TV IMHO now is very poor.
> >> >
> >> > With my best regards, Dmitry.
> >> >
> >>
> >> I have to admit that I am not familiar enough with SECAM myself to see
> >> this kind of trouble. For NTSC and PAL, tvtime is a great application
> >> -- the only shortcoming that bothers me about tvtime is lack of audio
> >> support. One must rely on a separate mechanism to hear audio, whether
> >> it's a patch cable from the tv tuner to the sound board, or a separate
> >> application decoding DMA audio. ...but that is not what this email
> >> thread is about.
> >>
> >> As far as simple tuning and analog television viewing goes, tvtime
> >> rocks. Is it really that difficult for SECAM users?
> >>
> >> In summary, you are telling us that we need to add userspace controls
> >> to handle gain control, for tuning SECAM. I am going to have to ask
> >> for help on this topic from those cc'd on this email. (Adding Hans
> >> Verkuil, as I value his opinion for controls and dealing with video
> >> standards in high regard)
> >>
> >> Personally, I don't quite understand why we would need to add such
> >> controls NOW, while we've supported this video standard for years
> >> already. I am not arguing against this in any way, but I dont feel
> >> like I'm qualified to accept this addition without hearing the
> >> opinions of others first.
> >>
> >> Can somebody help to shed some light?
> >>
> >> Cheers,
> >>
> >> Mike
> >
> > Mike,
> >
> > i did discuss this with Dmitri a lot on the list previously.
> >
> > I destroyed one of my FM1216ME/I MK3 tuners, searched all websites in
> > China, to convince him not to do that for the original Philips tuners.
> >
> > Andy was also pretty active on it, thanks for your help.
> >
> > However, it is for now only about that TCL MK3, using different filters
> > than the original Philips stuff, and their labs have clear results, that
> > they can improve SECAM-DK this way for their users.
>
> Thanks for the comment, Hermann.
>
> Do you think there is any way that we can automate this without having
> to expose an additional user control?
We should automate this.
1. The user will generally be incapable of setting it properly for a
number of reasons.
2. The tuner modules/subdevs are aware of the standards changes
via .s_std calls, so they should be able to set the TOP when needed.
3. The TOP also needs to be set for FM radio mode on tuners that support
FM.
Problems with proper automation of this feature:
1. We have many overloaded tuner definitions: a single definition is
used for multiple tuner models of varying types. These tuners *may*
need slightly different TOP settings; thus requiring splitting out to
separate tuner definitions. Maybe many won't.
2. Only the manufacturer has the engineering design data to say what the
proper TOP should be. That's hard to get for Leading suppliers. I have
no idea how much harder it would be for the knockoffs and clones.
Forget getting the proper values for counterfits.
3. A manufacturer like Dmitry's company can take measurments on
specimens that have been opened up, but it requires going through a
range of video input signal levels and a test on a single device from a
production run may not be representative of the worst case in that tuner
assembly's design.
4. Analog OTA is DEAD in the US; cable will follow in 2 years or so. My
personal level of caring about analog RF tuners is low.
> If you believe that it's necessary, I am fine with adding this, but I
> will need Mauro to agree on it as well -- that's why I'm asking for
> some argument points.
> Some questions that he might ask -- why do we need this in the saa7134
> driver but not the other drivers? Is this specific to this TCL MK3
> only? Could doing this help to improve SECAM support for users of
> other tuners?
This is about optimizing receiver system nosie figure under a range of
RF signal levels. The losses before the first gain stage dominate the
noise figure, and the gain of the first stage mitigates the noise
contributions of the components behind it. The higher the gain you can
maintain in the first stage without clipping/distortion, the better your
overall receiver noise figure, and the better your SNR. The worst
thing that can happen is a strong signal coming in and the TOP being set
to high (I think - I'm tired), so that the signal experiences non-linear
distortion in the first stage (Osc/Mixer and IF amplifier).
Here's a quick tutorial on the concept:
http://www.comsec.com/usrp/microtune/NF_tutorial.pdf
This is sometimes a problem that's *not* solvable with TOP settings for
some tuners, as the AGC signal from the sencond stage (IF demodulator)
is not fed to the first stage's AGC. It all depends on how the
manufacturer wired up the tuner internals.
Regards,
Andy
> Cheers,
>
> Mike
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 15.09.2009, 11:17 -0400 schrieb Gene Heskett:
> On Tuesday 15 September 2009, Andy Walls wrote:
> >On Tue, 2009-09-15 at 08:26 +0200, Hans Verkuil wrote:
> >> On Tuesday 15 September 2009 06:18:55 Michael Krufky wrote:
> >> > On Tue, Sep 15, 2009 at 12:07 AM, Dmitri Belimov <d.belimov@gmail.com>
> >> > wrote:
> >> >
> >> > Personally, I don't quite understand why we would need to add such
> >> > controls NOW, while we've supported this video standard for years
> >> > already. I am not arguing against this in any way, but I dont feel
> >> > like I'm qualified to accept this addition without hearing the
> >> > opinions of others first.
> >> >
> >> > Can somebody help to shed some light?
> >>
> >> It's the first time I've heard about SECAM and AGC-TOP problems. I do
> >> know that the TOP value is standard-dependent, although the datasheets
> >> recommend different SECAM-L values only. So I can imagine that in some
> >> cases you would like to adjust the TOP value a bit.
> >>
> >> The problem is that end-users will have no idea what to do with a control
> >> like that. It falls into the category of 'advanced controls' that might
> >> be nice to add but is only for very advanced users or applications.
> >
> >The AGC Take Over Point (TOP) is the signal level at which the 2nd stage
> >of the amplifier chain (after the IF filter) takes over gain control
> >from the 1st stage in the amplifier chain. The idea is to maximize
> >overall noise figure by boosting small signals as needed, but avoiding
> >hittng amplifer non-linearities that generate intermodulation products
> >(i.e. spectral "splatter").
> >
> >The TOP setting depends on the TV standard *and* the attenuation through
> >the IF filter. I'm fairly sure, it is something that one probably
> >should not change to a value different from the manufacturer's
> >recommendation for a particular TV standard, unless you are dealing with
> >input signals in a very controlled, known range aor you have taken
> >measurments inside the tuner and precisely know the loss through the IF
> >filter. If the user doesn't understand how the AGC-TOP setting will
> >affect his overall system noise figure, for all inoming signal
> >strengths, then the user shouldn't change it. (IMO)
>
> As a retired broadcast engineer, I can say that generally speaking, this is a
> knob that shouldn't be enabled. It may in some cases be able to get a db's
> worth of improvement, but the potential for worsening it by many db, by
> someone who doesn't understand the interactions, is much too high. Given a
> knob, it will be tweaked, usually detrimentally.
you likely get more readers on linux-media@vger.kernel.org these days,
which was considered the right thing to change to next, but, unlike the
dvb ML, video4linux still does not give any advice to the users to
change over to vger.
The Beholder Labs initially planed to introduce it to all tuners around,
including all Multi Europe Philips FM1216ME MK3.
We previously had separate tuners for Russia, maybe only caused by the
different radio bandwidth, but the point when that changed, and it did,
is still not fully investigated.
The case here now is, that we eventually have to deal with at least two
issues.
One is known as "Secam fire" ...
No such complaints on the original Philips tuners during the last four
years so far.
The other one is, that believed _one to one_ Chinese clones of the
original Philips tuners, still using the same Philips chips, have
different SAW filters.
My assumption so far is, that they are not as linear as claimed over the
covered (uncovered ;) frequency ranges, some ups and downs, and that is
what Dmitry tries to compensate in software. And least their labs have
good results for that ... ;)
The Russian border to China is very long, Dmitry told they can tweak
those tuners to receive, maybe somehow limited, even Chinese broadcast.
We have some special case here, so I don't tell just ignore it per se,
but we are also not forced to please some undocumented, maybe wrong
documented, hardware.
Cheers,
Hermann
> >> The proposed media controller actually gives you a way of implementing
> >> that as tuner-specific controls that do not show up in the regular
> >> /dev/videoX control list. I have no problems adding an AGC-TOP control as
> >> a tuner-specific control, but adding it as a generic control is a bad
> >> idea IMHO.
> >
> >If needed, it should be an advanced control or, dare I say, a tunable
> >via sysfs. Setting the TOP wrong will simply degrade reception for the
> >the general case of an unknown incoming signal level.
> >
> >The tuner-sumple code has initialization values for TOP. Also there are
> >some module options for the user to fix TOP to a value, IIRC. Both are
> >rather inflexible for someone who does want to manipulate the TOP in an
> >environment where the incoming RF signal levels are controlled.
> >
> >Regards,
> >Andy
> >
> >> Regards,
> >>
> >> Hans
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -144,6 +144,7 @@
case TUNER_PHILIPS_FM1256_IH3:
case TUNER_LG_NTSC_TAPE:
case TUNER_TCL_MF02GIP_5N:
+ case TUNER_TCL_MFPE05_2:
return ((status & TUNER_SIGNAL) == TUNER_STEREO_MK3);
default:
return status & TUNER_STEREO;
@@ -491,6 +492,18 @@
"(should be 4)\n", rc);
break;
}
+ case TUNER_TCL_MFPE05_2:
+ {
+
+ printk("posttune TCL_MFPE05_2\r\n");
+
+ if (priv->tun->initdata) {
+ printk("write AUX byte = 0x%X",priv->tun->initdata[2]);
+ simple_set_aux_byte(fe, config, priv->tun->initdata[2]);
+ }
+
+ break;
+ }
}
return 0;
@@ -499,6 +512,7 @@
static int simple_radio_bandswitch(struct dvb_frontend *fe, u8 *buffer)
{
struct tuner_simple_priv *priv = fe->tuner_priv;
+ u8 rc;
switch (priv->type) {
case TUNER_TENA_9533_DI:
@@ -513,6 +527,11 @@
case TUNER_LG_NTSC_TAPE:
case TUNER_PHILIPS_FM1256_IH3:
case TUNER_TCL_MF02GIP_5N:
+ buffer[3] = 0x19;
+ break;
+ case TUNER_TCL_MFPE05_2:
+ rc = buffer[2]&0xbf;
+ buffer[2] = rc; /* Switch OFF Charge Pump */
buffer[3] = 0x19;
break;
case TUNER_TNF_5335MF:
@@ -754,7 +773,53 @@
if (4 != rc)
tuner_warn("i2c i/o error: rc == %d (should be 4)\n", rc);
+ /* Write AUX byte */
+ switch (priv->type) {
+ case TUNER_TCL_MFPE05_2:
+ printk("write AUX byte\n");
+ simple_set_aux_byte(fe, 0x98, 0x20);
+ break;
+ }
+
return 0;
+}
+
+static int simple_set_tv_gain(struct dvb_frontend *fe,
+ u8 tvgain)
+{
+ struct tuner_simple_priv *priv = fe->tuner_priv;
+ int ret = -EINVAL;
+
+ switch (priv->type) {
+ case TUNER_TCL_MFPE05_2:
+ if (priv->tun->initdata) {
+ priv->tun->initdata[2] = tvgain;
+ printk("set AUX byte = 0x%X",priv->tun->initdata[2]);
+ ret = 0;
+ }
+ break;
+ } /* switch (priv->type) */
+
+ return ret;
+}
+
+static int simple_get_tv_gain(struct dvb_frontend *fe,
+ u8 *tvgain)
+{
+ struct tuner_simple_priv *priv = fe->tuner_priv;
+ int ret = -EINVAL;
+
+ switch (priv->type) {
+ case TUNER_TCL_MFPE05_2:
+ if (priv->tun->initdata) {
+ *tvgain = priv->tun->initdata[2];
+ printk("read AUX byte = 0x%X",priv->tun->initdata[2]);
+ ret = 0;
+ }
+ break;
+ } /* switch (priv->type) */
+
+ return ret;
}
static int simple_set_params(struct dvb_frontend *fe,
@@ -1321,6 +1321,31 @@
},
};
+/* ------------ TUNER_TCL_MFPE05_2 - TCL MFPE05-2 ALL ------------ */
+
+static struct tuner_range tuner_tcl_mfpe05_2_all_ranges[] = {
+ { 16 * 158.00 /*MHz*/, 0xc6, 0x01, },
+ { 16 * 441.00 /*MHz*/, 0xc6, 0x02, },
+ { 16 * 864.00 , 0xc6, 0x04, },
+};
+
+static struct tuner_params tuner_tcl_mfpe05_2_all_params[] = {
+ {
+ .type = TUNER_PARAM_TYPE_PAL,
+ .ranges = tuner_tcl_mfpe05_2_all_ranges,
+ .count = ARRAY_SIZE(tuner_tcl_mfpe05_2_all_ranges),
+ .cb_first_if_lower_freq = 1,
+ .has_tda9887 = 1,
+ .port1_active = 1,
+ .port2_active = 1,
+ .port2_invert_for_secam_lc = 1,
+ .port1_fm_high_sensitivity = 1,
+ .default_top_mid = -2,
+ .default_top_secam_mid = -2,
+ .default_top_secam_high = -2,
+ },
+};
+
/* --------------------------------------------------------------------- */
struct tunertype tuners[] = {
@@ -1779,6 +1804,14 @@
.params = tuner_partsnic_pti_5nf05_params,
.count = ARRAY_SIZE(tuner_partsnic_pti_5nf05_params),
},
+
+ [TUNER_TCL_MFPE05_2] = { /* TCL ALL */
+ .name = "TCL MFPE05-2 MK3 PAL/SECAM multi (Beholder Lab)",
+ .params = tuner_tcl_mfpe05_2_all_params,
+ .count = ARRAY_SIZE(tuner_tcl_mfpe05_2_all_params),
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
+ },
};
EXPORT_SYMBOL(tuners);
@@ -4500,7 +4500,7 @@
/* Alexey Osipov <lion-simba@pridelands.ru> */
.name = "Beholder BeholdTV M6",
.audio_clock = 0x00187de7,
- .tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
+ .tuner_type = TUNER_TCL_MFPE05_2,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
@@ -4537,7 +4537,7 @@
/* Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com> */
.name = "Beholder BeholdTV M63",
.audio_clock = 0x00187de7,
- .tuner_type = TUNER_PHILIPS_FM1216ME_MK3,
+ .tuner_type = TUNER_TCL_MFPE05_2,
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
@@ -7099,6 +7099,18 @@
}
break;
}
+ case SAA7134_BOARD_BEHOLD_M6:
+ case SAA7134_BOARD_BEHOLD_M63:
+ {
+ struct v4l2_queryctrl* ctl;
+ struct saa7134_fh *fh;
+ struct file *fl;
+
+ ctl->id = V4L2_CID_GAIN;
+ if (saa7134_queryctrl(fl,fh,ctl)==0){
+ ctl->flags &= ~(V4L2_CTRL_FLAG_DISABLED); /* enable this control */
+ }
+ }
} /* switch() */
/* initialize tuner */
@@ -413,6 +413,15 @@
.step = 1,
.default_value = 0,
.type = V4L2_CTRL_TYPE_INTEGER,
+ },{
+ .id = V4L2_CID_GAIN,
+ .name = "Gain",
+ .minimum = 0,
+ .maximum = 6,
+ .step = 1,
+ .default_value = 3,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .flags = V4L2_CTRL_FLAG_DISABLED,
},{
.id = V4L2_CID_HFLIP,
.name = "Mirror",
@@ -1128,6 +1137,9 @@
case V4L2_CID_HUE:
c->value = dev->ctl_hue;
break;
+ case V4L2_CID_GAIN:
+ c->value = dev->ctl_gain;
+ break;
case V4L2_CID_CONTRAST:
c->value = dev->ctl_contrast;
break;
@@ -1175,6 +1187,7 @@
unsigned long flags;
int restart_overlay = 0;
int err;
+ unsigned char tgain;
/* When called from the empress code fh == NULL.
That needs to be fixed somehow, but for now this is
@@ -1214,6 +1227,38 @@
dev->ctl_hue = c->value;
saa_writeb(SAA7134_DEC_CHROMA_HUE, dev->ctl_hue);
break;
+ case V4L2_CID_GAIN:
+ dev->ctl_gain = c->value;
+
+ switch (c->value) {
+ case 0:
+ tgain = 0x80|0x50; /* TOP = 103dB, ATC = OFF */
+ break;
+ case 1:
+ tgain = 0x80|0x40; /* TOP = 106dB, ATC = OFF */
+ break;
+ case 2:
+ tgain = 0x80|0x30; /* TOP = 109dB, ATC = OFF */
+ break;
+ case 3:
+ tgain = 0x80|0x20; /* TOP = 112dB, ATC = OFF */
+ break;
+ case 4:
+ tgain = 0x80|0x10; /* TOP = 115dB, ATC = OFF */
+ break;
+ case 5:
+ tgain = 0x80|0x00; /* TOP = 118dB, ATC = OFF */
+ break;
+ case 6:
+ tgain = 0x80|0x60; /* TOP = External AGC, ATC = OFF */
+ break;
+ default:
+ tgain = 0x80|0x20;
+ break;
+ }
+ /* call simple set AUX byte here */
+ /* simple_set_v_gain(); */
+ break;
case V4L2_CID_CONTRAST:
dev->ctl_contrast = c->value;
saa_writeb(SAA7134_DEC_LUMA_CONTRAST,
@@ -2534,6 +2579,7 @@
dev->ctl_bright = ctrl_by_id(V4L2_CID_BRIGHTNESS)->default_value;
dev->ctl_contrast = ctrl_by_id(V4L2_CID_CONTRAST)->default_value;
dev->ctl_hue = ctrl_by_id(V4L2_CID_HUE)->default_value;
+ dev->ctl_gain = ctrl_by_id(V4L2_CID_GAIN)->default_value;
dev->ctl_saturation = ctrl_by_id(V4L2_CID_SATURATION)->default_value;
dev->ctl_volume = ctrl_by_id(V4L2_CID_AUDIO_VOLUME)->default_value;
dev->ctl_mute = 1; // ctrl_by_id(V4L2_CID_AUDIO_MUTE)->default_value;
@@ -565,6 +565,7 @@
int ctl_bright;
int ctl_contrast;
int ctl_hue;
+ int ctl_gain; /* gain */
int ctl_saturation;
int ctl_freq;
int ctl_mute; /* audio */
@@ -127,6 +127,7 @@
#define TUNER_PHILIPS_FM1216MK5 79
#define TUNER_PHILIPS_FQ1216LME_MK3 80 /* Active loopthrough, no FM */
#define TUNER_PARTSNIC_PTI_5NF05 81
+#define TUNER_TCL_MFPE05_2 82 /* TCL clone of the Philips FM1216ME_MK3 */
/* tv card specific */
#define TDA9887_PRESENT (1<<0)