Many SPI controllers need to add properties to peripheral devices. This could be the delay in clock or data lines, etc. These properties are controller specific but need to be defined in the peripheral node because they are per-peripheral and there can be multiple peripherals attached to a controller. If these properties are not added to the peripheral binding, then the dtbs check emits a warning. But these properties do not make much sense in the peripheral binding because they are controller-specific and they will just pollute every peripheral binding. So this binding is added to collect all such properties from all such controllers. Peripheral bindings should simply refer to this binding and they should be rid of the warnings. There are some limitations with this approach. Firstly, there is no way to specify required properties. The schema contains properties for all controllers and there is no way to know which controller is being used. Secondly, there is no way to restrict additional properties. Since this schema will be used with an allOf operator, additionalProperties needs to be true. In addition, the peripheral schema will have to set unevaluatedProperties: false. Despite these limitations, this appears to be the best solution to this problem that doesn't involve modifying existing tools or schema specs. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211109181911.2251-2-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
143 lines
3.8 KiB
YAML
143 lines
3.8 KiB
YAML
# SPDX-License-Identifier: GPL-2.0
|
|
%YAML 1.2
|
|
---
|
|
$id: http://devicetree.org/schemas/spi/spi-controller.yaml#
|
|
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
|
|
|
title: SPI Controller Generic Binding
|
|
|
|
maintainers:
|
|
- Mark Brown <broonie@kernel.org>
|
|
|
|
description: |
|
|
SPI busses can be described with a node for the SPI controller device
|
|
and a set of child nodes for each SPI slave on the bus. The system SPI
|
|
controller may be described for use in SPI master mode or in SPI slave mode,
|
|
but not for both at the same time.
|
|
|
|
properties:
|
|
$nodename:
|
|
pattern: "^spi(@.*|-[0-9a-f])*$"
|
|
|
|
"#address-cells":
|
|
enum: [0, 1]
|
|
|
|
"#size-cells":
|
|
const: 0
|
|
|
|
cs-gpios:
|
|
description: |
|
|
GPIOs used as chip selects.
|
|
If that property is used, the number of chip selects will be
|
|
increased automatically with max(cs-gpios, hardware chip selects).
|
|
|
|
So if, for example, the controller has 4 CS lines, and the
|
|
cs-gpios looks like this
|
|
cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>;
|
|
|
|
Then it should be configured so that num_chipselect = 4, with
|
|
the following mapping
|
|
cs0 : &gpio1 0 0
|
|
cs1 : native
|
|
cs2 : &gpio1 1 0
|
|
cs3 : &gpio1 2 0
|
|
|
|
The second flag of a gpio descriptor can be GPIO_ACTIVE_HIGH (0)
|
|
or GPIO_ACTIVE_LOW(1). Legacy device trees often use 0.
|
|
|
|
There is a special rule set for combining the second flag of an
|
|
cs-gpio with the optional spi-cs-high flag for SPI slaves.
|
|
|
|
Each table entry defines how the CS pin is to be physically
|
|
driven (not considering potential gpio inversions by pinmux):
|
|
|
|
device node | cs-gpio | CS pin state active | Note
|
|
================+===============+=====================+=====
|
|
spi-cs-high | - | H |
|
|
- | - | L |
|
|
spi-cs-high | ACTIVE_HIGH | H |
|
|
- | ACTIVE_HIGH | L | 1
|
|
spi-cs-high | ACTIVE_LOW | H | 2
|
|
- | ACTIVE_LOW | L |
|
|
|
|
Notes:
|
|
1) Should print a warning about polarity inversion.
|
|
Here it would be wise to avoid and define the gpio as
|
|
ACTIVE_LOW.
|
|
2) Should print a warning about polarity inversion
|
|
because ACTIVE_LOW is overridden by spi-cs-high.
|
|
Should be generally avoided and be replaced by
|
|
spi-cs-high + ACTIVE_HIGH.
|
|
|
|
num-cs:
|
|
$ref: /schemas/types.yaml#/definitions/uint32
|
|
description:
|
|
Total number of chip selects.
|
|
|
|
spi-slave:
|
|
$ref: /schemas/types.yaml#/definitions/flag
|
|
description:
|
|
The SPI controller acts as a slave, instead of a master.
|
|
|
|
slave:
|
|
type: object
|
|
|
|
properties:
|
|
compatible:
|
|
description:
|
|
Compatible of the SPI device.
|
|
|
|
required:
|
|
- compatible
|
|
|
|
patternProperties:
|
|
"^.*@[0-9a-f]+$":
|
|
type: object
|
|
|
|
allOf:
|
|
- $ref: spi-peripheral-props.yaml
|
|
|
|
required:
|
|
- compatible
|
|
- reg
|
|
|
|
allOf:
|
|
- if:
|
|
not:
|
|
required:
|
|
- spi-slave
|
|
then:
|
|
properties:
|
|
"#address-cells":
|
|
const: 1
|
|
else:
|
|
properties:
|
|
"#address-cells":
|
|
const: 0
|
|
|
|
additionalProperties: true
|
|
|
|
examples:
|
|
- |
|
|
spi@80010000 {
|
|
#address-cells = <1>;
|
|
#size-cells = <0>;
|
|
compatible = "fsl,imx28-spi";
|
|
reg = <0x80010000 0x2000>;
|
|
interrupts = <96>;
|
|
dmas = <&dma_apbh 0>;
|
|
dma-names = "rx-tx";
|
|
|
|
display@0 {
|
|
compatible = "lg,lg4573";
|
|
spi-max-frequency = <1000000>;
|
|
reg = <0>;
|
|
};
|
|
|
|
sensor@1 {
|
|
compatible = "bosch,bme680";
|
|
spi-max-frequency = <100000>;
|
|
reg = <1>;
|
|
};
|
|
};
|