Wow! Lots of people being c/c here! Since all pertinent guys are at
lkml, I've just removed all those spam, keeping copied just the lists,
and Adrian, who warned me about it.
Em Qua, 2006-03-08 ?s 14:13 +0300, Brian Marete escreveu:
> What you say is quite correct.
>
> However, my card is not known by the driver, and `card=3' has been working
> for me all the while, with no problems at all. In any case, removing
> `disable_ir=1' from the insmod options hides the problem for me. By the way,
> that option was there since in an an earlier -rc, loading the driver without
> it would cause an oops.
The option disable_ir is, in fact, a workaround. If this is not needed
anymore, this is a progress ;) Anyway, having an OOPS is really bad. We
should go further to avoid oops on it.
IR on some saa7134 cards are really a trouble. Sometimes, it just
generates lots of weird events, since you are gathering a generic io
port (GPIO) from hardware to generate keypressing. Using the wrong port
may generate troubles at the system, by sending wrong events to input.
With a wrong card, if somebody fixed the IR, it may broke for your
board.
>
> If there are any hints about how I might discover the correct parameters for
> my card to be added to `saa7134-cards.c' I would love to hear them.
> I am tired of the FM radio not working anyway. Next time, I will make sure to
> avoid the cheap, brand less cards made in God Knows Where :)
El Cheapo boards are difficult to support. Most of they don't offer an
unique PCI ID. Others are just OEM cards. The same card is selled on
several different markets with different brand names (sometimes with
different GPIO ports and/or tuners).
For you to include it at kernel, you need to discover gpio ports used on
it. There are some wiki pages at http://linuxtv.org explaining the
process of identifying it using dscaler for m$. Dscaler is a freeware,
and have a small app, called regspy, that enables reading what windoze
is programming at some devices. For more details, please look at:
http://linuxtv.org/v4lwiki/index.php/GPIO_pins
>
> Thanks,
> Brian Marete.
>
> On 3/2/06, Mauro Carvalho Chehab <[email protected]> wrote:
> >
> >
> > > Subject : Oops in Kernel 2.6.16-rc4 on Modprobe of saa7134.ko
> > > References : http://lkml.org/lkml/2006/2/20/122
> > > Submitter : Brian Marete <[email protected]>
> > > Status : unknown
> >
> > This is not a regression, since the user is not configuring saa7134 with
> > the right card.
> >
> > Cheers,
> > Mauro.
> >
> >
>
>
> --
> B. Gitonga Marete
> Tel: +254-722-151-590
> _______________________________________________
> v4l-dvb-maintainer mailing list
> [email protected]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
Cheers,
Mauro.
Hi, Brian
Mauro Carvalho Chehab wrote:
> Wow! Lots of people being c/c here! Since all pertinent guys are at
> lkml, I've just removed all those spam, keeping copied just the lists,
> and Adrian, who warned me about it.
>
> Em Qua, 2006-03-08 ?s 14:13 +0300, Brian Marete escreveu:
>
>>What you say is quite correct.
>>
>>However, my card is not known by the driver, and `card=3' has been working
>>for me all the while, with no problems at all. In any case, removing
>>`disable_ir=1' from the insmod options hides the problem for me. By the way,
>>that option was there since in an an earlier -rc, loading the driver without
>>it would cause an oops.
>
> The option disable_ir is, in fact, a workaround. If this is not needed
> anymore, this is a progress ;) Anyway, having an OOPS is really bad. We
> should go further to avoid oops on it.
>
> IR on some saa7134 cards are really a trouble. Sometimes, it just
> generates lots of weird events, since you are gathering a generic io
> port (GPIO) from hardware to generate keypressing. Using the wrong port
> may generate troubles at the system, by sending wrong events to input.
> With a wrong card, if somebody fixed the IR, it may broke for your
> board.
<snip>
I tried to reproduce your problem but i didn't succeed yet. I also think
that the IR support could be the problem. Card 3 defines a GPIO based
remote support. As Mauro mentioned above, this is - at least - dangerous
if you force this card type but you don't have a remote control or just a
different one. This type of remote can use a GPIO port of the SAA713x to
generate interrupts. If this pin is floating on your card, the driver can
just be flooded with IRQs. We should have a look whether we can prevent this
in the IRQ handler.
Best regards
Hartmut