Dear all
I rewrite the part to read/write registers of the audio codec for Ali 5451
Audio Driver.
Best Regards
Lei Hu
Information about update:
Updated files: trident.c
Location: drivers/sound
Driver Version: 0.14.10
Kernel Version: 2.4.18
Attach Patch file:
(See attached file: patch)
On Thu, 2002-06-06 at 07:27, [email protected] wrote:
> Dear all
> I rewrite the part to read/write registers of the audio codec for Ali 5451
> Audio Driver.
The formatting seems to have gone a bit strange but I'll clean that up
and merge the change
Please read linux/Documentation/CodingStyle
Alan Cox wrote:
>On Thu, 2002-06-06 at 07:27, [email protected] wrote:
>
>
>>Dear all
>> I rewrite the part to read/write registers of the audio codec for Ali 5451
>>Audio Driver.
>>
>>
>
>The formatting seems to have gone a bit strange but I'll clean that up
>and merge the change
>
>
Why? Hardware semaphores are notorious for causing hangs. Nobody is
sharing the hardware under Linux, so I think we should enable access on
init, and not disable access until driver close. IMO the mixer should
be guarded by a Linux kernel semaphore... I have a patch from Thomas
Sailer (I think) lying around somewhere that does just that to the via
audio driver. Maybe we can adapt it.
(I cc'd this little detail, in my ali/trident.c patch review, to you)
Jeff
> Why? Hardware semaphores are notorious for causing hangs. Nobody is
> sharing the hardware under Linux, so I think we should enable access on
> init, and not disable access until driver close. IMO the mixer should
> be guarded by a Linux kernel semaphore... I have a patch from Thomas
> Sailer (I think) lying around somewhere that does just that to the via
> audio driver. Maybe we can adapt it.
> (I cc'd this little detail, in my ali/trident.c patch review, to you)
So add a timeout to it ?
Alan Cox wrote:
>>Why? Hardware semaphores are notorious for causing hangs. Nobody is
>>sharing the hardware under Linux, so I think we should enable access on
>>init, and not disable access until driver close. IMO the mixer should
>>be guarded by a Linux kernel semaphore... I have a patch from Thomas
>>Sailer (I think) lying around somewhere that does just that to the via
>>audio driver. Maybe we can adapt it.
>>(I cc'd this little detail, in my ali/trident.c patch review, to you)
>>
>>
>
>So add a timeout to it ?
>
>
There is a problem in via audio, that seems to be present in trident.c
too: trident_ioctl_mixdev doesn't protect the call to
codec->mixer_ioctl, which in turn can read and write to the AC97 codec.
I'm saying, (1) hardware semaphores are error prone and (2) are we using
the hardware sem to work around this lack of locking on ->mixer_ioctl?
Jeff
Hi David
Think you for help !!!
I recheck my driver and pay attention to codingstyle.
I attach file Patch and Ali5451 AC97 read /write spec .(See attached file:
ali5451 spec.doc)(See attached file: patch)
Hi Jeff
Please see my new ali5451 driver (trident.c ) about read /write mixer regiser.
The ali_acquire_codec_access function do not acquire hardware semaphore. It is
audio driver request to write ac97 mixer register.
Please see ali5451 spec 's ACWR . I think that use Linux kernel semaphore (
spin_lock )is repeat because I do read / write Mixer regiser really till
after 48k Hz then codec clocking is 48k hz .In the ali_waitfor_stimertick
function ,You can see it.
Ali5451 (controller ) to codec connection by AC-link,a AC-link output frame
begin with a low to high transition of SYNC. SYNC is synchronous to rising edge
of BIT_CK. NEXT SYNC and SYNC is 48k Hz . So I think that transmit data is
right.
I attach file ( STIME ) :(See attached file: Stimer.doc)