[alsa-devel] how to use mcbsp for i2s?
I'm currently working in adding an external codec to the beagleboard, so far the i2c control part is functional, now i want to use mcbsp3 to provide i2s transfers
Is there any way to test the mcbsp to validate the connection?
Also, I've done little modifications to the omap3beagle.c to change from mcbsp2 to mcbsp3, can someone validate this is correct?
In: static int __init omap3beagle_soc_init(void)
I changed to: *(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 2; /* McBSP3 */
It was: *(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 1; /* McBSP2 */
Is this correct? Or it should be changed in other places too?
Thanks
On Wed, Apr 01, 2009 at 12:29:02PM -0600, Ernesto Torres wrote:
I'm currently working in adding an external codec to the beagleboard, so far the i2c control part is functional, now i want to use mcbsp3 to provide i2s transfers
Is there any way to test the mcbsp to validate the connection?
The easiest thing is often to use a scope to check that clocks and data are present on the relevant lines.
On Wed, Apr 1, 2009 at 9:29 PM, Ernesto Torres skullmate@gmail.com wrote:
I'm currently working in adding an external codec to the beagleboard, so far the i2c control part is functional, now i want to use mcbsp3 to provide i2s transfers
Is there any way to test the mcbsp to validate the connection?
Also, I've done little modifications to the omap3beagle.c to change from mcbsp2 to mcbsp3, can someone validate this is correct?
In: static int __init omap3beagle_soc_init(void)
I changed to: *(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 2; /* McBSP3 */
It was: *(unsigned int *)omap3beagle_dai.cpu_dai->private_data = 1; /* McBSP2 */
Is this correct? Or it should be changed in other places too?
It is basically enough as well as setting correct DAI and clocking
configuration (if needed) in omap3beagle_hw_params.
But by default McBSP1 and 3 which available in Beale pin header are muxed to GPIO so you need to mux those pins for McBSP by the bootloader and with linux-omap kernel multiplexing support.
I may have a hack patch somewhere... I'll try to find it and post it here for reference.
Jarkko
On Thu, Apr 2, 2009 at 10:48 AM, Jarkko Nikula jhnikula@gmail.com wrote:
But by default McBSP1 and 3 which available in Beale pin header are muxed to GPIO so you need to mux those pins for McBSP by the bootloader and with linux-omap kernel multiplexing support.
I may have a hack patch somewhere... I'll try to find it and post it here for reference.
Grrr... cannot find the hack, I'm too keen to delete temporary hacks. I was
pretty sure I had it somewhere.
Basically it was adding necessary pin multiplexing configuration into arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c and then using omap_cfg_reg(...) in omap3beagle.c to change pin configuration from GPIOs to McBPS[1 | 3] pins.
Jarkko
On Thu, 2 Apr 2009 13:20:36 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
Grrr... cannot find the hack, I'm too keen to delete temporary hacks. I was
pretty sure I had it somewhere.
Basically it was adding necessary pin multiplexing configuration into arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c and then using omap_cfg_reg(...) in omap3beagle.c to change pin configuration from GPIOs to McBPS[1 | 3] pins.
Yes, I found it. Hack attached :-)
Now I don't have here Beagle to test but hack still applies on top of linux-omap. Then you will need CONFIG_OMAP_MUX=y and following lines into omap3beagle.c or board-omap3beagle.c.
omap_cfg_reg(AF6_3430_MCBSP3_DX); omap_cfg_reg(AE6_3430_MCBSP3_DR); omap_cfg_reg(AF5_3430_MCBSP3_CLKX); omap_cfg_reg(AE5_3430_MCBSP3_FSX);
Jarkko
thank you, I'll try it and let you know how it went
On Thu, Apr 2, 2009 at 10:56 AM, Jarkko Nikula jhnikula@gmail.com wrote:
On Thu, 2 Apr 2009 13:20:36 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
Grrr... cannot find the hack, I'm too keen to delete temporary hacks. I was
pretty sure I had it somewhere.
Basically it was adding necessary pin multiplexing configuration into arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c and then using omap_cfg_reg(...) in omap3beagle.c to change pin configuration from GPIOs to McBPS[1 | 3] pins.
Yes, I found it. Hack attached :-)
Now I don't have here Beagle to test but hack still applies on top of linux-omap. Then you will need CONFIG_OMAP_MUX=y and following lines into omap3beagle.c or board-omap3beagle.c.
omap_cfg_reg(AF6_3430_MCBSP3_DX); omap_cfg_reg(AE6_3430_MCBSP3_DR); omap_cfg_reg(AF5_3430_MCBSP3_CLKX); omap_cfg_reg(AE5_3430_MCBSP3_FSX);
Jarkko
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Im getting this output from muxing:
MUX: setup AF6_3430_MCBSP3_DX (0xd800216c): 0x0004 -> 0x0000 MUX: setup AE6_3430_MCBSP3_DR (0xd800216e): 0x0004 -> 0x0000 MUX: setup AF5_3430_MCBSP3_CLKX (0xd8002170): 0x0004 -> 0x0000 MUX: setup AE5_3430_MCBSP3_FSX (0xd8002172): 0x0004 -> 0x0000
Is this correct?
On Thu, Apr 2, 2009 at 11:27 AM, Ernesto Torres skullmate@gmail.com wrote:
thank you, I'll try it and let you know how it went
On Thu, Apr 2, 2009 at 10:56 AM, Jarkko Nikula jhnikula@gmail.com wrote:
On Thu, 2 Apr 2009 13:20:36 +0300 Jarkko Nikula jhnikula@gmail.com wrote:
Grrr... cannot find the hack, I'm too keen to delete temporary hacks. I was
pretty sure I had it somewhere.
Basically it was adding necessary pin multiplexing configuration into arch/arm/plat-omap/include/mach/mux.h and arch/arm/mach-omap2/mux.c and then using omap_cfg_reg(...) in omap3beagle.c to change pin configuration from GPIOs to McBPS[1 | 3] pins.
Yes, I found it. Hack attached :-)
Now I don't have here Beagle to test but hack still applies on top of linux-omap. Then you will need CONFIG_OMAP_MUX=y and following lines into omap3beagle.c or board-omap3beagle.c.
omap_cfg_reg(AF6_3430_MCBSP3_DX); omap_cfg_reg(AE6_3430_MCBSP3_DR); omap_cfg_reg(AF5_3430_MCBSP3_CLKX); omap_cfg_reg(AE5_3430_MCBSP3_FSX);
Jarkko
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-- ___________ EhTd
On Fri, 3 Apr 2009 10:14:45 -0600 Ernesto Torres skullmate@gmail.com wrote:
Im getting this output from muxing:
MUX: setup AF6_3430_MCBSP3_DX (0xd800216c): 0x0004 -> 0x0000 MUX: setup AE6_3430_MCBSP3_DR (0xd800216e): 0x0004 -> 0x0000 MUX: setup AF5_3430_MCBSP3_CLKX (0xd8002170): 0x0004 -> 0x0000 MUX: setup AE5_3430_MCBSP3_FSX (0xd8002172): 0x0004 -> 0x0000
Is this correct?
It look likes since debug output says that the muxmode for those pins are changed from mode 4 (gpio in this case) to 0 (McBSP3 pins in this case).
Actually all of those pins are configured as outputs in muxing module point of view but IRCC actually McBSP HW will set the direction depending on its configuration. At least I didn't notice any difference what was the muxing direction when I was playing with them shortly some time ago.
participants (3)
-
Ernesto Torres -
Jarkko Nikula -
Mark Brown