[alsa-devel] recording problem in beagleboard-mcbsp
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
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.
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?
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
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).
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
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.
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
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.htm... 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...
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.htm... 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.
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.htm... 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
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.htm... 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
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.htm... 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
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.htm... 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
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.htm... 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
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.htm... 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
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.htm... 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
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.htm... 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
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.
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..
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.
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
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.
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!!!
participants (3)
-
noman pouigt -
Peter Ujfalusi -
Variksla