An driver error when I using aplay!

An driver error when I using aplay!

[Roc Wu]

Hi folks:

I compiled the alsa-utils. Then I run the aplay on my
board like this:

# ./aplay -t wav -f U8 -r 22050 alarm.wav
Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate 22050
Hz, Mono
ALSA lib
pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange) Unable
to find an usable access for 'default'
aplay: set_params:832: Sample format non available

And the kernel driver will dump out the message as
below:
Badness in aaci_pcm_close at sound/arm/aaci.c:404
[<c012ead0>] (aaci_pcm_close+0x0/0x90) from
[<c011333c>] (snd_pcm_release_file+0
x58/0x8c)
 r5 = C03852BC  r4 = C03CDC88
[<c01132e4>] (snd_pcm_release_file+0x0/0x8c) from
[<c0113764>] (snd_pcm_release+
0x8c/0x110)
 r7 = C03852BC  r6 = C7BF8820  r5 = C0388A00  r4 =
C0388B18
[<c01136d8>] (snd_pcm_release+0x0/0x110) from
[<c0061e1c>] (__fput+0x58/0x138)
 r7 = C7DEB1E8  r6 = C7FF5260  r5 = C7AFD7FC  r4 =
C7BF8820
[<c0061dc4>] (__fput+0x0/0x138) from [<c0060824>]
(filp_close+0x84/0x90)
 r7 = 00000001  r6 = C7FEAA00  r5 = 00000000  r4 =
C7BF8820
[<c00607a0>] (filp_close+0x0/0x90) from [<c002e700>]
(put_files_struct+0x8c/0xe8
)
 r6 = 00000004  r5 = 00000001  r4 = C7FEAA00
[<c002e674>] (put_files_struct+0x0/0xe8) from
[<c002f314>] (do_exit+0x188/0x398)
 r7 = 00000100  r6 = C00169C0  r5 = C0390360  r4 =
C00169A0
[<c002f18c>] (do_exit+0x0/0x398) from [<c002f55c>]
(next_thread+0x0/0x28)
 r7 = 00000001  r6 = 00000001  r5 = 402DDE10  r4 =
402DDE10
[<c002f544>] (sys_exit+0x0/0x18) from [<c001e300>]
(ret_fast_syscall+0x0/0x2c)

Please give me some hints about the problem.

Thanks a lot
Best Regards



_________________________________________________________
Do You Yahoo!? 
嫌邮箱太小？雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Roc Wu]

Hi folks:

I don't want to post my question again. But there is
not any response about my question. Maybe I did some
thing wrong about asking question, please let me know.
I will change my method, Thanks a lot.

Please give me some help.

Best Regards


 --- Roc Wu <cooloney@yahoo.com.cn> 的正文：> Hi
folks:
> 
> I compiled the alsa-utils. Then I run the aplay on
> my
> board like this:
> 
> # ./aplay -t wav -f U8 -r 22050 alarm.wav
> Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate
> 22050
> Hz, Mono
> ALSA lib
> pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
> Unable
> to find an usable access for 'default'
> aplay: set_params:832: Sample format non available
> 
> And the kernel driver will dump out the message as
> below:
> Badness in aaci_pcm_close at sound/arm/aaci.c:404
> [<c012ead0>] (aaci_pcm_close+0x0/0x90) from
> [<c011333c>] (snd_pcm_release_file+0
> x58/0x8c)
>  r5 = C03852BC  r4 = C03CDC88
> [<c01132e4>] (snd_pcm_release_file+0x0/0x8c) from
> [<c0113764>] (snd_pcm_release+
> 0x8c/0x110)
>  r7 = C03852BC  r6 = C7BF8820  r5 = C0388A00  r4 =
> C0388B18
> [<c01136d8>] (snd_pcm_release+0x0/0x110) from
> [<c0061e1c>] (__fput+0x58/0x138)
>  r7 = C7DEB1E8  r6 = C7FF5260  r5 = C7AFD7FC  r4 =
> C7BF8820
> [<c0061dc4>] (__fput+0x0/0x138) from [<c0060824>]
> (filp_close+0x84/0x90)
>  r7 = 00000001  r6 = C7FEAA00  r5 = 00000000  r4 =
> C7BF8820
> [<c00607a0>] (filp_close+0x0/0x90) from [<c002e700>]
> (put_files_struct+0x8c/0xe8
> )
>  r6 = 00000004  r5 = 00000001  r4 = C7FEAA00
> [<c002e674>] (put_files_struct+0x0/0xe8) from
> [<c002f314>] (do_exit+0x188/0x398)
>  r7 = 00000100  r6 = C00169C0  r5 = C0390360  r4 =
> C00169A0
> [<c002f18c>] (do_exit+0x0/0x398) from [<c002f55c>]
> (next_thread+0x0/0x28)
>  r7 = 00000001  r6 = 00000001  r5 = 402DDE10  r4 =
> 402DDE10
> [<c002f544>] (sys_exit+0x0/0x18) from [<c001e300>]
> (ret_fast_syscall+0x0/0x2c)
> 
> Please give me some hints about the problem.
> 
> Thanks a lot
> Best Regards
> 
> 
> 
>
_________________________________________________________
> Do You Yahoo!? 
> 嫌邮箱太小？雅虎电邮自助扩容！
>
http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by the new
> InstallShield X.
> From Windows to Linux, servers to mobile,
> InstallShield X is the one
> installation-authoring solution that does it all.
> Learn more and
> evaluate today!
> http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/alsa-devel 

