Project

General

Profile

Using McASP Rx clock generation module

Added by Tom Riddle 12 months 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 12 months 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 12 months 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 12 months 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 12 months 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 11 months 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 11 months 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.

    (1-6/6)
    Add picture from clipboard (Maximum size: 500 MB)