search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.93k stars 6.65k forks source link

UART driver API should be made more power-friendly #23798

Open vanti opened 4 years ago

vanti commented 4 years ago

Is your enhancement proposal related to a problem? Please describe. Per discussion in #22998, currently the UART driver API exposes uart_poll_in() and uart_poll_out() which can be called at any time to check for input or output character, with the assumption that the UART remains active outside of the function call. This essentially means the UART cannot be automatically powered-down in the lifetime of the application (e.g. by the PM policy using the central method), short of having the application manually managing it.

Describe the solution you'd like The API should be refined to be more power-friendly.

Describe alternatives you've considered Some possible solutions:

  1. Remove the assumption by doing the polling inside uart_poll_in() and uart_poll_out(), such that uart_poll_in() would only pick up input while inside the function call, and uart_poll_out() would busy-wait for output to be complete.

  2. Drop support for these poll-based APIs and use interrupt-driven API instead, where we can for example disable the uart when the uart irq is disabled.

  3. Create CONFIG_UART_POLL_ENABLED Kconfig variable, and enable poll_in/poll_out only when this is set. This would allow the driver to decide whether to support the polling functions, and optimize power as a consequence. Note that some common functionalities such as the console should be modified to support both the polling and interrupt-driven approaches, so that it can be functional regardless of the setting of CONFIG_UART_POLL_ENABLED. Otherwise we are back to the situation where polling is needed most of the time and the UART would have to be kept powered to cater to the lowest common denominator.

jenmwms commented 4 years ago

In #2 solution in the description, would this require non-interrupt-based designs to then implement interrupts to comply with the API? Perhaps it only effects a small audience, but it's worth mentioning that there are some designs that choose to avoid interrupts and this would remove that choice?

vanti commented 4 years ago

In #2 solution in the description, would this require non-interrupt-based designs to then implement interrupts to comply with the API? Perhaps it only effects a small audience, but it's worth mentioning that there are some designs that choose to avoid interrupts and this would remove that choice?

@jenmwms Yes it would require non-interrupt-based designs to implement interrupts. If Zephyr has support for designs that choose to avoid interrupts, then this is not a viable solution.

I have added solution no. 3 which may be more appropriate.

tautologyclub commented 4 years ago

Well let the app developer do as she wishes, but zephyr components using poll_in should definitely 100% be discouraged imo.

carlescufi commented 4 years ago

@pabigot FYI, since you've been working on this.

zephyrbot commented 9 months ago

Hi @ceolin,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@vanti you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!