This patch series mainly fixes the saif record unwork issue.
The root cause consists of:
1) clk_prepare and clk_enable un-balanced
2) missed setting a proper initial clock rate for saif in dt
3) sgtl5000 dapm widget kcontrol does not work
So can not test record on mx28evk.
4) missed setting clkmux mode for saif in dt
With this patch series it can fix sgtl5000 widget kcontrol unwork
and saif record unwork issue.
BTW, just let people konw, i still met a few overruns during record,
that's another issue and will be fixed in separte patches later.
Patch based on sound-2.6/for-3.6.
Dong Aisheng (4):
ASoC: mxs-saif: fix clock prepare and enable unbalance issue
ASoC: mxs-saif: set a base clock rate for EXTMASTER mode work
ASoC: sgtl5000: remove unneeded snd_soc_dapm_new_widgets in probe
ARM: mx28evk: add missed clkmux select for saif
arch/arm/mach-mxs/mach-mxs.c | 3 +++
sound/soc/codecs/sgtl5000.c | 2 --
sound/soc/mxs/mxs-saif.c | 24 ++++++++++++++++++++++++
3 files changed, 27 insertions(+), 2 deletions(-)
From: Dong Aisheng <redacted>
Currently we directly call a clock_enable in trigger function without
a clk_prepare as pair first.
This will cause system hang immediately when run capture because
the clock was not prepared(playback does not hang because the clock was
prepared already by get_mclk before), a warning message in clock framework
may cause a deadlock to reclaim clock lock (see: pl011_console_write).
Here we prepare clock first in hw_param, then enable it in trigger
function to guarantee the balance.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
Signed-off-by: Dong Aisheng <redacted>
---
sound/soc/mxs/mxs-saif.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
@@ -394,9 +394,14 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream,structsnd_soc_dai*cpu_dai){structmxs_saif*saif=snd_soc_dai_get_drvdata(cpu_dai);+structmxs_saif*master_saif;u32scr,stat;intret;+master_saif=mxs_saif_get_master(saif);+if(!master_saif)+return-EINVAL;+/* mclk should already be set */if(!saif->mclk&&saif->mclk_in_use){dev_err(cpu_dai->dev,"set mclk first\n");
@@ -420,6 +425,11 @@ static int mxs_saif_hw_params(struct snd_pcm_substream *substream,returnret;}+/* prepare clk in hw_param, enable in trigger */+clk_prepare(saif->clk);+if(saif!=master_saif)+clk_prepare(master_saif->clk);+scr=__raw_readl(saif->base+SAIF_CTRL);scr&=~BM_SAIF_CTRL_WORD_LENGTH;
From: Dong Aisheng <redacted>
Set an initial clock rate for the saif internal logic to work
properly. This is important when working in EXTMASTER mode that
uses the other saif's BITCLK&LRCLK but it still needs a basic
clock which should be fast enough for the internal logic.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
Signed-off-by: Dong Aisheng <redacted>
---
sound/soc/mxs/mxs-saif.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
From: Dong Aisheng <redacted>
There's a driver bug that sgtl5000 dapm widget kcontrols do not work.
e.g. can not select capture mux with amixer tool(no error info prompted).
The root cause is that we still call snd_soc_dapm_new_widgets in
codec driver probe function afer converting to table based widgets.
This will cause the card dapm widgets are instantiated before the
dapm_routes are registered.
Then, no available dapm widget pathes can be found during instantiation
which finally will cause soc_dapm_mux_update_power to fail(can not find
correct path with kcontrol) in snd_soc_dapm_put_enum_double function.
Here we remove the unneeded snd_soc_dapm_new_widgets in codec probe
and let the soc core to handle the register sequence properly.
Then we can fix above issue.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
Signed-off-by: Dong Aisheng <redacted>
---
sound/soc/codecs/sgtl5000.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
On Fri, Jul 20, 2012 at 05:20:24PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <redacted>
Currently we directly call a clock_enable in trigger function without
a clk_prepare as pair first.
This will cause system hang immediately when run capture because
the clock was not prepared(playback does not hang because the clock was
prepared already by get_mclk before), a warning message in clock framework
may cause a deadlock to reclaim clock lock (see: pl011_console_write).
Here we prepare clock first in hw_param, then enable it in trigger
function to guarantee the balance.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
On Fri, Jul 20, 2012 at 05:20:25PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <redacted>
Set an initial clock rate for the saif internal logic to work
properly. This is important when working in EXTMASTER mode that
uses the other saif's BITCLK&LRCLK but it still needs a basic
clock which should be fast enough for the internal logic.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
Is this a board specific setup? Or every single imx28 based board that
wants recording function is going to need this setup?
BTW, the patch needs to get rebased on v3.6-rc1, where mach-mxs.c will
have some context update.
Regards,
Shawn
On Fri, Jul 20, 2012 at 05:20:26PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <redacted>
There's a driver bug that sgtl5000 dapm widget kcontrols do not work.
e.g. can not select capture mux with amixer tool(no error info prompted).
The root cause is that we still call snd_soc_dapm_new_widgets in
codec driver probe function afer converting to table based widgets.
This will cause the card dapm widgets are instantiated before the
dapm_routes are registered.
Then, no available dapm widget pathes can be found during instantiation
which finally will cause soc_dapm_mux_update_power to fail(can not find
correct path with kcontrol) in snd_soc_dapm_put_enum_double function.
Here we remove the unneeded snd_soc_dapm_new_widgets in codec probe
and let the soc core to handle the register sequence properly.
Then we can fix above issue.
Cc: Mark Brown <redacted>
Cc: Liam Girdwood <redacted>
Cc: Wolfram Sang <redacted>
Cc: Shawn Guo <redacted>
On imx53-qsb board:
Tested-by: Shawn Guo <redacted>
Is this a board specific setup? Or every single imx28 based board that
wants recording function is going to need this setup?
Yes, this is a board specific setup, just as non-dt does currently.
Different boards may have different setting.
BTW, the patch needs to get rebased on v3.6-rc1, where mach-mxs.c will
have some context update.
I can do it.
This patch series was made based on Mark's sound-2.6 tree.
Do you want this one go through mxs tree and other three go through Mark's tree?
I'm thinking maybe it would be better go through one tree(Mark's or Yours) since
without this one the saif record still can not work.
Maybe go through yours may save some conflicts.
Mark,
What's your suggestion?
Regards
Dong Aisheng
From: Lauri Hintsala <hidden> Date: 2012-07-24 12:46:38
Recording does not work.
On 07/20/2012 12:20 PM, Dong Aisheng wrote:
This patch series mainly fixes the saif record unwork issue.
The root cause consists of:
1) clk_prepare and clk_enable un-balanced
2) missed setting a proper initial clock rate for saif in dt
3) sgtl5000 dapm widget kcontrol does not work
So can not test record on mx28evk.
4) missed setting clkmux mode for saif in dt
With this patch series it can fix sgtl5000 widget kcontrol unwork
and saif record unwork issue.
BTW, just let people konw, i still met a few overruns during record,
that's another issue and will be fixed in separte patches later.
Patch based on sound-2.6/for-3.6.
I see two different issues.
1. Recorded audio file is totally silent. Hexdump shows zeros.
2. Recording/playback after first recording gives following error
"mxs-saif 80042000.saif: error: busy".
Please look at following logs.
Lauri
$ uname -a
Linux mx28evk 3.5.0-00004-g5b5b6fa #9 Tue Jul 24 15:21:25 EEST 2012
armv5tejl GNU/Linux
$ arecord --version
arecord: version 1.0.25 by Jaroslav Kysela [off-list ref]
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
$ arecord -f cd test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
^CAborted by signal Interrupt...
$ hexdump -C test.wav
00000000 52 49 46 46 24 e0 0f 00 57 41 56 45 66 6d 74 20
|RIFF$...WAVEfmt |
00000010 10 00 00 00 01 00 02 00 44 ac 00 00 10 b1 02 00
|........D.......|
00000020 04 00 10 00 64 61 74 61 00 e0 0f 00 00 00 00 00
|....data........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00100020
$ arecord -f cd test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,
Stereo
[ 90.610000] mxs-saif 80042000.saif: error: busy
[ 90.620000] asoc: machine hw_params failed: -16
arecord: set_params:1145: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (46439 46440)
PERIOD_SIZE: 2048
PERIOD_BYTES: 8192
PERIODS: 8
BUFFER_TIME: (371519 371520)
BUFFER_SIZE: 16384
BUFFER_BYTES: 65536
TICK_TIME: 0
$ aplay test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
[ 98.300000] mxs-saif 80042000.saif: error: busy
[ 98.310000] asoc: machine hw_params failed: -16
aplay: set_params:1145: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (46439 46440)
PERIOD_SIZE: 2048
PERIOD_BYTES: 8192
PERIODS: 8
BUFFER_TIME: (371519 371520)
BUFFER_SIZE: 16384
BUFFER_BYTES: 65536
TICK_TIME: 0
$ amixer
Simple mixer control 'Headphone',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 122 [96%] [9.50dB]
Front Right: Playback 122 [96%] [9.50dB]
Simple mixer control 'Headphone Mux',0
Capabilities: enum
Items: 'DAC' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Headphone Playback ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 192
Mono:
Front Left: Playback 173 [90%]
Front Right: Playback 173 [90%]
Simple mixer control 'Mic',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 4
Mono: 2 [50%] [30.00dB]
Simple mixer control 'Capture',0
Capabilities: cvolume penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 15
Front Left: Capture 14 [93%]
Front Right: Capture 14 [93%]
Simple mixer control 'Capture Attenuate Switch (-6dB)',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 2
Mono: 2 [100%]
Simple mixer control 'Capture Mux',0
Capabilities: enum
Items: 'MIC_IN' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Capture ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
From: Mark Brown <hidden> Date: 2012-07-24 19:18:25
On Fri, Jul 20, 2012 at 05:20:25PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <redacted>
Set an initial clock rate for the saif internal logic to work
properly. This is important when working in EXTMASTER mode that
uses the other saif's BITCLK&LRCLK but it still needs a basic
clock which should be fast enough for the internal logic.
From: Mark Brown <hidden> Date: 2012-07-24 19:20:08
On Fri, Jul 20, 2012 at 05:20:26PM +0800, Dong Aisheng wrote:
From: Dong Aisheng <redacted>
There's a driver bug that sgtl5000 dapm widget kcontrols do not work.
e.g. can not select capture mux with amixer tool(no error info prompted).
From: Mark Brown <hidden> Date: 2012-07-24 19:21:25
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and
requiring that you set some controls to route the audio through - are
you sure you've not missed anything there?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120724/104fec44/attachment-0001.sig>
From: Lauri Hintsala <hidden> Date: 2012-07-25 05:26:38
On 07/24/2012 10:21 PM, Mark Brown wrote:
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
quoted
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and
requiring that you set some controls to route the audio through - are
you sure you've not missed anything there?
I tried to set gains and other settings with alsamixer. I didn't see any
options for muting. Here is the output of amixer.
$ amixer
Simple mixer control 'Headphone',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 122 [96%] [9.50dB]
Front Right: Playback 122 [96%] [9.50dB]
Simple mixer control 'Headphone Mux',0
Capabilities: enum
Items: 'DAC' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Headphone Playback ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 192
Mono:
Front Left: Playback 173 [90%]
Front Right: Playback 173 [90%]
Simple mixer control 'Mic',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 4
Mono: 2 [50%] [30.00dB]
Simple mixer control 'Capture',0
Capabilities: cvolume penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 15
Front Left: Capture 14 [93%]
Front Right: Capture 14 [93%]
Simple mixer control 'Capture Attenuate Switch (-6dB)',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 2
Mono: 2 [100%]
Simple mixer control 'Capture Mux',0
Capabilities: enum
Items: 'MIC_IN' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Capture ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
The testing is not currently very reasonable. I have to reboot my
machine after every single recording because of "busy" bug.
Regards,
Lauri
On Wed, Jul 25, 2012 at 01:26:38PM +0800, Lauri Hintsala wrote:
On 07/24/2012 10:21 PM, Mark Brown wrote:
quoted
On Tue, Jul 24, 2012 at 03:46:38PM +0300, Lauri Hintsala wrote:
quoted
1. Recorded audio file is totally silent. Hexdump shows zeros.
This one is commonly due to devices powering up muted by default and
requiring that you set some controls to route the audio through - are
you sure you've not missed anything there?
I tried to set gains and other settings with alsamixer. I didn't see any
options for muting. Here is the output of amixer.
$ amixer
Simple mixer control 'Headphone',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 127
Mono:
Front Left: Playback 122 [96%] [9.50dB]
Front Right: Playback 122 [96%] [9.50dB]
Simple mixer control 'Headphone Mux',0
Capabilities: enum
Items: 'DAC' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Headphone Playback ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
Simple mixer control 'PCM',0
Capabilities: pvolume penum
Playback channels: Front Left - Front Right
Limits: Playback 0 - 192
Mono:
Front Left: Playback 173 [90%]
Front Right: Playback 173 [90%]
Simple mixer control 'Mic',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 4
Mono: 2 [50%] [30.00dB]
Simple mixer control 'Capture',0
Capabilities: cvolume penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 15
Front Left: Capture 14 [93%]
Front Right: Capture 14 [93%]
Simple mixer control 'Capture Attenuate Switch (-6dB)',0
Capabilities: volume volume-joined penum
Playback channels: Mono
Capture channels: Mono
Limits: 0 - 2
Mono: 2 [100%]
Simple mixer control 'Capture Mux',0
Capabilities: enum
Items: 'MIC_IN' 'LINE_IN'
Item0: 'LINE_IN'
Simple mixer control 'Capture ZC',0
Capabilities: pswitch pswitch-joined penum
Playback channels: Mono
Mono: Playback [on]
The testing is not currently very reasonable. I have to reboot my
machine after every single recording because of "busy" bug.
I reproduced your issue.
It seems the root cause is that you used the wrong device to record.
The record device is 1.
root at freescale ~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
Can you try again with below command?
arecord -D hw:0,1 -d 5 -f S16_LE -r 44100 -c 2 1.wav
However, i think it is an issue of the driver that it should report an error
if find user are using a device to do playback or capture without that capability.
I'm wondering soc-core may need provide an interface for user to change the DAI capability
according to the real using, e.g: only playback are used.
I'm not sure if we already have one.
Will do some research on it.
Regards
Dong Aisheng
On Mon, Jul 23, 2012 at 10:36:33AM +0800, Dong Aisheng wrote:
This patch series was made based on Mark's sound-2.6 tree.
Do you want this one go through mxs tree and other three go through Mark's tree?
Yes. That's the way to save conflict.
I'm thinking maybe it would be better go through one tree(Mark's or Yours) since
without this one the saif record still can not work.
The recording has been broken. There is no point to force the whole
series to go via one tree. When sound and arm-soc get merged on
linux-next (for testing) and mainline, the recording gets back to work.
--
Regards,
Shawn
On Sat, Jul 28, 2012 at 04:25:48PM +0800, Shawn Guo wrote:
On Mon, Jul 23, 2012 at 10:36:33AM +0800, Dong Aisheng wrote:
quoted
This patch series was made based on Mark's sound-2.6 tree.
Do you want this one go through mxs tree and other three go through Mark's tree?
Yes. That's the way to save conflict.
quoted
I'm thinking maybe it would be better go through one tree(Mark's or Yours) since
without this one the saif record still can not work.
The recording has been broken. There is no point to force the whole
series to go via one tree. When sound and arm-soc get merged on
linux-next (for testing) and mainline, the recording gets back to work.
Understand.
Will rebase it and resend it for this one.
Regards
Dong Aisheng