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.

  • Resolved

Linux/66AK2G12: Unable to set LPSC for peripherals used by DSP

Part Number: 66AK2G12

Tool/software: Linux

Hello,

I am using Processor SDK 4.2.0.9 with CCSv7.3.0.  The various component versions are those that came with that release.

I have modified the MCASP example project to use the hardware configuration on my custom K2G board.  I merged this project with an IPC example so that I could get the DSP running at the same time as Linux, and it does do that.  The catch is that I must manually enable the LPSC in charge of the McASP.  My procedure goes something like this:

- Power up system, let Linux boot.
- Get audio clocks running and IIS routed around the board
- Launch target config and connect DSP
- Load DSP GEL, enable all PSC
- resume processor
- use mpmcl to reset, load, and run the DSP.

This works some of the time.  Sometimes the McASP gets stuck transmitting a single buffer (as though the processor has been halted), or I get an Event Combiner error saying that the event I have connected to the DSP through the CIC (DSP Event 64) is "unplugged".  Sometimes CCS just crashes when I try to connect the processor.  The event combiner error happens whenever I try to restart the program using mpmcl, i.e. if the program was running and I reset and reloaded it.

I encountered similar behavior when I was developing this project using the OMAP-L138.  That post is located here: https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/612298?tisearch=e2e-sitesearch&keymatch=%20user:301823

How would I go about setting up the LPSC in Linux for the DSP to use?  I would like for Linux to do all of the chip level configuration.  I have:

- Enabled McASP0 in the device tree
- Added reserved slot ranges in the device tree (  ti,edma-reserved-slot-ranges = <24 2>, <128 48>;  )

Any ideas of where to look/what to do to make these two coexist on this platform?

Jeff

  • In reply to Nick Saulnier:

    Nick,

    Sounds good. I'll let you know when I get to it.

    For now, yes, it's entirely in the DSP. DSP receives, DSP processes, DSP transmits. It might be nice to be able to pass audio data via IPC from the ARM to the DSP so that the ARM could use the DSP as a sort of media player, but that's a task for later, and in this case the ARM still would not have control of the McASP.

    Rex,

    Thank you for the input. I look forward to hearing what the DSP engineer has to say. I'll post any progress I make on the memory map here.

    Jeff
  • In reply to Nick Saulnier:

    Nick,

    With respect to the LPSC setting from RTOS, I noticed that the McASP driver attempts to set the LPSC (at least the source references it mcasp_drv.c:5563:Mcasp_localLpscOn()).  Wouldn't this negate the need to manually enable the LPSC?

    I have yet to implement the device tree changes.  That will likely happen sometime this week.

    Jeff

  • In reply to Jeffrey Limbocker:

    Hello Jeff,

    Maybe? That function returns a "MCASP_COMPLETED" regardless of whether it accomplishes anything if BIOS_PWRM_ENABLE is not defined. I would be interested to see if a) BIOS_PWRM_ENABLE is defined for you, and b) what the function returns when it is called. It didn't look like the Power_setDependency function that Mcasp_localLpscOn calls messes with the kick registers, but I did not drill down far enough to be sure.

    Regards,
    Nick
  • In reply to Nick Saulnier:

    Hi Nick,

    It's hard to tell if BIOS_PWRM_ENABLE is defined since the McASP libraries came precompiled with the SDK. That said, a text search on the entire PDK directory structure shows no mention of it being defined, so I am going to assume not.

    I did some searching for what that compiler switch does and found this post: e2e.ti.com/.../123279
    which seems to suggest that I wouldn't need to enable the switch for my purposes. I don't need any frequency/voltage scaling for this product, and that is what the post says the compiler switch would enable. That said, that's for another processor, so things could be different here.

    In this processor, the power management is being handled by the M4 Core running the SCI firmware, correct? Are there rules about which cores can interface with the power manager? Could it be that having the SCI processor running is preventing the LPSC function from enabling the peripheral?

    Jeff
  • In reply to Jeffrey Limbocker:

    Hello Nick,

    I have some updates.  I have finally been able to implement the suggested changes.  I removed the change I made to the McASP linux driver, disabled the device tree node, and modified the board init function.  I simply modified the pscConfigs array in evmK2G_clock.c to only include the PSC I needed, then I changed the Board_init(arg) call to only take BOARD_INIT_MODULE_CLOCK as a parameter.  With this change, the program will run when I start it with the debugger.

    At the present moment, I cannot get the application to run through MPMCL.  The log (/var/log/messages) shows that the memory allocation is failing.  I suspect this has something to do with the memory map.  I'm still waiting to hear from the DSP engineer that was mentioned earlier.

    Jeff

  • In reply to Jeffrey Limbocker:

    Hello Jeff,

    Sorry for the delay. I pinged our DSP experts to see if they can comment.

    EDIT 7/16/2018: I moved Jeff's response asking about the resource table and IPC here. This particular thread will continue discussing the issue of LPSC, but might be influenced by the discussion at that new thread.


    Regards,
    Nick

  • In reply to Nick Saulnier:

    Since the new topic has been split to a new thread, I will mark this issue as resolved.

    Summary of the solution:
    Since ARM never needs to take control of the peripheral, the DSP can do the initialization for the McASP, including the LPSC. To do this, the board library was used and modified such that calling Board_init( BOARD_INIT_MODULE_CLOCK) sets up only the LPSC needed. There may be more elegant solutions to this problem (i.e. call the LPSC setup function directly) but this solution works for me. It was required that the Linux device tree set up only the pinmux for the McASP and that the McASP remain "disabled" in the device tree.

    Much thanks to Yordan and Nick for their assistance on this issue.

    Jeff

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.