[linux-dvb] Re : Re : Re : [Patch] saa7146: 'wait_for_debi_done' fixes

manu eallaud at yahoo.fr
Fri Oct 12 01:24:36 CEST 2007


On 10/11/2007 06:41:14 PM, Oliver Endriss wrote:
> manu wrote:
> > On 10/10/2007 01:02:46 PM, Oliver Endriss wrote:
> > > manu wrote:
> > > > On 10/09/2007 06:15:14 PM, Oliver Endriss wrote:
> > > > > @all users of saa7146-based cards
> > > > >
> > > > > (drivers: dvb-ttpci, budget, budget-ci, budget-av)
> > > > >
> > > > > Please test whether the attached patch has any negative
> effects.
> > > > >
> > > > > Two fixes for the 'saa7146_wait_for_debi_done' code:
> > > > > (a) Timeout did not work when the routine was called with
> > > interrupts
> > > > >     disabled.
> > > > > (b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
> > > > >     Seems to be very important on fast machines!
> > > > >
> > > > > Based on a patch posted by e9hack at vdr-portal.
> > > > >
> > > > > If nobody complains I will commit this patch next week.
> > > >
> > > > Well sorry it seems to create an oops on my box. Just to make
> sure
> > > > though: it is the first time I compile and load modules from
> > > mercurial
> > > > and so could it just be a compatibility problem with my
> 2.6.20-16
> > > > Ubuntu Feisty kernel?
> > >
> > > Please make sure that you do not mix v4l/dvb modules from the
> original
> > > kernel and the HG driver, or you will see all kinds of crashes.
> > >
> > > First try the HG driver without my patch. If it works, apply the
> patch
> > > and try again.
> > >
> >
> > OK now everything looks identical to the bug I described in a
> previous
> > post: this time CAM is OK looking at the logs (though gnutv -cammenu
> 
> > seems unresponsive whereas it used to work before, did something
> > change, should I recompile it?), but dmesg says no driver found for
> the
> > frontend...
> 
> You do not have to recompile the application.
> 
> Just to be sure:
> There is no difference whether you apply the patch or not.
> Correct?

Well at first I thought that no, but it seems that the frontend is  
found more easily with this patch, whereas it sometimes fails to be  
loaded with the clean tree. See below.

> Are you referring to the thread 'TT S-1500 CI not finding frontend
> driver'?

Yes

> Did the card ever work reliably in this machine?
> Type of machine? SMP system?

Via KM400, yes I know, AMD athlon (single core cpu).
Yes beautifully, but at some point I got a weird error: the cam stopped  
working (I got a dvb error in dmesg) and I had either to reboot or just  
eject/reinsert I don't remember now. Since then it has been on and off.  
And now I get "CAM did not respond" in the logs, even thoughI get the  
full cam signature in the logs: so my guess is that the CI interface  
works as it is able to retrieve the module name/signature, but the CAM  
itself is damaged.
This leads to my next question: is it possible that the bad CAM induces  
i2c errors/timeouts leading to the frontend not being found? And in  
this respect your patch seems to be helpful, as the frontend is, AFAICT  
always found now.

> Did the problem appear after updating the driver?

Nope

> I2C bus problems might be caused by a broken power supply or
> mainboard.
> You might also try a different pci slot.

Well the power supply of the beast is certailny not very good, but now  
I think that th CAM is faulty.
Thx a lot,
Bye
Manu

	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com




More information about the linux-dvb mailing list