The lp5569 features a double functioning pin for enable and pwm control.
The chip, however, uses the first rising edge to initialize and get ready
for i2c communication, and then the pin alters function to pwm mode.
Add support for providing enable-gpios to the lp5569 in the dts, which
will make sure to assert the pin and wait for the chip to initialize
before attempting further configuration of the chip.
Signed-off-by: Emil Juhl <emdj@bang-olufsen.dk>
The lp5569 controller contains an internal charge pump which can be useful
for driving LEDs with a forward voltage greater than the lp5569 supply.
Taking advantage of the charge pump can alleviate the need for an external
boost converter.
Add a dts property, charge-pump-mode, to the ti,lp5569 binding with which
the cp_mode bits of the MISC register will be configured.
Following the datasheet, the possible configurations are:
0x00 -> disabled (default)
0x01 -> 1x mode
0x10 -> 1.5x mode
0x11 -> auto mode
Signed-off-by: Emil Juhl <emdj@bang-olufsen.dk>
Add support for the IS31FL3194 3-channel LED driver. This driver can be
configured to handle its outputs as either a single RGB LED or (up to)
three independent LEDs.
Signed-off-by: Luca Burelli <l.burelli@arduino.cc>
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>
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>
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>
This patch adds a description section for the pwms property of the PWM
LED child node. This intends to explain how the period field is used by
the led_pwm driver and to help with its configuration.
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>
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>
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>
DTS property attributes are (by default) not required.
Explicitly specifying `required: false` is redundant.
Perhaps a warning to that effect would be useful.
Signed-off-by: Chris Friedt <cfriedt@meta.com>
The gpio-leds binding is meant for LED drivers, not GPIO. As in Linux,
move the binding to the led folder.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
All in tree device drivers use some form of DEVICE_DT_GET
so we no longer need to require label properties.
Signed-off-by: Kumar Gala <galak@kernel.org>
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>
Convert the keyscan portion of the Holtek HT16K33 driver to adhere to
the kscan API instead of the GPIO API.
When this driver was introduced the kscan API was not present. The
keyscan driver was therefore implemented as a GPIO interrupt driver.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
This patch adds a label property to the PWM LED parent node and fixes
the label property description of the child node. Indeed it is the label
of a parent node which can be used as device_get_binding() parameter to
retrieve the LED device, and not the one of a child node.
Fixes#34275
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
This patch adds a DTS binding for the Texas Instruments LP5030 and
LP5036 I2C LED controllers. They are respectively providing up to 30
and 36 channels (i.e. 10 or 12 RGB LEDs).
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
The led-controller DT binding gathers some common properties for LED
controllers and for the LED child nodes.
One notable property is "color-mapping" which allows to define a channel
to color mapping for multicolor LEDs.
Signed-off-by: Simon Guinot <simon.guinot@seagate.com>
Signed-off-by: Maxime Bittan <maxime.bittan@seagate.com>
The value of a label property isn't really the name of an API. It's
the name of a device, as passed to device_get_binding().
Let's just say that directly so people know what this means in
practice instead of what's currently used as the description, which is
harder to understand and not really accurate.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Add any useful information from 'title:' to the 'description:' strings
(e.g. explanations of acronyms), and remove 'title:' as well as any
copy-pasted "this binding gives a ..." boilerplate.
Also clean some description strings up a bit.
Some other things could probably be cleaned up (replacing 'GPIO node'
with 'GPIO controller' on controllers for consistency, for example), but
I kept things close to the original to avoid accidentally messing up.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Deprecate 'sub-node:' and add a more general 'child-binding:' mechanism
to bindings. Keep supporting 'sub-node:', but print a deprecation
warning when it's used.
Like 'sub-node:', 'child-binding:' gives a binding to child nodes, but
the binding is required to be a complete binding, and is treated (and
checked) like a normal binding.
'child-binding:' can in turn contain another 'child-binding:', up to any
number of levels. This is automatic from treating it like a normal
binding, and from the code initializing parent Devices before child
Devices.
This lets nodes give bindings to grandchildren.
For example, take this devicetree fragment:
parent {
compatible = "foo";
child-1 {
grandchild-1 {
...
};
grandchild-2 {
...
};
};
child-2 {
grandchild-3 {
...
};
};
};
The binding for 'foo' could provide bindings for grandchild-1/2/3 like
this:
compatible: "foo"
# Binding for children
child-binding:
title: ...
description: ...
...
# Binding for grandchildren
child-binding:
title: ...
description: ...
properties:
...
Due to implementation issues with the old devicetree scripts, only two
levels of 'child-binding:' is supported for now. This limitation will go
away in Zephyr 2.2.
Piggyback shortening 'description:' and 'title:' in some bindings that
provide child bindings. This makes the generated header a bit neater.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Instead of
child:
bus: foo
parent:
bus: bar
, have
child-bus: foo
parent-bus: bar
'bus' is the only key that ever appears under 'child' and 'parent'.
Support the old keys for backwards compatibility, with a deprecation
warning if they're used.
Also add 'child/parent-bus' tests to the edtlib test suite. It was
untested before.
I also considered putting more stuff under 'child' and 'parent', but
there's not much point when there's just a few keys I think. Top-level
stuff is cleaner and easier to read.
I'm planning to add a 'child-binding' key a bit later (like 'sub-node',
but more flexible), and child-* is consistent with that.
Also add an unrelated test-bindings/grandchild-3.yaml that was
accidentally left out earlier.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Instead of
properties:
compatible:
constraint: "foo"
, just have
compatible: "foo"
at the top level of the binding.
For backwards compatibility, the old 'properties: compatible: ...' form
is still accepted for now, and is treated the same as a single-element
'compatible:'.
The old syntax was inspired by dt-schema (though it isn't
dt-schema-compatible), which is in turn a thin wrapper around
json-schema (the idea is to transform .dts files into YAML and then
verify them).
Maybe the idea was to gradually switch the syntax over to dt-schema and
then be able to use unmodified dt-schema bindings, but dt-schema is
really a different kind of tool (a completely standalone linter), and
works very differently from our stuff (see schemas/dt-core.yaml in the
dt-schema repo to get an idea of just how differently).
Better to keep it simple.
This commit also piggybacks some clarifications to the binding template
re. '#cells:'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The 'category: required/optional' setting for properties is just a
yes/no thing. Using a boolean makes it clearer, so have
'required: true/false' instead.
Print a clear error when 'category:' is used:
edtlib.EDTError: please put 'required: true' instead of 'category:
required' in 'properties: foo: ...' in
test-bindings/sub-node-parent.yaml - 'category' has been removed
The old scripts in scripts/dts/ ignore this setting, and only print a
warning if 'category: required' in an inherited binding is changed to
'category: optional'. Remove that code, since the new scripts already
have the same check.
The replacement was done with
git ls-files 'dts/bindings/*.yaml' | xargs sed -i \
-e 's/category:\s*required/required: true/' \
-e 's/category:\s*optional/required: false/'
dts/binding-template.yaml is updated as well.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Convert type from compound to phandle-array for various bindings that
have properties like like <FOO>-gpios, pwms, clocks,
interrupt-extended, etc. that are phandle-array's.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
* Add "#address-cells" and "#size-cells" to base.yaml as properties
that can exist on any node. Cleanup other bindings that inherit
from the base.yaml.
* Add "status" property with an enum of valid options.
* Add "interrupt-parent" to base.yaml. It's a phandle to the node
which is the interrupt controller for the interrupt.
* Add "interrupt-extended" to base.yaml. Provides a way to specify
an interrupt-parent and specifier in a single property. Useful if
a device has multiple interrupts in which different interrupts go
to different interrult controllers.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
In most cases #<FOO>-cells should be a constant. For example in spi
controller #address-cells should be 1, and #size-cells should be 0.
Use the const attribute to specify such single known values. Add const
value to missing bindings which have cells.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
No binding has anything but 'version: 0.1', and the code in scripts/dts/
never does anything with it except print a warning if it isn't there.
It's undocumented what it means.
I suspect it's overkill if it's meant to be the binding format version.
If we'd need to tell different versions from each other, we could change
some other minor thing in the format, and it probably won't be needed.
Remove the 'version' fields from the bindings and the warning from the
scripts/dts/ scripts.
The new device tree script will give an error when unknown fields appear
in bindings.
The deletion was done with
git ls-files 'dts/bindings/*.yaml' | xargs sed -i '/^\s*version: /d'
Some blank lines at the beginning of bindings were removed as well.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Now that the generation script doesn't look at the "generation" in the
YAML, we can remove it from the binding files.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Several bindings have an expectation of sub-nodes that describe the
actual infomation. The sub-nodes don't have any compatiable so we can't
key on that.
So we can add the concept of a sub-node to the YAML to handle cases like
'gpio-keys', 'gpio-leds', 'pwm-leds', etc..
The sub-node in the YAML is effective the "binding" params that describe
what properties should exist in the sub-node.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
YAML document separators are needed e.g. when doing
$ cat doc1.yaml doc2.yaml | <parser>
For the bindings, we never parse concatenated documents. Assume we don't
for any other .yaml files either.
Having document separators in e.g. base.yaml makes !include a bit
confusing, since the !included files are merged and not separate
documents (the merging is done in Python code though, so it makes no
difference for behavior).
The replacement was done with
$ git ls-files '*.yaml' | \
xargs sed -i -e '${/\s*\.\.\.\s*/d;}' -e 's/^\s*---\s*$//'
First pattern removes ... at the end of files, second pattern clears a
line with a lone --- on it.
Some redundant blank lines at the end of files were cleared with
$ git ls-files '*.yaml' | xargs sed -i '${/^\s*$/d}'
This is more about making sure people can understand why every part of a
binding is there than about removing some text.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Move common properties like 'compatible', 'reg', 'reg-names',
'interrupts', 'interrupt-names', and 'label' into one common base.yaml
that all the other yaml's can inherit from. This removes both
duplication and inconsistent definition.
The device specific yamls just need to say if a property is 'required'
or not.
NOTE: due to some generation conflicts we did not covert
'soc-nv-flash.yaml' to use base.yaml.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
The HT16K33 is a memory mapping, multifunction LED controller
driver. The controller supports up to 128 LEDs (up to 16 rows and 8
commons) and matrix key scan circuit of up to 13x3 keys.
This commit adds support for the keyscan functionality of the HT16K33.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
The HT16K33 is a memory mapping, multifunction LED controller
driver. The controller supports up to 128 LEDs (up to 16 rows and 8
commons) and matrix key scan circuit of up to 13x3 keys.
This commit add support for the LED driver functionality of the
HT16K33.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
The 'id' field was never used and tended to just have the compat of the
node. Lets remove it and removed some code in extract_dts_includes.py
related to it. Added a warning if 'id' is set in a yaml so we can
remove it going forward.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
