initialize device to DEVICE_PM_OFF_STATE?

[denis]

I have a nRF5340 with a UART that connects to a circuit that is not powered on until it is needed by the application.  So the UART must be powered off until the application requires it.  I see that there is a function device_set_power_state that I can use with DEVICE_PM_ACTIVE_STATE to turn it on.  However, I don't see a way to initialize the device to DEVICE_PM_OFF_STATE.  Is there something I need to do in the dts to indicate that?

[Elfving]

Hey Denis!

It is a bit tricky to make make the peripheral not to start off being initialized. The Zephyr drivers don't allow you to do that, though you can use the nrfx ones.

Take a look at this post.

Best regards,

Elfving

[denis]

There doesn't seem to be anything to preclude a driver initializing into DEVICE_PM_OFF_STATE.  Would be great to have a configuration option, something like CONFIG_UART_3_NRF_PM_OFF_STATE=y, for this in the uart_nrfx_uarte.c driver.  I may look at adding that, unless you know of something in Zephyr that would cause that not to work?

[Elfving]

Hello Denis!

denis said:

There doesn't seem to be anything to preclude a driver initializing into DEVICE_PM_OFF_STATE.

denis said:

I may look at adding that, unless you know of something in Zephyr that would cause that not to work?

It isn't possible to defer the Zephyr driver model init functions; they are always run before main(). But what you can do is something along the lines of what we've done here & here: return -EBUSY when driver is still initializing.

denis said:

Would be great to have a configuration option, something like CONFIG_UART_3_NRF_PM_OFF_STATE=y

Yes, absolutely. I had a talk with one of our SW engineers about it, and he think he's seen some issue upstream about this, but isn't sure.

Modifying drivers can be a hassle though. Any reason why you can't simply turn it off at the start of the application?

Best regards,

Elfving

[denis]

When the device driver is initialized it brings the TX pin high (and RX high with a pull-up).  These pins are going to an unpowered circuit.  That exceeds the maximum allowed voltage on the pins in that unpowered circuit.  Electrically this is violating the specifications.

Using other SDKs this has never been an issue, since typically the application explicitly initializes the drivers after main is started and it has full control over the sequence.

It would be a great addition to Zephyr if the device driver configurations from the device tree were typically simply default initial values, device initialization can be deferred to the application, and there was support for reconfiguration and de-initialization.

It looks like I will need to use the Nordic peripheral directly, or use nrfx to access the peripheral, since the Zephyr driver doesn't support this.  Which is a shame since there is a fair amount of useful code in the Zephyr driver that I will probably need to reproduce...

[Elfving]

Hey Denis!

I understand.

Then I guess you are stuck with either seeing if manipulating the drivers to do something along the lines of the -EBUSY trick can help, or using the nrfx drivers.

denis said:

It would be a great addition to Zephyr if the device driver configurations from the device tree were typically simply default initial values

Yeah, sadly I don't know when or even if this will be implemented.

Best regards,

Elfving