* recording problem in beagleboard-mcbsp
@ 2015-03-27 20:24 noman pouigt
2015-03-27 21:20 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-03-27 20:24 UTC (permalink / raw)
To: peter.ujfalusi, broonie; +Cc: alsa-devel
Problem: not able to record with any of the devices
in beagleboard-xm.
Analysis: userspace is stuck in snd_pcm_readi function
and kernel space i don't see snd_pcm_update_hw_ptr
function being called.
Checked the I2S clocks and they are perfect and recording
data line is moving based on the data. I am able to do playback
though.
I am using below command to do recording. Do i need to add
additional switches?
Linux kernel: 3.19
root@arm:~# arecord -t wav -c 2 -r 44100 -f S32_LE -v test.wav
Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Linear conversion PCM (S16_LE)
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 27560
period_size : 5512
period_time : 124988
tstamp_mode : NONE
period_step : 1
avail_min : 5512
period_event : 0
start_threshold : 1
stop_threshold : 27560
silence_threshold: 0
silence_size : 0
boundary : 1806172160
Slave: Hardware PCM card 0 'omap3beagle' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 27560
period_size : 5512
period_time : 124988
tstamp_mode : NONE
period_step : 1
avail_min : 5512
period_event : 0
start_threshold : 1
stop_threshold : 27560
silence_threshold: 0
silence_size : 0
boundary : 1806172160
appl_ptr : 0
hw_ptr : 0
[ 74.696319] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
[ 74.696380] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
[ 74.696411] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
[ 74.696441] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
[ 74.696472] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
[ 74.696502] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
[ 74.696533] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
[ 74.696563] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
[ 74.696594] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
[ 74.696594] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
[ 74.696624] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
[ 74.696655] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
[ 74.696685] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
[ 74.696716] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
setup:
beagleoboard-xm
ubuntu distribution
arecord used
jaroslav recording application also tried
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-03-27 20:24 recording problem in beagleboard-mcbsp noman pouigt
@ 2015-03-27 21:20 ` noman pouigt
2015-03-31 18:41 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-03-27 21:20 UTC (permalink / raw)
To: peter.ujfalusi, broonie; +Cc: alsa-devel
On Fri, Mar 27, 2015 at 1:24 PM, noman pouigt <variksla@gmail.com> wrote:
> Problem: not able to record with any of the devices
> in beagleboard-xm.
>
> Analysis: userspace is stuck in snd_pcm_readi function
> and kernel space i don't see snd_pcm_update_hw_ptr
> function being called.
>
> Checked the I2S clocks and they are perfect and recording
> data line is moving based on the data. I am able to do playback
> though.
>
> I am using below command to do recording. Do i need to add
> additional switches?
>
>
> Linux kernel: 3.19
>
> root@arm:~# arecord -t wav -c 2 -r 44100 -f S32_LE -v test.wav
> Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
> Plug PCM: Linear conversion PCM (S16_LE)
> Its setup is:
> stream : CAPTURE
> access : RW_INTERLEAVED
> format : S32_LE
> subformat : STD
> channels : 2
> rate : 44100
> exact rate : 44100 (44100/1)
> msbits : 32
> buffer_size : 27560
> period_size : 5512
> period_time : 124988
> tstamp_mode : NONE
> period_step : 1
> avail_min : 5512
> period_event : 0
> start_threshold : 1
> stop_threshold : 27560
> silence_threshold: 0
> silence_size : 0
> boundary : 1806172160
> Slave: Hardware PCM card 0 'omap3beagle' device 0 subdevice 0
> Its setup is:
> stream : CAPTURE
> access : MMAP_INTERLEAVED
> format : S16_LE
> subformat : STD
> channels : 2
> rate : 44100
> exact rate : 44100 (44100/1)
> msbits : 16
> buffer_size : 27560
> period_size : 5512
> period_time : 124988
> tstamp_mode : NONE
> period_step : 1
> avail_min : 5512
> period_event : 0
> start_threshold : 1
> stop_threshold : 27560
> silence_threshold: 0
> silence_size : 0
> boundary : 1806172160
> appl_ptr : 0
> hw_ptr : 0
>
> [ 74.696319] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
> [ 74.696380] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
> [ 74.696411] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
> [ 74.696441] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
> [ 74.696472] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
> [ 74.696502] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
> [ 74.696533] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
> [ 74.696563] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
> [ 74.696594] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
> [ 74.696594] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
> [ 74.696624] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
> [ 74.696655] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
> [ 74.696685] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
> [ 74.696716] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
>
>
> setup:
> beagleoboard-xm
> ubuntu distribution
> arecord used
> jaroslav recording application also tried
using max98090 codec and not using twl.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-03-27 21:20 ` noman pouigt
@ 2015-03-31 18:41 ` noman pouigt
2015-04-01 18:46 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-03-31 18:41 UTC (permalink / raw)
To: peter.ujfalusi, broonie; +Cc: alsa-devel
On Fri, Mar 27, 2015 at 2:20 PM, noman pouigt <variksla@gmail.com> wrote:
> On Fri, Mar 27, 2015 at 1:24 PM, noman pouigt <variksla@gmail.com> wrote:
>> Problem: not able to record with any of the devices
>> in beagleboard-xm.
>>
>> Analysis: userspace is stuck in snd_pcm_readi function
>> and kernel space i don't see snd_pcm_update_hw_ptr
>> function being called.
>>
>> Checked the I2S clocks and they are perfect and recording
>> data line is moving based on the data. I am able to do playback
>> though.
>>
>> I am using below command to do recording. Do i need to add
>> additional switches?
>>
>>
>> Linux kernel: 3.19
>>
>> root@arm:~# arecord -t wav -c 2 -r 44100 -f S32_LE -v test.wav
>> Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
>> Plug PCM: Linear conversion PCM (S16_LE)
>> Its setup is:
>> stream : CAPTURE
>> access : RW_INTERLEAVED
>> format : S32_LE
>> subformat : STD
>> channels : 2
>> rate : 44100
>> exact rate : 44100 (44100/1)
>> msbits : 32
>> buffer_size : 27560
>> period_size : 5512
>> period_time : 124988
>> tstamp_mode : NONE
>> period_step : 1
>> avail_min : 5512
>> period_event : 0
>> start_threshold : 1
>> stop_threshold : 27560
>> silence_threshold: 0
>> silence_size : 0
>> boundary : 1806172160
>> Slave: Hardware PCM card 0 'omap3beagle' device 0 subdevice 0
>> Its setup is:
>> stream : CAPTURE
>> access : MMAP_INTERLEAVED
>> format : S16_LE
>> subformat : STD
>> channels : 2
>> rate : 44100
>> exact rate : 44100 (44100/1)
>> msbits : 16
>> buffer_size : 27560
>> period_size : 5512
>> period_time : 124988
>> tstamp_mode : NONE
>> period_step : 1
>> avail_min : 5512
>> period_event : 0
>> start_threshold : 1
>> stop_threshold : 27560
>> silence_threshold: 0
>> silence_size : 0
>> boundary : 1806172160
>> appl_ptr : 0
>> hw_ptr : 0
>>
>> [ 74.696319] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
>> [ 74.696380] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
>> [ 74.696411] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
>> [ 74.696441] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
>> [ 74.696472] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
>> [ 74.696502] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
>> [ 74.696533] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
>> [ 74.696563] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
>> [ 74.696594] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
>> [ 74.696594] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
>> [ 74.696624] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
>> [ 74.696655] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
>> [ 74.696685] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
>> [ 74.696716] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
>>
>>
>> setup:
>> beagleoboard-xm
>> ubuntu distribution
>> arecord used
>> jaroslav recording application also tried
> using max98090 codec and not using twl.
I was wondering if i can get some help in this?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-03-31 18:41 ` noman pouigt
@ 2015-04-01 18:46 ` Peter Ujfalusi
2015-04-07 4:29 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-01 18:46 UTC (permalink / raw)
To: noman pouigt, broonie; +Cc: alsa-devel
On 03/31/2015 09:41 PM, noman pouigt wrote:
> I was wondering if i can get some help in this?
I can take a look at this on Monday the earliest...
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-01 18:46 ` Peter Ujfalusi
@ 2015-04-07 4:29 ` noman pouigt
2015-04-07 9:22 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-07 4:29 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Wed, Apr 1, 2015 at 11:46 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 03/31/2015 09:41 PM, noman pouigt wrote:
>> I was wondering if i can get some help in this?
>
> I can take a look at this on Monday the earliest...
Hi Peter,
Did you get a chance to look at it?
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-07 4:29 ` noman pouigt
@ 2015-04-07 9:22 ` Peter Ujfalusi
2015-04-07 18:33 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-07 9:22 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/07/2015 07:29 AM, noman pouigt wrote:
> On Wed, Apr 1, 2015 at 11:46 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 03/31/2015 09:41 PM, noman pouigt wrote:
>>> I was wondering if i can get some help in this?
>>
>> I can take a look at this on Monday the earliest...
> Hi Peter,
>
> Did you get a chance to look at it?
Yes,
Monday was a day off ;)
I have tested and capture works on Beagle-xM:
McBSP2 slave, twl4030 master
McBSP2 master, twl4030 slave
With the following command:
arecord -Dhw:0,0 -t wav -c 2 -r 44100 -f S32_LE -v > /dev/null
arecord -Dhw:0,1 -t wav -c 2 -r 44100 -f S32_LE -v > /dev/null
Note that hw:0,1 is not available upstream, it is my test PCM for CxS setup
(codec slave).
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-07 9:22 ` Peter Ujfalusi
@ 2015-04-07 18:33 ` noman pouigt
2015-04-08 9:52 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-07 18:33 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Tue, Apr 7, 2015 at 2:22 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/07/2015 07:29 AM, noman pouigt wrote:
>> On Wed, Apr 1, 2015 at 11:46 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>> On 03/31/2015 09:41 PM, noman pouigt wrote:
>>>> I was wondering if i can get some help in this?
>>>
>>> I can take a look at this on Monday the earliest...
>> Hi Peter,
>>
>> Did you get a chance to look at it?
>
> Yes,
> Monday was a day off ;)
>
> I have tested and capture works on Beagle-xM:
> McBSP2 slave, twl4030 master
> McBSP2 master, twl4030 slave
>
> With the following command:
> arecord -Dhw:0,0 -t wav -c 2 -r 44100 -f S32_LE -v > /dev/null
In my setup codec(max98090) is master and mcbsp is slave. I used above
command and got below error:
arecord: set_params:1233: Sample format non available
Available formats:
- S16_LE
So i changed the format to S16_LE and got below error:
arecord: pcm_read:2031: read error: Input/output error
I checked the dmesg and found out that interrupt triggered only
once and after some time all widgets gets powered down.
Below is part of the dmesg.
[ 174.186431] snd_pcm_lib_read
[ 174.186462] snd_pcm_lib_read1
[ 174.187042] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
[ 174.187072] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
[ 174.187103] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
[ 174.187133] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
[ 174.187164] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
[ 174.187194] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
[ 174.187225] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
[ 174.187255] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
[ 174.187286] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
[ 174.187316] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
[ 174.187347] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
[ 174.187377] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
[ 174.187408] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
[ 174.187438] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
[ 174.187469] omap-mcbsp 48074000.mcbsp: ***********************
[ 174.187499] snd_pcm_update_hw_ptr0
May i know where am i going wrong?
> arecord -Dhw:0,1 -t wav -c 2 -r 44100 -f S32_LE -v > /dev/null
>
> Note that hw:0,1 is not available upstream, it is my test PCM for CxS setup
> (codec slave).
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-07 18:33 ` noman pouigt
@ 2015-04-08 9:52 ` Peter Ujfalusi
2015-04-08 23:44 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-08 9:52 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/07/2015 09:33 PM, noman pouigt wrote:
> In my setup codec(max98090) is master and mcbsp is slave. I used above
> command and got below error:
> arecord: set_params:1233: Sample format non available
> Available formats:
> - S16_LE
The codec only supports S16_LE or S24_LE.
> So i changed the format to S16_LE and got below error:
> arecord: pcm_read:2031: read error: Input/output error
>
> I checked the dmesg and found out that interrupt triggered only
> once and after some time all widgets gets powered down.
> Below is part of the dmesg.
>
> [ 174.186431] snd_pcm_lib_read
> [ 174.186462] snd_pcm_lib_read1
> [ 174.187042] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
> [ 174.187072] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
> [ 174.187103] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
> [ 174.187133] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
> [ 174.187164] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
> [ 174.187194] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
> [ 174.187225] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
> [ 174.187255] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
> [ 174.187286] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
> [ 174.187316] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
> [ 174.187347] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
> [ 174.187377] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
> [ 174.187408] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
> [ 174.187438] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
> [ 174.187469] omap-mcbsp 48074000.mcbsp: ***********************
> [ 174.187499] snd_pcm_update_hw_ptr0
>
> May i know where am i going wrong?
First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
running and look at the hw_ptr if it has moved at all.
Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
If the DMA has not moved it means that McBSP does not received the FS which
would indicate the frame start, thus it will not sample data in, thus it will
not trigger the DMA to read the data out.
Since the capture is working on McBSP2 in McBSP slave (and master also) the
only thing which can be wrong is the way the max98090 is wired up or some mux
issue again as it was before for you.
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-08 9:52 ` Peter Ujfalusi
@ 2015-04-08 23:44 ` noman pouigt
2015-04-09 12:06 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-08 23:44 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Wed, Apr 8, 2015 at 2:52 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/07/2015 09:33 PM, noman pouigt wrote:
>> In my setup codec(max98090) is master and mcbsp is slave. I used above
>> command and got below error:
>> arecord: set_params:1233: Sample format non available
>> Available formats:
>> - S16_LE
>
> The codec only supports S16_LE or S24_LE.
>
>> So i changed the format to S16_LE and got below error:
>> arecord: pcm_read:2031: read error: Input/output error
>>
>> I checked the dmesg and found out that interrupt triggered only
>> once and after some time all widgets gets powered down.
>> Below is part of the dmesg.
>>
>> [ 174.186431] snd_pcm_lib_read
>> [ 174.186462] snd_pcm_lib_read1
>> [ 174.187042] omap-mcbsp 48074000.mcbsp: **** McBSP255 regs ****
>> [ 174.187072] omap-mcbsp 48074000.mcbsp: DRR2: 0xedd0abce
>> [ 174.187103] omap-mcbsp 48074000.mcbsp: DRR1: 0x0000
>> [ 174.187133] omap-mcbsp 48074000.mcbsp: DXR2: 0x0000
>> [ 174.187164] omap-mcbsp 48074000.mcbsp: DXR1: 0x0000
>> [ 174.187194] omap-mcbsp 48074000.mcbsp: SPCR2: 0x0230
>> [ 174.187225] omap-mcbsp 48074000.mcbsp: SPCR1: 0x0031
>> [ 174.187255] omap-mcbsp 48074000.mcbsp: RCR2: 0x8041
>> [ 174.187286] omap-mcbsp 48074000.mcbsp: RCR1: 0x0040
>> [ 174.187316] omap-mcbsp 48074000.mcbsp: XCR2: 0x8041
>> [ 174.187347] omap-mcbsp 48074000.mcbsp: XCR1: 0x0040
>> [ 174.187377] omap-mcbsp 48074000.mcbsp: SRGR2: 0x001f
>> [ 174.187408] omap-mcbsp 48074000.mcbsp: SRGR1: 0x0f00
>> [ 174.187438] omap-mcbsp 48074000.mcbsp: PCR0: 0x000f
>> [ 174.187469] omap-mcbsp 48074000.mcbsp: ***********************
>> [ 174.187499] snd_pcm_update_hw_ptr0
>>
>> May i know where am i going wrong?
>
> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
> running and look at the hw_ptr if it has moved at all.
It has not moved at all.
>
> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
I did enable the interrupt but all i am getting is below for both
playback and capture
usecase:
omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
Remember playback is working in both the slave and master mode (codec slave
and codec master).
>
> If the DMA has not moved it means that McBSP does not received the FS which
> would indicate the frame start, thus it will not sample data in, thus it will
> not trigger the DMA to read the data out.
Used scope to check FS and Bit clock and found below (running arecord
with 44100):
bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
in master mode this time.
>
> Since the capture is working on McBSP2 in McBSP slave (and master also) the
> only thing which can be wrong is the way the max98090 is wired up or some mux
> issue again as it was before for you.
Below is the mux setting which i did and because of which playback is working:
MCBsp in master mode
configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
+ >;
+ };
};
Even if MCBSP_DR is not connected properly it should record atleast noise.
I also tried Thomas Niederprüm below advice when running McBsp in slave mode
shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
dts. Then your
bitclock would enter through CLKR as well as CLKX.
But this also didn't work.
Found out only below register changes between playback and capture:
In playback
SPCR2: 0x02f5
SPCR1: 0x0030
In capture:
SPCR2: 0x02f0
SPCR1: 0x0031
There are no difference between any other register. I think mcbsp
registers are fine
but can you confirm if there should be any more differences?
Please advice what might be going wrong?
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-08 23:44 ` noman pouigt
@ 2015-04-09 12:06 ` Peter Ujfalusi
2015-04-09 14:07 ` Peter Ujfalusi
2015-04-09 23:02 ` noman pouigt
0 siblings, 2 replies; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-09 12:06 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/09/2015 02:44 AM, noman pouigt wrote:
>> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
>> running and look at the hw_ptr if it has moved at all.
>
> It has not moved at all.
So McBSP does not detect start condition on the FS line.
>> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
>> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
>
> I did enable the interrupt but all i am getting is below for both
> playback and capture
> usecase:
> omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
This is because you dump the registers and it read the DDR register. The FIFO
is empty and you try to read data out.
> Remember playback is working in both the slave and master mode (codec slave
> and codec master).
>>
>> If the DMA has not moved it means that McBSP does not received the FS which
>> would indicate the frame start, thus it will not sample data in, thus it will
>> not trigger the DMA to read the data out.
>
> Used scope to check FS and Bit clock and found below (running arecord
> with 44100):
> bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
> in master mode this time.
>
>>
>> Since the capture is working on McBSP2 in McBSP slave (and master also) the
>> only thing which can be wrong is the way the max98090 is wired up or some mux
>> issue again as it was before for you.
>
> Below is the mux setting which i did and because of which playback is working:
> MCBsp in master mode
> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
> +
> + mcbsp1_pins: pinmux_mcbsp1_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
> + >;
> + };
> };
>
> Even if MCBSP_DR is not connected properly it should record atleast noise.
>
> I also tried Thomas Niederprüm below advice when running McBsp in slave mode
> shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
> dts. Then your
> bitclock would enter through CLKR as well as CLKX.
> But this also didn't work.
>
> Found out only below register changes between playback and capture:
> In playback
> SPCR2: 0x02f5
> SPCR1: 0x0030
> In capture:
> SPCR2: 0x02f0
> SPCR1: 0x0031
>
> There are no difference between any other register. I think mcbsp
> registers are fine
> but can you confirm if there should be any more differences?
> Please advice what might be going wrong?
Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
It might worth a try to do something like:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
has removed.
Or to switch to use McBSP3.
But for some reason now I can not get the recording working via McBSP1 either.
I remember that it worked not that long time ago...
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 12:06 ` Peter Ujfalusi
@ 2015-04-09 14:07 ` Peter Ujfalusi
2015-04-09 23:04 ` noman pouigt
2015-04-09 23:02 ` noman pouigt
1 sibling, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-09 14:07 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/09/2015 03:06 PM, Peter Ujfalusi wrote:
> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
> It might worth a try to do something like:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
> has removed.
> Or to switch to use McBSP3.
>
> But for some reason now I can not get the recording working via McBSP1 either.
> I remember that it worked not that long time ago...
One thing I would also try:
use the codec as master and connect the FS to McBSP1 FSX _and_ FSR. Do the
same for the bclk (connect it to BCLKX _and_ BCLKR of McBSP1)
Configure the pin mux for these pins also.
--
Péter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 12:06 ` Peter Ujfalusi
2015-04-09 14:07 ` Peter Ujfalusi
@ 2015-04-09 23:02 ` noman pouigt
2015-04-10 7:13 ` Peter Ujfalusi
2015-04-13 15:14 ` Peter Ujfalusi
1 sibling, 2 replies; 25+ messages in thread
From: noman pouigt @ 2015-04-09 23:02 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
[-- Attachment #1: Type: text/plain, Size: 4211 bytes --]
On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/09/2015 02:44 AM, noman pouigt wrote:
>>> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
>>> running and look at the hw_ptr if it has moved at all.
>>
>> It has not moved at all.
>
> So McBSP does not detect start condition on the FS line.
>
>>> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
>>> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
>>
>> I did enable the interrupt but all i am getting is below for both
>> playback and capture
>> usecase:
>> omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
>
> This is because you dump the registers and it read the DDR register. The FIFO
> is empty and you try to read data out.
>
>> Remember playback is working in both the slave and master mode (codec slave
>> and codec master).
>>>
>>> If the DMA has not moved it means that McBSP does not received the FS which
>>> would indicate the frame start, thus it will not sample data in, thus it will
>>> not trigger the DMA to read the data out.
>>
>> Used scope to check FS and Bit clock and found below (running arecord
>> with 44100):
>> bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
>> in master mode this time.
>>
>>>
>>> Since the capture is working on McBSP2 in McBSP slave (and master also) the
>>> only thing which can be wrong is the way the max98090 is wired up or some mux
>>> issue again as it was before for you.
>>
>> Below is the mux setting which i did and because of which playback is working:
>> MCBsp in master mode
>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>> +
>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>> + pinctrl-single,pins = <
>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>> + >;
>> + };
>> };
>>
>> Even if MCBSP_DR is not connected properly it should record atleast noise.
>>
>> I also tried Thomas Niederprüm below advice when running McBsp in slave mode
>> shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
>> dts. Then your
>> bitclock would enter through CLKR as well as CLKX.
>> But this also didn't work.
>>
>> Found out only below register changes between playback and capture:
>> In playback
>> SPCR2: 0x02f5
>> SPCR1: 0x0030
>> In capture:
>> SPCR2: 0x02f0
>> SPCR1: 0x0031
>>
>> There are no difference between any other register. I think mcbsp
>> registers are fine
>> but can you confirm if there should be any more differences?
>> Please advice what might be going wrong?
>
> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
> It might worth a try to do something like:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
> has removed.
This patch seems pretty old and I am not able to apply it as i am
using latest kernel.
kernel: 3.19
> Or to switch to use McBSP3.
tried this as well but even playback didn't work.
+ mcbsp3_pins: pinmux_mcbsp3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
+ >;
+ };
attached patch where i replaced the mcbsp1 to mcbsp3 number in machine file.
do you think this configuration is right? I tried both master and slave mode
and both didn't work but i was getting right bit clock and FS clock.
>
> But for some reason now I can not get the recording working via McBSP1 either.
> I remember that it worked not that long time ago...
>
> --
> Péter
[-- Attachment #2: mcbsp3.patch --]
[-- Type: text/x-patch, Size: 5599 bytes --]
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 25f7b0a..215eb86 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -59,8 +59,8 @@
compatible = "ti,omap-twl4030";
ti,model = "omap3beagle";
- ti,mcbsp = <&mcbsp2>;
- ti,codec = <&twl_audio>;
+ ti,mcbsp = <&mcbsp3>;
+ ti,codec = <&max98090>;
};
gpio_keys {
@@ -246,6 +246,15 @@
OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
>;
};
+
+ mcbsp3_pins: pinmux_mcbsp3_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
+ OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
+ >;
+ };
};
&omap3_pmx_core2 {
@@ -292,6 +301,11 @@
&i2c2 {
clock-frequency = <400000>;
+
+ max98090: max98090@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ };
};
&i2c3 {
@@ -339,6 +353,7 @@
pinctrl-0 = <&uart3_pins>;
};
+
&gpio1 {
pinctrl-names = "default";
pinctrl-0 = <&gpio1_pins>;
@@ -363,6 +378,23 @@
status = "okay";
};
+/*&mcbsp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp1_pins>;
+
+ status = "okay";
+};*/
+
+&mcbsp1 {
+ status = "disabled";
+};
+
+&mcbsp3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcbsp3_pins>;
+
+ status = "okay";
+};
&dss {
status = "ok";
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index b112b1c..a4c3748 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -1997,6 +1997,10 @@ static int max98090_dai_hw_params(struct snd_pcm_substream *substream,
snd_soc_update_bits(codec, M98090_REG_INTERFACE_FORMAT,
M98090_WS_MASK, 0);
break;
+ case 24:
+ snd_soc_update_bits(codec, M98090_REG_INTERFACE_FORMAT,
+ M98090_WS_MASK, 2);
+ break;
default:
return -EINVAL;
}
@@ -2089,6 +2093,7 @@ static int max98090_dai_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
{
struct snd_soc_codec *codec = dai->codec;
+ int reg;
struct max98090_priv *max98090 = snd_soc_codec_get_drvdata(codec);
switch (cmd) {
@@ -2589,15 +2594,6 @@ static int max98090_i2c_probe(struct i2c_client *i2c,
goto err_enable;
}
- ret = devm_request_threaded_irq(&i2c->dev, i2c->irq, NULL,
- max98090_interrupt, IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
- "max98090_interrupt", max98090);
- if (ret < 0) {
- dev_err(&i2c->dev, "request_irq failed: %d\n",
- ret);
- return ret;
- }
-
ret = snd_soc_register_codec(&i2c->dev,
&soc_codec_dev_max98090, max98090_dai,
ARRAY_SIZE(max98090_dai));
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index fb1f6bb..3176f1b 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -54,6 +54,12 @@ static int omap_twl4030_hw_params(struct snd_pcm_substream *substream,
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
unsigned int fmt;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int err = 0;
+ int ret = 0;
+#if 0
+int div, clk_id,freq;
switch (params_channels(params)) {
case 2: /* Stereo I2S mode */
@@ -70,7 +76,58 @@ static int omap_twl4030_hw_params(struct snd_pcm_substream *substream,
return -EINVAL;
}
+ snd_soc_runtime_set_dai_fmt(rtd, fmt);
+ snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
+ SND_SOC_CLOCK_IN);
+div = clk_id = freq = 0;
+switch (params_rate(params)) {
+case 44100: /* 44.117 */
+ div = 68;
+ clk_id = OMAP_MCBSP_SYSCLK_CLKS_FCLK;
+ freq = 96000000;
+ break;
+case 48000: /* 48.032 */
+ div = 54;
+ clk_id = OMAP_MCBSP_SYSCLK_CLK;
+ freq = 83000000;
+ break;
+default:
+ printk(KERN_ERR "hw params: unknown rate %d\n",
+ params_rate(params));
+ return -EINVAL;
+}
+
+ret = snd_soc_dai_set_sysclk(cpu_dai, clk_id, freq, SND_SOC_CLOCK_IN);
+if (ret < 0) {
+ printk("what the hell\n");
+ return -EINVAL;
+}
+ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div);
+if (ret < 0) {
+ printk("what the hell going on\n");
+ return -EINVAL;
+}
+ return ret;
+#else
+ switch (params_channels(params)) {
+ case 2: /* Stereo I2S mode */
+ fmt = SND_SOC_DAIFMT_I2S |
+ SND_SOC_DAIFMT_NB_NF |
+ SND_SOC_DAIFMT_CBM_CFM;
+ break;
+ case 4: /* Four channel TDM mode */
+ fmt = SND_SOC_DAIFMT_DSP_A |
+ SND_SOC_DAIFMT_IB_NF |
+ SND_SOC_DAIFMT_CBM_CFM;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
+ SND_SOC_CLOCK_IN);
return snd_soc_runtime_set_dai_fmt(rtd, fmt);
+#endif
}
static struct snd_soc_ops omap_twl4030_ops = {
@@ -228,13 +285,12 @@ static int omap_twl4030_card_remove(struct snd_soc_card *card)
/* Digital audio interface glue - connects codec <--> CPU */
static struct snd_soc_dai_link omap_twl4030_dai_links[] = {
{
- .name = "TWL4030 HiFi",
- .stream_name = "TWL4030 HiFi",
- .cpu_dai_name = "omap-mcbsp.2",
- .codec_dai_name = "twl4030-hifi",
- .platform_name = "omap-mcbsp.2",
- .codec_name = "twl4030-codec",
- .init = omap_twl4030_init,
+ .name = "max98090 HiFi",
+ .stream_name = "max98090 HiFi",
+ .cpu_dai_name = "omap-mcbsp.3",
+ .codec_dai_name = "HiFi",
+ .platform_name = "omap-mcbsp.3",
+ .codec_name = "max98090.1-0010",
.ops = &omap_twl4030_ops,
},
{
[-- Attachment #3: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 14:07 ` Peter Ujfalusi
@ 2015-04-09 23:04 ` noman pouigt
2015-04-10 7:11 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-09 23:04 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Thu, Apr 9, 2015 at 7:07 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/09/2015 03:06 PM, Peter Ujfalusi wrote:
>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>> It might worth a try to do something like:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>> has removed.
>> Or to switch to use McBSP3.
>>
>> But for some reason now I can not get the recording working via McBSP1 either.
>> I remember that it worked not that long time ago...
>
> One thing I would also try:
> use the codec as master and connect the FS to McBSP1 FSX _and_ FSR. Do the
> same for the bclk (connect it to BCLKX _and_ BCLKR of McBSP1)
> Configure the pin mux for these pins also.
I did but it didn't work.Below is my configuration.
configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
+ OMAP3_CORE1_IOPAD(0x218E, PIN_OUTPUT | MUX_MODE0)
+ >;
+ };
};
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 23:04 ` noman pouigt
@ 2015-04-10 7:11 ` Peter Ujfalusi
2015-04-10 17:54 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-10 7:11 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/10/2015 02:04 AM, noman pouigt wrote:
> On Thu, Apr 9, 2015 at 7:07 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 04/09/2015 03:06 PM, Peter Ujfalusi wrote:
>>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>>> It might worth a try to do something like:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>>> has removed.
>>> Or to switch to use McBSP3.
>>>
>>> But for some reason now I can not get the recording working via McBSP1 either.
>>> I remember that it worked not that long time ago...
>>
>> One thing I would also try:
>> use the codec as master and connect the FS to McBSP1 FSX _and_ FSR. Do the
>> same for the bclk (connect it to BCLKX _and_ BCLKR of McBSP1)
>> Configure the pin mux for these pins also.
>
> I did but it didn't work.Below is my configuration.
> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
> +
> + mcbsp1_pins: pinmux_mcbsp1_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
> + OMAP3_CORE1_IOPAD(0x218E, PIN_OUTPUT | MUX_MODE0)
> + >;
> + };
What about the codec master mode? Does that work?
> };
>>
>> --
>> Péter
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 23:02 ` noman pouigt
@ 2015-04-10 7:13 ` Peter Ujfalusi
2015-04-10 17:53 ` noman pouigt
2015-04-13 15:14 ` Peter Ujfalusi
1 sibling, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-10 7:13 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/10/2015 02:02 AM, noman pouigt wrote:
> On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 04/09/2015 02:44 AM, noman pouigt wrote:
>>>> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
>>>> running and look at the hw_ptr if it has moved at all.
>>>
>>> It has not moved at all.
>>
>> So McBSP does not detect start condition on the FS line.
>>
>>>> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
>>>> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
>>>
>>> I did enable the interrupt but all i am getting is below for both
>>> playback and capture
>>> usecase:
>>> omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
>>
>> This is because you dump the registers and it read the DDR register. The FIFO
>> is empty and you try to read data out.
>>
>>> Remember playback is working in both the slave and master mode (codec slave
>>> and codec master).
>>>>
>>>> If the DMA has not moved it means that McBSP does not received the FS which
>>>> would indicate the frame start, thus it will not sample data in, thus it will
>>>> not trigger the DMA to read the data out.
>>>
>>> Used scope to check FS and Bit clock and found below (running arecord
>>> with 44100):
>>> bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
>>> in master mode this time.
>>>
>>>>
>>>> Since the capture is working on McBSP2 in McBSP slave (and master also) the
>>>> only thing which can be wrong is the way the max98090 is wired up or some mux
>>>> issue again as it was before for you.
>>>
>>> Below is the mux setting which i did and because of which playback is working:
>>> MCBsp in master mode
>>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>>> +
>>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>>> + pinctrl-single,pins = <
>>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>>> + >;
>>> + };
>>> };
>>>
>>> Even if MCBSP_DR is not connected properly it should record atleast noise.
>>>
>>> I also tried Thomas Niederprüm below advice when running McBsp in slave mode
>>> shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
>>> dts. Then your
>>> bitclock would enter through CLKR as well as CLKX.
>>> But this also didn't work.
>>>
>>> Found out only below register changes between playback and capture:
>>> In playback
>>> SPCR2: 0x02f5
>>> SPCR1: 0x0030
>>> In capture:
>>> SPCR2: 0x02f0
>>> SPCR1: 0x0031
>>>
>>> There are no difference between any other register. I think mcbsp
>>> registers are fine
>>> but can you confirm if there should be any more differences?
>>> Please advice what might be going wrong?
>>
>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>> It might worth a try to do something like:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>> has removed.
> This patch seems pretty old and I am not able to apply it as i am
> using latest kernel.
> kernel: 3.19
It removed functionality, you might want ton hack something similar back for
testing
>
>> Or to switch to use McBSP3.
>
> tried this as well but even playback didn't work.
> + mcbsp3_pins: pinmux_mcbsp3_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
> + >;
> + };
>
> attached patch where i replaced the mcbsp1 to mcbsp3 number in machine file.
> do you think this configuration is right? I tried both master and slave mode
> and both didn't work but i was getting right bit clock and FS clock.
By default codec is master, so try to set the mux accordingly.
>
>>
>> But for some reason now I can not get the recording working via McBSP1 either.
>> I remember that it worked not that long time ago...
>>
>> --
>> Péter
--
Péter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-10 7:13 ` Peter Ujfalusi
@ 2015-04-10 17:53 ` noman pouigt
2015-04-10 22:58 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-10 17:53 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Fri, Apr 10, 2015 at 12:13 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/10/2015 02:02 AM, noman pouigt wrote:
>> On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>> On 04/09/2015 02:44 AM, noman pouigt wrote:
>>>>> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
>>>>> running and look at the hw_ptr if it has moved at all.
>>>>
>>>> It has not moved at all.
>>>
>>> So McBSP does not detect start condition on the FS line.
>>>
>>>>> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
>>>>> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
>>>>
>>>> I did enable the interrupt but all i am getting is below for both
>>>> playback and capture
>>>> usecase:
>>>> omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
>>>
>>> This is because you dump the registers and it read the DDR register. The FIFO
>>> is empty and you try to read data out.
>>>
>>>> Remember playback is working in both the slave and master mode (codec slave
>>>> and codec master).
>>>>>
>>>>> If the DMA has not moved it means that McBSP does not received the FS which
>>>>> would indicate the frame start, thus it will not sample data in, thus it will
>>>>> not trigger the DMA to read the data out.
>>>>
>>>> Used scope to check FS and Bit clock and found below (running arecord
>>>> with 44100):
>>>> bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
>>>> in master mode this time.
>>>>
>>>>>
>>>>> Since the capture is working on McBSP2 in McBSP slave (and master also) the
>>>>> only thing which can be wrong is the way the max98090 is wired up or some mux
>>>>> issue again as it was before for you.
>>>>
>>>> Below is the mux setting which i did and because of which playback is working:
>>>> MCBsp in master mode
>>>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>>>> +
>>>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>>>> + pinctrl-single,pins = <
>>>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>>>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>>>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>>>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>>>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>>>> + >;
>>>> + };
>>>> };
>>>>
>>>> Even if MCBSP_DR is not connected properly it should record atleast noise.
>>>>
>>>> I also tried Thomas Niederprüm below advice when running McBsp in slave mode
>>>> shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
>>>> dts. Then your
>>>> bitclock would enter through CLKR as well as CLKX.
>>>> But this also didn't work.
>>>>
>>>> Found out only below register changes between playback and capture:
>>>> In playback
>>>> SPCR2: 0x02f5
>>>> SPCR1: 0x0030
>>>> In capture:
>>>> SPCR2: 0x02f0
>>>> SPCR1: 0x0031
>>>>
>>>> There are no difference between any other register. I think mcbsp
>>>> registers are fine
>>>> but can you confirm if there should be any more differences?
>>>> Please advice what might be going wrong?
>>>
>>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>>> It might worth a try to do something like:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>>> has removed.
>> This patch seems pretty old and I am not able to apply it as i am
>> using latest kernel.
>> kernel: 3.19
>
> It removed functionality, you might want ton hack something similar back for
> testing
I will give it a try but wouldn't it be nice if i can directly write
to mux registers
to get back the functionality.
>
>>
>>> Or to switch to use McBSP3.
>>
>> tried this as well but even playback didn't work.
>> + mcbsp3_pins: pinmux_mcbsp3_pins {
>> + pinctrl-single,pins = <
>> + OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
>> + >;
>> + };
>>
>> attached patch where i replaced the mcbsp1 to mcbsp3 number in machine file.
>> do you think this configuration is right? I tried both master and slave mode
>> and both didn't work but i was getting right bit clock and FS clock.
>
> By default codec is master, so try to set the mux accordingly.
I did change the machine driver accordingly as below and sent you the patch
which i used.
anyway below is the change which i did:
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ int err = 0;
+ int ret = 0;
+int div, clk_id,freq;
switch (params_channels(params)) {
case 2: /* Stereo I2S mode */
fmt = SND_SOC_DAIFMT_I2S |
SND_SOC_DAIFMT_NB_NF |
- SND_SOC_DAIFMT_CBM_CFM;
+ SND_SOC_DAIFMT_CBS_CFS;
break;
case 4: /* Four channel TDM mode */
fmt = SND_SOC_DAIFMT_DSP_A |
SND_SOC_DAIFMT_IB_NF |
- SND_SOC_DAIFMT_CBM_CFM;
+ SND_SOC_DAIFMT_CBS_CFS;
break;
default:
return -EINVAL;
}
- return snd_soc_runtime_set_dai_fmt(rtd, fmt);
+ snd_soc_runtime_set_dai_fmt(rtd, fmt);
+ snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
+ SND_SOC_CLOCK_IN);
+div = clk_id = freq = 0;
+switch (params_rate(params)) {
+case 44100: /* 44.117 */
+ div = 68;
+ clk_id = OMAP_MCBSP_SYSCLK_CLKS_FCLK;
+ freq = 96000000;
+ break;
+case 48000: /* 48.032 */
+ div = 54;
+ clk_id = OMAP_MCBSP_SYSCLK_CLK;
+ freq = 83000000;
+ break;
+default:
+ printk(KERN_ERR "hw params: unknown rate %d\n",
+ params_rate(params));
+ return -EINVAL;
+}
ret = snd_soc_dai_set_sysclk(cpu_dai, clk_id, freq, SND_SOC_CLOCK_IN);
if (ret < 0) {
printk("what the hell\n");
return -EINVAL;
}
ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div);
if (ret < 0) {
printk("what the hell going on\n");
return -EINVAL;
}
return ret;
>
>>
>>>
>>> But for some reason now I can not get the recording working via McBSP1 either.
>>> I remember that it worked not that long time ago...
>>>
>>> --
>>> Péter
>
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-10 7:11 ` Peter Ujfalusi
@ 2015-04-10 17:54 ` noman pouigt
2015-04-10 21:42 ` noman pouigt
0 siblings, 1 reply; 25+ messages in thread
From: noman pouigt @ 2015-04-10 17:54 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Fri, Apr 10, 2015 at 12:11 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/10/2015 02:04 AM, noman pouigt wrote:
>> On Thu, Apr 9, 2015 at 7:07 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>> On 04/09/2015 03:06 PM, Peter Ujfalusi wrote:
>>>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>>>> It might worth a try to do something like:
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>>>> has removed.
>>>> Or to switch to use McBSP3.
>>>>
>>>> But for some reason now I can not get the recording working via McBSP1 either.
>>>> I remember that it worked not that long time ago...
>>>
>>> One thing I would also try:
>>> use the codec as master and connect the FS to McBSP1 FSX _and_ FSR. Do the
>>> same for the bclk (connect it to BCLKX _and_ BCLKR of McBSP1)
>>> Configure the pin mux for these pins also.
>>
>> I did but it didn't work.Below is my configuration.
>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>> +
>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>> + pinctrl-single,pins = <
>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>> + OMAP3_CORE1_IOPAD(0x218E, PIN_OUTPUT | MUX_MODE0)
>> + >;
>> + };
>
> What about the codec master mode? Does that work?
I will also try this and update.
>
>> };
>>>
>>> --
>>> Péter
>
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-10 17:54 ` noman pouigt
@ 2015-04-10 21:42 ` noman pouigt
0 siblings, 0 replies; 25+ messages in thread
From: noman pouigt @ 2015-04-10 21:42 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Fri, Apr 10, 2015 at 10:54 AM, noman pouigt <variksla@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 12:11 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 04/10/2015 02:04 AM, noman pouigt wrote:
>>> On Thu, Apr 9, 2015 at 7:07 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>>> On 04/09/2015 03:06 PM, Peter Ujfalusi wrote:
>>>>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>>>>> It might worth a try to do something like:
>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>>>>> has removed.
>>>>> Or to switch to use McBSP3.
>>>>>
>>>>> But for some reason now I can not get the recording working via McBSP1 either.
>>>>> I remember that it worked not that long time ago...
>>>>
>>>> One thing I would also try:
>>>> use the codec as master and connect the FS to McBSP1 FSX _and_ FSR. Do the
>>>> same for the bclk (connect it to BCLKX _and_ BCLKR of McBSP1)
>>>> Configure the pin mux for these pins also.
>>>
>>> I did but it didn't work.Below is my configuration.
>>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>>> +
>>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>>> + pinctrl-single,pins = <
>>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>>> + OMAP3_CORE1_IOPAD(0x218E, PIN_OUTPUT | MUX_MODE0)
>>> + >;
>>> + };
>>
>> What about the codec master mode? Does that work?
> I will also try this and update.
Tried this as well and it didn't work. Strange that FSR and CLKR is also
having the required clocks.
>>
>>> };
>>>>
>>>> --
>>>> Péter
>>
>>
>> --
>> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-10 17:53 ` noman pouigt
@ 2015-04-10 22:58 ` noman pouigt
0 siblings, 0 replies; 25+ messages in thread
From: noman pouigt @ 2015-04-10 22:58 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Fri, Apr 10, 2015 at 10:53 AM, noman pouigt <variksla@gmail.com> wrote:
> On Fri, Apr 10, 2015 at 12:13 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>> On 04/10/2015 02:02 AM, noman pouigt wrote:
>>> On Thu, Apr 9, 2015 at 5:06 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>>>> On 04/09/2015 02:44 AM, noman pouigt wrote:
>>>>>> First check the /proc/asound/card0/pcm0c/sub0/status while the capture is
>>>>>> running and look at the hw_ptr if it has moved at all.
>>>>>
>>>>> It has not moved at all.
>>>>
>>>> So McBSP does not detect start condition on the FS line.
>>>>
>>>>>> Enable more interrupts in sound/soc/omap/mcbsp.c:omap_mcbsp_config(), like
>>>>>> RUNDFLEN, ROVFLEN and see if you have overflow in McBSP.
>>>>>
>>>>> I did enable the interrupt but all i am getting is below for both
>>>>> playback and capture
>>>>> usecase:
>>>>> omap-mcbsp 48074000.mcbsp: RX Buffer Underflow!
>>>>
>>>> This is because you dump the registers and it read the DDR register. The FIFO
>>>> is empty and you try to read data out.
>>>>
>>>>> Remember playback is working in both the slave and master mode (codec slave
>>>>> and codec master).
>>>>>>
>>>>>> If the DMA has not moved it means that McBSP does not received the FS which
>>>>>> would indicate the frame start, thus it will not sample data in, thus it will
>>>>>> not trigger the DMA to read the data out.
>>>>>
>>>>> Used scope to check FS and Bit clock and found below (running arecord
>>>>> with 44100):
>>>>> bit clock is running at 1.420 MHz and FS at 44100 kHz. Configured MCBsp
>>>>> in master mode this time.
>>>>>
>>>>>>
>>>>>> Since the capture is working on McBSP2 in McBSP slave (and master also) the
>>>>>> only thing which can be wrong is the way the max98090 is wired up or some mux
>>>>>> issue again as it was before for you.
>>>>>
>>>>> Below is the mux setting which i did and because of which playback is working:
>>>>> MCBsp in master mode
>>>>> configured mcbsp1_clkx, mcbsp1_fsx, mcbsp1_dx and mcbsp1_dr
>>>>> +
>>>>> + mcbsp1_pins: pinmux_mcbsp1_pins {
>>>>> + pinctrl-single,pins = <
>>>>> + OMAP3_CORE1_IOPAD(0x2196, PIN_OUTPUT | MUX_MODE0)
>>>>> + OMAP3_CORE1_IOPAD(0x2198, PIN_OUTPUT | MUX_MODE0)
>>>>> + OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0)
>>>>> + OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0)
>>>>> + OMAP3_CORE1_IOPAD(0x218C, PIN_OUTPUT | MUX_MODE0)
>>>>> + >;
>>>>> + };
>>>>> };
>>>>>
>>>>> Even if MCBSP_DR is not connected properly it should record atleast noise.
>>>>>
>>>>> I also tried Thomas Niederprüm below advice when running McBsp in slave mode
>>>>> shorten the CLKR and CLKX pins and mux the CLKR pin as INPUT in your
>>>>> dts. Then your
>>>>> bitclock would enter through CLKR as well as CLKX.
>>>>> But this also didn't work.
>>>>>
>>>>> Found out only below register changes between playback and capture:
>>>>> In playback
>>>>> SPCR2: 0x02f5
>>>>> SPCR1: 0x0030
>>>>> In capture:
>>>>> SPCR2: 0x02f0
>>>>> SPCR1: 0x0031
>>>>>
>>>>> There are no difference between any other register. I think mcbsp
>>>>> registers are fine
>>>>> but can you confirm if there should be any more differences?
>>>>> Please advice what might be going wrong?
>>>>
>>>> Hrm, McBSP1 is kind of problematic port since it has 6pin config by default.
>>>> It might worth a try to do something like:
>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/113058.html
>>>> has removed.
>>> This patch seems pretty old and I am not able to apply it as i am
>>> using latest kernel.
>>> kernel: 3.19
>>
>> It removed functionality, you might want ton hack something similar back for
>> testing
>
> I will give it a try but wouldn't it be nice if i can directly write
> to mux registers
> to get back the functionality.
Anyway i tried adding this hack below
void __init omap3_ctrl_init(void)
{
+ int devconf0;
omap_ctrl_writel(OMAP3430_AUTOIDLE_MASK, OMAP2_CONTROL_SYSCONFIG);
omap3_ctrl_set_iva_bootmode_idle();
omap3_ctrl_setup_d2d_padconf();
+devconf0 = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+devconf0 |= OMAP2_MCBSP1_CLKR_MASK | OMAP2_MCBSP1_FSR_MASK;
+omap_ctrl_writel(devconf0, OMAP2_CONTROL_DEVCONF0);
}
and run in codec slave and mcbsp1 master mode. It didn't work. Playback
as you know is already working without this change.
>>
>>>
>>>> Or to switch to use McBSP3.
>>>
>>> tried this as well but even playback didn't work.
>>> + mcbsp3_pins: pinmux_mcbsp3_pins {
>>> + pinctrl-single,pins = <
>>> + OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
>>> + OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
>>> + OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
>>> + OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
>>> + >;
>>> + };
>>>
>>> attached patch where i replaced the mcbsp1 to mcbsp3 number in machine file.
>>> do you think this configuration is right? I tried both master and slave mode
>>> and both didn't work but i was getting right bit clock and FS clock.
>>
>> By default codec is master, so try to set the mux accordingly.
> I did change the machine driver accordingly as below and sent you the patch
> which i used.
> anyway below is the change which i did:
> + struct snd_soc_dai *codec_dai = rtd->codec_dai;
> + struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> + int err = 0;
> + int ret = 0;
> +int div, clk_id,freq;
>
> switch (params_channels(params)) {
> case 2: /* Stereo I2S mode */
> fmt = SND_SOC_DAIFMT_I2S |
> SND_SOC_DAIFMT_NB_NF |
> - SND_SOC_DAIFMT_CBM_CFM;
> + SND_SOC_DAIFMT_CBS_CFS;
> break;
> case 4: /* Four channel TDM mode */
> fmt = SND_SOC_DAIFMT_DSP_A |
> SND_SOC_DAIFMT_IB_NF |
> - SND_SOC_DAIFMT_CBM_CFM;
> + SND_SOC_DAIFMT_CBS_CFS;
> break;
> default:
> return -EINVAL;
> }
>
> - return snd_soc_runtime_set_dai_fmt(rtd, fmt);
> + snd_soc_runtime_set_dai_fmt(rtd, fmt);
> + snd_soc_dai_set_sysclk(codec_dai, 0, 13000000,
> + SND_SOC_CLOCK_IN);
> +div = clk_id = freq = 0;
> +switch (params_rate(params)) {
> +case 44100: /* 44.117 */
> + div = 68;
> + clk_id = OMAP_MCBSP_SYSCLK_CLKS_FCLK;
> + freq = 96000000;
> + break;
> +case 48000: /* 48.032 */
> + div = 54;
> + clk_id = OMAP_MCBSP_SYSCLK_CLK;
> + freq = 83000000;
> + break;
> +default:
> + printk(KERN_ERR "hw params: unknown rate %d\n",
> + params_rate(params));
> + return -EINVAL;
> +}
> ret = snd_soc_dai_set_sysclk(cpu_dai, clk_id, freq, SND_SOC_CLOCK_IN);
> if (ret < 0) {
> printk("what the hell\n");
> return -EINVAL;
> }
> ret = snd_soc_dai_set_clkdiv(cpu_dai, OMAP_MCBSP_CLKGDV, div);
> if (ret < 0) {
> printk("what the hell going on\n");
> return -EINVAL;
> }
> return ret;
>
>>
>>>
>>>>
>>>> But for some reason now I can not get the recording working via McBSP1 either.
>>>> I remember that it worked not that long time ago...
>>>>
>>>> --
>>>> Péter
>>
>>
>> --
>> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-09 23:02 ` noman pouigt
2015-04-10 7:13 ` Peter Ujfalusi
@ 2015-04-13 15:14 ` Peter Ujfalusi
2015-04-14 9:39 ` Peter Ujfalusi
1 sibling, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-13 15:14 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/10/2015 02:02 AM, noman pouigt wrote:
>> Or to switch to use McBSP3.
>
> tried this as well but even playback didn't work.
> + mcbsp3_pins: pinmux_mcbsp3_pins {
> + pinctrl-single,pins = <
> + OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
> + OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
> + >;
> + };
Should be:
mcbsp3_pins: pinmux_mcbsp3_pins {
pinctrl-single,pins = <
OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* FSX */
OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* CLKX */
OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* DX */
OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* DR */
>;
};
Based on the schematics.
But for some reason I did not got capture working with this for the first try.
Then my MicroSD card decided that it is now in Write Protected mode and can
not recover it, no matter how I try (MicroSD does not have physical switch).
Have you tried to attach the codec to McBSP2? There is a P18 on the backside
of the xM (near to the MicroSD slot, 4 pin square c onnector) with
FSX/CLKX/DR/DX of McBSP2. You will need smaller pins to connect the line to
this header
The strange thing is that McBSP2 and 3 are mostly identical (they only have
different FIFO size) and McBSP3 is used in N9 to connect with twl5030 codec
while the McBSP2 is used with tlv320dac33. I know they work(ed) since I wrote
the audio support for the phone back in the days.
I need to find a spare MicrSD card now to boot the board, which I do not have ATM.
In any ways right now I have no idea why McBSP1 is not working as it should,
it is odd never the less.
--
Péter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-13 15:14 ` Peter Ujfalusi
@ 2015-04-14 9:39 ` Peter Ujfalusi
2015-04-14 12:39 ` Peter Ujfalusi
0 siblings, 1 reply; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-14 9:39 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/13/2015 06:14 PM, Peter Ujfalusi wrote:
> On 04/10/2015 02:02 AM, noman pouigt wrote:
>>> Or to switch to use McBSP3.
>>
>> tried this as well but even playback didn't work.
>> + mcbsp3_pins: pinmux_mcbsp3_pins {
>> + pinctrl-single,pins = <
>> + OMAP3_CORE1_IOPAD(0x216C, PIN_OUTPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x216E, PIN_INPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x2170, PIN_OUTPUT | MUX_MODE1)
>> + OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0)
>> + >;
>> + };
>
> Should be:
> mcbsp3_pins: pinmux_mcbsp3_pins {
> pinctrl-single,pins = <
> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* FSX */
> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* CLKX */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* DX */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* DR */
> >;
> };
>
> Based on the schematics.
>
> But for some reason I did not got capture working with this for the first try.
> Then my MicroSD card decided that it is now in Write Protected mode and can
> not recover it, no matter how I try (MicroSD does not have physical switch).
>
> Have you tried to attach the codec to McBSP2? There is a P18 on the backside
> of the xM (near to the MicroSD slot, 4 pin square c onnector) with
> FSX/CLKX/DR/DX of McBSP2. You will need smaller pins to connect the line to
> this header
>
> The strange thing is that McBSP2 and 3 are mostly identical (they only have
> different FIFO size) and McBSP3 is used in N9 to connect with twl5030 codec
> while the McBSP2 is used with tlv320dac33. I know they work(ed) since I wrote
> the audio support for the phone back in the days.
>
> I need to find a spare MicrSD card now to boot the board, which I do not have ATM.
>
> In any ways right now I have no idea why McBSP1 is not working as it should,
> it is odd never the less.
OK, got another SD card.
McBSP3 in master mode works (no codec connected) playback and capture as well.
The pins for McBSP3:
OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
I still not sure why McBSP1 is not working..
--
Péter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-14 9:39 ` Peter Ujfalusi
@ 2015-04-14 12:39 ` Peter Ujfalusi
2015-04-14 16:41 ` Variksla
2015-04-14 22:32 ` noman pouigt
0 siblings, 2 replies; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-14 12:39 UTC (permalink / raw)
To: noman pouigt; +Cc: alsa-devel, broonie
On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
> OK, got another SD card.
> McBSP3 in master mode works (no codec connected) playback and capture as well.
>
> The pins for McBSP3:
> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
>
> I still not sure why McBSP1 is not working..
This pinctrl setting is not correct for McBSP3. I was changing the registers
on the fly, that's why it was working when I replied.
In McBSP3 master mode, you need:
OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
Which would work in McBSP3 slave mode as well.
Playback, capture works (McBSP3 master). I have connected DX to DR and
captured whatever I was playing. Came back fine.
As for McBSP1 I think this should get it working:
OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0) /* mcbsp1_dr.mcbsp1_dr */
If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
for CLK.
--
Péter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-14 12:39 ` Peter Ujfalusi
@ 2015-04-14 16:41 ` Variksla
2015-04-15 6:03 ` Peter Ujfalusi
2015-04-14 22:32 ` noman pouigt
1 sibling, 1 reply; 25+ messages in thread
From: Variksla @ 2015-04-14 16:41 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
> On Apr 14, 2015, at 5:39 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
>
>> On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
>> OK, got another SD card.
>> McBSP3 in master mode works (no codec connected) playback and capture as well.
>>
>> The pins for McBSP3:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
>>
>> I still not sure why McBSP1 is not working..
>
> This pinctrl setting is not correct for McBSP3. I was changing the registers
> on the fly, that's why it was working when I replied.
>
> In McBSP3 master mode, you need:
> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
Weird. If mcbsp3 is master I am wondering why we are configuring fsx and clkx as input.
>
> Which would work in McBSP3 slave mode as well.
> Playback, capture works (McBSP3 master). I have connected DX to DR and
> captured whatever I was playing. Came back fine.
>
> As for McBSP1 I think this should get it working:
> OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
> OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
> OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
> OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
> OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
> OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0) /* mcbsp1_dr.mcbsp1_dr */
>
> If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
> for CLK.
>
> --
> Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-14 12:39 ` Peter Ujfalusi
2015-04-14 16:41 ` Variksla
@ 2015-04-14 22:32 ` noman pouigt
1 sibling, 0 replies; 25+ messages in thread
From: noman pouigt @ 2015-04-14 22:32 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, broonie
On Tue, Apr 14, 2015 at 5:39 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> On 04/14/2015 12:39 PM, Peter Ujfalusi wrote:
>> OK, got another SD card.
>> McBSP3 in master mode works (no codec connected) playback and capture as well.
>>
>> The pins for McBSP3:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_OUTPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_OUTPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
>>
>> I still not sure why McBSP1 is not working..
>
> This pinctrl setting is not correct for McBSP3. I was changing the registers
> on the fly, that's why it was working when I replied.
Ok great. FINALLY it is working after lots of try and incase it might anyone
who is trying to use below combination is working:
Linux kernel :
VERSION = 3
PATCHLEVEL = 19
SUBLEVEL = 0
EXTRAVERSION =
NAME = Diseased Newt
MCBSB3 in slave mode, max98090 in master mode and mux setting
as below:
> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
both recording and playback is working.
MCBSP3 is working also in the case where it is master mode and
codec is in slave mode.
I referenced AM/DM37X Multimedia Device Silicon Revision 1.x version
R(public version)
for the mux settings. In this i see MCBSP3_DX as 216c. I think this is not the
right revision.
>
> Which would work in McBSP3 slave mode as well.
> Playback, capture works (McBSP3 master). I have connected DX to DR and
> captured whatever I was playing. Came back fine.
>
> As for McBSP1 I think this should get it working:
> OMAP3_CORE1_IOPAD(0x2196, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsx.mcbsp1_fsx */
> OMAP3_CORE1_IOPAD(0x218e, PIN_INPUT | MUX_MODE0) /* mcbsp1_fsr.mcbsp1_fsr */
> OMAP3_CORE1_IOPAD(0x2198, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkx.mcbsp1_clkx */
> OMAP3_CORE1_IOPAD(0x218c, PIN_INPUT | MUX_MODE0) /* mcbsp1_clkr.mcbsp1_clkr */
> OMAP3_CORE1_IOPAD(0x2190, PIN_OUTPUT | MUX_MODE0) /* mcbsp1_dx.mcbsp1_dx */
> OMAP3_CORE1_IOPAD(0x2192, PIN_INPUT | MUX_MODE0) /* mcbsp1_dr.mcbsp1_dr */
>
> If McBSP1 is slave, then connect the FS to both FSX and FSR and do the same
> for CLK.
I didn't test this however as i just wanted any mcbsp connection to work but
i think this should work as well.
>
> --
> Péter
Thanks a ton for helping out!!!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: recording problem in beagleboard-mcbsp
2015-04-14 16:41 ` Variksla
@ 2015-04-15 6:03 ` Peter Ujfalusi
0 siblings, 0 replies; 25+ messages in thread
From: Peter Ujfalusi @ 2015-04-15 6:03 UTC (permalink / raw)
To: Variksla; +Cc: alsa-devel, broonie
On 04/14/2015 07:41 PM, Variksla wrote:
>> In McBSP3 master mode, you need:
>> OMAP3_CORE1_IOPAD(0x2172, PIN_INPUT | MUX_MODE0) /* mcbsp3_fsx.mcbsp3_fsx */
>> OMAP3_CORE1_IOPAD(0x2178, PIN_INPUT | MUX_MODE1) /* uart2_tx.mcbsp3_clkx */
>> OMAP3_CORE1_IOPAD(0x2174, PIN_OUTPUT | MUX_MODE1) /* uart2_cts.mcbsp3_dx */
>> OMAP3_CORE1_IOPAD(0x2176, PIN_INPUT | MUX_MODE1) /* uart2_rts.mcbsp3_dr */
>
> Weird. If mcbsp3 is master I am wondering why we are configuring fsx and clkx as input.
When we configure the pads, we set the input enable bit which will set the pin
to bidirectional mode.
The 4pin McBSP ports will get their FSR/CLKR from the actual pin. If the pin
is set to output only, no signal will come back to McBSP -> capture will not
work. This is why we need to set input enable, so that the signal going out
will be able to get back to McBSP's FSR/CLKR internal line.
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2015-04-15 6:03 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-27 20:24 recording problem in beagleboard-mcbsp noman pouigt
2015-03-27 21:20 ` noman pouigt
2015-03-31 18:41 ` noman pouigt
2015-04-01 18:46 ` Peter Ujfalusi
2015-04-07 4:29 ` noman pouigt
2015-04-07 9:22 ` Peter Ujfalusi
2015-04-07 18:33 ` noman pouigt
2015-04-08 9:52 ` Peter Ujfalusi
2015-04-08 23:44 ` noman pouigt
2015-04-09 12:06 ` Peter Ujfalusi
2015-04-09 14:07 ` Peter Ujfalusi
2015-04-09 23:04 ` noman pouigt
2015-04-10 7:11 ` Peter Ujfalusi
2015-04-10 17:54 ` noman pouigt
2015-04-10 21:42 ` noman pouigt
2015-04-09 23:02 ` noman pouigt
2015-04-10 7:13 ` Peter Ujfalusi
2015-04-10 17:53 ` noman pouigt
2015-04-10 22:58 ` noman pouigt
2015-04-13 15:14 ` Peter Ujfalusi
2015-04-14 9:39 ` Peter Ujfalusi
2015-04-14 12:39 ` Peter Ujfalusi
2015-04-14 16:41 ` Variksla
2015-04-15 6:03 ` Peter Ujfalusi
2015-04-14 22:32 ` noman pouigt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.