• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 777 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x MCASP sample clock question

Wolfgang Muees1
Genius 3685 points

I wonder about an obvious error/misdocumentation in the MCASP driver/hardware:

In the linux driver, sound/soc/davinci/davinci-mcasp.c, function davinci_mcasp_set_dai_fmt.

in the register DAVINCI_MCASP_ACLKXCTL_REG, the bits ACLKXPOL and ACLKRPOL are set according to the

data format SND_SOC_DAIFMT_xxx. ACLKRPOL is set to the opposite value of ACLKXPOL.

This is consistent with the usual hardware requirement, that a data bit is output at the starting edge of the bit clock, and the incomming data is sampled with the opposite edge of the bit clock (in the middle of the bit).

However, in the Technical Reference Manual, Chapter 22.4.1, Registers ACLKXCTL and ACLKRCTL, Bit 7 = CLKRP/CLKXP, the description is so that both bits must be set TO THE SAME value.

I suspect that a wrong clock edge programming for the receiver would mostly not result in a transmission error, because the data bit will be sampled on the end of the bit period, and maybe will be still valid (but at the absolute edge of the timing window).

So my question is: is there an error in the documention, and the linux driver author has doing the "right thing" without doccumenting the errata, or is the documentation correct and the linux driver author made a mistake?

regards

Wolfgang

  • 0
    TI__Mastermind 30110 points

    Hi Wolfgang,

    Wolfgang Muees1 said:
    However, in the Technical Reference Manual, Chapter 22.4.1, Registers ACLKXCTL and ACLKRCTL, Bit 7 = CLKRP/CLKXP, the description is so that both bits must be set TO THE SAME value.

    In the McASP the TX and RCV Clock can be completely independant. Therefore that are no specific requirements to set both CLKRP/CLKXP to the same value.

    The CLKRP/CLKXP settings will depend the specific use case. If ASYNC=0 then you are correct there might requirements for polarity on both the TX and RCV side.

    Hope it helps.

    Anthony

  • 0 in reply to AnBer
    TI__Mastermind 30110 points

    Just to clarify:

    I think that the AM335x datasheet SPRS717F page 210 shows CLKXP = CLKRP = 0 or CLKXP = CLKRP = 1 just because it is more convenient to represent visually. There are no firm requirement to have both CLKXP and CLKRP to be equal.

    The value that need to be used are depending on the transmitter and receiver. In case the McASP is the clock master and use MCASPx_ACLKX as bit clock for both TX and RCV then:
    - CLKXP value depend on the external receiver (when it can sample the data)
    - CLKRP value depend on the external transitter (on which edge of the CLK he receives it will place the data on his TX pin)
    Refer to the datasheet of the device that you hook to the mcASP to see what is required.

    Anthony

  • 0 in reply to AnBer
    Genius 3685 points

    Anthony,

    thank you for your answer, but it does not cover the real topic...

    Consider a codec which has the same clock polarity for transmitter and receiver. This is the common case, and I expect the linux mcasp driver is written for that common case.

    If I look at the manual, it is clear for me that CLKXP and CLKRP must be set to the same value.

    But if I look to the source code of the linux mcasp driver, CLKXP and CLKRP are set to different values all the times.

    So I think that obviously, the manual or the driver is plain wrong. As both driver and manual are from TI, I want a statement from TI which one is wrong!

    best regards

    Wolfgang

  • 0 in reply to Wolfgang Muees1
    TI__Guru**** 393215 points
    Hi Wolfgang,
     
    There is confirmation from the factory team that the AM335X TRM is correct as compared to the McASP specification.
  • 0 in reply to Biser Gatchev-XID
    Genius 3685 points

    Hello Biser,

    thank you very much for this confirmation.

    In fact, this was the expected answer - the chapter about MCASP in the TRM is very good, and it is very obvious that the author has a very good knowledge.

    In contrast, the mcasp linux driver is the opposite: buggy as hell, non-functional for most data formats, broken FIFO handling, etc...

    I am fighting with this driver for 1 week now, and it's very unclear to me how such an incomplete and untested driver could have escaped the TI quality control...

    best regards

    Wolfgang

  • 0 in reply to Wolfgang Muees1
    TI__Guru**** 393215 points
    Wolfgang,
     
    I can't help on this. I work only on hardware issues on the forums.
  • 0 in reply to Wolfgang Muees1
    TI__Mastermind 30110 points

    Wolfgang,

    Wolfgang Muees1 said:
    If I look at the manual, it is clear for me that CLKXP and CLKRP must be set to the same value.

    What document/section/page/paragraph do you refer to in this case?

    Wolfgang Muees1 said:
    Consider a codec which has the same clock polarity for transmitter and receiver. This is the common case, and I expect the linux mcasp driver is written for that common case.

    What is important is that the transmitter/receiver side timings do match. One should always double check the McASP timings vs the ADC/DAC/CODEC timings to ensure operability.
    The driver need to be generic but it is still one implementation example that is validated on one particular HW.

    Best regards,

    Anthony

  • 0 in reply to AnBer
    Genius 3685 points

    AnBer,

    you still have not understand my question.

    I fear I can't help you..

    regards

    Wolfgang