_________________________________________________________
Do You Yahoo!? 
嫌邮箱太小？雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Clemens Ladisch]

Roc Wu wrote:
> > # ./aplay -t wav -f U8 -r 22050 alarm.wav
> > Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate 22050 Hz, Mono
> > ALSA lib pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
> > Unable to find an usable access for 'default'
> > aplay: set_params:832: Sample format non available
> >
> > And the kernel driver will dump out the message as below:
> > Badness in aaci_pcm_close at sound/arm/aaci.c:404

This seems to be a bug in the sound driver.

However, arm/aaci.c is not part of the official ALSA distribution.
AFAIK it's a patch written by Russell King.


HTH
Clemens




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Roc Wu]

 --- Clemens Ladisch <clemens@ladisch.de> 的正文：>
Roc Wu wrote:
> > > # ./aplay -t wav -f U8 -r 22050 alarm.wav
> > > Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate
> 22050 Hz, Mono
> > > ALSA lib
> pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
> > > Unable to find an usable access for 'default'
> > > aplay: set_params:832: Sample format non
> available
> > >
> > > And the kernel driver will dump out the message
> as below:
> > > Badness in aaci_pcm_close at
> sound/arm/aaci.c:404
> 
> This seems to be a bug in the sound driver.
> 
> However, arm/aaci.c is not part of the official ALSA
> distribution.
> AFAIK it's a patch written by Russell King.
> 
> 
> HTH
> Clemens
> 
Yes. Thanks for your replay. Maybe I should send the
mail to arm-linux mailist.

PS. Could you recommend some docs about the ALSA
internals and Low level drivers? There are too many
docs in the www.alsa-project.org, I am an embedded
Linux driver developer, so which one is suit for me?

Thanks a lot
Best Regards


_________________________________________________________
Do You Yahoo!? 
嫌邮箱太小？雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 05:25:22PM +0800, Roc Wu wrote:
>  --- Clemens Ladisch <clemens@ladisch.de> µÄÕýÎÄ£º>
> Roc Wu wrote:
> > > > # ./aplay -t wav -f U8 -r 22050 alarm.wav
> > > > Playing WAVE 'alarm.wav' : Unsigned 8 bit, Rate
> > 22050 Hz, Mono
> > > > ALSA lib
> > pcm_plug.c:727:(snd_pcm_plug_hw_refine_schange)
> > > > Unable to find an usable access for 'default'
> > > > aplay: set_params:832: Sample format non
> > available
> > > >
> > > > And the kernel driver will dump out the message
> > as below:
> > > > Badness in aaci_pcm_close at
> > sound/arm/aaci.c:404
> > 
> > This seems to be a bug in the sound driver.

Actually, I disagree.  It's an ALSA bug.  The warning is created if
the AACI close method is called while the DMA or IO is still running.
If DMA is still running here, we've already freed the DMA buffer, so
we're either reading from or writing to memory we don't own - which is
a major bug.

The question is therefore: why is ALSA trying to shut down and free a
device which still has DMA running?  To be more explicit, why didn't
ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
calling the hw_free or close methods?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Jaroslav Kysela]

On Mon, 7 Jun 2004, Russell King wrote:

> Actually, I disagree.  It's an ALSA bug.  The warning is created if
> the AACI close method is called while the DMA or IO is still running.
> If DMA is still running here, we've already freed the DMA buffer, so
> we're either reading from or writing to memory we don't own - which is
> a major bug.
> 
> The question is therefore: why is ALSA trying to shut down and free a
> device which still has DMA running?  To be more explicit, why didn't
> ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
> calling the hw_free or close methods?

The midlevel calls *drop() (which must stop the running stream) and then
->hw_free and ->close callbacks. I've never seen this error, so I suspect
that something else is wrong.

Could you track why snd_pcm_playback_drop() call fails in 
snd_pcm_release() for this hardware?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Developer docs missing from ALSA web server - was:Re: [Alsa-devel] An driver error when I using aplay!

