Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@...> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://github.com/zephyrproject-rtos/zephyr/pull/25999

To be clear, this PR is limited to nRF SoCs only, it is not a
project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.

I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling
hardware flow control for both UART and UARTE:

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uarte.html#dtbinding-nordic-nrf-uarte
https://docs.zephyrproject.org/latest/reference/devicetree/bindings/serial/nordic%2Cnrf-uart.html#dtbinding-nordic-nrf-uart

Looking at the code, if hw-flow-control is disabled in DTS (the
default), then in both drivers cfg->flow_ctrl is false. The HAL
configuration structure ends up with flow control disabled in that case:

https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uart.c#L346
https://github.com/zephyrproject-rtos/zephyr/blob/5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1/drivers/serial/uart_nrfx_uarte.c#L397

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://github.com/zephyrproject-rtos/zephyr/pull/25999/files#diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7

But it seems like at a board maintainer level, you can leave the SoC
default as-is to make flow control "opt in" as requested.

Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?

It looks like flow control is off by default and it's opt-in; what did I
miss?

Thanks!
Martí

Thanks,
Jamie

Hi Marti,
Let's say there is a board (all our boards are Nordic-based so this applies to all of them) which has a UART brought out to a header, the UART might be used for a multitude of things, it could be a debug port which is mostly unused, or it could be connected to a PC for exchanging a lot of data, or it could be connected to a shield, perhaps a modem, which does not have flow control pins - this is one board (and one .dts file) but with different requirements for flow control, in the old system this worked fine and flow control could be enabled or disabled on a per-project configuration or even by board/shield overlays (one board but many different projects). With the new system, that isn't possible, this requires unique board .dts files because you can no longer disable or enable flow control via a Kconfig option (yet strangely parity is still a Kconfig option, the change itself doesn't really make sense to me).
The issue is not that it is opt-in or opt-out, the issue is that it is opt-in at a DTS level (and thus a board level) and not opt-in at a project level. If we enable flow control for our board, we need to add overlays to every sample project for all of our boards whereby flow control isn't needed which becomes a mess.
Thanks,
Jamie

Hi Jaime,

Jamie Mccrae <Jamie.Mccrae@...> writes:

Hi Marti,
Let's say there is a board (all our boards are Nordic-based so this
applies to all of them) which has a UART brought out to a header, the
UART might be used for a multitude of things, it could be a debug port
which is mostly unused, or it could be connected to a PC for
exchanging a lot of data, or it could be connected to a shield,
perhaps a modem, which does not have flow control pins - this is one
board (and one .dts file) but with different requirements for flow
control, in the old system this worked fine and flow control could be
enabled or disabled on a per-project configuration or even by
board/shield overlays (one board but many different projects). With
the new system, that isn't possible, this requires unique board .dts
files because you can no longer disable or enable flow control via a
Kconfig option

I think we might be talking past each other but I think I'm finally
getting what you mean.

It does sound like we agree that:

