Forums » Software Development »
Using McASP Rx clock generation module
Added by Tom Riddle about 6 years ago
Hi,
We are developing a new codec using the MityDSP. So the Industrial IO has the DSD1791 audio DAC on it's McASP. This DAC uses the TX clock generation module (ACLKX and AFSX) for the bit and word clock. The other L138 EVMs also uses the TX generation module to interface to their codecs.
Since they are independent generators I would think it would be possible to instead use the available RX clock generation module (ACLKR and AFSR), whose signals are available on the I/O connectors along with serializer signals (AXR13, AXR14). We would disable the existing DAC by placing it in reset. We would also need to jump the Audio_Sysclk (mclk) over to the connector. We are suggesting this interface to our I2S codec
AXR14 - Dout (omap_gpo_6)
AXR13 - Din (omap_gpo_5)
ACLKR - bit clock (omap_gpo_15)
AFSR - word clk (omap_gpo_13)
MCLK - Audio_sysclk (jumper to connector)
We've already been successful getting our codec registered as a sound over I2C by creating a separate dai interface using a modified davinci-indio.c. Looks like the place for modifications are in the EVM Linux source (sound / soc / davinci / davinci-mcasp.c) in order to use the RX generation module.
Let me know if I've overlooked something or what else I need to consider.
Thanks in advance, Tom
Replies (6)
RE: Using McASP Rx clock generation module - Added by Tom Riddle about 6 years ago
Hi,
We are working thru enabling of the McASP Rx clock generator module. After making source updates to davinci_mcasp.c we've been successful in generating a frame clock (AFSR) and see it's output on omap_gpo_13, but we cannot observe the expected output clock (ACLKR) on omap_gpo_15 on either J700 or J701.
So seeing the AFSR output confirms a number of things, since this is driven off of the RCLK. The regs of interest are listed below with their values
AHCLKRCTL = 0x0
ACLKRCTL = 0xaf
AHCLKXCTL = 0x0
ACLKXCTL = 0xef
tracing back ACLKXCTL.6 = 1, which is ASYNC operation, thus RCLK will come from the Rx clock generator.
next ACLKRCTL.5 = 1 CLKRM = 1, and AHCLKRCTL.15 = 0 HCLKRM = 0 so the AUDIO_SYSCLK on AHCLKR pin is the source.
So now we look at the ACLKR pin
The McASP PFUNC reg = 0x0, all McASP signals are enabled. Then
MCASP_PDIR = 0xb4008000
Which has the AUDIO_SYSCLK as driving both the inputs AHCLKR & AHCLKX. The rest are outputs.
So I can't probe the even pins of J101 to get to pin 20 ACLKR. I have looked at both J700-20 & J701-18 and see no signal activity.
Industrial IO Development Kit (L138) - 80-000268RI-3 Rev C and have verified that the PCB label matches the schematic 80-000268RI-3 we are referencing.
Is there a way I can probe on the MityDSP module to verify that ACLKR is there?
Tom
RE: Using McASP Rx clock generation module - Added by Michael Williamson about 6 years ago
Hi Tom,
Have you checked the pinmux settings for the IO Pin are set to use the McASP function and not GPIO or something else?
The only option (what we do) for probing even pins on the connector is to tack a small wire on the edge connector (like inductor / magnet wire) and pull it out for scope access...
-Mike
RE: Using McASP Rx clock generation module - Added by Tom Riddle about 6 years ago
Hi Mike, thanks for responding.
So I have updated the baseboard-industrialio.c to enable all of the baseboard_mcasp_pins (like the ti evm) and even took out the GPIO configs for 13 & 15 which certainly can get overridden later, just in case.
The start of davinci_hw_common_param sets all the pins again to be McASP. The user manual suggests the MCASP_PFUNC reg is the only place where the distinction is made between McASP and GPIO functionality. Can GPIO functionality be set somewhere else? Regs, Tom
RE: Using McASP Rx clock generation module - Added by Jonathan Cormier about 6 years ago
Can you dump the pinmux registers so we can double check them?
0x01C14120 - PINMUX0
0x01C14124 - PINMUX1
RE: Using McASP Rx clock generation module - Added by Tom Riddle about 6 years ago
Hi Jonathan,
Ok, good suggestion... thanks... the pinmux read
PINMUX0 = 0x8811.1110
so it's not getting set to ACLKR, instead to PRU0_R3122, not even a gpio, which interesting.
PINMUX1 = 0x8888.8881
all of the serializer pins are GPIOs with the exception of AXR15, which is expected.
So the good news is that forcing the PINMUX0 to 0x8811.1111 when the mcasp inits enables the clock output.
Now onto where to effect the proper changes, still need to make updates for the data serializer pins. Could leave the pinmux updates in the mcasp_probe, but was thinking that setting it up within the arch/arm/mach-davinci/baseboard-industrialio.c would make more sense?
RE: Using McASP Rx clock generation module - Added by Jonathan Cormier about 6 years ago
Ideally you should get it working from the baseboard as that should be the source of all the pinmux settings. Not sure what else might be overriding things. I have run into cases where i had multiple pinmux configs overriding each other in the baseboard and didn't notice at first.
