On Tuesday 15 Nov 2005 20:22, Johannes Stezenbach wrote: > On Tue, Nov 15, 2005 Andrew de Quincey wrote: > > Hi, this patch allows frontends (and the user) to select from one of > > several different tuning algorithms. The patch adds four possibilities: > > > > 1) SW - the current dvb-kernel software zigzag code. > > 2) HW - the hardware supports zigzagging internally (e.g. DST), so use > > that as it will be faster. > > 3) ADAPTIVE - frontend-specific code exploiting frontend-specific > > features. 4) SIMPLE - just set the frontend once and do nothing else > > (e.g. for frequency scanner apps). > > > > Frontends can specify which algorithms they support using > > FE_CAPS_CAN_TUNE_ALGO_*. They can also specify the default algorithm to > > use. Currently the default is SW for all frontends except the DST (which > > has HW). > > > > ADAPTIVE is not implemented internally yet. Enough information to do this > > for many frontends is provided on their datasheets - for example I know > > roughly how to do it for the stv0299, stv0297, and sh1420 frontends. This > > needs experimentation before any real adaptive code can be committed to > > CVS however, but I thought it was better to change the API _once_ instead > > of several times. None of the frontends currently set the > > FE_CAN_TUNE_ALGO_ADAPTIVE flag, so it cannot be accidentally enabled. > > > > The userspace app can also choose an algorithm using an IOCTL. > > > > When a frontend device is opened read/write, the tuning algo will > > automatically be set back to whatever the frontend specified as the > > default - so that userspace apps don't have to care if something else > > changed algos. > > I wanted to have a way to turn off zig-zag etc. for a long time. > > However, I would prefer to implement this via an > FE_SET_FRONTEND_EXT (bad name, need a better one) ioctl, > which is basically the same as FE_SET_FRONTEND plus an > added flags field. This way you could have one flag > for switching off zig-zag, one for switching band filters > for analog tuning (some FE have IF output to feed an > analog demod) etc. > > What do you think? Yeah! I've been thinking along those lines myself a bit... discuss in a bit. Anyway, here is the latest patch. This one is much better IMO: 1) The userspace IOCTL only lets you choose between normal and scan. We can think about doing this using FE_SET_FRONTEND_EXT in a bit. 2) I've pulled all of the current tuning code in dvb_frontend_thread() out into a seperate function dvb_frontend_swzigzag(). 3) There is a new function pointer in the dvb_frontend_ops - tune(). If this is nonzero, it will be called in the main tuning loop. The frontend is then responsible for ALL of its own tuning maintenance. If is it NULL, dvb_frontend_swzigzag() will be used. BTW: dvb_frontend_ops.set_frontend() and dvb_frontend_ops.get_tune_settings() are only used by the dvb_frontend_swzigzag().. if the driver defines tune(), those functions are superfluous. -------------- next part -------------- A non-text attachment was scrubbed... Name: tunealgo-4.patch Type: text/x-diff Size: 18500 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/linux-dvb/attachments/20051115/b0b198ce/tunealgo-4-0001.bin
