On Thu, 27 Mar 2003, Shaun Jackman wrote:
>
> Does this make .tuner_type change unnecessary, since it can be set
> using the tuner= parameter?
Yes, but it won't solve the audio issues.
>
> > > I'm not even sure the audio_clock change is necessary.
> >
>
> I'll do some empirical tests and find out.
Please do check if the default audio clock is ok with your NTSC board.
>
> > > The GPIO value is actually what I think made the difference to my
> > > audio. Any idea why?
> >
> > Probably some external audio mux chip connected to the gpio pins.
>
> That would make sense. If it doesn't affect other cards, could the
> GPIO value I listed be incorporated into main driver?
I just checked the new gpiomask on my PAL-FV2K, and it seems to work
fine (i.e., no ill-effects), but I only have a weak TV signal to test
with.
However, instead of using
.gpiomask = 0x8018e700, // sdj
Wouldn't it be better to do an initialization using 0x80188700 to the
^-- 8 and not e
GPIO registers on module initialization, and keep .gpiomask = 0x6000 as
defined in the entry since only two bits are used for selecting the Audio
mux. This ensures that the other bits are not 'changed' during an audio
switch (and is more self-documenting).
T.C.
----
Wan Tat Chee (Lecturer)
School of Computer Science, Univ. Science Malaysia,
11800 Minden, Penang, Malaysia. Ofc Ph: +604 653-3888 x 3617
Internet: tcwan@xxxxxxxxx Web: http://nrg.cs.usm.my/~tcwan
GPG Key : http://nrg.cs.usm.my/~tcwan/tcw_gpg-20030322.asc
F'print : DCF2 B9B2 FA4D 1208 AD59 14CA 9A8F F54D B2C4 63C7
