imx8mn ecspi2 in M7 conflicting with ecspi1 in A53 core?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8mn ecspi2 in M7 conflicting with ecspi1 in A53 core?

789 Views
massimoanghilie
Contributor I

Hi,

I've built an application for the M7 core that acquires some data from an ADC connected to the ECSPI2 port of the SoC; the ECSPI2 interrupt is used to handle the data transfer.

Then I've the linux Yocto running on the A53 core that is driving an LCD (ST7735S graphic controller) through the spidev driver, connected to the ESCPI1 port of the soc .

Now, when the M7 core is not running the display draws perfectly, but when the M7 runs its application I see errors in drawings on the LCD. Also if I run on the M7 core another kind of application that do not uses the ECPSI2 all works good.

Is there any resctriction in using at the same time two different ecspi on the two cores(M7 and A53)? Are they conflicting in some way? Is there somethig that I'm missing in my desgin?

Any help will be appreciated,

many thanks

Massimo

Labels (1)
0 Kudos
2 Replies

701 Views
kef2
Senior Contributor V

Hi,

 

I don't know imx8mm specifics, from experience with iMX7D: you should check what are clock sources of peripherals in question. Linux eCSPI driver disables all unused parent clocks as soon as transfer is complete. Say you run your peripheral on Cortex-M side, not necessarily eCSPI. If this -M side peripheral has common clock with your Linux side eCSPI, and if no other device on Linux uses the same clock (so that another Linux driver doesn't allow eCSPI driver to turn off common clock) - you are in trouble. You may inspect `/sys/kernel/debug/clk/clk_summary` to see what's going on. eCSPI source clocks while idle are marked there as unused, Linux has no idea what's going on on Cortex-M.

There should be specific settings in DT to let Linux know which clocks are used by Cortex-M software and should be never disabled, so that Linux would not disturb your Cortex-M. AFAIK there are no such settings, and the best way to solve it seems to be patching clock driver.

 

Edward

0 Kudos

711 Views
AldoG
NXP TechSupport
NXP TechSupport

Hello,

Please make sure that you have disabled ECSPI2 resources used in your M7 code from your device tree, be it the pads that you are using and the nodes.

A good test would be trying with your example disabling all ECSPI references in dts and check that the example runs well when Linux boots.

Best regards,
Aldo.

0 Kudos