Add "no-reset" DT property to optionally avoid resetting the SEC

[Brandon-Hurst]

PR Description

This is a carryover of PR 32 on the lnxdsp-linux repo: analogdevicesinc/lnxdsp-linux#32

In cases where the SHARC cores absolutely must be booted before ARM Linux, applications utilizing ADI's SHARC FreeRTOS image will crash if the SEC is reset due to using a System Event Controller (SEC) soft interrupt to drive the rescheduler. This is due to a silicon anomaly that prevents utilizing SHARC core-level interrupts instead of the SEC.

Therefore, an optional DT property is added to the SEC driver which allows NOT resetting the SEC in the event that an RTOS-based application is running prior to ARM Linux booting.

• Add boolean "no-reset" property to DT bindings for ADI SEC driver
• Add condition check to NOT reset the SEC if "no-reset" is set in DT

Please let me know if there are any specific unmet needs regarding contribution format / CI.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have compiled my changes, including the documentation
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly
• I have provided links for the relevant upstream lore

[Brandon-Hurst]

Willing to document this if there's a good place -- let me know :)

I'm aware of this spot but doesn't seem like there's much DT documentation there just yet:
https://analogdevicesinc.github.io/documentation/products/adsp/index.html

[nunojsa]

Some comments from me...

[nunojsa]

I wonder if there's any way to check the SHARC status so that we don't need a new property?

[Brandon-Hurst]

I'm not sure if there's a way to do this that could easily cut across SC-58X, SC-59X, etc.

For the SC589, the HRM does give a bit in the RCU_MSG register that indicates the SEC has been initialized already:

https://www.analog.com/media/en/dsp-documentation/processor-manuals/SC58x-2158x-hrm.pdf
Pg. 234 / 6-17

Also, the SEC Core Interfaces do respectively have some enable bits in the SEC_CCTL ("SCI Control") registers for each core:

Pg 271 / 7-26

I'm not generally aware of how the hardware looks on the other SHARC cores, perhaps there is a portable solution that can be unified.

I see some benefit in having something in the bindings files (e.g. a DT property) in that it at least offers a bit of a general warning about shared resources...this bug took many months to identify, and one of the things that helped was looking back to older kernels and seeing they had a kernel CLI option for this. I consider a DT prop to be similarly informative. There are certainly more places where problems like this can creep in, and this fix doesn't attempt to account for all of them. But the indication in this case was helpful since the SEC is a critical system resource.

I could see the below as a solution. Let me know if this makes sense and I'll give it a build/test.

Disclosure: I had an LLM look through the PDF to find the register fields and recommend a solution. The only thing that seems not real here is the RCU0_MSG_SECINIT field, which would need to be defined.

include/linux/soc/adi/rcu.h

/* Bit values for the RCU0_MSG register */
//...
#define RCU0_MSG_C1ACTIVATE             0x00080000      /* Core 1 Activated */
#define RCU0_MSG_C2ACTIVATE             0x00100000      /* Core 2 Activated */
#define RCU0_MSG_SECINIT                0x00200000      /* SEC Initialized */

drivers/soc/adi/mach-sc5xx/sec.c

/* Check the SHARC cores & SEC for early runtime activity */
u32 rcu_msg = adi_rcu_readl(adi_rcu, ADI_RCU_REG_MSG);
bool sharc_active = (rcu_msg & (RCU0_MSG_C1ACTIVATE | RCU0_MSG_C2ACTIVATE)) != 0;
bool sec_initialized = (rcu_msg & RCU0_MSG_SECINIT) != 0;

/* Reset the SEC if the ARM core is first to boot */
if (!(sharc_active || sec_initialized)) {
    dev_info(dev, "SHARC cores active, skipping SEC reset\n");
}
else {
    /* Reset the SEC */
    //...
}

[pamolloy]

This is really a hack for an unsupported use case, but better to keep the hack in tree than e-mail a patch to a customer. This will never go upstream so the commit message should include a [ADI] prefix.

[nunojsa]

Disclosure: I had an LLM look through the PDF to find the register fields and recommend a solution. The only thing that seems not real here is the RCU0_MSG_SECINIT field, which would need to be defined.

Well, if we have a reliable way of detect that the core is up and running and we do not want/should reset it, it should be a viable upstream patch. I mean, if there's a real usecase for it...

I see some benefit in having something in the bindings files (e.g. a DT property) in that it at least offers a bit of a general warning about shared resources...

However, as a DT property might be harder to sell. DT is about HW descriptions and this looks like policy/config. However the line is thin and it could be acceptable if there's no other reliable way to detect this during early boot (and again, there are real usecases for it).

[pamolloy]

Unfortunately, some warnings to not fail CI/CD, but should still get fixed:

https://github.com/analogdevicesinc/linux/actions/runs/22081840180/job/63808472717?pr=3131#step:7:25

And the Signed-off-by and author e-mail should be analog.com

[pamolloy]

Suggested change

	description: Prevents resetting the SEC to preserve SHARC interrupts
	description: Prevents resetting the SEC to preserve SHARC interrupts if Linux boots after the SHARC cores are booted. This is not an officially supported boot flow and other system issues may occur

Something along those lines