Move the syscall_handler.h header, used internally only to a dedicated
internal folder that should not be used outside of Zephyr.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
If the underlying PWM device does not have a PM callback,
the PWM LED driver will flood the console with error logs.
The change ignores the error if there is no PM callback
for the PWM device.
Signed-off-by: Dennis Grijalva <dennisgrijalva@meta.com>
The PCA9633 i2c LED controller offers an All Call address in its nominal
operation, allowing simultaneous communication with all instances present
on the same i2c bus. The default address is 0x70. While this functionality
is convenient, it is possible that the board uses another i2c component
that also uses this address (for example, the shtcx). In such cases, the
address conflict prevents the proper functioning of the system.
The idea is to add a "disable-allcall" property to the device tree. If this
option is present, the initialization of the PCA9633 forces the bit 0
(ALLCALL) to be set to false, thereby disabling this function. It is
necessary to add this property to all PCA9633 devices on the bus to free up
the address 0x70.
Signed-off-by: Steve Jacot-Guillarmod <steve@piziwate.net>
The controller and the driver support two hardware configurations:
- one three-channel (RGB) LED
- or three single-channel LEDs
Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
The led identifer should refer to devicetree ordering, not to the index
used by the controller. This way, it will be possible to deactivate
some leds or to reorganize the indexing if necessary.
Signed-off-by: Mathieu Anquetin <mathieu.anquetin@groupe-cahors.com>
Some boards may have connected the enable pin of the chipset to a GPIO.
On these boards, it is necessary to configure and set this GPIO before
using the chipset, otherwise the I2C circuitry is disabled.
Based on initial work from:
- Marek Janus <marek.janus@grinn-global.com>
- Rico Ganahl <rico.ganahl@bytesatwork.ch>
Signed-off-by: Mathieu Anquetin <mathieu.anquetin@groupe-cahors.com>
The LP50XX family has a specific register to reset the configuration to
default state from any other state. Use this instead of relying on the
manual configuration of registers during startup.
Based on initial work from: Marek Janus <marek.janus@grinn-global.com>
Signed-off-by: Mathieu Anquetin <mathieu.anquetin@groupe-cahors.com>
Add support for LP5009, LP5012, LP5018 and LP5024 devices which only
differ by the number of LEDs they can control.
Also, update application sample to run on all these new supported
devices.
Based on initial work from:
- Marek Janus <marek.janus@grinn-global.com>
- Rico Ganahl <rico.ganahl@bytesatwork.ch>
Signed-off-by: Mathieu Anquetin <mathieu.anquetin@groupe-cahors.com>
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>
According to Kconfig guidelines, boolean prompts must not start with
"Enable...". The following command has been used to automate the changes
in this patch:
sed -i "s/bool \"[Ee]nables\? \(\w\)/bool \"\U\1/g" **/Kconfig*
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to align with macros used to obtain a device reference (e.g.
DEVICE_DT_GET), align the PM macros to use "GET" instead of "REF". This
change should have low impact since no official release has gone out yet
with the "REF" macros.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The device PM subsystem _depends_ on device, not vice-versa. Devices
only hold a reference to struct pm_device now, and initialize this
reference with the value provided in Z_DEVICE_DEFINE. This requirement
can be solved with a forward struct declaration, meaning there is no
need to include device PM headers.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since drivers implement a callback based on action and not the state,
we should be using the API based on the action instead of the one based
on the state.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
