MCXN947 HPDAC backport

[wesOS]

I am backporting the Zephyr nxp_hpdac driver to Zephyr 4.3 for an MCXN947-based board.

The upstream driver does not use a device init callback. However, on Zephyr 4.3 the HPDAC does not work correctly unless I explicitly initialize the DAC2 clock, SPC analog modules and reset before using the peripheral.

I added an nxp_hpdac_init() function which performs the following steps:

CLOCK_SetClkDiv(kCLOCK_DivDac2Clk, 1U)
CLOCK_AttachClk(kFRO_HF_to_DAC2)
CLOCK_EnableClock(kCLOCK_Dac2)

SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac2)
SPC_EnableLowPowerModeAnalogModules(SPC0, kSPC_controlDac2)

RESET_PeripheralReset(kDAC2_RST_SHIFT_RSTn)

DAC14_DoSoftwareReset()
DAC14_DoFIFOReset()

SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlVref)

These initialization steps were based on the MCXN947 reference manual and implemented using the corresponding MCUX SDK APIs.

The init function is registered as the device init callback through DEVICE_DT_INST_DEFINE(). With these changes, the HPDAC works correctly.

I also checked the Zephyr MCUX SYSCON clock-control driver and the mcux_lpc_syscon_clock.h bindings, but I could not find an HPDAC/DAC2 clock identifier or clock-control implementation for this peripheral, so I am currently using the MCUX SDK clock, SPC and reset APIs directly.

My questions are:

1. Is this the correct approach when backporting the MCXN947 HPDAC driver?

2. In newer Zephyr versions, are these resources initialized somewhere else, or does the upstream nxp_hpdac driver assume that they have already been configured?

3. Is the HPDAC device init callback the correct place for this MCXN947-specific initialization, or should these steps be handled elsewhere in Zephyr?

I have attached the complete backported driver for reference.

[Harry_Zhang]

Hi  @wesOS 

1. Is this the correct approach when backporting the MCXN947 HPDAC driver?

Yes, this is a reasonable and practical approach for the backport. If the required DAC2 clock, SPC analog modules, VREF, and reset resources are not initialized elsewhere in the Zephyr 4.3 environment, performing the initialization in the driver is necessary to ensure correct HPDAC operation.

2. In newer Zephyr versions, are these resources initialized somewhere else, or does the upstream nxp_hpdac driver assume that they have already been configured?

HPDAC support has already been added upstream:

https://github.com/zephyrproject-rtos/zephyr/pull/104642

However, I performed a quick verification using the current upstream implementation and observed that the DAC2 clock does not appear to be configured. For example, CLOCK_GetDacClkFreq(2) reports 0 Hz in my test environment, while the equivalent MCUX SDK example reports 48 MHz after the DAC clock is configured.

Based on this observation, it appears that the current driver may be assuming that certain device resources have already been configured. Could you please double-check the clock configuration path on your side as well?

I will also report this to our Zephyr team for further investigation and work with them to address the issue if a missing clock initialization bug is confirmed.

3. Is the HPDAC device init callback the correct place for this MCXN947-specific initialization, or should these steps be handled elsewhere in Zephyr?

For a backport, placing this logic in the HPDAC device initialization callback is a practical and acceptable solution.

That said, the MCXN947-specific DAC2 clock, SPC, VREF, and reset configuration should ideally be clearly isolated as SoC-specific functionality rather than embedded as generic HPDAC behavior. In the longer term, these resources would preferably be managed through Zephyr infrastructure such as clock, reset, or power-management frameworks where applicable.

BR

Harry

[wesOS]

Thanks, I double-checked the DAC2 clock path on my MCXN947 setup.

Before the HPDAC driver configures the clock: <inf> dac_nxp_hpdac: DAC2 clock before config: 0 Hz

After:

CLOCK_SetClkDiv(kCLOCK_DivDac2Clk, 1U);
CLOCK_AttachClk(kFRO_HF_to_DAC2);
CLOCK_EnableClock(kCLOCK_Dac2);

I get: <inf> dac_nxp_hpdac: DAC2 clock after config: 48000000 Hz

So I am seeing the same behavior on my side: the DAC2 clock is not configured before the HPDAC driver initialization.

Your explanation about keeping the MCXN947-specific resource handling isolated also makes sense.

What I am mainly trying to understand now is how you expect that initialization to be divided in the eventual upstream solution.

For example, do you expect the DAC2 clock configuration, SPC/VREF setup and reset handling to each move into their corresponding Zephyr/SoC infrastructure, with `dac_nxp_hpdac.c` only keeping the generic HPDAC initialization?

I am mainly asking so I can understand the intended ownership of each initialization step and keep the backport reasonably aligned with that direction.

Thank you.

BR 

Ouassim

[Harry_Zhang]

Hi @wesOS 

Thanks for confirming your results. The fact that both of us observe DAC2 clock before config: 0 Hz and 48000000 Hz after the clock configuration strongly suggests that the DAC2 clock is not initialized before the HPDAC driver runs.

I have already reported the bug fix to our internal Zephyr team.

After looking further into the FRDM-MCXN947 implementation, I found that the existing DAC clock initialization is currently handled at the board level rather than in the DAC drivers themselves.

zephyr/boards/nxp/frdm_mcxn947/board.c

the function:

void board_early_init_hook(void)

performs the clock and SPC initialization for both DAC0 and DAC1:

#if DT_NODE_HAS_STATUS_OKAY(DT_NODELABEL(dac0))
        SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac0);
        CLOCK_SetClkDiv(kCLOCK_DivDac0Clk, 1u);
        CLOCK_AttachClk(kFRO_HF_to_DAC0);

        CLOCK_EnableClock(kCLOCK_Dac0);
#endif

#if DT_NODE_HAS_STATUS_OKAY(DT_NODELABEL(dac1))
        SPC_EnableActiveModeAnalogModules(SPC0, kSPC_controlDac1);
        CLOCK_SetClkDiv(kCLOCK_DivDac1Clk, 1u);
        CLOCK_AttachClk(kFRO_HF_to_DAC1);

        CLOCK_EnableClock(kCLOCK_Dac1);
#endif

Based on the current implementation, my expectation would be to keep the solution consistent with the existing board design. In other words, the DAC2 clock initialization could be added to board_early_init_hook() alongside the existing DAC0/DAC1 initialization rather than placing board-specific clock setup into the generic HPDAC driver.

BR

Harry