Enabled support for is31fl3733 driver. This driver supports
the full LED API, and enables the following features of the is31fl3733:
- individual LED dimming
- individual LED enable/disable
- bulk writes of LED enabled and dimming states
- global LED current limit
- blanking (via custom API)
Signed-off-by: Daniel DeGrasse <daniel@degrasse.com>
The set_brightness function of the led_pwm driver uses a default PWM
period (defined in the pwms DT property) to compute a pulse passed to
the pwm_set_pulse_dt function. If this default period is greater than
2^32/100 nanoseconds (about 43 milliseconds) then the calculation may
overflow.
This patch prevents this overflow by running the pulse computation under
a cast with a larger type (uint64_t).
Reported-by: Scott Worley <scott.worley@microchip.com>
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
The IS31FL3216A is a fun light LED controller. The LED current of each
channel can be set in 256 steps by adjusting the PWM duty cycle through
an I2C interface.
Signed-off-by: Guy Morand <guy.morand@bytesatwork.ch>
Adding device power management for the ti lp5569 led controller driver.
Allow the option to either use device power managemnt while keeping the
voltage on or to use device power management including using e.g. a voltage
domain that controls the led controller voltage on-demand.
Signed-off-by: Jonas Remmert <j.remmert@phytec.de>
Add a minimal driver for the ti lp5569 led controller. The driver supports
multiple instances. Commands on|off|set_brightness are supported.
Signed-off-by: Jonas Remmert <j.remmert@phytec.de>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The help text indicates the range of value is 0-255, while the actual
maximum value acceptable is 100.
This commit updates the text to accurately reflect the acceptable
value range for the set_brightness API.
Signed-off-by: Chen Xingyu <hi@xingrz.me>
MISRA Rule 5.7 requires uniqueness of tag identifiers. Shell is
frequently problematic because many code uses `const struct shell
*shell`. This causes CI noise every time one of these shell files is
edited, so let's update all of them with `const struct shell *sh`
instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Unify the drivers/*/Kconfig menuconfig title strings to the format
"<class> [(acronym)] [bus] drivers".
Including both the full name of the driver class and an acronym makes
menuconfig more user friendly as some of the acronyms are less well-known
than others. It also improves Kconfig search, both via menuconfig and via
the generated Kconfig documentation.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Implement a LED driver for Microchip XEC using the breathing,
blinking LED controller. The driver supports LED on, off, and
blink API's. The BBLED block uses the 32768 Hz clock domain
allowing the module to operate in light and deep sleep states.
Blink frequency is 32768 divided by 256 * (prescale + 1) where
prescale is a 12-bit value. Duty cycle is specified by an 8-bit
value where 0 = full off, 127 is 50%, and 255 is full on.
Signed-off-by: Jay Vasanth <jay.vasanth@microchip.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>
Toward deprecated DT_LABEL() macro, replace the handful of cases
that use DT_LABEL(node) with DT_PROP(node, label).
Signed-off-by: Kumar Gala <galak@kernel.org>
* Utilize DT_HAS_<COMPAT>_ENABLED for devicetree based drivers
* Move to using select I2C' instead of 'depends on'
(see commit df81fef944 for
more details)
Signed-off-by: Kumar Gala <galak@kernel.org>
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>
In order to be consistent with what is possible in Devicetree, always
take a period in nanoseconds. Other scales or units may be specified by
using, e.g., the PWM_MSEC() macros (all of them converting down to
nanoseconds). This change then deletes the "_nsec" and "_usec" versions
of the pwm_set call.
Note that this change limits the period to UINT32_MAX nanoseconds,
~4.3s. PWM is, in generali, used with periods below the second so it
should not be a problem.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify the driver by using pwm_dt_spec.
TODO: decide if pwm_dt_spec should also store period.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
