BLE SW controller PA/LNA pins configuration in device tree

[hubertmis]

It looks that currently there are two ways to define PA/LNA pins for radio drivers in Zephyr. One of them is device tree like here:

zephyr/boards/arm/nrf21540dk_nrf52840/nrf21540dk_nrf52840.dts

Line 113 in 1b680c8

nrf_radio_fem: nrf21540_fem {

or https://github.com/nrfconnect/sdk-nrf/tree/master/dts/bindings/radio_fem . The other one is to use Kconfig like here:

zephyr/subsys/bluetooth/controller/Kconfig.ll_sw_split

Line 549 in 1b680c8

menuconfig BT_CTLR_GPIO_PA

I think it should be unified and the device tree seems like a better place to define pin numbers.

I would like Software BLE Controller to use pins description in the device tree and deprecate pins description in Kconfig.

[cvinayak]

This is a welcome request. If anyone with better knowledge to port Kconfig define used, to using the devicetree then its quicker to have this enhancement.

[hubertmis]

While developing FEM support for 802.15.4 we have gained enough knowledge to port Generic and Skyworks FEM bindings https://github.com/nrfconnect/sdk-nrf/tree/master/dts/bindings/radio_fem to Zephyr. However, we don't have enough knowledge about BLE Controller to help start using DTS description in this module. I think a good starting point could be an example how MPSL is using DTS to configure FEMs:
https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/mpsl/Kconfig.fem
https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/mpsl/mpsl_fem.c

[carlescufi]

This is probably related to #31336, which I think @cvinayak would like to complete soon.

[mbolivar-nordic]

Happy to pick this up, but it looks like #31336 may already have an owner who will take this over. I'm going to leave this alone unless I hear otherwise and work on other DT related conversions in our IPs.

[mbolivar-nordic]

@hubertmis I have reviewed the existing materials and I have a proposal for how to proceed.

I think the request is for me to write a single DT binding that will apply to the Skyworks 66112 device and other similar devices, as well as the nRF21540 and potentially other Nordic FEMs. I think that has to be the case since we want to be able to use all of these devices as a FEM within the split controller code in a generic way as we do now.

In order to do this in an upstream-friendly way, this will require some changes to our downstream bindings, linked here for context:

• https://github.com/nrfconnect/sdk-nrf/blob/master/dts/bindings/radio_fem/generic-fem-two-ctrl-pins.yaml
• https://github.com/nrfconnect/sdk-nrf/blob/master/dts/bindings/radio_fem/skyworks%2Csky66112-11.yaml
• https://github.com/nrfconnect/sdk-zephyr/blob/master/dts/bindings/net/wireless/nordic%2Cnrf21540-fem.yaml

The issue is that available documents use different terms:

Re: CONFIG_BT_CTLR_GPIO_PA_PIN:

• generic-fem-two-ctrl-pins.yaml and skyworks,sky66112-11.yaml seem to call this "ctx-gpios"
• nordic,nrf21540-fem.yaml seems to call this "tx-en-gpios"
• the docs for the MPSL library which consumes these refers to this as the "PA" pin, like the existing Zephyr Kconfig option

Re: CONFIG_BT_CTLR_GPIO_LNA_PIN:

• generic-fem-two-ctrl-pins.yaml and skyworks,sky66112-11.yaml seem to call this "crx-gpios"
• nordic,nrf21540-fem.yaml seems to call this "rx-en-gpios"
• MPSL refer to this as the "LNA" pin, like the existing Zephyr Kconfig option

We need to standardize property names in the upstream binding. I suggest:

# generic-two-pin-fem.yaml
properties:
  pa-gpios:
        type: phandle-array
        required: true
        description: |
          Configuration for the power amplifier enable pin. For
          example, to use an active-high pin 3 on GPIO controller
          gpio1, write the following:

            pa-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;

          This pin should be activated during transmission, and
          deactivated during reception.

  lna-gpios:
        type: phandle-array
        required: true
        description: |
          Configuration for the low noise amplifier enable pin. This
          should be written in the same way as pa-gpios.

          This pin should be activated during reception, and
          deactivated during transmission.

# nordic,nrf21540.yaml
compatible: "nordic,nrf21540.yaml"
include: generic-two-pin-fem.yaml
description: |
  The SoC GPIO controlling the TX_EN pin of the nRF21540 should
  be set via the pa-gpios property. Similarly, RX_EN should be
  set via lna-gpios.
properties:
  # device-specific properties, e.g. 'pdn-gpios', ...

# skyworks,sky66112-11.yaml
compatible: "skyworks,sky66112-11"
include: generic-two-pin-fem.yaml
description: |
  The SoC GPIO controlling the CTX pin of the SKY66112-11 should
  be set via the pa-gpios property. Similarly, CRX should be
  set via lna-gpios.
properties:
  # device-specific properties ...

That is, the binding would standardize on the terms "PA" and "LNA", like the Kconfig option does now.

Developers using the device-specific bindings would need to change terms from what their datasheets use to fit in this framework E.g. CTX becomes PA for Skyworks, and RX_EN becomes LNA for nRF21540.

Work for you?