- dts/arm/nordic/*.dtsi sets hw-flow-control to 'false' by default,
meaning flow control is opt-in at the SoC level

- boards/arm/.../BOARD.dts files can still set per-board defaults for
hw-flow-control for each uart node, so it's up to the board maintainer
to decide if they want to change that default

- each 'project' (Zephyr application) can still change that using a DTS
overlay

(yet strangely parity is still a Kconfig option, the
change itself doesn't really make sense to me).

I agree that seems like some future work to move to DT but it was
probably out of scope for PR #25999. I'll leave it to Krzysztof to
comment on whether he'll be moving parity to DT also.

The issue is not that it is opt-in or opt-out, the issue is that it is
opt-in at a DTS level (and thus a board level) and not opt-in at a
project level. If we enable flow control for our board, we need to add
overlays to every sample project for all of our boards whereby flow
control isn't needed which becomes a mess.

The Kconfig options that are gone now were per-instance
(UART_0_NRF_FLOW_CONTROL, UART_1_NRF_FLOW_CONTROL, etc.), so I'm still
confused about what you were doing that used to work on a "project" wide
basis that no longer does.

If you were doing something like this in <app>/Kconfig:

config UART_1_NRF_FLOW_CONTROL
default y if BOARD_MY_BOARD

source "Kconfig.zephyr"

Then you can just move that same setting to <app>/boards/my_board.overlay.

If you were doing something like this:

config UART_1_NRF_FLOW_CONTROL
default y if SOC_FAMILY_NRF

source "Kconfig.zephyr"

Then unless *all* of your boards use UART 1 in the same way for that
purpose, this seems like an unsafe thing to do.

So I still don't get what you are trying to say; can you please provide
a sample of what you were doing before to make this concrete?

Thanks,
Martí

Thanks,
Jamie

-----Original Message-----
From: Bolivar, Marti <Marti.Bolivar@...>
Sent: 13 May 2021 17:11
To: Jamie Mccrae <Jamie.Mccrae@...>; devel@...
Cc: Chruściński, Krzysztof <Krzysztof.Chruscinski@...>
Subject: Re: [Zephyr-devel] Review of concept of changing UART flow control from Kconfig to DTS config

EXTERNAL EMAIL: Be careful with attachments and links.

Hi (and +Krzysztof in Cc),

"lairdjm via lists.zephyrproject.org"
<jamie.mccrae=lairdconnect.com@...> writes:

Hi,
I only noticed today that the Kconfig option for enabling hardware
flow control on UARTs, which used to be an optional Kconfig option,
was removed and replaced with a DTS boards file configuration option
instead, as per
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839519950%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0W%2B%2BfqwljQG6qjP9QMhB8iurIcO7XVWYSWflTzQzr4o%3D&amp;reserved=0

To be clear, this PR is limited to nRF SoCs only, it is not a project-wide change.

I find this to be a bit of a step backwards for application
development, we have many boards in zephyr that we and customers use,
these boards might be used for something simple like a sensor or might
be used alongside a PC for doing some heavy processing and message
passing over Bluetooth, so with a sensor, the log system might be
active but it won't have anything connected to it most of the time
unless there's an issue, so flow control is not required here, if it's
enabled then it's going to cause an issue once the UART buffer gets
full. However, on a PC communications module, that would be using the
UART constantly, and need data integrity so needs flow control - in
the old system, the boards file would have the flow control pins and
it would be disabled by default, a project could enable it with a
Kconfig option, this was great. However with the new system, it seems
that we need to force flow control on all our boards, and then in
instances where it's not needed, have an overlay for that specific
board (and we have many boards) to delete the hardware flow control
part. This means that to enable hardware flow control, we need to
update our boards file then add an overlay to almost every sample
application in zephyr for most of our boards to disable flow control.
This seems a bit chaotic to me so I would like to revisit this concept
of having flow control configurable as a Kconfig option, the pins
should be defined in the DTS file which hasn't changed but if flow
control is needed or not should be controlled on a project basis, opt
in not opt out.

I'm having a bit of trouble understanding what you mean here.

The boolean hw-flow-control property is still available for enabling hardware flow control for both UART and UARTE:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uarte.html%23dtbinding-nordic-nrf-uarte&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=C9EI5WbaHSkWuLTC2UWStIEy3Ci%2Fu%2BzfHMYs25tJbOo%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.zephyrproject.org%2Flatest%2Freference%2Fdevicetree%2Fbindings%2Fserial%2Fnordic%252Cnrf-uart.html%23dtbinding-nordic-nrf-uart&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=p7RxoZRshUR6g4G%2BObmjzpwCkY4CmULrwJPMewLTbD0%3D&amp;reserved=0

Looking at the code, if hw-flow-control is disabled in DTS (the default), then in both drivers cfg->flow_ctrl is false. The HAL configuration structure ends up with flow control disabled in that case:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uart.c%23L346&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NPYYVLZDGn51OzWHL7gCJzh1k4K8IO2tNYmXlKU6OcI%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fblob%2F5f5fb7d7925be3b40b4a963b11fb8b4cfedf03a1%2Fdrivers%2Fserial%2Fuart_nrfx_uarte.c%23L397&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vJEoEuuSIBa6kdW7RmFttrB8BePBXVSjW%2BLrnSxGyso%3D&amp;reserved=0

So flow control at a SoC level seems to be turned off by default.

It's true that many boards in PR #25999 do enable it by default, e.g.
nRF52840-DK:

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzephyrproject-rtos%2Fzephyr%2Fpull%2F25999%2Ffiles%23diff-f496b12068cf78fdbb22c1b8a4eaeb66010db95b4e80db7377a340ae30a83519R7&;data=04%7C01%7CMarti.Bolivar%40nordicsemi.no%7C5c1be122bb954defc40408d916c23c8e%7C28e5afa2bf6f419a8cf6b31c6e9e5e8d%7C0%7C0%7C637565846839529903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gxlorGb5sNWseWeGo%2BlxMxcq0s%2F87Vx76MjrZQxfM9k%3D&amp;reserved=0

But it seems like at a board maintainer level, you can leave the SoC default as-is to make flow control "opt in" as requested.

Are there any thoughts on this subject and how to get this working,
focused on ease of being able to set this for ours and customer's
reuse?

It looks like flow control is off by default and it's opt-in; what did I miss?

Thanks!
Martí

Thanks,
Jamie

THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.