[James Courtier-Dutton]

Roc Wu wrote:
>>
>>>>Unable to find an usable access for 'default'
>>>>aplay: set_params:832: Sample format non
>>
>>available
>>
> 
> Yes. Thanks for your replay. Maybe I should send the
> mail to arm-linux mailist.
> 
> PS. Could you recommend some docs about the ALSA
> internals and Low level drivers? There are too many
> docs in the www.alsa-project.org, I am an embedded
> Linux driver developer, so which one is suit for me?
> 
> Thanks a lot
> Best Regards
> 

The useful developer docs seem to have been lost off the alsa web server.
From: http://www.alsa-project.org/documentation.php3#Driver, there are 
the following broken links:
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html
http://www.alsa-project.org/~iwai/alsa-driver-api/index.html

When you build a new alsa driver, you generally have to also create a 
/usr/share/alsa/cards/XXX  file, where XXX is the name of your driver.

The XXX comes from either: -
  strcpy(card->driver, "XXX");  in your probe routine.

I think you will find the most help if you post the unfinished source 
code for your driver, so that people can look at it, and maybe suggest 
corrections for you.

The best way to test your new driver is with a test tool like 
speaker-test or pcm.

With these you can send a tone to the speakers. You can also set the 
sample rate and number of channels, so that it can test the driver, 
without needing to use plug devices initially.
E.g. If your sound card can only do 48khz stereo. Start testing it with:
speaker-test -r48000 -Dhw:0,0 -c2

plug devices tend not to work well until you have a correctly 
functioning driver.

Cheers
James


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 12:43:01 +0200 (CEST),
Jaroslav wrote:
> 
> On Mon, 7 Jun 2004, Russell King wrote:
> 
> > Actually, I disagree.  It's an ALSA bug.  The warning is created if
> > the AACI close method is called while the DMA or IO is still running.
> > If DMA is still running here, we've already freed the DMA buffer, so
> > we're either reading from or writing to memory we don't own - which is
> > a major bug.
> > 
> > The question is therefore: why is ALSA trying to shut down and free a
> > device which still has DMA running?  To be more explicit, why didn't
> > ALSA call the trigger callback with SNDRV_PCM_TRIGGER_STOP prior to
> > calling the hw_free or close methods?
> 
> The midlevel calls *drop() (which must stop the running stream) and then
> ->hw_free and ->close callbacks. I've never seen this error, so I suspect
> that something else is wrong.

i guess so, too.  as you can see in the original post, the error
returned from hw_params callback (sample not available), thus it
doesn't call trigger(START) callback yet at all.

unfurtunately i can't tell any more unless i read the driver code.
where can i find the code?


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
> i guess so, too.  as you can see in the original post, the error
> returned from hw_params callback (sample not available), thus it
> doesn't call trigger(START) callback yet at all.

If we never got past hw_params() then we didn't enable the IO,
and it must be that something else in the system fiddled with
the chip and set it incorrectly.

> unfurtunately i can't tell any more unless i read the driver code.
> where can i find the code?

I never officially released the driver, though it was part of the
old -rmk patches back in the 2.6.0-test era.  Where Roc has got
the source from, and what modifications have been made is anyones
guess.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 14:08:17 +0100,
Russell King wrote:
> 
> On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
> > i guess so, too.  as you can see in the original post, the error
> > returned from hw_params callback (sample not available), thus it
> > doesn't call trigger(START) callback yet at all.
> 
> If we never got past hw_params() then we didn't enable the IO,
> and it must be that something else in the system fiddled with
> the chip and set it incorrectly.
> 
> > unfurtunately i can't tell any more unless i read the driver code.
> > where can i find the code?
> 
> I never officially released the driver, though it was part of the
> old -rmk patches back in the 2.6.0-test era.  Where Roc has got
> the source from, and what modifications have been made is anyones
> guess.

Roc sent me the code now :)

after a quick look, it seems that txcr isn't initialized in the open
callback but only in hw_params callback (which was never called in
this case).  if my guess is correct, adding the following to
aacpi_playback_open() should fix this problem:

	chan->txcr = 0;


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 03:40:23PM +0200, Takashi Iwai wrote:
> At Mon, 7 Jun 2004 14:08:17 +0100,
> Russell King wrote:
> > 
> > On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
> > > i guess so, too.  as you can see in the original post, the error
> > > returned from hw_params callback (sample not available), thus it
> > > doesn't call trigger(START) callback yet at all.
> > 
> > If we never got past hw_params() then we didn't enable the IO,
> > and it must be that something else in the system fiddled with
> > the chip and set it incorrectly.
> > 
> > > unfurtunately i can't tell any more unless i read the driver code.
> > > where can i find the code?
> > 
> > I never officially released the driver, though it was part of the
> > old -rmk patches back in the 2.6.0-test era.  Where Roc has got
> > the source from, and what modifications have been made is anyones
> > guess.
> 
> Roc sent me the code now :)
> 
> after a quick look, it seems that txcr isn't initialized in the open
> callback but only in hw_params callback (which was never called in
> this case).

