How to use AHCLK with McASP

Przemyslaw Wrzos

I am attempting to run my McASP from the the AHCLKX_IN input rather than AUXCLK. The problem I encounters is that if I only clk_enable() the clock connected to the AHCLKX_IN input I can not write to any of the McASP configuration registers. I get the Kernel error:

user.alert kernel: Unhandled fault: Precise External Abort on non-linefetch (0x1028) at 0xfa0500b0

If I enable both the clock on AHCLKX_IN and the AUXCLK then it seems to work fine.

Obviously running two different clocks is undesirable so I would like to know what the correct way to do this is?

The Technical Reference manual also makes a vague reference to the McASP System Clock, but doesn't say very much about it. Is this somehow related to AUXCLK? What is the correct way for me to set up the clocking on the McASP if I wish to use AHCLK instead of AUXCLK?

over 13 years ago

0 Pavel Botev over 13 years ago

TI__Guru**** 170625 points

Hi Przemyslaw,

DM814x has 6 instances of the McASP module (from McASP0 to McASP5). Which instance do you want to use? Can you reproduce this bug for instance McASP5 (base address 0x4A1AE000) ?

When you refer to the clock connected to the AHCLKX_IN input, do you mean mcasp[n]_ahx_ck (described in file clock814x_data.c) ?

When you refer to the clock AUXCLK, do you mean mcasp[n]_fck (described in file clock814x_data.c) ?

Best Regards,

Pavel

0 Przemyslaw Wrzos over 13 years ago in reply to Pavel Botev

Prodigy 245 points

In my case I was using McASP2. So I had to clk_enable() both mcasp3_ahx_ck and mcasp3_fck even though I'm using only mcasp3_ahx_ck to generate the clock signals. If I only enable mcasp3_ahx_ck then I get the error I mentioned above.

Is that sufficient information or do you still want me to try it specifically with McASP5?

0 Pavel Botev over 13 years ago in reply to Przemyslaw Wrzos

TI__Guru**** 170625 points

Przemyslaw,

The problem is that I can access McASP2 (base address 0x48050000) registers without any modifications, I do not need to clk_enable() nor mcasp3_ahx_ck nor mcasp3_fck. These both clocks are functional clocks, and for accessing peripheral registers you need the OCP interface (L3/L4 interconnect) clock mcasp3_ick.Thus for access McASP2 registers you need the CM_ALWON_MCASP2_CLKCTRL[1:0] MODULEMODE = 0x2.

So I need some more details. Are you on the latest EZSDK 5.04.00.11 with PSP 04.04.00.01?

What is the value of the CM_ALWON_MCASP2_CLKCTRL[1:0] MODULEMODE bitfield (address 0x48181548) at:

1. at boot time

2. after you clk_enable() the mcasp_fck

Best Regards,

Pavel

0 Przemyslaw Wrzos over 13 years ago in reply to Pavel Botev

Prodigy 245 points

Pavel,

Thanks, I appreciate your help, that indeed explains the problem. If I don't clk_enable() mcasp3_fck then CM_ALWON_MCASP2_CLKCTRL value stays on 0x30000 (in other words the interface clock is off). After clk_enable() it changes to 0x2 (interface clock on). Looking inside clock814x_data.c seems to explain why. The mcasp3_fck definition includes this:

.enable_reg = TI81XX_CM_ALWON_MCASP2_CLKCTRL

So it seems enabling the McASP2 functional clock also enables the appropriate interface clock.

Interestingly I couldn't reproduce this error with McASP5 since it seems to be set up differently, there is no individual interface clock control there. In fact I can't see any reference to any control of the sort in the kernel source at all, I'm sure it's there somewhere but I'm not curious enough to go digging at this point. McASP 3, 4 and 5 seem to be working fine for me for now.

I think I'm just going to stick to enabling the mcasp3_fck clock inside the driver code since it seems the only higher level interface available for turning the interface clock on. Though perhaps the correct solution would be for the clock814x_data.c definitions for the AHCLK inputs to be updated.

I have one other question you might be able to help me with: Where does the value for TI81XX_L4_SLOW_IO_OFFSET come from and why is this used in the kernel to offset the CM_ALWON_MCASP2_CLKCTRL address? I could not find any references to this in the CPU documentation.

Cheers

0 Pavel Botev over 13 years ago in reply to Przemyslaw Wrzos

TI__Guru**** 170625 points

Hi Przemyslaw,

This issue (with McASP2 interface clock) is fixed in the latest EZSDK 5.04.

About TI81XX_L4_SLOW_IO_OFFSET, in which file it is used to offset the CM_ALWON_MCASP2_CLKCTRL? Could you please also paste the line that do this?

BR,

Pavel

0 Przemyslaw Wrzos over 13 years ago in reply to Pavel Botev

Prodigy 245 points

Hi Pavel,

I'm not sure what you mean. The kernel I'm using in my build is the same as in EZSDK 5.04/PSP 4.04. It doesn't seem so much an issue as a design choice, i.e. the interface clocks are controlled via the same kernel object as one of the functional clocks. You can confirm this your self by checking the mcasp2_fck definition in arch/arm/mach-omap2/clock814x_data.c, on line 3102 we see: .enable_reg = TI81XX_CM_ALWON_MCASP2_CLKCTRL

Regarding the offset to CM_ALWON_MCASP2_CLKCTRL. We find the following definitions in arch/arm/mach-omap2/cm81xx.h:

297: #define TI81XX_CM_ALWON_MCASP2_CLKCTRL TI81XX_CM_REGADDR(TI81XX_CM_ALWON_MOD, 0x0148)
 21: #define TI81XX_CM_REGADDR(module, reg) \
 22:   TI81XX_L4_SLOW_IO_ADDRESS(TI81XX_PRCM_BASE + (module) + (reg))

And then we have the following in arm/plat-omap/include/plat/io.h:

 87: #define TI81XX_L4_SLOW_IO_ADDRESS(pa) IOMEM((pa) + TI81XX_L4_SLOW_IO_OFFSET)
 86: #define TI81XX_L4_SLOW_IO_OFFSET 0xb2000000

That's why when you print the actual value represented by TI81XX_CM_ALWON_MCASP2_CLKCTRL in the kernel, you get 0xfa181548 which is 0x48181548 offset by 0xb2000000. I was curious what the reason for that was.

Cheers

Processors

Processors forum

How to use AHCLK with McASP