MCXN947 HPDAC backport 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. Analog(ADC|CMP|DAC|OpAmps) Clock|Timers MCXN 回复： MCXN947 HPDAC backport 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
查看全文
