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>
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>
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>
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>
Right now "lp5562_led_blink" unconditionally find and assign a engine
that is not executing at the moment. This is an issue, if 3 "led" are
already using an engine. That is a call to "lp5562_led_blink" could
terminate with error, even if the "led" is already using an engine.
This commit fixes this issue by adding a check to see if engine is
linked and reuse it, otherwise assign a free engine.
Signed-off-by: Anuj Pathak <anuj@croxel.com>
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>
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>
Convert led drivers to use new DT variants of the DEVICE APIs.
DEVICE_AND_API_INIT -> DEVICE_DT_DEFINE
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Kernel timeouts have always been a 32 bit integer despite the
existence of generation macros, and existing code has been
inconsistent about using them. Upcoming commits are going to make the
timeout arguments opaque, so fix things up to be rigorously correct.
Changes include:
+ Adding a K_TIMEOUT_EQ() macro for code that needs to compare timeout
values for equality (e.g. with K_FOREVER or K_NO_WAIT).
+ Adding a k_msleep() synonym for k_sleep() which can continue to take
integral arguments as k_sleep() moves away to timeout arguments.
+ Pervasively using the K_MSEC(), K_SECONDS(), et. al. macros to
generate timeout arguments.
+ Removing the usage of K_NO_WAIT as the final argument to
K_THREAD_DEFINE(). This is just a count of milliseconds and we need
to use a zero.
This patch include no logic changes and should not affect generated
code at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Re-run with updated script to convert integer literal delay arguments to
k_sleep to use the standard timeout macros.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
move led.h to drivers/led.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
move i2c.h to drivers/i2c.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
According to datasheet, there needs to be a minimum of 488µs
between each write to Enable register
Signed-off-by: Alexander Svensen <alsv@nordicsemi.no>
Change code from using now deprecated DT_<COMPAT>_<INSTANCE>_<PROP>
defines to using DT_INST_<INSTANCE>_<COMPAT>_<PROP>.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Since the lp5562 led driver still supports both DTS and non-DTS
configuration, we update the code to use DT_<COMPAT>_<INSTANCE>
defines for the CONFIG_HAS_DTS_I2C case.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add support for TI LP5562 I2C 4-channel LED driver.
Supported blinking period: 1ms - 1000ms
Supported brightness value: 0% - 100%
This driver supports the entire currently available API.
Signed-off-by: Johannes Hutter <johannes@proglove.de>
