The SoC, driver, and board support for the CC2650 and CC2650 Sensortag
aren't currently supported and we are removing them as such. If anyone
is interesting in supporting this platform we can easily recovery it
from git.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
This header is found on TI LaunchPad development kits and BoosterPack
expansion modules. This binding allows boards to define mappings from
header pins to device GPIOs.
Signed-off-by: Brett Witherspoon <spoonb@cdspooner.com>
Add driver for the Texas Instruments LMP90xxx series of multi-channel,
low-power 16-/24-bit sensor analog frontends (AFEs).
The functionality is split into two drivers; an ADC driver and a GPIO
driver.
Tested with LMP90080 and LMP90100.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
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>
NXP's LPC family of MCU's GPIOs parameters is udated.
Boards LPC54xxx and LPC55xxx have updated values according
pin and interrupt layout.
Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
Provide a clear description of the how the binding maps nexus parent
pin indexes to header pin locations. Also use the standard name "Uno"
when identifying the header physical layout, contrasted with Mega/Due
which is a different physical layout.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Unlike most other GPIO controllers which support 32 pins this device
only supports 16. (There is an SX1508B that has 8 pins, but the
driver doesn't support it.)
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
All 96Boards complying to the IE spec exposes either 40pin or 30pin
standard low speed connectors for peripheral connectivity. These
connectors are well defined and available in the IE spec. So, lets
create a devicetree binding for the 40pin header for the 1.8v IE
96Boards. This binding will be utilized by the 96Boards
for exposing the GPIO pins as nexus node as per the devicetree spec.
This will allow the shields and applications to use board independent
GPIO mapping.
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
All 96Boards complying to the IE spec exposes either 40pin or 30pin
standard low speed connectors for peripheral connectivity. These
connectors are well defined and available in the IE spec. So, lets
create a devicetree binding for the most commonly used 30pin header
for the 3.3v IE 96Boards. This binding will be utilized by the 96Boards
for exposing the GPIO pins as nexus node as per the devicetree spec.
This will allow the shields and applications to use board independent
GPIO mapping.
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
With https://github.com/zephyrproject-rtos/zephyr/pull/20185, multi-line
descriptions will be formatted nicely, but using '>' breaks it, because
it removes internal newlines (including between paragraphs).
See https://yaml-multiline.info/.
Replace 'description: >' with 'description: |' to encourage '|'. That'll
prevent '>' from getting copied around and messing up long descriptions.
This will lead to some extra newlines in the output, but it's fine.
Line-wrapping messes up any manual formatting.
The replacement was done with
$ git ls-files 'dts/bindings/*.yaml' | \
xargs sed -i 's/description:\s*>/description: |/'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Add binding for arm,mps2-fpgaio-gpio and update device tree and change
FPGA GPIO init code to utilize device tree defines.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Implement a nice generalization suggested by Bobby Noelte.
Instead of having a generic #cells key in bindings, have source-specific
*-cells keys. Some examples:
interrupt-cells:
- irq
- priority
- flags
gpio-cells:
- pin
- flags
pwm-cells:
- channel
- period
This makes bindings a bit easier to read, and allows a node to be a
controller for many different 'phandle-array' properties.
The prefix before *-cells is derived from the property name, meaning
there's no fixed set of *-cells keys. This is possible because of the
earlier 'phandle-array' generalization.
The older #cells key is supported for backwards compatibility, but
generates a deprecation warning.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Use the new 'compatible:', 'include:', and 'required:' keys, and clean
it up like other bindings.
Shorten the 'description:' text, because it appears in the output as a
comment above the generated macros, and it looks neater.
Fixes: #19385
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>
The arc_iot.dtsi used "intel,qmsi-ss-gpio" and "intel,qmsi-ss-i2c"
compatiables, however we have no drivers for these and it seems wrong
that the ARC platform would utilize such compatiables. Remove the
compatiable fields for now (proper one's can be added when there are I2C
and GPIO drivers for this platform).
Also remove the binding files associated with "intel,qmsi-ss-gpio" and
"intel,qmsi-ss-i2c" as nothing in tree utilizes them.
Fixes: 19227
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
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>
Sanity-checking each !included file separately was inherited from the
old scripts. It makes it messy to check that combinations of fields make
sense, e.g. to check 'const:' or 'default:' against 'type:', since those
fields might come from different files (this is handy, since it makes
sense to just add/change a 'const:' value, for example).
Drop the requirement that each !included file is a complete binding in
itself, and treat them as binding fragments instead. Only check the
final merged binding.
This also means that !included files no longer need to have a
'description:' or 'title:' (those have always been unused for !included
files), so remove those, and add comments that explain what the
fragments are for instead. That should demystify bindings a bit.
Also fix the descriptions of i2c.yaml, i2s.yaml, spi.yaml, and
uart.yaml. They're for controllers, not devices. These are copy-paste
error from the corresponding device .yaml files.
Piggyback some indentation consistency nits in binding-template.yaml.
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>
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>
Introduce a gpio.yaml that GPIO controller bindings should inherit
from. gpio.yaml defines the properties "gpio-controller" and
"#gpio-cells" which all gpio controllers should have.
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>
I'm guessing STM32 GPIO nodes don't generate interrupts, because I can't
find any device tree nodes with 'compatible = "st,stm32-gpio"' and an
'interrupts' property.
Remove the required 'interrupts' property from the binding. This fixes a
bunch of errors in
https://github.com/zephyrproject-rtos/zephyr/issues/17532.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Since the nxp,imx-gpio binding is shared between i.MX and i.MX-RT SoC
the 'rdc' property needs to be optional (as it doesn't make sense on the
RT SoCs).
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
A number of dts bindings mark 'interrupts' as a required property when
in fact they are not for those devices. Remove the 'required' setting
and just have 'interrupts' as 'optional'.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
We removed support for cell_string some time ago, so we have some stale
references in a number of bindings that we can remove.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
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>
Dts Nodes for all the GPIO portswere defined. In addition,
a new binding file was created for the gpio driver.
Signed-off-by: Francisco Munoz <francisco.munoz.ruiz@intel.com>
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>
Add initial support for the TI CC13x2 / CC26x2 series with the CC2652R
and CC1352R SoCs. The UART and GPIO peripherals are supported. Drivers
use the driverlib HAL from the TI CC13x2 / CC26x2 SDK.
Signed-off-by: Brett Witherspoon <spoonb@cdspooner.com>
The GPIO driver for the Intel Apollo Lake has so many pins it has to
export ten devices to shoehorn its one device into the GPIO API. The
current implementation uses the shared IRQ driver because these
pseudodevices all share one IRQ. However, since the GPIO driver is
aware of all the possible interrupt sources, it's smaller and faster
(and not even messy) to handle it internally, so this patch eliminates
the dependency on the shared IRQ driver.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Enable the clock for GPIO ports on the RV32M1 SoC before attempting to
access the port controller registers.
Fixes: #15339
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
To avoid confusion, callbacks using ordinal pin numbers
is going to be reverted. So the driver has to be re-worked
to expose multiple devices so each device has 32 pins.
Also fixes#12765
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Kumar Gala