Why should it be explicitly initialised?  Take a moment to consider
what guarantees snd_card_new() gives for the allocated memory.  Yep,
that's right - it's initialised to zero.  So, chan->txcr is already
initialised to zero.

So, let's step back and consider.

At init time.
	chan->txcr is zeroed.
open
	no change.
hw_parms
	chan->txcr may be set to the required format if successful,
	but isn't.
close
	chan->txcr should still be zero.

Even if hw_params did succeed, then chan->txcr will be set to something
which doesn't have TXCR_TXEN set, until the trigger is called with
SNDRV_PCM_TRIGGER_START.

So I still assert that the problem is in ALSA core or in modifications
to the code.

> if my guess is correct, adding the following to
> aacpi_playback_open() should fix this problem:
> 
> 	chan->txcr = 0;

So respectfully I think the above is crap.

But unfortunately I don't have the driver code myself to be able to
comment, so its probably been fscked.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 14:51:13 +0100,
Russell King wrote:
> 
> On Mon, Jun 07, 2004 at 03:40:23PM +0200, Takashi Iwai wrote:
> > At Mon, 7 Jun 2004 14:08:17 +0100,
> > Russell King wrote:
> > > 
> > > On Mon, Jun 07, 2004 at 02:45:20PM +0200, Takashi Iwai wrote:
> > > > i guess so, too.  as you can see in the original post, the error
> > > > returned from hw_params callback (sample not available), thus it
> > > > doesn't call trigger(START) callback yet at all.
> > > 
> > > If we never got past hw_params() then we didn't enable the IO,
> > > and it must be that something else in the system fiddled with
> > > the chip and set it incorrectly.
> > > 
> > > > unfurtunately i can't tell any more unless i read the driver code.
> > > > where can i find the code?
> > > 
> > > I never officially released the driver, though it was part of the
> > > old -rmk patches back in the 2.6.0-test era.  Where Roc has got
> > > the source from, and what modifications have been made is anyones
> > > guess.
> > 
> > Roc sent me the code now :)
> > 
> > after a quick look, it seems that txcr isn't initialized in the open
> > callback but only in hw_params callback (which was never called in
> > this case).
> 
> Why should it be explicitly initialised?  Take a moment to consider
> what guarantees snd_card_new() gives for the allocated memory.  Yep,
> that's right - it's initialised to zero.  So, chan->txcr is already
> initialised to zero.

You're right.  The error was not txcr, but in another WARN_ON() for
checking chan->tx_substream (line 404)!  (Russell, you mislead this,
too ;)

The reason is same -- since hw_params is not called,
chan->tx_substream is not set, too.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[James Courtier-Dutton]

Russell King wrote:
> 
> But unfortunately I don't have the driver code myself to be able to
> comment, so its probably been fscked.
> 

If the code was posted publically, the author of the code would get a 
lot more useful help from more eyes.


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 04:18:55PM +0200, Takashi Iwai wrote:
> You're right.  The error was not txcr, but in another WARN_ON() for
> checking chan->tx_substream (line 404)!  (Russell, you mislead this,
> too ;)

Well I don't have the exact source which this guy is using, so I can
only guess.

> The reason is same -- since hw_params is not called,
> chan->tx_substream is not set, too.

Wrong.  It's memset to zero by matter of fact of how it is allocated.
I'm surprised you don't know this.  It is afterall code which I thought
you'd be fully aware of, being core ALSA code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 03:24:46PM +0100, James Courtier-Dutton wrote:
> Russell King wrote:
> > 
> > But unfortunately I don't have the driver code myself to be able to
> > comment, so its probably been fscked.
> > 
> 
> If the code was posted publically, the author of the code would get a 
> lot more useful help from more eyes.

The author of the code (me) is complaining that he can't see the
exact code in question because it appears to be either and old
version or contains additional modifications.

And the reason it isn't publically released yet is because ALSA
fails to work correctly on ARM, so the desire to release it and
end up supporting a lot of whinging people, explaining why core
ALSA on ARM is broken is _NOT_ what I want.

I'm not in the habbit of releasing known broken code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 16:04:42 +0100,
Russell King wrote:
> 
> On Mon, Jun 07, 2004 at 04:18:55PM +0200, Takashi Iwai wrote:
> > You're right.  The error was not txcr, but in another WARN_ON() for
> > checking chan->tx_substream (line 404)!  (Russell, you mislead this,
> > too ;)
> 
> Well I don't have the exact source which this guy is using, so I can
> only guess.

