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