[Fwd: [patch 4/5] saa7134-tvaudio: kthread conversion]

[hermann-pitton at arcor.de (hermann pitton)]

Am Dienstag, den 29.05.2007, 15:21 -0300 schrieb Mauro Carvalho Chehab:
> Em Seg, 2007-05-28 ?s 23:46 +0200, hermann pitton escreveu:
> > Am Montag, den 28.05.2007, 09:11 -0300 schrieb Mauro Carvalho Chehab:
> > > Em Dom, 2007-05-27 ?s 22:39 +0200, hermann pitton escreveu:
> > > > Hi,
> > > > 
> > > > Am Samstag, den 26.05.2007, 07:57 -0300 schrieb Mauro Carvalho Chehab:
> > > > > Guys,
> > > > > 
> > > > > Please test this change on saa7134.
> > > > > 
> > > > > Cheers,
> > > > > Mauro.
> > > > > 
> > > > 
> > > > we must test it, seems nobody likes to do it happily..
> > > 
> > > This patch is waiting for a long time on -mm for us to test.
> > > 
> > > > Attached is a version of the patch that adopts it to the current master
> > > > repo. 
> > > 
> > > Thanks.
> > > 
> > > > Does this work on 2.4x already? Not checked.
> > > 
> > > Might be, but kernel threads changed from 2.4. I'm not sure if we should
> > > care about 2.4 (although I have some patches - yet not committed - that
> > > allows compiling our tree and vivi driver on 2.4).
> > > 
> > > > Please test.
> > > > 
> > > > How should we proceed with testing?
> > > > Hartmut needs enough feedback.
> > > > 
> > > > Have started some testing now on saa7134 und saa7131e and simple tuner,
> > > > tda9887 and tda8290/tda8275a, the other audio inputs, radio not yet.
> > > > 
> > > > It seems to work without any negative impact so far.
> > > 
> > > I think this patch is relevant on countries where more than one
> > > different audio standard can happen. kthread monitors audio carrier,
> > > monitors changes and re-configure audio decoder if another audio STD is
> > > detected. 
> > >  
> > 
> > Yes, that makes "testing" difficult, also mute and automute are involved
> > and video signal detection. The detection is different for saa7134 and
> > saa7133/35/31e, also insmod options to override the detection like
> > audio_ddep for saa7133 only. And things like automute timings needed on
> > channel switch differ between tuner types.
> > By default the thread starts, so I can do testing by all sort of
> > switching, but not for the automated standard switching, but since that
> > is all untouched, likely all works.
> > 
> > It must of course be acked by Hartmut, but they are waiting since
> > October last year and really can expect that something happens here.
> > 
> > Hartmut implemented that the thread does not start on other inputs than
> > tuner anymore, also the SECAM_DK versus SECAM_L detection problem is
> > resolved by adding an insmod option. If radio is handled directly on
> > saa7133 from Philips silicon tuners SIF input at amux TV, radio mute
> > works. (saa7130 and saa7134 can't do that)
> > 
> > The driver is in the best shape ever for worldwide audio detection.
> > Hartmut borrowed a signal generator to track stuff down with not enough
> > feedback even on the list. Also to get the MK3 like tuners correct
> > helped a lot.
> > 
> > A remaining issue, people are whining at the apps lists and bugtrackers,
> > is the not working dual language detection on saa7133 and the like.
> > 
> > On saa7134 I would like to add a mute section with amux TV at least to
> > those cards with radio and without external audio mux. For such with
> > gpio controlled muxes Nickolay did already, on radio amux TV it is not
> > needed.
> > 
> > Now, on the others, the radio doesn't stop on exit and the mute calls of
> > the apps don't come through either. Also the digital sound of the other
> > inputs stays open on exit if not switched to the TV input before. 
> > By the way, on simple tuners the radio output, if radio is not used,
> > emits TV mono sound.
> > 
> > Maybe there is a better solution, but some cards do it already and the
> > only side effect is, with automute enabled and _without_ a video signal
> > on that inputs, one gets audio muted when switching to them by
> > saa7134-video.
> > Guess only a very few people will be surprised by that new behavior and
> > the benefits seem to be clear. If it is all not needed it is a bug
> > somewhere I guess.
> > 
> > There is no hurry for the latter stuff, but on the kthread conversion we
> > must move.
> 
> Your arguments seem valid to me. As you've tested it, can you send me
> your acked-by?
> 
> Cheers,
> Mauro

Mauro,

Gerd has a new email, also the old at bytesex.org is still there.

>   Hi,
> > you get out of reach at suse.de.
> >   
> It's kraxel at redhat.com now ;)
> 
> > If you have any time and remember something, please comment.
> >   
> Sorry, too long ago.  I know it's tricky with all the different tv
> norms 
> and audio subnorms, it is quite hard to test and I was very
> conservative 
> with changes because of that.  But I don't remember all the gloory 
> chipset-specific details any more ...
> 
> cheers,
>   Gerd

Gerd thanks for reply, we should stay very conservative.

I'll wait for Hartmut commenting on that.

For my very limited testing abilities on a single standard only,
I'll do it again to be hopefully sure nothing has changed.
Expect a such limited acked-by until next week.

Cheers,
Hermann