Don't take serious, I'd thought of that, too :)

> > The reason is same -- since hw_params is not called,
> > chan->tx_substream is not set, too.
> 
> Wrong.  It's memset to zero by matter of fact of how it is allocated.
> I'm surprised you don't know this.  It is afterall code which I thought
> you'd be fully aware of, being core ALSA code.

No, the problematic line is:

	WARN_ON(chan->tx_substream != substream);

It can't pass because chan->tx_substream is always NULL (as you wrote)
unless hw_params is called.  The check is wrong.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 05:13:47PM +0200, Takashi Iwai wrote:
> At Mon, 7 Jun 2004 16:04:42 +0100,
> Russell King wrote:
> > 
> > On Mon, Jun 07, 2004 at 04:18:55PM +0200, Takashi Iwai wrote:
> > > You're right.  The error was not txcr, but in another WARN_ON() for
> > > checking chan->tx_substream (line 404)!  (Russell, you mislead this,
> > > too ;)
> > 
> > Well I don't have the exact source which this guy is using, so I can
> > only guess.
> 
> Don't take serious, I'd thought of that, too :)
> 
> > > The reason is same -- since hw_params is not called,
> > > chan->tx_substream is not set, too.
> > 
> > Wrong.  It's memset to zero by matter of fact of how it is allocated.
> > I'm surprised you don't know this.  It is afterall code which I thought
> > you'd be fully aware of, being core ALSA code.
> 
> No, the problematic line is:
> 
> 	WARN_ON(chan->tx_substream != substream);
> 
> It can't pass because chan->tx_substream is always NULL (as you wrote)
> unless hw_params is called.  The check is wrong.

Ah, well, in my current version of this, I've completely removed that
check.  Whether there are any other changes, I've no idea.  However,
my current version doesn't work at all at the moment because its in
the middle of having experimental DMA support added, rather than
being sucky PIO-only.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 16:18:12 +0100,
Russell King wrote:
> 
> > No, the problematic line is:
> > 
> > 	WARN_ON(chan->tx_substream != substream);
> > 
> > It can't pass because chan->tx_substream is always NULL (as you wrote)
> > unless hw_params is called.  The check is wrong.
> 
> Ah, well, in my current version of this, I've completely removed that
> check.  Whether there are any other changes, I've no idea.

I also won't debug this any more unless the code is opened
publicly...

>   However,
> my current version doesn't work at all at the moment because its in
> the middle of having experimental DMA support added, rather than
> being sucky PIO-only.

Where we're here:  I'd really like to fix the DMA problem of ALSA on
ARM.  As I sent you before, the patch is already there but I have no
idea whether it's really right or not.  Could you please comment
whether the assumptions below are correct?

- the page struct can be retrieved from dma_addr_t of
  dma_alloc_coherent() like

	virt_to_page(bus_to_virt(addr))

- adding pgprot_noncached() in fop->mmap callback assures that the
  mmaped page is accessed without cache side effects.


thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 05:32:35PM +0200, Takashi Iwai wrote:
> At Mon, 7 Jun 2004 16:18:12 +0100,
> Russell King wrote:
> > 
> > > No, the problematic line is:
> > > 
> > > 	WARN_ON(chan->tx_substream != substream);
> > > 
> > > It can't pass because chan->tx_substream is always NULL (as you wrote)
> > > unless hw_params is called.  The check is wrong.
> > 
> > Ah, well, in my current version of this, I've completely removed that
> > check.  Whether there are any other changes, I've no idea.
> 
> I also won't debug this any more unless the code is opened
> publicly...

I wasn't asking you to. 8)

> >   However,
> > my current version doesn't work at all at the moment because its in
> > the middle of having experimental DMA support added, rather than
> > being sucky PIO-only.
> 
> Where we're here:  I'd really like to fix the DMA problem of ALSA on
> ARM.  As I sent you before, the patch is already there but I have no
> idea whether it's really right or not.  Could you please comment
> whether the assumptions below are correct?
> 
> - the page struct can be retrieved from dma_addr_t of
>   dma_alloc_coherent() like
> 
> 	virt_to_page(bus_to_virt(addr))

Well, bus_to_virt() is a deprecated interface, and one which is
meaningless on certain classes of machines.  Really, we shouldn't
be adding code which relies on it.

What we should be doing is something like the following, which is
a generic set of coherent DMA allocation, freeing, and mmap
functions which would cover any driver-model based device.

snd_pcm_ops_t should have a mmap() method just like everything else
in the kernel, which allows drivers to select the appropriate mmap()
implementation.

> - adding pgprot_noncached() in fop->mmap callback assures that the
>   mmaped page is accessed without cache side effects.

