[linux-dvb] HVR4000 Support

Manu Abraham abraham.manu at gmail.com
Sun Mar 18 13:00:06 CET 2007


On 3/18/07, Darron Broad <darron at kewl.org> wrote:
> In message <1a297b360703180432v94b513bj441248b8a59a62c2 at mail.gmail.com>, "Manu Abraham" wrote:
>
> lo
>
> >On 3/18/07, Darron Broad <darron at kewl.org> wrote:
> >> In message <1a297b360703180407r63b1e98dj561ae0a0abc8188f at mail.gmail.com>, "Manu Abraham" wrote:
> >> >On 3/18/07, Darron Broad <darron at kewl.org> wrote:
> >>
> >> lo
> >>
> >> >> >> 3. the delivery field has to be set
> >> >> >>
> >> >> >
> >> >> >
> >> >> >delivery system is set using DVBFE_SET_PARAMS, without which you
> >> >> >wouldn't be able to tune to anything, because of the switch statement.
> >> >>
> >> >> the delivery type is indeed taken from the command line and used for
> >> >> logic in the code, however, it's not passed to the driver.
> >> >>
> >> >
> >> >It is. Take a look at the delsys switch in the stb0899 driver. The
> >> >STB0899 depends on the delivery system and the Physical Layer
> >> >parameters to decide which modulation to use.
> >> >
> >> >http://linuxtv.org/hg/~manu/stb0899-c5?f=d6f0bf7681d1;file=linux/drivers/media/dvb/frontends/stb0899_drv.c;sty
> >le=
> >> >gitweb
> >> >The delivery system is sent to the driver, without which
> >> >tuning/demodulation is impossible "on any multistandard demod"
> >>
> >> specifically Steve's driver needs to the delivery system type
> >> to be set when calling set_params.
> >>
> >> it would appear from your code snippet that your driver is
> >> setting internal state when peforming a query. surely this
> >> is illogical behaviour.
> >
> >
> >Sorry, nope. Since the IOCTL is RW not R
>
> >#define DVBFE_GET_INFO _IOWR('o', 85, struct dvbfe_info)
>
> please explain why you have chosen a function named GET
> to SET internal state.
>

on a multistandard demod/tuner, what info do you want to get ? Rather
than setting delivery system again which is redundant, it is used with
the same IOCTL

It doesn't matter whether one uses set_params (does a blind setup of
the frontend) or search (uses a frontend dependant algorithm to do
scan's /szap or say blindscan's)

just that the delivery system type is cached in one IOCTL call, which
anyway needs to be set to get the relevant delivery system type.


> BTW, the unmodded szap only worked for you because it
> queried the current state inadvertantly setting internal
> state before calling set_params without actually specifying
> the correct internal state.

> if an application does a query and sets state to DVB-S2
> then decides to tune to DVB-S the internal state will
> be incorrect.

Don't think so

what szap does (on each szap) --

* DVBFE_GET_INFO (set's up delivery system for querying the relevant info)
* DVBFE_SET_PARAMS (set the "current" delivery system related parameters)

Worked for me, both ways toggling between dvb-s and dvb-s2. For a
couple of others as well, AFAICS.

Manu



More information about the linux-dvb mailing list