drivers: memc: Fix various APS6404 device driver issues

[ioannis-karachalios]

This commit deals with fixing various issues that prevents the APS6404 MSPI device from being built. In specific:

1. Fix default timing macro definitions to build with an MSPI controller, other than AMBIG. Add macro definition for MSPI_PORT.
2. Timing settings should be applied only when MSPI_TIMING is defined. Otherwise, the APS6404 initialization routine should fail with -EIO.
3. Similarly, use MSPI_XIP and MSPI_SCRAMBLE to apply XIP and SCRAMBLE device settings, respectively (optimization).
4. Based on current MEMC_INIT_PRIORITY (0), APS6404 device should be initialized before the underlying MSPI bus is enabled, and so the APS6404 initialization routine should fail during controller's bus check. Change init. priority to a value higher than MSPI_INIT_PRIORITY (70).

Fixes #81151

[swift-tk]

@ioannis-karachalios Thanks for filing the PR, I was going to fix those things but apparently you’ve beat me to it😄.

[ioannis-karachalios]

@ioannis-karachalios Thanks for filing the PR, I was going to fix those things but apparently you’ve beat me to it😄.

@swift-tk, you're welcome. I am working on a new family of device that is going to support the MSPI driver and I came across these errors.

[swift-tk]

@ioannis-karachalios Please note that you also have to fix the CI checks before a merge.

[RichardSWheatley]

@ioannis-karachalios Thanks for filing the PR, I was going to fix those things but apparently you’ve beat me to it😄.

@swift-tk, you're welcome. I am working on a new family of device that is going to support the MSPI driver and I came across these errors.

I am following as we are creating another device driver for memc. Same family, higher density.

[ioannis-karachalios]

"Please note that you also have to fix the CI checks before a merge."
@swift-tk, to my understanding, the CI errors should be irrelevant to the underlying changes.

[RichardSWheatley]

Why are these ifdef's included of the enable is already there?

To save code space?

[swift-tk]

When XIP is not supported by a specific hardware, CONFIG_MSPI_XIP=n is used to indicate that. This also means that xip_config may not be implemented, so calling it in device driver may result in error. Leaving it out of compile will not only save code space but also ensure the device driver is still functional without optional features.
Additionally, one can also choose to disable XIP even when it is supported.

[swift-tk]

"Please note that you also have to fix the CI checks before a merge." @swift-tk, to my understanding, the CI errors should be irrelevant to the underlying changes.

Could you try rebase to latest main and try again with the CI. If that don't work, I will ask help in discord.

[ioannis-karachalios]

Could you try rebase to latest main and try again with the CI. If that don't work, I will ask help in discord.
I re-based to the latest main, but CI reports the same twister errors, again. I'd appreciate if we seek for assistance in discord as my schedule is tight at the moment to further investigate it.

[swift-tk]

I did not notice the default 0 was gone.

[ioannis-karachalios]

I did not notice the default 0 was gone.

@swift-tk, I was under the impression that a zero value should be given if not defined, explicitly. Thanks for your support.

[mmahadevan108]

@ioannis-karachalios , we are only merging PR that have a Zephyr Issue linked to it. If this is needed for the 4.0 release, then please add a Zephyr issue with details about the problem seen and link it to this PR.

[ioannis-karachalios]

@mmahadevan108, I opened #81151 bug report incident linked to this PR.