Correct, but as it has been already decided elsewhere, interfaces
which expose pgprot tweaking are broken and new ones should not be
introduced.  They also _may_ only affect the userspace mapping of
that memory and not kernel space, so this doesn't help the control
or status mmaped pages.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 16:44:01 +0100,
Russell King wrote:
> 
> > Where we're here:  I'd really like to fix the DMA problem of ALSA on
> > ARM.  As I sent you before, the patch is already there but I have no
> > idea whether it's really right or not.  Could you please comment
> > whether the assumptions below are correct?
> > 
> > - the page struct can be retrieved from dma_addr_t of
> >   dma_alloc_coherent() like
> > 
> > 	virt_to_page(bus_to_virt(addr))
> 
> Well, bus_to_virt() is a deprecated interface, and one which is
> meaningless on certain classes of machines.

Yes, ideally such a stuff should be really in the arch-specific kernel
part.  (BTW, the above is assumed to be ARM specific.)

> Really, we shouldn't be adding code which relies on it.

Agreed.

> What we should be doing is something like the following, which is
> a generic set of coherent DMA allocation, freeing, and mmap
> functions which would cover any driver-model based device.

So, do you mean to hide the stuffs like above (and cache disabling) in
this new mmap function dedicated for the coherent DMA?

> snd_pcm_ops_t should have a mmap() method just like everything else
> in the kernel, which allows drivers to select the appropriate mmap()
> implementation.

I thought of this, too.  This may help some cases, but we still need a
generic solution, because a PCI driver can be used in different
architectures.


> > - adding pgprot_noncached() in fop->mmap callback assures that the
> >   mmaped page is accessed without cache side effects.
> 
> Correct, but as it has been already decided elsewhere, interfaces
> which expose pgprot tweaking are broken and new ones should not be
> introduced.

Hmm, is there a standard interface for this purpose?
So far, setting like
	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
looks like the only way to achieve this.

(If this whole mmap method itself is hidden in the generic function,
 this is not exposed, though...)

> They also _may_ only affect the userspace mapping of
> that memory and not kernel space, so this doesn't help the control
> or status mmaped pages.

Oh yes, then how about to use a DMA page for the control/status mmap,
too?


thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Russell King]

On Mon, Jun 07, 2004 at 06:25:15PM +0200, Takashi Iwai wrote:
> At Mon, 7 Jun 2004 16:44:01 +0100,
> Russell King wrote:
> > What we should be doing is something like the following, which is
> > a generic set of coherent DMA allocation, freeing, and mmap
> > functions which would cover any driver-model based device.
> 
> So, do you mean to hide the stuffs like above (and cache disabling) in
> this new mmap function dedicated for the coherent DMA?

Absolutely - it hides how the mapping from the coherent DMA allocation
is handled from the drivers and puts it where it's supposed to be - in
the architecture code.

> > snd_pcm_ops_t should have a mmap() method just like everything else
> > in the kernel, which allows drivers to select the appropriate mmap()
> > implementation.
> 
> I thought of this, too.  This may help some cases, but we still need a
> generic solution, because a PCI driver can be used in different
> architectures.

Yes, but at least if you have a common function you won't have to
modify thousands of drivers - and you'll need that function to
get at the struct device.  Eg, something like:

static int aaci_pcm_mmap(snd_pcm_substream_t *substream, struct vm_area_struct *vma)
{
        struct aaci *aaci = substream->private_data;
        return devdma_mmap(&aaci->dev->dev, substream, vma);
}

int devdma_mmap(struct device *dev, snd_pcm_substream_t *substream, struct vm_area_struct *vma)
{
        snd_pcm_runtime_t *runtime = substream->runtime;
        return dma_mmap_coherent(dev, vma, runtime->dma_area, runtime->dma_addr, runtime->dma_bytes);
}

And devdma_mmap contains whatever is necessary for each architecture
until they implement dma_mmap_coherent - which would be something akin
to the code currently in pcm_native.c for handling this itself.  IOW,
snd_pcm_mmap_data_open, snd_pcm_mmap_data_close, snd_pcm_mmap_data_nopage
and the bulk of snd_pcm_mmap_data in devdma_mmap().

> > > - adding pgprot_noncached() in fop->mmap callback assures that the
> > >   mmaped page is accessed without cache side effects.
> > 
> > Correct, but as it has been already decided elsewhere, interfaces
> > which expose pgprot tweaking are broken and new ones should not be
> > introduced.
> 
> Hmm, is there a standard interface for this purpose?

No - because it's completely non-portable.  Eg, not all architectures
are capable of turning off the cache on a per-page basis.

> > They also _may_ only affect the userspace mapping of
> > that memory and not kernel space, so this doesn't help the control
> > or status mmaped pages.
> 
> Oh yes, then how about to use a DMA page for the control/status mmap,
> too?

