Re: KWORLD DVB-T 220RF Very slow to open() and tune

[Barry Scott <barry.scott@xxxxxxxxxxxx>]

Hartmut Hackmann wrote:
> Hi, Barry
>
> Barry Scott wrote:
> > Hartmut Hackmann wrote:
> >
> > > Hi,
> > >
> > > Barry Scott wrote:
> > >
> > > > Hartmut Hackmann wrote:
> > > >
> > > > > This change is dangerous:
> > > > > Some tuner datasheets state that you may never set a frequency
> > > > > outside the normal range since recovery after an LO cutoff can
> > > > > not be guaranteed. This is what the original code is good for.
> > > >
> > > >
> > > > It is safe as the code never asks the tuner to use 0.
> > > > There is code already in the driver that checks for 0 and skips
> > > > tuning. However...
> > > >
> > > > Having read the code more deeply this seems to be a better patch.
> > > >
> > > > The first section makes tuning conditional on the input being tv.
> > > > Or should it be conditional on number of tuners being > 0?
> > > >
> > > > The second part stops open() from tuning.
> > > >
> > > > This has the end user effect that opening the device is fast.
> > > > Selection of Composite or S-Video is fast, as tuning is not run
> > > > when an input that is not tv is selected.
> > > >
> > > > Can you see any problems with this approach?
> > > >
> > > > Barry
> > > >
> > > > diff -r 7b945ba585c3 linux/drivers/media/video/saa7134/saa7134-video.c
> > > > --- a/linux/drivers/media/video/saa7134/saa7134-video.c Tue Oct 31 
> > > > 15:33:29 2006 -0300
> > > > +++ b/linux/drivers/media/video/saa7134/saa7134-video.c Wed Nov 08 
> > > > 14:52:18 2006 +0000
> > > > @@ -604,7 +604,9 @@ static void set_tvnorm(struct saa7134_de
> > > >        saa_writeb(SAA7134_RAW_DATA_GAIN,         0x40);
> > > >        saa_writeb(SAA7134_RAW_DATA_OFFSET,       0x80);
> > > >
> > > > -       saa7134_i2c_call_clients(dev,VIDIOC_S_STD,&norm->id);
> > > > +       /* only tell the tuner if this is a tv input */
> > > > +        if (card_in(dev,dev->ctl_input).tv)
> > > > +               saa7134_i2c_call_clients(dev,VIDIOC_S_STD,&norm->id);
> > > > }
> > > >
> > > > static void video_mux(struct saa7134_dev *dev, int input)
> > > > @@ -1332,14 +1334,6 @@ static int video_open(struct inode *inod
> > > >        saa7134_pgtable_alloc(dev->pci,&fh->pt_cap);
> > > >        saa7134_pgtable_alloc(dev->pci,&fh->pt_vbi);
> > > >
> > > > -       if (fh->radio) {
> > > > -               /* switch to radio mode */
> > > > -               saa7134_tvaudio_setinput(dev,&card(dev).radio);
> > > > -               saa7134_i2c_call_clients(dev,AUDC_SET_RADIO, NULL);
> > > > -       } else {
> > > > -               /* switch to video/vbi mode */
> > > > -               video_mux(dev,dev->ctl_input);
> > > > -       }
> > > >        return 0;
> > > > }
> > > >
> > > > --
> > > > video4linux-list mailing list
> > > > Unsubscribe 
> > > > mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
> > > > https://www.redhat.com/mailman/listinfo/video4linux-list
> > > I think the first part of the patch is ok but i feel uncertain with the
> > > 2nd part. I need to test it.
> > > But i am still convinced that we should improve the root cause: the
> > > (necessarily) slow and uninterruptible tuning process....
> > Have you been able to test this patch? Do you need a mail with 
> > [PATCH] in
> > the subject to help track this?
> >
> > Barry
> Sorry, i haven't found the time yet. Btw: I got a new recommendation 
> for the
> tuning code that uses shorter delays. I started implementing this.
Thats good to know but has no relevance to the problem I've fixed. I 
surprised that
you keep mentioning the speed of tuning when the bug is that tuning is 
not required
at all for S-Video input.

Barry

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list