* 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 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-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-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 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 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 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
* 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
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.