Oddly that's what I did on VIVT caches to get Alsa working a few months
ago, but its very unclean and the way I did it, it exposes the "dma"
address in the actual page - which would be a major security problem
if I let the code out.  As I said back then, I didn't have a clean
solution for this.

There are other problems with VIPT caches where the cache colour
becomes important and directly impinges on this "shared" mmap method,
but that's another story.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Roc Wu]

 --- Russell King <rmk+alsa@arm.linux.org.uk>
的正文：> On Mon, Jun 07, 2004 at 02:45:20PM +0200,
Takashi
> Iwai wrote:
> > i guess so, too.  as you can see in the original
> post, the error
> > returned from hw_params callback (sample not
> available), thus it
> > doesn't call trigger(START) callback yet at all.
> 
> If we never got past hw_params() then we didn't
> enable the IO,
> and it must be that something else in the system
> fiddled with
> the chip and set it incorrectly.
> 
> > unfurtunately i can't tell any more unless i read
> the driver code.
> > where can i find the code?
> 
> I never officially released the driver, though it
> was part of the
> old -rmk patches back in the 2.6.0-test era.  Where
> Roc has got
> the source from, and what modifications have been
> made is anyones
> guess.

Oh, the code is not officially version. It's from the
ARM Ltd for the Versatile Platform Board. 

So please forgive me for making Russell confused.

Because I am not familar with the ALSA internal code,
I send the error here.

Thanks a lot
Best Regards.


