Sorry,
My mistake, I was under the impression that "read_rf_strength" was
already a tuner interface.
So in that case it would be usefull to have included in the tuner interface.
Still policy on whether it is reported to userspace should reside
within the demod driver as outlined below I think.
As for the name I think it would cause less confusion to call it
similar to the function thats used in "struct frontend"
(get_signal_strength).
Regards,
Henk
On 8/31/07, Henk <henk.vergonet@xxxxxxxxx> wrote:
> Of course from a kernel perspective it is a simple addition, but where
> should we form a userspace perspective decide on which signal strength
> function to use?
>
> I don't think an extra interface should be needed here.
>
>
> For example if a demodulator is unable to provide signal strengths on
> his own there is always the possibility to request it from the tuner
> (if available) and report that.
>
>
> For example how about this alternative. In the demod driver you could use:
>
>
> int demod_get_rf_strength(struct dvb_frontend *fe, u16 *strength)
> {
> /* No I dont support this so see if we can get something from the tuner */
> if ( fe->ops.tuner_ops.get_rf_strength(fe, strength) )
> return fe->ops.tuner_ops.get_rf_strength(fe, strength);
>
> return -ENOSYS;
> }
>
>
> That way you can decide in the demod driver what's the best way on how
> to deal with this specific hardware "feature".
>
> Regards,
> Henk
>
>
>
> On 8/30/07, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote:
> > Michael Krufky wrote:
> > > struct dvb_frontend_ops contains a function pointer for reading signal
> > > strength from the demodulator, however, it would also be useful to be
> > > able to read the signal strength from the tuner, itself.
> > >
> > > As of now, in dvb_tuner_ops, we only have the following function for status:
> > >
> > > int (*get_status)(struct dvb_frontend *fe, u32 *status);
> > >
> > > The usability of this function is rather limited, and currently only
> > > provides a mechanism for reading a limited amount of bits. The current
> > > status bits are as follows:
> > >
> > > #define TUNER_STATUS_LOCKED 1
> > > #define TUNER_STATUS_STEREO 2
> > >
> > > ...this doesn't really lend itself for a useful signal strength reading.
> > >
> > > I can cite two examples of how this would be useful in the current codebase:
> > >
> > > 1) Some demodulators do not directly provide signal strength readings.
> > > For example, lgdt330x. In order to provide some sort of measurement,
> > > other values are used to arrive at an estimated reading.
> > >
> > > If we had a read_signal_strength function available from the tuner
> > > driver, such demodulator drivers that are otherwise unable to provide
> > > this functionality directly would be able to read the signal strength
> > > from the tuner driver, and either pass on that value, or use it in its
> > > calculation of status readings.
> > >
> > > 2) The analog tuner system accesses the tuner modules directly, and
> > > would benefit greatly from having such functionality available to be
> > > able to read signal strength from the tuner.
> >
> > Manu and I spoke about this on irc today, and we decided that it would be better
> > to name this function, "get_rf_strength" ... So, the change would be as follows:
> >
> >
> > --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.h
> > +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.h
> > @@ -92,6 +92,7 @@
> > #define TUNER_STATUS_LOCKED 1
> > #define TUNER_STATUS_STEREO 2
> > int (*get_status)(struct dvb_frontend *fe, u32 *status);
> > + int (*get_rf_strength)(struct dvb_frontend *fe, u16 *strength);
> >
> > /** These are provided seperately from set_params in order to facilitate silicon
> > * tuners which require sophisticated tuning loops, controlling each
> > parameter seperately. */
> >
> >
> > This is a rather trivial addition, so I doubt there will be any debate on this
> > matter. I plan to move forward with this tonight, unless anybody is opposed.
> >
> > Any acks would still be appreciated, of course :-)
> >
> > Regards,
> >
> > Mike Krufky
> >
> >
> > _______________________________________________
> > linux-dvb mailing list
> > linux-dvb@xxxxxxxxxxx
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> >
>
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
