Commit graph

11 commits

Author SHA1 Message Date
Benjamin Cabé
f72942067a drivers: led: fix LED_BRIGTHNESS_MAX typo
Renames LED_BRIGTHNESS_MAX to LED_BRIGHTNESS_MAX in led.h and all
in-tree users of the macro.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
2025-06-09 14:50:33 -07:00
Fabio Baltieri
ac1dec0498 led: drop led_context.h
led_context.h contains a single struct with max and min period, current
drivers that use it have hardcoded values and they set it at init.

This data is not used anywhere, and it makes very little sense to use
some SRAM for it.

Hardcode the limit for each driver and drop the struct and file.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-22 02:21:51 +02:00
Fabio Baltieri
62c1fb2097 led: drop min/max brightness from struct led_data
This is always 0 to 100, hardcode the range.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Fabio Baltieri
69e739359f led: check for valid brightness range at API level
The API specifies that brightness is 0 to 100, no point checking it in
the individual drivers.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Fabio Baltieri
551c1363dd led: add and use a LED_BRIGTHNESS_MAX definition
The led_set_brightness API says that brightness is defined as
percentage, add a macro from the max and use it everywhere.

Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
2025-05-14 16:27:18 +02:00
Yishai Jaffe
c09930ed30 drivers: led: Place API into iterable section
Add wrapper DEVICE_API macro to all led_driver_api instances.

Signed-off-by: Yishai Jaffe <yishai1999@gmail.com>
2024-12-02 22:07:36 +00: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
Benjamin Björnsson
21cf889c87 drivers: led: tlc59108: Update driver to use i2c_dt_spec
Simplify driver by using i2c_dt_spec for bus access.

Signed-off-by: Benjamin Björnsson <benjamin.bjornsson@gmail.com>
2022-07-18 18:42:52 +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
Nazar Kazakov
9713f0d47c everywhere: fix typos
Fix a lot of typos

Signed-off-by: Nazar Kazakov <nazar.kazakov.work@gmail.com>
2022-03-14 20:22:24 -04:00
John Kjellberg
f452a086fb drivers: led: Add LED driver support for TLC59108
Add support for TI TLC59108 an I2C 8-bit LED driver.
Supported blinkink period: 41ms to 10730ms
Supported brightness value: 0 to 100%

This driver supports the following APIs:

1. led_blink
2. led_set_brightness
3. led_on
4. led_off

This is a modified version of the NXP PCA9633 driver.

Signed-off-by: John Kjellberg <kjellberg.john@gmail.com>
2021-08-03 19:03:29 -04:00