_________________________________________________________
Do You Yahoo!? 
嫌邮箱太小？雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/10m/*http://cn.mail.yahoo.com/event/10m.html


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Takashi Iwai]

At Mon, 7 Jun 2004 19:04:16 +0100,
Russell King wrote:
> 
> > > snd_pcm_ops_t should have a mmap() method just like everything else
> > > in the kernel, which allows drivers to select the appropriate mmap()
> > > implementation.
> > 
> > I thought of this, too.  This may help some cases, but we still need a
> > generic solution, because a PCI driver can be used in different
> > architectures.
> 
> Yes, but at least if you have a common function you won't have to
> modify thousands of drivers - and you'll need that function to
> get at the struct device.  Eg, something like:
> 
> static int aaci_pcm_mmap(snd_pcm_substream_t *substream, struct vm_area_struct *vma)
> {
>         struct aaci *aaci = substream->private_data;
>         return devdma_mmap(&aaci->dev->dev, substream, vma);
> }
> 
> int devdma_mmap(struct device *dev, snd_pcm_substream_t *substream, struct vm_area_struct *vma)
> {
>         snd_pcm_runtime_t *runtime = substream->runtime;
>         return dma_mmap_coherent(dev, vma, runtime->dma_area, runtime->dma_addr, runtime->dma_bytes);
> }

This looks nice.  I'd love to have such one, too.


> And devdma_mmap contains whatever is necessary for each architecture
> until they implement dma_mmap_coherent - which would be something akin
> to the code currently in pcm_native.c for handling this itself.  IOW,
> snd_pcm_mmap_data_open, snd_pcm_mmap_data_close, snd_pcm_mmap_data_nopage
> and the bulk of snd_pcm_mmap_data in devdma_mmap().

Well, in practice, there are some hurdles.

- For using nopage vma_ops, we need to set an appropriate
  vma_private_data to pass the base DMA pointer and address.  If this
  is a kmalloc data created in dev_mmap(), how can we release it?

- Instead of using nopage, we need mark pages as reserved so that
  mmap callback can simply use remap_page_addr(), since
  dma_alloc_coherent() doesn't do this on all architectures.

  The question is who should mark this reseved hack.  Ideally,
  dma_alloc_coherent() assures that the pages are marked as reserved.
  Otherwise, dev_mmap() itself would need to handle this
  marking/clearing.

- Handling of SG coherent DMA case?  If nopage is not used, the caller
  can call dev_mmap() on each page.  If nopage is used, the
  SG-implementation must be in nopage, too.


If we assumed that the passed DMA buffer is already marked as
reserved, using remap_page_addr() in mmap would be the easiest
solution.

On the other hand, when we just fix the ALSA case, providing the DMA
-> page conversion (let's call dma_map_to_page) would be the
easiest.  (Except for the cache stuff of control/status pages.)



> > > > - adding pgprot_noncached() in fop->mmap callback assures that the
> > > >   mmaped page is accessed without cache side effects.
> > > 
> > > Correct, but as it has been already decided elsewhere, interfaces
> > > which expose pgprot tweaking are broken and new ones should not be
> > > introduced.
> > 
> > Hmm, is there a standard interface for this purpose?
> 
> No - because it's completely non-portable.  Eg, not all architectures
> are capable of turning off the cache on a per-page basis.

Ok.  This can be hidden in dev_mmap(), too, if we do it right...


> > > They also _may_ only affect the userspace mapping of
> > > that memory and not kernel space, so this doesn't help the control
> > > or status mmaped pages.
> > 
> > Oh yes, then how about to use a DMA page for the control/status mmap,
> > too?
> 
> Oddly that's what I did on VIVT caches to get Alsa working a few months
> ago, but its very unclean and the way I did it, it exposes the "dma"
> address in the actual page - which would be a major security problem
> if I let the code out.  As I said back then, I didn't have a clean
> solution for this.

Well, i386 and x86-64 provide a function change_page_attr() for this
purpose.  But it's also a horrible arch-spec hack.

How about to introduce a function like alloc_pages_noncached()?


--
Takashi Iwai <tiwai@suse.de>		ALSA Developer - www.alsa-project.org


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Russell King]

On Tue, Jun 08, 2004 at 05:48:45PM +0200, Takashi Iwai wrote:
> At Mon, 7 Jun 2004 19:04:16 +0100,
> Russell King wrote:
> > > > They also _may_ only affect the userspace mapping of
> > > > that memory and not kernel space, so this doesn't help the control
> > > > or status mmaped pages.
> > > 
> > > Oh yes, then how about to use a DMA page for the control/status mmap,
> > > too?
> > 
> > Oddly that's what I did on VIVT caches to get Alsa working a few months
> > ago, but its very unclean and the way I did it, it exposes the "dma"
> > address in the actual page - which would be a major security problem
> > if I let the code out.  As I said back then, I didn't have a clean
> > solution for this.
> 
> Well, i386 and x86-64 provide a function change_page_attr() for this
> purpose.  But it's also a horrible arch-spec hack.
> 
> How about to introduce a function like alloc_pages_noncached()?

Just a quick response on this point while I wait for a rebuild (because
I don't have time to think about the rest of your reply at the moment -
and then I'll probably forget about it by the end of tonight, sorry...)

I think you'll find that alloc_pages_noncached() is unimplementable on
x86 and other architectures.  Some architectures are unable to turn the
cache on and off on a per-page basis, while others can.  Some need to
ensure that the relative mappings of two pages fall on the same cache
colour.  Some need reprogramming of some hardware depending on where
stuff is mapped.  The list goes on and on...

Basically, I think you'll find that this part of the ALSA API isn't
universally implementable across all kernel architectures.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org

Re: An driver error when I using aplay!

[Takashi Iwai]

At Tue, 8 Jun 2004 17:40:58 +0100,
Russell King wrote:
> 
> On Tue, Jun 08, 2004 at 05:48:45PM +0200, Takashi Iwai wrote:
> > At Mon, 7 Jun 2004 19:04:16 +0100,
> > Russell King wrote:
> > > > > They also _may_ only affect the userspace mapping of
> > > > > that memory and not kernel space, so this doesn't help the control
> > > > > or status mmaped pages.
> > > > 
> > > > Oh yes, then how about to use a DMA page for the control/status mmap,
> > > > too?
> > > 
> > > Oddly that's what I did on VIVT caches to get Alsa working a few months
> > > ago, but its very unclean and the way I did it, it exposes the "dma"
> > > address in the actual page - which would be a major security problem
> > > if I let the code out.  As I said back then, I didn't have a clean
> > > solution for this.
> > 
> > Well, i386 and x86-64 provide a function change_page_attr() for this
> > purpose.  But it's also a horrible arch-spec hack.
> > 
> > How about to introduce a function like alloc_pages_noncached()?
> 
> Just a quick response on this point while I wait for a rebuild (because
> I don't have time to think about the rest of your reply at the moment -
> and then I'll probably forget about it by the end of tonight, sorry...)

Hehe, I have also a quite limited FIFO queue ;)

> I think you'll find that alloc_pages_noncached() is unimplementable on
> x86 and other architectures.  Some architectures are unable to turn the
> cache on and off on a per-page basis, while others can.  Some need to
> ensure that the relative mappings of two pages fall on the same cache
> colour.  Some need reprogramming of some hardware depending on where
> stuff is mapped.  The list goes on and on...

Yes.

> Basically, I think you'll find that this part of the ALSA API isn't
> universally implementable across all kernel architectures.

Right.  Remember that now the control/status mmap isn't mandatory any
more.  We can live without it safely.  But still it's nicer to use it
as much as possible.

That is, the scenario is:  alloc_pages_noncached() may fail - we
accept it.  Then the mmap returns the error, and alsa-lib tries
non-mmap behavior.

--
Takashi Iwai <tiwai@suse.de>		ALSA Developer - www.alsa-project.org


-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org