Commit graph

7 commits

Author SHA1 Message Date
Kenneth J. Miller e78e8d7c3f drivers: lora: sx126x: Support fine-grained STM32WL PA config
Add STM32WL-specific sx126x_set_tx_params function based on the
STM32CubeWL modifications to LoRaMac-node.

Add the "power-amplifier-output" DT property to
"st,stm32wl-subghz-radio" for selecting between the RFO_LP and RFO_HP
output configurations provided by the above mentioned function.

Add the "rfo-lp-max-power" and "rfo-hp-max-power" DT properties for
defining the maximum design power of the respective outputs' matching
networks.

closes #48511

Signed-off-by: Kenneth J. Miller <ken@miller.ec>
2023-04-24 13:33:25 +02:00
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
Gerard Marull-Paretas fb60aab245 drivers: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:58:21 +02:00
Henrik Brix Andersen d4023b3c1b drivers: gpio: move non-standard dts flags to be soc specific
Reserve the upper 8 bits of gpio_dt_flags_t for SoC specific flags and
move the non-standard, hardware-specific GPIO devicetree flags (IO
voltage level, drive strength, debounce filter) from the generic
dt-bindings/gpio/gpio.h header to SoC specific dt-bindings headers.

Some of the SoC specific dt-bindings flags take up more bits than
necessary in order to retain backwards compatibility with the deprecated
GPIO flags. The width of these fields can be reduced/optimized once the
deprecated flags are removed.

Remove hardcoded use of GPIO_INT_DEBOUNCE in GPIO client drivers. This
flag can now be set in the devicetree for boards/SoCs with debounce
filter support. The SoC specific debounce flags have had the _INT part
of their name removed since these flag must be passed to
gpio_pin_configure(), not gpio_pin_interrupt_configure().

Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
2022-03-10 13:46:34 -05:00
Fabio Baltieri d6731819e3 drivers: sx126x_standalone: use the correct dev_data for dio1 callback
The current code uses dev->data for finding back the instance data
structure in various places, but for the dio1 irq callback, dev refers
to the GPIO device node (not the LORA radio one), so dev->data returns a
pointer to the GPIO data rather than a "struct sx126x_data".

Fix that by using CONTAINER_OF to find back the correct structure from
the callback pointer.

The bug was introduced in:

  74efaa920a drivers: sx126x: refactor few functions for stm32wl support

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
2021-08-16 04:57:41 -04:00
Fabio Baltieri 2916133b06 drivers: sx126x_standalone: convert to gpio_dt_spec APIs
Convert the standalone part of the sx126x driver to the new gpio_dt_spec
APIs. This allows moving the specific GPIOs in that part of the driver
and out of struct sx126x_data.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
2021-07-15 21:30:28 -04:00
Fabio Baltieri 74efaa920a drivers: sx126x: refactor few functions for stm32wl support
Move few functions around in preparation of adding the STM32WL variant
of the driver.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
2021-07-15 21:30:28 -04:00